Re: [saag] Pinning

[Steven Bellovin <[e-mail]>]

On Jun 5, 2012, at 3:55 PM, Sean Turner wrote:

> All,
> 
> There are many proposals for how to say which key or certificate or trust anchor should be used by the client in a TLS session that it is about to open. These proposals include making that decision in the DNS (https://datatracker.ietf.org/doc/draft-ietf-dane-protocol/), in the application after TLS has happened once, to be remembered in the future (https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/), and in the TLS handshake (https://datatracker.ietf.org/doc/draft-perrin tls-tack/). If more than one of these protocols are deployed, operational mistakes could lead to a client getting conflicting information.
> 
> Similarly, there are also proposals on how to say whether or not a client should expect to see a particular service running under TLS. These proposals include making that indication in the DNS (draft hoffman-server-has-tls, expired but might be revived) and in the application after TLS has happened once, to be remembered in the future (https://datatracker.ietf.org/doc/draft-ietf-websec-strict-transport sec/). If more than one of these protocols are deployed, operational mistakes could lead to a client getting conflicting information.
> 
> Is a standards-track operations statement needed to describe the choices that a TLS server administrator has, and to deal with conflicts between the proposals?

It strikes me more as BCP material.  If there are multiple standards,
what's needed is advice on how to choose amongst them, rather than a
standards track document that says "ignore these other standards track
RFCs and use this other one instead."



		--Steve Bellovin, https://www.cs.columbia.edu/~smb