On 2/19/11 8:21 PM, Scott Schmit wrote:
> Some of these are nits, some not:

And all are appreciated.

> Abstract:
> ---------
>
>>   TLS and DTLS use certificates for authenticating the server.  Users
>>   want their applications to verify that the certificate provided by
>>   the TLS server is in fact associated with the domain name they
>>   expect.  Instead of trusting a certification authority to have made
>              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>   this association correctly, the user might instead trust the
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>   authoritative DNS server for the domain name to make that
>>   association.  This document describes how to use secure DNS to
>>   associate the TLS server's certificate with the the intended domain
>>   name.
>
> I would argue that in DNSSEC, each zone operator is a CA, just not a
> PKIX CA.

I would disagree. It is a trust anchor, not a certification authority. 
Yes, most users today don't understand the difference, but we should 
still be fairly precise in our language because some do. In specific, 
certification authorities do many things that are unimportant to most 
users but are definitely not done by zone operators. For example, zone 
operators probably do not do proof-of-possession checks for the the 
private key paired to the public key in the certificate, whereas most 
CAs do.

>
> How does this sound instead?
>
>     TLS and DTLS use certificates for authenticating the server.  Users
>     want their applications to verify that the certificate provided by
>     the TLS server is in fact associated with the domain name they
>     expect. DNSSEC provides a mechanism for a zone operator to sign DNS
>     information directly.  This way, bindings of keys to domains are
>     asserted not by external entities, but by the entities that operate
>     the DNS.  This document describes how to use secure DNS to associate
>     the TLS server's certificate with the the intended domain name.
>
> (I used the text from the charter, I figured that's the least
> controversial option).

That new text seems fine, and does not assert that DNS operators are CAs 
:-). Having the abstract actually use the words from the charter also 
seems like a good idea.

> Section 2.2:
> ------------
>
> I'm not the first to mention this, but I think the overlap between the
> certificate type and hash type is a bad idea. It allows nonsensical
> combinations to be expressed with all the problems that go with it.
>
> It would make much more sense for the certificate type to only indicate
> the kind of certificate that is referenced, and the second field
> indicates how that reference is formatted in the RDATA. This would
> change the text to something like:
>
>     o  A one-octet value, called "certificate type", specifying the
>        provided association that will be used to match the target
>        certificate.  This will be an IANA registry in order to make it
>        easier to add additional certificate types in the future.  The
>        types defined in this document are:
>
>           1 -- An end-entity certificate
>
>           2 -- A certification authority's certificate
>
>     o  A one-octet value, called "reference type", specifying how the
>        certificate association is presented.  This value is defined in a
>        new IANA registry.  The types defined in this document are:
>
>           0 -- Full certificate in DER encoding
>
>           1 -- SHA-1 hash of the certificate in DER encoding
>
>           2 -- SHA-256 hash of the certificate in DER encoding
>
>           3 -- SHA-384 hash of the certificate in DER encoding
>
>        Using the same hash algorithm as is used in the signature in the
>        certificate will make it more likely that the TLS client will
>        understand this TLSA data.
>
> Unless these are all MUSTs, the document needs to indicate which are
> required and which are not.

Hrm. I like the addition of the 0 type for reference type; it definitely 
solves the silly-state problem. Given that this is an on-the-wire 
change, it needs to be discussed more. I have opened issue #20 for it.

> Section 3:
> ----------
>
> Should "If the application receives zero usable certificate
> associations, it processes TLS in the normal fashion." be a MUST?

It could be, but it doesn't need to be, because that is already covered 
in the TLS spec.

> The last statement in section three should probably be:
>
> "If no match between the usable certificate association(s) and the
> server's end entity certificate in TLS is found, the TLS client MUST
> abort the handshake with an "unknown_ca" error."
>
> This adds "usable" to make clear the distinction between this and the
> "continue as usual" case.

Good catch. Fixed.

> Also, I changed access_denied to unknown_ca.
> According to RFC 5246:
>
>>   unknown_ca
>>      A valid certificate chain or partial chain was received, but the
>>      certificate was not accepted because the CA certificate could not
>>      be located or couldn't be matched with a known, trusted CA.  This
>>      message is always fatal.
>>
>>   access_denied
>>      A valid certificate was received, but when access control was
>>      applied, the sender decided not to proceed with negotiation.  This
>>      message is always fatal.
>
> To me, unknown_ca looks like the correct error -- DANE is about allowing
> DNSSEC to redefine what the trusted CAs are.

However, unknown_ca requires that a chain or partial chain be received, 
and one might not have been sent. For access_denied, you don't need a chain.

> Section 4.2/4.3:
> ----------------
>
> Value 255 is unspecified. Is this a typo, or was that intended to be
> reserved as experimental?

The latter, and yet we forgot to add that to the draft. FWIW, I strongly 
prefer "private use" to "experimental". Fixed in the next version.

> We need to specify which algorithms are required, optional, etc.

Yes we do, but people wanted to push that off to later. I think it is 
still good to delay it until we are sure about the format and so on. I 
have opened this as issue #21 on the tracker.

> I don't think the registry policies are sufficiently restrictive to
> prevent using up the available space. At minimum it should require
> expert review if not IETF Review. Otherwise, the only limitation on
> registration is an independent RFC.

There has been a not great track record with "expert review" for 
registries that have only occasional additions. (Ask Phill about his 
long-delayed request for a new RRtype...)

> Just to demonstrate how quickly the hash type (or whatever it turns
> into) could be used up, NIST is currently holding a competition to
> decide what algorithm will become SHA-3. They are now on their final
> round of competition, and there are no further opportunities for tweaks
> to the algorithms. So, all those algorithms are permanent and readily
> available.

That is an overstatement. NIST has made it clear that it might make 
changes in whatever algorithm it decides.

> So how many would that take up? I count 29 (4 BLAKE, 4 Groestl, 4
> Keccak, 4 JH, 13 Skein). Throw in SHA-224, SHA-512 (from FIPS-180-3),
> SHA-512/224, SHA-512/256 (from FIPS-180-4 once it's finalized), MD5, and
> the existing entries from dane-04, and you have 37 entries--about 1/7th
> of the available space.

And yet none of the SHA-3 candidates have been proposed as hash 
algorithms for this protocol (or any IETF protocol that I know of).

If the registry starts to fill up, the IETF can decide to tighten the 
registration rules at that time. There is no need to over-tighten now.

> Section 5:
> ----------
>
> You have two references to just A records and three to A/AAAA records.
> That's probably incomplete editing to change them all to the latter.

Good catch; done.

> Also, I don't understand this paragraph:
>
>>   A DNS administrator who goes rogue and changes both the A and TLSA
>>   records for a domain name can cause the user to go to an unauthorized
>>   server that will appear authorized, unless the client performs
>>   certificate validation and rejects the certificate.  That
>>   administrator could probably get a certificate issued anyway, so this
>>   is not an additional threat.
>
> What certificate validation is the client going to do that would detect
> this attack?

There is none. The Security Considerations section is for all 
considerations, not just ones that can be easily caught.

> The good news about this kind of attack is that it can be detected (by
> machine, admittedly) since all the certificates/associations are
> published in the DNS (unlike a rogue PKIX CA).

*Might* be caught: an attacker can give different answers to different 
DNS requests. This seems too far down the rathole to want to write 
about, I think, but others might want it.

> Maybe this is a lack of operational experience, but I'm not sure I
> understand why adding or changing TLSA information would be less
> protected than for A/AAAA records?

It isn't: they are identical.

> Hope this helps.

It does indeed. As we move through the open issues, it will be 
interesting to see how the WG feels about the new ones.