Re: Last Call: <draft-ietf-dnsop-onion-tld-00.txt> (The .onion Special-U

Hi Peter,

> I object to the publication of the above draft as Proposed Standard.
> The intended registration is incompatible with the registration policy
> laid out in RFC 6761 and is likely to create a false sense of security.
To deal with the latter, first:

The intended registration is not, and nowhere intends, to create any sense of 
security at all, let alone a false one.

The intended registration is meant as an enabler for the existing and ongoing 
population of onion space, and to enable the broad adoption of SSL certificates 
within that space.

It would be a broad and implausible assertion that SSL Certificates and HTTPS 
does not provide security for users of Web (and other) protocols, but to argue 
that the registration of “.onion” as a special use domain name would be equal 
to making the argument that the existence of “.com” as a registered TLD somehow 
engenders a false sense of security.

This latter point is arguable, I suppose, but the false sense of security 
engendered there would reside in DNS and not in the fact of registration.  :-)

> It is unclear what path is suggested by the IESG since the draft, other than
> RFC 6762 for the "local." TLD, does not contain a protocol specification.
The Tor protocol is controlled by Tor, and is apt to change; there is enough 
description there to explain how onion addresses are mechanically generated, 
but to tie the registration RFC to a specific implementation/version seemed 
unwise.


> It is my reading that any protocol eligible for a registration in the "Special
> Names" registry has to be an IETF Standards Track protocol - the grandfathered
> entries in that very registry nonwithstanding.  Any deliberations w.r.t. the
> Tor protocol are missing from the above draft and the Last Call message.
We are not seeking to register the protocol.  We are seeking to register a 
namespace that the protocol uses.


> The "Special Names" registry does not offer any means to convey any particular
> behaviour, let alone differences between various reserved names.  It is more
> than brave to expect that non-supporting implementations would be able (or
> willing) to follow the SHOULDs in the first quoted block.

The advice received from IANA last night as part of the last call, suggests 
this:


> > However, one reviewer added the following:
> >
> > "My comment would be there is nothing in the IANA considerations regarding 
> > how IANA manages the root zone, although immediately prior it says:
> >
> > "'DNS Registries/Registrars: Registrars MUST NOT register .onion names; all 
> > such requests MUST be denied.'
> >
> > "I believe 'register' in this context is not sufficiently clear. Perhaps 
> > 'delegate' is intended? For example, normally for a reserved name IANA would 
> > keep a record in the root zone database to acknowledge this, but this could 
> > appear to prohibit keeping a record for this purpose. Further, my 
> > understanding is part of the reason for this whole I-D is to all SSL 
> > certificate vendors (which are often DNS registries/registrars) to allow 
> > registration of SSL certificates for .onion names. I would say a plain 
> > reading of this may prohibit that. I would suggest there be an explicit 
> > additional category that makes it clear it expects service providers, such 
> > as trust providers, for to support .onion domains in such applications."

…so this suggestion - which myself and Jacob Appelbaum (the authors) warmly 
wish to adopt - would lead to “.onion” being reserved and not delegated, but 
also clearly documented as a space in which SSL certificates are to be issued.  
I think that would aid the goals we’ve sought to describe in the draft.


> It remains to be specified how these "generated" responses would interact
> with DNSSEC validation.  Again, it is unclear how agnostic (as of today)
> recursive resolvers would learn about the new name and apply specific 
> behaviour to it.
I think the IANA proposition would mean that DNSSEC would cease to be an issue, 
but perhaps you would like to suggest some alternative wording for us to 
consider?


> The draft does not explain why it asks for a "special name" at the top level.
> Neither the draft nor the Last Call document or envision any coordination
> with the responsible body as per the MoU RFC 2860.

I believe that that was dealt with extensively in DNSOP.  Mark?


    -a


—
Alec Muffett
Security Infrastructure
Facebook Engineering
London

signature.asc
Description: Message signed with OpenPGP using GPGMail