[websec] separate pinning header (was: Pinning and beyond...)

[=JeffH <[e-mail]>]

from <https://tools.ietf.org/html/draft-evans-palmer-hsts-pinning-00> :

 > 6.5. Pinning Without Requiring HTTPS
 >
 >    Some host operators would like to take advantage of certificate
 >    pinning without requiring HTTPS, but having clients require pins in
 >    the event that they do connect to the host with HTTPS.  As specified
 >    above, the current HSTS-based mechanism does not allow for this:
 >    clients that receive the pins directive via HSTS will also therefore
 >    require HTTPS -- that is the purpose of HSTS after all.  To have an
 >    additional directive, e.g. mode=optional, would not work because
 >    older clients that support HSTS but not the mode extension would
 >    effectively require HTTPS.
 >
 >    Alternatives include (a) putting the pins directive in a new header
 >    instead of extending HSTS; and (b) some kind of hack like setting
 >    maxAge=0 and having an additional directive to keep the pins alive
 >    (e.g. pinMaxAge).  These alternatives seem ugly to us and we welcome
 >    suggestions for a better way to support this deployment scenario.

In this thread..

  Re: [websec] Pinning and beyond Was: Next rev of HSTS certificate
  pinning draft (Tobias Gondrom)
  https://www.ietf.org/mail-archive/web/websec/current/msg00593.html

..several folks make the argument for option (a) putting the pins directive in 
a new header instead of extending HSTS, which I'm tending to agree with. It 
seems to be the cleanest approach overall.


If we had a header that looks like..

   PINS: max-age=n; pin=...; pin=...; ...

..and assuming we're not using the pin-break-verifier-and-code mechanism (as 
discussed in another thread ("breaking pins")), then a UA could manage pins 
using these steps:

     If UA connects (over TLS and without TLS errors/warnings) to
     previously-unpinned TLS host, and receives correct PIN header with
     max-age > 0, then UA notes host as Known Pinned Host.

     If UA validly connects to Known Pinned Host (over TLS) and any info
     in returned PIN header differs from noted info, and header's
     max-age > 0, it notes the newer info. This means that if a formerly
     asserted pin fingerprint no longer appears, the UA removes that
     unmentioned pin fingerprint from the Known Pinned Host's metadata.
     If a new one appears, it adds it.

     If UA validly connects to Known Pinned Host (over TLS) and the
     received PIN header's max-age = 0, it unnotes (i.e. forgets) the
     host as a Pinned Host.


Thoughts?

=JeffH