>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 <turn...@ieca.com> > Subject: [saag] Pinning > Date: June 5, 2012 12:55:29 PM PDT > To: s...@ietf.org > > 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 > s...@ietf.org > https://www.ietf.org/mailman/listinfo/saag _______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
