IETF Secretariat | 7 Jul 15:02 2014
Picon

ID Tracker State Update Notice: <draft-ietf-websec-key-pinning-19.txt>

Last call has been made for draft-ietf-websec-key-pinning and state has been changed to In Last Call
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/

Barry Leiba | 26 Jun 13:00 2014
Picon

AD review of draft-ietf-websec-key-pinning-17

With the publication request for draft-ietf-websec-key-pinning, here's
my AD review.  I'm putting the document into "Revised I-D Needed"
substate.  That said, you should definitely push back at me on points
below that you disagree with.  And note the point about the registry
that you're not creating, which I specifically want to discuss with
you.

Yoav, thanks for a very good shepherd writeup.

Tiny thing in the Abstract: we have to squash this "this memo" stuff
forever, but it'll probably take forever to do it.  Please make it
"this document".

Similarly in the Introduction: Remember that the text has to make
sense after publication.  "We propose a new HTTP header to enable..."
doesn't do that (even though "Proposed Standard" will be the RFC's
status).  Go with "This document defines a new HTTP header that
enables...".

Tiny editorial: I suggest changing "that becomes invalid.  (See
Section 4.)" to "that becomes invalid (see Section 4)." -- merging the
citation into the sentence.  There are a couple of other citations in
the document that also read like that.

And in general, wherever you have a citation that looks like this: ([RFC6234])
...remove the parentheses so it looks like this: [RFC6234]

Is "we believe that" in the middle of the second paragraph something
that should stand as it is in the final RFC?

(Continue reading)

internet-drafts | 17 Jun 01:33 2014
Picon

I-D Action: draft-ietf-websec-key-pinning-15.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Web Security Working Group of the IETF.

        Title           : Public Key Pinning Extension for HTTP
        Authors         : Chris Evans
                          Chris Palmer
                          Ryan Sleevi
	Filename        : draft-ietf-websec-key-pinning-15.txt
	Pages           : 26
	Date            : 2014-06-16

Abstract:
   This memo describes an extension to the HTTP protocol allowing web
   host operators to instruct user agents to remember ("pin") the hosts'
   cryptographic identities for a given period of time.  During that
   time, UAs will require that the host present a certificate chain
   including at least one Subject Public Key Info structure whose
   fingerprint matches one of the pinned fingerprints for that host.  By
   effectively reducing the number of authorities who can authenticate
   the domain during the lifetime of the pin, pinning may reduce the
   incidence of man-in-the-middle attacks due to compromised
   Certification Authorities.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-websec-key-pinning-15

(Continue reading)

Chris Palmer | 17 Jun 01:12 2014
Picon

Re: I-D Action: draft-ietf-websec-key-pinning-12.txt

On Mon, May 19, 2014 at 11:28 PM, Trevor Perrin <trevp <at> trevp.net> wrote:

>> PKP vs. PKP-RO:
>> https://code.google.com/p/key-pinning-draft/source/detail?r=994a00dc31bf2cca6f3edea29871a6a4f18090f9
>
> The new text about PKP-RO in 2.5 (quoted below) seems to say that a
> PKP-RO header is only evaluated against the current connection, not
> stored as a pin.  I thought we decided the opposite (which is what I
> think 2.3.2 is saying):
>
> 2.3.2 (existing text):
>   If a Host sets both the Public-Key-Pins header and the Public-Key-
>    Pins-Report-Only header, the UA MUST note and enforce Pin Validation
>    as specified by the Public-Key-Pins header, and SHOULD note the Pins
>    and directives given in the Public-Key-Pins-Report-Only header.

Most recent text
(https://tools.ietf.org/html/draft-ietf-websec-key-pinning-14#section-2.3.2),
FWIW:

"""
   If a Host sets both the PKP header and the PKP-RO header, the UA MUST
   note and enforce Pin Validation as specified by the PKP header, and
   SHOULD note the Pins and directives given in the PKP-RO header.  If
   the UA does note the Pins and directives in the PKP-RO header it
   SHOULD evaluate the specified policy and SHOULD report any would-be
   Pin Validation failures that would occur if the report-only policy
   were enforced.
"""

(Continue reading)

internet-drafts | 13 Jun 02:23 2014
Picon

I-D Action: draft-ietf-websec-key-pinning-14.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Web Security Working Group of the IETF.

        Title           : Public Key Pinning Extension for HTTP
        Authors         : Chris Evans
                          Chris Palmer
                          Ryan Sleevi
	Filename        : draft-ietf-websec-key-pinning-14.txt
	Pages           : 25
	Date            : 2014-06-12

Abstract:
   This memo describes an extension to the HTTP protocol allowing web
   host operators to instruct user agents to remember ("pin") the hosts'
   cryptographic identities for a given period of time.  During that
   time, UAs will require that the host present a certificate chain
   including at least one Subject Public Key Info structure whose
   fingerprint matches one of the pinned fingerprints for that host.  By
   effectively reducing the number of authorities who can authenticate
   the domain during the lifetime of the pin, pinning may reduce the
   incidence of man-in-the-middle attacks due to compromised
   Certification Authorities.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-websec-key-pinning-14

(Continue reading)

Trevor Perrin | 5 Jun 02:48 2014
Picon

PKP-RO (was Re: I-D Action: draft-ietf-websec-key-pinning-12.txt)

Anyone have comments on below?  Is there agreement on what PKP-RO should do yet?

On Mon, May 19, 2014 at 11:28 PM, Trevor Perrin <trevp <at> trevp.net> wrote:
> On Tue, May 13, 2014 at 2:09 PM, Chris Palmer <palmer <at> google.com> wrote:
>>
>> PKP vs. PKP-RO:
>> https://code.google.com/p/key-pinning-draft/source/detail?r=994a00dc31bf2cca6f3edea29871a6a4f18090f9
>
> The new text about PKP-RO in 2.5 (quoted below) seems to say that a
> PKP-RO header is only evaluated against the current connection, not
> stored as a pin.  I thought we decided the opposite (which is what I
> think 2.3.2 is saying):
>
> 2.3.2 (existing text):
>   If a Host sets both the Public-Key-Pins header and the Public-Key-
>    Pins-Report-Only header, the UA MUST note and enforce Pin Validation
>    as specified by the Public-Key-Pins header, and SHOULD note the Pins
>    and directives given in the Public-Key-Pins-Report-Only header.
>
> 2.5 (new text):
>     The UA SHOULD NOT note any pins or other policy expressed in the PKP-
>     RO response header field.

Trevor

Chris Palmer | 27 May 20:28 2014
Picon

Re: key-pinning overrides and reporting

On Thu, May 22, 2014 at 12:49 AM, Yoav Nir <ynir.ietf <at> gmail.com> wrote:

> Interesting question. IMO (no hats) the answer should be no. If the UA has disabled pin validation (as
section 2.6 says it may) then it should not send reports either.

Thanks for raising the question, Igor. I am inclined to agree with
Yoav. Anyone else have thoughts?

Is section 2.6 a good place to put a note about this issue? Proposed text:

"""
If Pin Validation is not in effect (e.g. because the user has elected
to disable it, or because a presented certificate chain chains up to a
locally-installed anchor), and if the server has set a report-uri in a
PKP or PKP-RO header, the UA SHOULD NOT send any reports to the
report-uri for the given certificate chain.
"""

Yoav Nir | 25 May 22:45 2014
Picon

Shooting yourself in the foot with HSTS and HPKP

Hi

We’ve had a few threads ([1]) on this list about administrators needing to be careful when activating
HSTS and/or HPKP, because a common mistake like forgetting to replace the certificate in time can brick
your site. The usual conclusion was that companies and organizations without the proper technical
capacity to maintain a valid certificate should not use these features ([2])

So today we got a real live demo how this can happen even to big, well-funded companies ([3]). HSTS and HPKP
were not involved - this was not a browser, but a client that was programmed to hard-fail when receiving an
expired certificate. It is the equivalent of a site with HSTS, and if it can happen to them, it could happen
to anybody.

I’m not saying we should revisit our previous decisions. Obviously Apple can fix this now in minutes
(probably already has), and all the consequences are some bad press. I just think it is illuminating that
even at large companies there is no guarantee that an action that needs to be performed once a year will be
done correctly.

Yoav

[1] http://www.ietf.org/mail-archive/web/websec/current/msg01119.html (just an example - there
were many threads)
[2] http://www.ietf.org/mail-archive/web/websec/current/msg01213.html
[3] http://www.macrumors.com/2014/05/25/apple-software-update-invalid/
=JeffH | 15 May 00:17 2014

fyi: Analyzing Forged SSL Certificates in the Wild

Analyzing Forged SSL Certificates in the Wild
Lin-Shung Huang, Alex Ricey, Erling Ellingseny, Collin Jackson

Abstract—The SSL man-in-the-middle attack uses forged SSL
certificates to intercept encrypted connections between clients
and servers. However, due to a lack of reliable indicators, it is
still unclear how commonplace these attacks occur in the wild. In
this work, we have designed and implemented a method to detect
the occurrence of SSL man-in-the-middle attack on a top global
website, Facebook. Over 3 million real-world SSL connections
to this website were analyzed. Our results indicate that 0.2%
of the SSL connections analyzed were tampered with forged
SSL certificates, most of them related to antivirus software and
corporate-scale content filters. We have also identified some SSL
connections intercepted by malware. Limitations of the method
and possible defenses to such attacks are also discussed.

https://www.linshunghuang.com/papers/mitm.pdf

news coverage..

https://news.google.com/news?ncl=dCtyuKtyM9cSNPM9nzTnp15Wfnh4M&q=IopFailZeroAccessCreate&lr=English&hl=en&sa=X

internet-drafts | 13 May 23:14 2014
Picon

I-D Action: draft-ietf-websec-key-pinning-13.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Web Security Working Group of the IETF.

        Title           : Public Key Pinning Extension for HTTP
        Authors         : Chris Evans
                          Chris Palmer
                          Ryan Sleevi
	Filename        : draft-ietf-websec-key-pinning-13.txt
	Pages           : 25
	Date            : 2014-05-13

Abstract:
   This memo describes an extension to the HTTP protocol allowing web
   host operators to instruct user agents (UAs) to remember ("pin") the
   hosts' cryptographic identities for a given period of time.  During
   that time, UAs will require that the host present a certificate chain
   including at least one Subject Public Key Info structure whose
   fingerprint matches one of the pinned fingerprints for that host.  By
   effectively reducing the number of authorities who can authenticate
   the domain during the lifetime of the pin, pinning may reduce the
   incidence of man-in-the-middle attacks due to compromised
   Certification Authorities.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-websec-key-pinning-13

(Continue reading)

Ivan Ristić | 23 Apr 10:31 2014
Picon

Clarify pin validation for hosts with multiple trust paths

In Section 2.6. ("Validating Pinned Connections"), there is this wording:

"To perform Pin Validation, the UA will compute the SPKI Fingerprints
 for each certificate in the Pinned Host's validated certificate
 chain, [...]"

It is assumed that there is only one validated certificate chain. In
practice, there could be multiple valid certificate chains, some with
pins, others without. It's possible that a UA will first process the
paths, select one deemed to be the "best", only after which the pins
will be examined. If the selected path is without pins, the connection
will fail, even though there might be another paths that could have been
used.

I think the specification should describe this situation, and instruct
UAs to try alternative (acceptable) trust paths in case of pin failure.

--

-- 
Ivan


Gmane