On Thu, Mar 12, 2015 at 12:35 AM, Moritz Bartl <moritz(a)torservers.net> wrote:
> (**) Nobody has actually proven that you can circumvent the read-only
> bit and simply write with modified kernel drivers ("please don't write
> ...
> The (micro)SD exposes registers for permanent write protection (cannot
> be undone) and temporary write protection. If you set TMP_WRITE_PROTECT
> and expose the SD card as USB device (not as mmc card), the registers
> cannot be accessed from the host, so they cannot be changed. For an
> example of this, see https://github.com/Nephiel/sdlocker-tiny . Maybe
> there's a nice little SD card USB reader with a firmware that can be
> patched for this.
I wish to look at this further, but if these are normal mmc / usb / ata / scsi
commmand opcodes (not actually requiring a physical burning interface),
than you can do this commands over camcontrol freebsd or maybe
[h|s]dparm linux without special dongle.
https://www.ietf.org/id/draft-appelbaum-dnsop-onion-tld-00.txt
dnsop J. Appelbaum
Internet-Draft Tor Project Inc.
Intended status: Standards Track A. Muffett
Expires: September 6, 2015 Facebook
March 5, 2015
The .onion Special-Use Domain Name
draft-appelbaum-dnsop-onion-tld-00
Abstract
This document registers the ".onion" Special-Use Domain Name.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 6, 2015.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 2
2. The ".onion" Special-Use TLD . . . . . . . . . . . . . . . . 2
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . 3
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Normative References . . . . . . . . . . . . . . . . . . 5
5.2. Informative References . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
The Tor network [Dingledine2004] has the ability to host network
services using the ".onion" Top-Level Domain. Such addresses can be
used as other domain names would be (e.g., in URLs [RFC3986]), but
instead of using the DNS infrastructure, .onion names are hashes that
correspond to the identity of a given service, thereby combining
location and authentication.
In this way, .onion names are "special" in the sense defined by
[RFC6761] Section 3; they require hardware and software
implementations to change their handling, in order to achieve the
desired properties of the name (see Section 4). These differences
are listed in Section 2.
Like other TLDs, .onion addresses can have an arbitrary number of
subdomain components. This information is not meaningful to the Tor
protocol, but can be used in application protocols like HTTP
[RFC7230].
See [tor-address] and [tor-rendezvous] for the details of the
creation and use of .onion names.
1.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. The ".onion" Special-Use TLD
These properties have the following effects upon parties using or
processing .onion names (as per [RFC6761]):
1. Users: human users are expected to recognize .onion names as
having different security properties, and also being only
available through software that is aware of onion addresses.
2. Application Software: Applications that implement the Tor
protocol MUST recognize .onion names as special by either
accessing them directly, or using a proxy (e.g., SOCKS [RFC1928])
to do so. Applications that do not implement the Tor protocol
SHOULD generate an error upon the use of .onion, and SHOULD NOT
perform a DNS lookup.
3. Name Resolution APIs and Libraries: Resolvers that implement the
Tor protocol MUST either respond to requests for .onion names by
resolving them (see [tor-rendezvous]) or by responding with
NXDOMAIN. Other resolvers SHOULD respond with NXDOMAIN.
4. Caching DNS Servers: Caching servers SHOULD NOT attempt to look
up records for .onion names. They SHOULD generate NXDOMAIN for
all such queries.
5. Authoritative DNS Servers: Authoritative servers SHOULD respond
to queries for .onion with NXDOMAIN.
6. DNS Server Operators: Operators SHOULD NOT configure an
authoritative DNS server to answer queries for .onion. If they
do so, client software is likely to ignore any results (see
above).
7. DNS Registries/Registrars: Registrars MUST NOT register .onion
names; all such requests MUST be denied.
3. IANA Considerations
This document registers the "onion" TLD in the registry of Special-
Use Domain Names [RFC6761]. See Section 2 for the registration
template.
4. Security Considerations
.onion names are often used provide access to end to end encrypted,
secure, anonymized services; that is, the identity and location of
the server is obscured from the client. The location of the client
is obscured from the server. The identity of the client may or may
not be disclosed through an optional cryptographic authentication
process.
These properties can be compromised if, for example:
o The server "leaks" its identity in another way (e.g., in an
application-level message), or
o The access protocol is implemented or deployed incorrectly, or
o The access protocol itself is found to have a flaw.
.onion names are self-authenticating, in that they are derived from
the cryptographic keys used by the server in a client verifiable
manner during connection establishment. As a result, the
cryptographic label component of a .onion name is not intended to be
human-meaningful.
The Tor network is designed to not be subject to any central
controlling authorities with regards to routing and service
publication, so .onion names cannot be registered, assigned,
transferred or revoked. "Ownership" of a .onion name is derived
solely from control of a public/private key pair which corresponds to
the algorithmic derivation of the name.
Users must take special precautions to ensure that the .onion name
they are communicating with is correct, as attackers may be able to
find keys which produce service names that are visually or apparently
semantically similar to the desired service.
Also, users need be aware of the difference between a .onion name
used and accessed directly via Tor-capable software, versus .onion
subdomains of other TLDs and providers (e.g., the difference between
example.onion and example.onion.tld).
The cryptographic label for an .onion name is constructed by hashing
the public key of the service with SHA1, truncating the output of the
hash to 80 bits in length and the resulting hash output is
concatenated with the string ".onion". As the number of output bits
in generating the .onion name is less than the full size of the
corresponding public key, an attacker may also be able to find a key
that produces a collision with the same .onion name with
substantially less work than a cryptographic attack on the full
strength key. If this is possible the attacker may be able to
impersonate the service on the network.
If client software attempts to resolve a .onion name, it can leak the
identity of the service that the user is attempting to access to DNS
resolvers, authoritative DNS servers, and observers on the
intervening network. This can be mitigated by following the
recommendations in Section 2.
5. References
5.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
RFC 6761, February 2013.
5.2. Informative References
[Dingledine2004]
Dingledine, R., Mathewson, N., and P. Syverson, "Tor: the
second-generation onion router", 2004, <https://www.onion-router.net/Publications/tor-design.pdf>.
[RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and
L. Jones, "SOCKS Protocol Version 5", RFC 1928, March
1996.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005.
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", RFC 7230, June
2014.
[tor-address]
Mathewson, N. and R. Dingledine, "Special Hostnames in
Tor", September 2001,
<https://gitweb.torproject.org/torspec.git/plain/address-
spec.txt>.
[tor-rendezvous]
Mathewson, N. and R. Dingledine, "Tor Rendezvous
Specification", April 2014,
<https://gitweb.torproject.org/torspec.git/plain/rend-
spec.txt>.
Authors' Addresses
Jacob Appelbaum
Tor Project Inc.
Alec Muffett
Facebook
...
There is an event in DC about the Freedom of Information Act on March
13, 2015. There is also supposed to be a livestream of the conference
for anyone to watch online.
The Freedom of Information Act can be used by anyone to request records
from the US federal government. Many states and countries also have
their own public records laws which can be very useful for journalists
and researchers.
Link
http://www.newseum.org/event/2015-national-freedom-of-information-day-confe…
Copy/Past of Agenda
2015 National Freedom of Information Day
March 13 – The Knight Studio at the Newseum
8:15 - 8:30 a.m. Welcome:
Gene Policinski, Chief Operating Officer, Newseum Institute
Patrice McDermott, Executive Director, OpenTheGovernment.org
8:30 - 9:10 a.m. Speaker: Miriam Nisbet, former director of
Office of Government Information Services, National Archives
9:10 – 9:15 a.m. BREAK
9:15 – 10:50 a.m. Sunshine Week at ‘10’ – and in 2015
Presented by Reporters Committee for Freedom of the Press,
American Society of News Editors and Sunshine in Government Initiative
Remarks: Rick Blum, Executive Director, Sunshine in Government Initiative
Moderator: Andy Alexander, Visiting Professional, E.W. Scripps School
of Journalism, Ohio University
Panelists: Pete Weitzel, former editor, The Miami Herald; former
executive director, Coalition of Journalists for Open Government
Deb Gersh Hernandez, Communications Director, Reporters Committee for
Freedom of the Press and co-coordinator, Sunshine Week
Megan Rhyne, Executive Director, Virginia Coalition for Open Government
SW- 2015
Moderator: Kevin Hall, Chief Economics Correspondent, McClatchy Newspapers
Presenters: Brian Carovillano, Vice President and Managing Editor, U.S.
news, The Associated Press
Bill Sternberg, Deputy Editorial Page Editor, USA TODAY
10:50 - 11 a.m. BREAK
11 a.m. - 12:45 p.m. Open Government: Successes, Challenges, Prospects
Presented by OpenTheGovernment.org
Moderator: Sean Moulton, Director, Open Government Policy, Center
for Effective Government
Panelists: Sean Vitka, Federal Policy Manager, Sunlight Foundation
Tom Blanton, Director, National Security Archive
Shanna Devine, Legislative Director, Government Accountability Project
Miriam Nisbet Former Director, OGIS
Eric Mill, 18F Project, General Services Administration
Respondents
Moderator: Joe Goldman, President, Democracy Fund
Prof. Bruce Cain, Professor of Political Science, Stanford University
(via Skype)
Charles Clark, Senior Correspondent, Government Executive Media Group
12:45 p.m. – 1:15 p.m. 2015 James Madison Award
Presented by the American Library Association
Remarks: Sari Feldman, ALA President-elect
Speaker: Madison Award winner (via video)
Concludes
----- Forwarded message from ron minnich <rminnich(a)gmail.com> -----
Date: Mon, 09 Mar 2015 03:06:07 +0000
From: ron minnich <rminnich(a)gmail.com>
To: coreboot <coreboot(a)coreboot.org>
Subject: [coreboot] Fwd: lowRISC in Google Summer of Code 2015
Message-ID: <CAP6exY+27t8R7sU552nf7aZTR_0jaP5kcmq3wOCPBV3zLv2+8Q(a)mail.gmail.com>
---------- Forwarded message ---------
From: lowRISC Announcements <list(a)ann.lowrisc.org>
Date: Sun, Mar 8, 2015 at 1:52 PM
Subject: lowRISC in Google Summer of Code 2015
To: <rminnich(a)gmail.com>
We're pleased to announce that lowRISC is taking part in Google Summer of
Code
as a mentoring organisation. We're working with a number of our friends in
the
wider free and open source software and hardware communities to provide a
range of project ideas in a number of different implementation languages
covering every level of the hardware/software stack. GSoC provides a stipend
of $5500 for selected students to work on open source over the summer.
Student applications open on Monday 16th March. For more information, see
the
GSoC FAQ
<https://www.google-melange.com/gsoc/document/show/gsoc_
program/google/gsoc2015/help_page>.
The full lowRISC ideas list is available here
<http://www.lowrisc.org/docs/gsoc-2015-ideas/>, and the titles are listed
below. We're also very interested in student-proposed ideas. Massive thanks
are due to everyone who has volunteered to mentor.
* A fully open source FPGA compilation flow using Yosys
* Accessing the OpenCores ecosystem (implementing a Wishbone to TileLink
bridge)
* jor1k port to RISC-V
* Extend Tavor to support directed generation of assembly test cases
* Constrained randomised testing with coverage tracking in Cocotb
* TCP offload to minion cores using rump kernels
* Schematic Viewer for Netlists (SVG/JavaScript)
* Porting Icarus Verilog to JavaScript using Emscripten
* Optimized ray tracer for Nyuzi parallel processor
* Porting musl libc to RISC-V
* LLVM pass for control-flow hijacking protection using lowRISC’s tagged
memory
* Porting L4/FIASCO.OC to RISC-V
* Adding Chisel support to FuseSoC
* Trace Debugging Infrastructure for lowRISC
* OCaml native code port to RISC-V
* JTAG hardware debugging support for Nyuzi
Even if you're not a student, we'd appreciate your help in spreading the
word
to ensure we get the best possible applicants. As ever, we invite you to
subscribe to the lowrisc-dev discussion list
<http://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/lowrisc-dev-lists.lowrisc.org>,
idle on #lowRISC on irc.oftc.net, and follow @lowRISC on Twitter.
-- The lowRISC team
------
If you wish to unsubscribe, click http://subscribe.lowrisc.org/
unsubscribe?email=rminnich%40gmail.com&secret=e66ba8262f518ffbe2fb50edd82c61
f0ed8f5c6a
--
coreboot mailing list: coreboot(a)coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
----- End forwarded message -----
