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". 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". --Paul Hoffman
Received on Tuesday, 20 May 2014 15:27:16 UTC