> 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
