headers
Alexey Melnikov | 5 Dec 2011 00:04
Favicon

Re: Acceptance of draft-evans-palmer-key-pinning as a WG document

On 17/11/2011 09:01, Alexey Melnikov wrote:
> Dear WG participants,
>
> During the WebSec WG face-to-face meeting in Taipei there was room's 
> rough consensus to accept draft-evans-palmer-key-pinning as a WG 
> document. This is of course subject to confirmation on the WebSec 
> mailing list and this message is doing just that.
>
> Please state your preferences about accepting or rejecting this 
> document as a WG document before November 25th in reply to this 
> message, or directly to Tobias and myself.
To close the loop on this: I've seen several statement of support on the 
mailing list with nobody voicing opposition. There is WG consensus to 
accept the document and as you might have noticed a -00 version of the 
WG document was posted.

Best Regards,
Alexey, as a WebSec WG co-chair.
Permalink | Reply | 0 comments |
headers
Chris Palmer | 9 Dec 2011 03:25
Picon
Favicon

Re: Comments on draft-ietf-websec-key-pinning-00

On Tue, Nov 29, 2011 at 7:44 PM, Manger, James H
<James.H.Manger <at> team.telstra.com> wrote:

> First, nice work.

Thanks!

> > If the Public-Key-Pins response header field does not meet all three
> > of these criteria [error-free TLS; current key; backup pin], the UA MUST
> > NOT note the host as a Pinned Host,
> > and MUST discard any previously set Pinning Metadata for that host in
> > its non-volatile store.
>
> This seems to make it too easy for an attacker to force a UA to discard
> previously set pins for a host, removing the protection they offered. If an
> attacker inserts a Public-Key-Pins HTTP response header into an HTTP (not
> HTTPS) response from the server it will fail the 1st criteria (over an
> error-free TLS connection). Is that all it takes to turn off pinning for
> that host?

I think I can satisfy your concern by adding a sentence saying that
UAs MUST only pay attention to the Public-Key-Pins response header
field if the connection is over TLS. I think that is implicit now,
e.g. in the first criterion:

"""The UA MUST note the pins if and only if it received the
Public-Key-Pins response header field over an error-free TLS
connection."""

I'll change it to:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Manger, James H | 10 Dec 2011 15:30

Key pinning for DSA keys with inherited domain params

A DSA public key consists of an integer y, plus domain parameters p, q, and g. The domain parameters may be
included in a SubjectPublicKeyInfo value for the key in a certificate, but they may also be omitted if the
CA that issued the certificate uses the same domain parameters for its key. [See RFC 3279 Algorithms and
Identifiers for PKIX, section 2.3.2; http://tools.ietf.org/html/rfc3279#section-2.3.2]

This seems like a problem for key pinning as specified in draft-ietf-websec-key-pinning-01, where a pin
is the hash of a SubjectPublicKeyInfo value. My guess is that it is insecure for a pin to only cover y, but not
p, q, and g.

Without going back to the maths of DSA, I suspect an attacker can find another set of domain parameters and
private key that have the same public key (y) as a victim. This attacker key can have the same pin as the victim's.

I think the same issue applies to ECDSA and ECDH keys, and potentially other public key algorithms as well.

Possible solutions:

1. Say the pinning mechanism MUST NOT be used when a SubjectPublicKeyInfo value does not completely
specify the public key, such as when holding a DSA key without its domain parameters. This would be
acceptable if no one uses the inherit-parameters-from-the-CA option. I have no idea whether or not that
is true.

2. Define a special rule for each known algorithm that can inherit parameters (such as DSA): the domain
parameters MUST be added (from the CA cert, for instance) before calculating the pin. That is a bit of a
burden for all implementations.

--James Manger
Permalink | Reply | 7 comments |
headers
davidillsley | 11 Dec 2011 14:03
Picon

Feedback on draft-ietf-websec-key-pinning-01

Hi all,
It's good to see the progress in draft-ietf-websec-key-pinning-01. I'm still concerned about the impact
of pinning on non-pinned domains, and don't see anything present to warn about or mitigate this.
Apologies if I've missed discussion of this on-list/in the archives.

My concern centers on domains which aren't currently secured, and in the current environment (IMHO)
reasonably so e.g. news.bbc.co.uk  or theregister.co.uk

With pinning, if they lose control of their DNS*, visitors during that period can be HSTS+pinned to a
certificate which the domain owner has no access to, leading them open to long-term denial of service
(beyond reclamation of DNS) or extortion.

There's a variant with TLS enabled sites without pinning which could still be pinned to keys which the
domain owner doesn't have access to.

There are a few responses to this I can think of:

1. It's 2011/2012... everyone should be using TLS+HSTS+Pinning
2. It's fine - important sites will have decent pull with browser vendors to ship unlock pins...
3. Modify the spec to make the vulnerability smaller

1 may be a valid response, but in that case, I think the spec should call out this potential vulnerability in
section 3 and highlight that the only complete mitigation is to go to TLS+HSTS+Pinning. I think it's
important to call out to implementors this possibility, and that they might have to deal with something
like (2).

2 isn't really a solution and doesn't sit well as inevitably smaller sites won't have as good a pull with
vendors and could be disadvantaged. Also, I doubt the vendors really want to get into the game of
identifying this game.
(Continue reading)

Permalink | Reply | 14 comments |
headers
Paul Hoffman | 12 Dec 2011 01:38

A few comments on draft-ietf-websec-key-pinning

Greetings again. Alexey asked me to review draft-ietf-websec-key-pinning with an eye towards which
areas are likely to need more work. I hope the following comments are helpful.

- There needs to be an early balancing the advantages of pinning versus the disadvantages. A description of
the possible downsides should be at least partially listed in Section 1, with a pointer to the Security Considerations.

- Some of the significant disadvantages of pinning are not covered. The biggest of these (although I could
be wrong) is that an MITM can start using the pinning header with a long max-age before the "real" site has
used the pinning header. When the user finally gets to the "real" site, they will not connect to it because
of the MITM's pin, giving the MITM a second attempt to come back later. There are probably some other nasty
consequences of this. 

- While hash agility is a good thing, the current draft's way of doing this is not the right way. I propose that
it instead be changed to "must be sha-256 or sha-384, and later algorithms can be added only by an RFC
updating this document".

- The first paragraph of Section 3 should have its own sub-head to clarify that it is not superior to the text
in Section 3.1. But, more importantly, Section 3 needs to list the areas where this protocol gives an MITM
better attacks than they have now, and should list those first.

Early nit: The first paragraph of Section 1 makes it sound like the pinning header "does not scale"; this is
clearly not what is intended.

--Paul Hoffman
Permalink | Reply | 11 comments |
headers
Stephen Farrell | 12 Dec 2011 01:53
Picon
Picon

Re: A few comments on draft-ietf-websec-key-pinning


One other thing...

I guess I wonder if the "ni" URI scheme thing [1] is really
useful for this or not. That was after all the reason for
the earlier discussion on this list. (I think.)

Note that I don't really mind if the answer is yes or no. I
do think that one way to use URIs to name things via hash
function outputs is a good thing, and that two or more ways
to do that would be a bad thing, but not all uses of hashes
to identify things need to use URIs and I'm not sure which
analysis applies here.

In any case, be good to decide that too.

S.

[1] http://tools.ietf.org/html/farrell-decade-ni-00

On 12/12/2011 12:38 AM, Paul Hoffman wrote:
> Greetings again. Alexey asked me to review draft-ietf-websec-key-pinning with an eye towards which
areas are likely to need more work. I hope the following comments are helpful.
>
> - There needs to be an early balancing the advantages of pinning versus the disadvantages. A description
of the possible downsides should be at least partially listed in Section 1, with a pointer to the Security Considerations.
>
> - Some of the significant disadvantages of pinning are not covered. The biggest of these (although I could
be wrong) is that an MITM can start using the pinning header with a long max-age before the "real" site has
used the pinning header. When the user finally gets to the "real" site, they will not connect to it because
(Continue reading)

Permalink | Reply | 0 comments |
headers
Yoav Nir | 12 Dec 2011 15:57
Picon
Favicon

Re: A few comments on draft-ietf-websec-key-pinning


On Dec 12, 2011, at 2:38 AM, Paul Hoffman wrote:

> Greetings again. Alexey asked me to review draft-ietf-websec-key-pinning with an eye towards which
areas are likely to need more work. I hope the following comments are helpful.
> 
> - There needs to be an early balancing the advantages of pinning versus the disadvantages. A description
of the possible downsides should be at least partially listed in Section 1, with a pointer to the Security Considerations.
> 
> - Some of the significant disadvantages of pinning are not covered. The biggest of these (although I could
be wrong) is that an MITM can start using the pinning header with a long max-age before the "real" site has
used the pinning header. When the user finally gets to the "real" site, they will not connect to it because
of the MITM's pin, giving the MITM a second attempt to come back later. There are probably some other nasty
consequences of this. 

Section 2.3 does say that pins must only be noted if they come over an error-free HTTPS connection, where the
chain contains the pinned SPKI. So the MITM would have to be able to take over the DNS (at least for a while) as
in the attack described by David on 11-Dec.
Maybe we can mitigate this with a version of this header (or another one) that says "no pins for the next x seconds"

> 
> - While hash agility is a good thing, the current draft's way of doing this is not the right way. I propose
that it instead be changed to "must be sha-256 or sha-384, and later algorithms can be added only by an RFC
updating this document".

A year from now, "sha-256" is going to be ambiguous. Better to say "sha2-256".

> 
> - The first paragraph of Section 3 should have its own sub-head to clarify that it is not superior to the text
in Section 3.1. But, more importantly, Section 3 needs to list the areas where this protocol gives an MITM
(Continue reading)

Permalink | Reply | 9 comments |
headers
Adam Langley | 12 Dec 2011 16:03
Picon
Favicon

Re: Key pinning for DSA keys with inherited domain params

On Sat, Dec 10, 2011 at 9:30 AM, Manger, James H
<James.H.Manger <at> team.telstra.com> wrote:
> 1. Say the pinning mechanism MUST NOT be used when a SubjectPublicKeyInfo value does not completely
specify the public key, such as when holding a DSA key without its domain parameters. This would be
acceptable if no one uses the inherit-parameters-from-the-CA option. I have no idea whether or not that
is true.

I believe that you're correct that this is a problem and I suggest
your solution (1): a public key pin cannot be formed if the SPKI is
incomplete when taken in isolation.

Cheers

AGL
Permalink | Reply | 6 comments |
headers
Paul Hoffman | 12 Dec 2011 16:06

Re: A few comments on draft-ietf-websec-key-pinning


On Dec 12, 2011, at 6:57 AM, Yoav Nir wrote:

> Section 2.3 does say that pins must only be noted if they come over an error-free HTTPS connection, where
the chain contains the pinned SPKI. So the MITM would have to be able to take over the DNS (at least for a
while) as in the attack described by David on 11-Dec.

I don't agree that the MITM must control the DNS for this attack to work. As long as the MITM can intercept the
TLS handshake, and the client isn't doing OCSP (or the MITM intercepts that too), using a rogue cert works;
thus the rogue pinning works as well.

> Maybe we can mitigate this with a version of this header (or another one) that says "no pins for the next x seconds"

That still doesn't deal with the site that hears about the pinning header after the MITM does.

> A year from now, "sha-256" is going to be ambiguous. Better to say "sha2-256".

Good point, and one that might be made on the SAAG list as well.

--Paul Hoffman
Permalink | Reply | 8 comments |
headers
Yoav Nir | 12 Dec 2011 16:19
Picon
Favicon

Re: A few comments on draft-ietf-websec-key-pinning


On Dec 12, 2011, at 5:06 PM, Paul Hoffman wrote:

> 
> On Dec 12, 2011, at 6:57 AM, Yoav Nir wrote:
> 
>> Section 2.3 does say that pins must only be noted if they come over an error-free HTTPS connection, where
the chain contains the pinned SPKI. So the MITM would have to be able to take over the DNS (at least for a
while) as in the attack described by David on 11-Dec.
> 
> I don't agree that the MITM must control the DNS for this attack to work. As long as the MITM can intercept the
TLS handshake, and the client isn't doing OCSP (or the MITM intercepts that too), using a rogue cert works;
thus the rogue pinning works as well.

The rogue cert works only if it validates. So the attacker will have to have compromised the CA as well.
Besides, one could argue that using a certificate without OCSP or checking the CRL is not "error-free",
but that would have to be clarified.

> 
>> Maybe we can mitigate this with a version of this header (or another one) that says "no pins for the next x seconds"
> 
> That still doesn't deal with the site that hears about the pinning header after the MITM does.

Agree, but it allows me to make my site safe from rogue pinning attacks now.

> 
>> A year from now, "sha-256" is going to be ambiguous. Better to say "sha2-256".
> 
> Good point, and one that might be made on the SAAG list as well.
>
(Continue reading)

Permalink | Reply | 1 comment |

Gmane