- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Tue, 20 May 2014 09:54:22 -0700
- To: Paul Hoffman <paul.hoffman@gmail.com>
- Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
On 20 May 2014 08:26, Paul Hoffman <paul.hoffman@gmail.com> wrote: > The new material on what might be called "alternate service pinning" has the > advantages and faults of any of the security pinning protocols that the IETF > makes. Please note how tortured the key pinning discussion in the websec WG > has become; there is no reason why alternate service pinning will be any > easier. This isn't to say that you shouldn't do it, just that you should > expect it to be a protracted and sometimes circular discussion full of "but > what if; so the protocol now has to". The hope was to attract some of the expertise in the hopes that that would help avoid all of the torture. > Separately, the text in Section 4 concerns me because it seems easy to > mis-implement. That is, the API flag that says "this connection is/isn't > running under authenticated TLS" becomes critical; it is even more important > than the API flag for "this connection is/isn't running under TLS". Please > consider calling this out more strongly in Section 4, and add it to the > Security Considerations. Encouraging developers to have a unit test for > "start a connection with unauthenticated TLS and then then try to request an > https: resource and make sure that fails". The idea that TLS == security is one that has been very well socialized. The education programme has been very effective. So yes, I get your point. Maybe there's a case for further highlighting the distinction we want to retain, at least at the broadest level of generality: https == secure, http == not. That is the point of Section 6.1, but I might be convinced that repetition of this is necessary.
Received on Tuesday, 20 May 2014 16:54:50 UTC