Re: [saag] Pinning

On Tue, Jun 5, 2012 at 8:55 PM, Sean Turner <turners@ieca.com> 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.

You forgot Certificate Transparency :-)

http://www.links.org/files/CertificateAuthorityTransparencyandAuditability.pdf

> 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
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag