Re: New Version Notification for draft-nottingham-http2-encryption-03.txt

[Martin Thomson <[e-mail]>]

On 20 May 2014 08:26, Paul Hoffman <[e-mail]> 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.