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

From: =JeffH <[email-masked]>
Date: Fri, 14 Oct 2011 15:05:13 -0700

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

---

From: Tom Ritter <[email-masked]>
Date: Fri, 14 Oct 2011 20:56:51 -0400

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

I agree.  Separating it into a header may also enable it to find its
way into other protocols that travel over TLS, and reuse some of the
same parsing/validation code.

-tom

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 15 Oct 2011 21:22:31 -0400

A big use case that we want to support for our apps is to be able to push
out security policy for domains that we know are being targeted.

We can't push out security policy for every site on the Web into clients but
we can easily cover the top 95% of targeted sites with a pretty short list
of policy statements.

And a huge sub case here would be to pull up security policy for an
employer's site for a company machine. This is done today with real utility
but its all proprietary.

But that really should be agile across multiple protocols. So for example,
HTTP, IMAP, POP3

On Fri, Oct 14, 2011 at 8:56 PM, Tom Ritter <[email-masked]> wrote:

> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec
>

-- 
Website: http://hallambaker.com/

---

From: Chris Palmer <[email-masked]>
Date: Mon, 17 Oct 2011 14:36:11 -0700

> same parsing/validation code.

Actually, there is nothing too HTTP-specific about HSTS as it exists
now, so you could conceivably use it in other header-having protocols.

I am ok with putting pins in their own header. I'll be rolling another
rev of the document and will send it around!

Thanks again, all.