Re: [websec] Review of draft-evans-palmer-hsts-pinning-00

[Tom Ritter <[e-mail]>]

I'm excited about this draft.

> >    Note that to validate pins, UAs must necessarily read the headers of
> >    a response.
> [5] response = HTTP response?
> This implies that the pin check machinery is up at the HTTP layer rather than down lower in or near the TLS layer, which implies that the UA can make normal HTTP requests to a bogus Known Pinned Host, and send cookies, before realizing that the pin check has failed.
> This is a fundamental security issue.

I don't think this is worded correctly.

If a site is a Known Pinned Host, the pin check should occur after
recieving the certificate chain, but before the TLS session is wholly
established.  If this check does not pass, the connection is
aborted.[1]

If a pin check occured at the HTTP layer and does occur after a TLS
session has been established, data was sent by the client, and the
response received - I see only two things that could happen that would
be 'new' to the User Agent.

1) 'Oh, this site supports pinning.  I didn't know that.  I'll note it
down as a Known Pinned Host.  Let me check the pins just to be sane.'
This check wouldn't actually provide any security (that's what
preloading is for) - if the pins didn't match, either the server is
messed up or the attacker was incompetant because they could have
changed the pins.
2) 'I just recieved an unpin directive for the certificate I just used
to connect.' This is again a case of the server being messed up. [2]

So I think the existing wording is wrong, and better wording would be
something like:

Upon receipt of this header field, the UA will note the HSTS Host as a
Known Pinned HSTS Host if it was previously not.  When connecting to a
Known Pinned HSTS Host, the UA will compare the public key
fingerprint(s) in the Host's certificate chain to the pinned
fingerprints, and will fail closed before sending a HTTP request
unless at least one public key in the chain has a fingerprint matching
one of the pinned fingerprints.  (Following the HSTS specification,
TLS errors for HSTS hosts must be hard, with no chance for the user to
click through any warnings or errors.  We treat fingerprint mismatch
in the same way.)

Where I added
 - "..will note the HSTS Host as a Known Pinned HSTS Host IF IT WAS
PREVIOUSLY NOT."
 - "...will fail closed BEFORE SENDING A HTTP REQUEST unless at least...".


[1] From an engineering perspective, perhaps the connection IS
established because that occurs in a modular library that does not
know of pinning, but the HTTP request would not be sent, because the
connection would be examined outside the library.

[2] Do we handle the case where Alice connects to a Known Pinned Site,
recieves a valid certificate, but the certificate is unpinned in the
Pinning Header?  I think this is an error case, because while the
initial connection is valid, any subsequent connections in the TLS
session were 'fruit of the poison tree' - made using an unpinned
certificate.  I also think behavior should be noted explictly.


I have an additional comment: this header field could grow quite
large.  Site operators may wish to omit it in the response in several
scenarios that indicate to them the client has recieved it already.  I
don't see a reason this would cause any issue, I'm just noting it.

-tom