I have just submitted an updated version of the session continuation draft.

Hi,

I would like to discuss a possible vulnerability in Public Key Pinning scheme (http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/ ), related to certificate revocation checking. I would appreciate if anybody can review and verify my observations.

Section 2.6 the draft states that when the UA connects to a pinned host, it must terminate the TLS connection, if there are any errors. The referred rfc, RFC 6797, clarifies that error could be related to certificate revocation checking or server identity checking.

But it is not mandatory that during TLS handshake, UA performs certificate revocation or an assertive answer is found about the revocation status of the certificate. The reasons could be:

1.      OCSP is disabled by default at the UA and the user has not changed it.

2.      OCSP checking is disabled by the user.

3.      OCSP check is performed but no answer is obtained from the OCSP server within the stipulated timeout.

So it is very much possible that the UA accepts the PKP header from the host without verifying the revocation status of the host certificate used in TLS handshake.

In the case of the host losing its private key to an attacker, the attacker may be able to block the host permanently from connecting to the UA, as explained below. The host’s CA would have revoked the certificate but the unreliability in revocation checking creates a vulnerability.

Suppose an attacker is in possession of the private key of the host and the host certificate is duly revoked by the issued CA. Attacker may succeed in diverting the UA to his server when UA tries to connect to the valid host. Attacker may mount a DNS attack or a MIM attack to achieve this. Since he posses the valid private key, the TLS connection will be successful. The only other thing he needs is that UA doesn’t get to know the revocation status of the certificate. Here, the attacker is able to make the UA accept whatever PKP headers sent in the HTTP response.

Say, the attacker has two key pairs, KeyPair1 and Keypair2, and holds a valid certificate for KeyPair1.

He constructs a PKP header,

Public-Key-Pins: max-age= (maximum possible value);

               pin-sha1= (pin corresponding to compromised key);

               pin-sha1= (pin corresponding to KeyPair1);

When UA accepts this PKP header, effectively the attacker is able to set a new backup pin.

The attacker can set a new PKP header in subsequent connection. He can use KeyPair1 in the TLS handshake.

Public-Key-Pins: max-age= (maximum possible value);

               pin-sha1= (pin corresponding to KeyPair1);

               pin-sha1= (pin corresponding to KeyPair2);

Now the UA sets both pins to be attacker’s pins and the valid host is permanently blocked from connecting to the UA.

To avoid this attack, shouldn’t we mandate revocation checking when PKP headers are accepted?

Thanks,

Vinod.

I have reviewed this draft, and here are some comments.

Section 2.1 last paragraph says that the hash function MUST be sha1 or sha256. This is weird. First it provides no algorithm agility, so adding support for, say, SHA-3 would require a document that updates this one (section 2.4 says so explicitly). Second, SHA2-256 is slower on 64-bit platforms than SHA2-512, so right now some may prefer it. Third, in various locales, some other hash function might be required, such as GOST-34.311-95. I would much prefer that we referred to a registry of hash names ( perhaps this one ), and allow anything from there (notably, it doesn't solve the GOST issue). There should be implementation advice advising support of SHA-1 and SHA-256, perhaps even calling them "mandatory to implement", but I don't think we need to require a new spec for updating a list of algorithms. It might also be good to advise on using the same hash algorithm that is used in the signature of the certificate, as the client would be sure to be able to calculate the hash function (or it wouldn't be able to verify the certificate signature.

Some of the mandates in section 2 are mixed up. Section 2.2.1 second sentence has "… UAs MUST treat the host …" - clearly a UA mandate. But this is part of section 2.2 ("Server Processing Model").  UA mandates should be somewhere under section 2.3 ("User Agent Processing Model"). Some cleaning up is needed there.

Section 2.6 requires the same no-error-or-block behavior here as in HSTS. I wonder if we need this level of strictness, or whether requiring this only for errors involving the verification of pins. IOW, should this document require that expired certificates cause a block, when such policy can and should be communicated via HSTS?

Section 2.8 is about pinning self-signed (or self-issued) certificates. Should mention DANE (RFC 6698) type 2 or 3, because those are a more trust-worthy case than normal self-signed or self-issued certificates.

Section 4 (security considerations) should have something about why it's wrong to use this header without HSTS. 3rd paragraph of section 1 says that using them together is intended, so we should explain why.

Section 5: yes, there are actions for IANA, as they allocate HTTP headers (other than X-something).  See the text from draft -14 of HSTS:

15. IANA Considerations

Below is the Internet Assigned Numbers Authority (IANA) Permanent Message Header Field registration information per [RFC3864]. Header field name: Strict-Transport-Security Applicable protocol: HTTP Status: standard Author/Change controller: IETF Specification document(s): this one

A more structural note: The introduction looks a little thin to me. The draft dives into syntax in section 2 before the reader has any idea:

• When and why you should want to add this header to your web server responses. What is this defending against
• Why you would want to pin an end-entity key, and alternatively why you would want to ping something higher up the chain
• What does it mean when there are multiple pins. AND? OR?

The third question is answered later in the draft, but I think this information should go in the introduction.

And one nit:

• The upper-case SHOULD in the introduction seems inappropriate. RFC 2119 labels SHOULD (not sure this is even a pun) be used for cases of interoperability or for preventing harm. Here, the use is the simple English "should", and doesn't mandate anything at all, so it ought to be lower-case:
  "We propose a new HTTP header to enable a web host to express to user agents (UAs) which Subject Public Key Info (SPKI) structure(s) UAs *should* expect to be present in the host's certificate chain in future connections using TLS (see [RFC5246]).

Note: this review is with no hats. It is not part of some last-call process. Please treat this as any other review on the list.

Yoav