The way that the UKS attack is mitigated here is counter-intuitive. It is via inclusion of the *name* in the handshake transcript and validation of that name that we get the protection we need.
Victor is right to question this. This isn't a very obvious result and needs more text than a single simple sentence. On 23 March 2017 at 02:15, Viktor Dukhovni <[email protected]> wrote: > >> On Mar 22, 2017, at 10:56 AM, Melinda Shore <[email protected]> >> wrote: >> >> The draft could definitely benefit from >> additional review. > > Quick comment: > > 3.3. Raw Public Keys > > [RFC7250] specifies the use of raw public keys for both server and > client authentication in TLS 1.2. It points out that in cases where > raw public keys are being used, code for certificate path validation > is not required. However, DANE provides a mechanism for securely > binding a raw public key to a named entity in the DNS, and when using > DANE for authentication a raw key may be validated using a path > chaining back to a DNSSEC trust root. This has the added benefit of > mitigating an unknown key share attack, as described in > [I-D.barnes-dane-uks]. > > Binding raw public keys to a node in the DNS tree does not by itself > mitigate (or militate against) UKS attacks. Indeed with just a raw > public key there are no names to check in any server certificate, > so when the application (web browsing) is vulnerable to UKS, raw > public create an exposure to such attacks. > > However, the use of the "DNSSEC Authentication Chain Extension" > means that the server in fact cryptographically commits (because > the TLS handshake finished message commits both sides to the same > session transcript) to the DNS location (owner name) of its TLSA > records. So it is not DANE (RFC6698, RFC7671) that protects RPK > against UKS, but rather this draft! > > What "DNSSEC Authentication Chain Extension" does is effectively > augment RPK with the server's name that would otherwise be found > in the certificate, a reverse SNI if you like (but actually > stronger than names in certificates, because it also binds the > protocol and port). > > -- > Viktor. > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
