Subject: [dane] Fwd: [saag] Pinning

From: Paul Hoffman <[email-masked]>
Date: Tue, 5 Jun 2012 13:47:49 -0700

From the SAAG mailing list, but appropriate here. I bet that Sean would appreciate all discussion to go on on the SAAG mailing list...

Begin forwarded message:

> From: Sean Turner <[email-masked]>
> Subject: [saag] Pinning
> Date: June 5, 2012 12:55:29 PM PDT
> To: [email-masked]
> 
> 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?
> 
> spt
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag