Re: [websec] Comments on draft-ietf-websec-key-pinning

Hi Jeffrey-- I share your concerns about MitM attacks on the web, and I'm also not happy about the compromises made in HPKP about "locally-installed" trust roots, fwiw. But i don't think your arguments are helping. On Sat 2015-02-21 21:38:20 -0500, Jeffrey Walton wrote: > You'll have to forgive

Re: [websec] Comments on draft-ietf-websec-key-pinning

Thanks Ryan. >> I don't believe this proposal - in its current form - will prove >> effective in the canonical cases: (1) CA failure like Diginotar; and >> (2) MitM attacks like Superfish. Are there other obvious cases I >> missed that this control will be effective? > > You're factually wrong

Re: [websec] Comments on draft-ietf-websec-key-pinning

On Thu, February 19, 2015 11:38 am, Jeffrey Walton wrote: > I don't believe this proposal - in its current form - will prove > effective in the canonical cases: (1) CA failure like Diginotar; and > (2) MitM attacks like Superfish. Are there other obvious cases I > missed that this control will

Re: [websec] Comments on draft-ietf-websec-key-pinning

> Ryan's previous post already covered the reasons for disabling pin > validation for user-defined trust anchors, which still hold even though > Superfish did their superfish thing. That's not acceptable for two reasons. First, the user did not take an administrative action. Second, pinning is a c

Re: [websec] Comments on draft-ietf-websec-key-pinning

On Thu, Feb 19, 2015 at 9:43 AM, Jeffrey Walton wrote: > Quod erat demonstratum: > > http://arstechnica.com/security/2015/02/lenovo-pcs-ship-with-man-in-the-middle-adware-that-breaks-https-connections/ > > This proposal needs to be revisited. It has serious defects. Ryan's previous post already

Re: [websec] Comments on draft-ietf-websec-key-pinning

Quod erat demonstratum: http://arstechnica.com/security/2015/02/lenovo-pcs-ship-with-man-in-the-middle-adware-that-breaks-https-connections/ This proposal needs to be revisited. It has serious defects. On Fri, Jan 2, 2015 at 12:21 AM, Jeffrey Walton wrote: > I'd like to share some comments on >

Re: [websec] Comments on draft-ietf-websec-key-pinning

On Thu, January 1, 2015 9:21 pm, Jeffrey Walton wrote: > I'd like to share some comments on > https://tools.ietf.org/html/draft-ietf-websec-key-pinning-21. Hi Jeffrey, Though I see Yoav has already mentioned that these comments are well beyond the IETF LC phase, thus will not result in any chan

Re: [websec] Comments on draft-ietf-websec-key-pinning

Hi, Jeffrey Thanks for the review. However, if you look at the datatracker link ([1]), you’ll see that this draft has been approved by the IESG 2.5 months ago. Its publication as RFC is only waiting for a referenced document to be published. I’m afraid it’s too late now. Yoav [1] https://dat

[websec] Comments on draft-ietf-websec-key-pinning

I'd like to share some comments on https://tools.ietf.org/html/draft-ietf-websec-key-pinning-21. Pubic key pinning is an effective security control and I'm glad to see the IETF moving forward with it. And I'm especially thankful to Palmer and Sleevi for taking the time to put it together and sheph

Re: [websec] Comments on draft-ietf-websec-key-pinning-06

CAA does not require a central registry. But it does require CAs to decide what DNS name(s) they are going to use. For key pinning to work the Web Browsers are going to have to track the correspondence of name to roots in any case. So it basically becomes a consistency thing. If it makes sense to

Re: [websec] Comments on draft-ietf-websec-key-pinning-06

On Fri, Jun 28, 2013 at 8:00 AM, Phillip Hallam-Baker wrote: > CAA faced the problem of identifying a CA. > > During the evolution of the draft we went through pretty much every scheme > mentioned in this thread. In the end we decided to go with a domain name > that is asserted for that purpose by

Re: [websec] Comments on draft-ietf-websec-key-pinning-06

CAA faced the problem of identifying a CA. During the evolution of the draft we went through pretty much every scheme mentioned in this thread. In the end we decided to go with a domain name that is asserted for that purpose by the CA. So symantec.com / comodo.com / etc. At this point the main r

Re: [websec] Comments on draft-ietf-websec-key-pinning-06

On 26/06/13 08:13, Trevor Perrin wrote: > > On Mon, Jun 24, 2013 at 2:29 PM, Chris Palmer > wrote: > > If you haven't already, I'd urge everyone to take pcaps of a web > session to their bank or to their web mail provider or whatever. I > think you'll quickl

Re: [websec] Comments on draft-ietf-websec-key-pinning-06

On Mon, Jun 24, 2013 at 2:29 PM, Chris Palmer wrote: > If you haven't already, I'd urge everyone to take pcaps of a web > session to their bank or to their web mail provider or whatever. I > think you'll quickly see that even a large HPKP header, say 500 bytes, > is not going to be the thing that

Re: [websec] Comments on draft-ietf-websec-key-pinning-06

On Mon, Jun 24, 2013 at 6:30 PM, Tobias Gondrom wrote: > On 25/06/13 05:06, Trevor Perrin wrote: > > > On Mon, Jun 24, 2013 at 12:01 AM, Tobias Gondrom < > tobias.gond...@gondrom.org> wrote: > >> >> On 24/06/13 09:13, Trevor Perrin wrote: >> >> Depends on the number of pinned keys. Chrome's e

Re: [websec] Comments on draft-ietf-websec-key-pinning-06

On 25/06/13 05:06, Trevor Perrin wrote: > > On Mon, Jun 24, 2013 at 12:01 AM, Tobias Gondrom > mailto:tobias.gond...@gondrom.org>> wrote: > > > On 24/06/13 09:13, Trevor Perrin wrote: >> Depends on the number of pinned keys. Chrome's existing preloads >> [1] have 9, 5, 19, 36, 2, and 2

Re: [websec] Comments on draft-ietf-websec-key-pinning-06

On Mon, Jun 24, 2013 at 12:01 AM, Tobias Gondrom wrote: > > On 24/06/13 09:13, Trevor Perrin wrote: > > Depends on the number of pinned keys. Chrome's existing preloads [1] > have 9, 5, 19, 36, 2, and 2 keys. That's a mean of 12, which would be >500 > bytes with SHA256. > > IMHO the expected s

Re: [websec] Comments on draft-ietf-websec-key-pinning-06

Hi all, comments inline. Best regards, Tobias On 24/06/13 09:13, Trevor Perrin wrote: > > On Sun, Jun 23, 2013 at 12:25 AM, Yoav Nir > wrote: > > Hi David > > As far as I know, this idea was not discussed before. If we were > to do this, the proper URI f

Re: [websec] Comments on draft-ietf-websec-key-pinning-06

On Sun, Jun 23, 2013 at 12:25 AM, Yoav Nir wrote: > Hi David > > As far as I know, this idea was not discussed before. If we were to do > this, the proper URI for this would be some kind of RFC 5785 URI like > "/.well-known/pins" or "/.well-known/hpkp". > > Looking at the examples in the key-p

Re: [websec] Comments on draft-ietf-websec-key-pinning-06

Hi David As far as I know, this idea was not discussed before. If we were to do this, the proper URI for this would be some kind of RFC 5785 URI like "/.well-known/pins" or "/.well-known/hpkp". Looking at the examples in the key-pinning draft, an HPKP header using SHA-1 takes just under 120 by

[websec] Comments on draft-ietf-websec-key-pinning-06

I sent the mail below to the draft-ietf-websec-key-pinning-06 authors, and Chris Palmer suggested I raise the points on this mailing list. He also mentioned a previous discussion (which I haven't been able to locate) around a well-known host security information URL; if there's a good place to g

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

On Tue, Nov 29, 2011 at 7:44 PM, Manger, James H 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

[websec] Comments on draft-ietf-websec-key-pinning-00

Comments on draft-ietf-websec-key-pinning-00: First, nice work. §2.3 "Noting Pins" 2nd-last paragraph: 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 MUS