Re: [websec] Requiring OCSP Stapling as a directive in HSTS

[Tom Ritter]

On 19 January 2015 at 13:17, Ryan Sleevi  wrote:
> On Mon, January 19, 2015 9:55 am, Tom Ritter wrote:
>>  The threat model I'm trying to address is an attacker who can get a
>>  valid certificate misissued for a domain.  Because of the revocation
>>  situation, the attacker can then MITM users with impunity, blocking
>>  revocation lookups if they occur.  While UAs would receive a crlset or
>>  other push of revoked certificates, I believe that the UA will still
>>  work if that connection is blocked, and it's not clear how long that
>>  connection must be blocked before the UA stops working entirely.  (If
>>  that happens at all.)
>
> In this threat model, where does NTP fit? It seems like you're assuming
> the attacker can intercept both the target site and the UA's distribution
> mechanisms, so I would presume that they're also privileged enough to
> mount NTP attacks?


That's true.  It would be broken by NTP and an attacker attaching an
older OCSP staple.  (Similarly, an attacker could use an old staple
and a previously compromised certificate, one since expired.)

The best proposal I've heard for fixing NTP was using TLS (either in
the protocol or an HTTP Date header) for broad resolution plus NTP for
fine-grained skew.  I'd love to see OSes and/or UAs adopt it.


>>  While I'm not opposed to making the language say "Hard Fail Revocation
>>  Checking" I would expect UAs to interpret that as OCSP stapling, and
>>  would not want to delay implementation to account for unlikely-used
>>  corner cases.  And if we say OCSP Stapling, there's no reason that
>>  down the road we could add a new directive for 'hard-fail-revocation'
>>  and let it encompass many different checks.
>
> To make sure this is clear: You're suggesting hard-fail OCSP checking when
> the OCSP directive is present in the header (always), and you're just
> quibbling over the naming of that directive here, right?
>
> I'm just making sure, since soft-fail OCSP stapling doesn't seem to make a
> lot of sense?

I'm definitely not proposing soft-fail anything.

I was dancing around options for what the directive would mean, trying
not to be too religious about it:
a) Call it "Require OCSP Stapling"
b) Call it "Require Hard Fail Revocation Checking" and UAs really
implement it as requiring a Staple
c) Call it "Require Hard Fail Revocation Checking" and UAs implement
it as requiring a CRL, Staple, or Successful OCSP query

I like (a), followed by (b), and least of all (c).  I think (c) is the
most work and is going backwards from what UAs seem to want - so least
likely to be implemented.


>>  As far as 'Where?' and why 'In HSTS'?  I see four options: a HTTP
>>  Header, a TLS Extension, a DNSSEC record, and a Certificate Extension.
>
> You missed a fifth.
>
> A .well-known URI (RFC 5785) used to configure security-policy at the
> domain level.
>
> I don't suggest this as something that the browser would background fetch
> (although certainly, it could be induced so coupled with a header).

I'm not sure I understand: there's a .well-known URL that says "Must
Staple" _and_ a header?

> Moreso, I'm suggesting that this be used to build such preload lists of
> security policy so that they can be distributed.

I'm not sure I understand you entirely, but if you're suggesting that
the crawl +  browser preload is the mechanism by which this is
deployed, I'm kind of 'meh' on that.  It relies on a site operator
inducing a company to crawl their site and bake the policy into the
software somehow.  It feels like taking something that's two-party
(site operator and user agent) and making it three (adding user agent
infrastructure and crawling robots).


> The failure mode of a bad HSTS header is not too bad - you're stuck on
> TLS. If accidentally set / by an attacker / things really hit the fan, you
> could stick one of the many CDNs in front of your site to handle the TLS
> to your unencrypted backend.
>
> The failure mode of a bad HPKP header is decidedly worse - total site
> denial if you do key rotation / change CAs. Preloading is one way to
> mitigate this (by providing some consistent view of effective policy),
> although even that can be botched (e.g. CryptoCat recently rotated CAs and
> thus committed pinning suicide, at least until Chrome 41). The security
> considerations of hostile pinning alone accounted for quite a bit of
> discussion.
>
> OCSP stapling I think falls somewhere in the middle here on the risk
> proposition - there's still a vast, depressing majority of server software
> that doesn't support OCSP stapl

[websec] Requiring OCSP Stapling as a directive in HSTS

[Tom Ritter]

Hi all.  I'd like to propose an idea: add an optional directive to the
HSTS header that, when included, mandates any certificate received for
a domain require OCSP Stapling. It would respect includeSubdomains and
max-age.



The threat model I'm trying to address is an attacker who can get a
valid certificate misissued for a domain.  Because of the revocation
situation, the attacker can then MITM users with impunity, blocking
revocation lookups if they occur.  While UAs would receive a crlset or
other push of revoked certificates, I believe that the UA will still
work if that connection is blocked, and it's not clear how long that
connection must be blocked before the UA stops working entirely.  (If
that happens at all.)

Counting from the detection of the attack (which efforts like CT and
Pinning help detect), requiring OCSP stapling changes the window of
attack from {forever?, 30 days?, an unknown value?} to the OCSP
staple's lifetime.  (Assuming the attacker gets a OCSP signature right
before revocation.)



Why OCSP stapling and not require the UA to instead use 'hard-fail'
revocation checking?  Well, CRLs have all sorts of drawbacks: longer
expiry times, large sizes, and they're pretty much being phased out
everywhere.  (I know about Delta-CRLs - developing a specification for
them, implementing, and deploying them will take years, if ever, due
to IPR stuff. This does not.)   What about requiring OCSP querying?
Browsers don't much care for that - it's slow, can timeout for
non-security reasons, it's out of the control of the web site owner.
That leaves us with OCSP Stapling - it's fast, implemented, deployed.

While I'm not opposed to making the language say "Hard Fail Revocation
Checking" I would expect UAs to interpret that as OCSP stapling, and
would not want to delay implementation to account for unlikely-used
corner cases.  And if we say OCSP Stapling, there's no reason that
down the road we could add a new directive for 'hard-fail-revocation'
and let it encompass many different checks.



As far as 'Where?' and why 'In HSTS'?  I see four options: a HTTP
Header, a TLS Extension, a DNSSEC record, and a Certificate Extension.

Certificate Extension is being worked on
(https://datatracker.ietf.org/doc/draft-hallambaker-tlsfeature/) but I
see it as a compliment to this.  The certificate extension only
dictates policy for this certificate.  If we assume an attacker can
get a misissued certificate for a domain, the cert extension is only
useful when it is the default issuing status and an attacker must have
additional privledges to circumvent it.  And it doesn't make sense to
have a certificate extension dictate policy for a whole domain, that's
a very strange location to put this sort of data.

A DNSSEC record has deployment problems, we can't retrieve it
reliably. Fallback or soft-fail provides no security and is useless
here.

A TLS Extension makes a certain amount of sense.  We're trying to
dictate a policy for TLS connections, not HTTP.  But it's more
difficult to deploy TLS Extensions than HTTP headers, the TLS working
group is tremendously busy, and technically this would fit more with
the closed PKIX group.

That leaves us with a HTTP Header.  I think it makes more sense to put
this as a directive on HSTS rather than making a new header. While I
could imagine situations where one would want to require revocation
checking (or pinning for example) without requiring TLS, I don't see
it as a huge use case.  Rather, putting it in HSTS is a small
incremental upgrade that avoids redefining all the other stuff.



Should the UA require a staple for all certs in the chain
(Intermediates included) or just the leaf?  I'm not religious about
one or the other, I'd probably lean towards requiring all but I'd need
to review the implementation and deployment status of multi-stapling.
Just requiring the leaf is simpler from a deployment perspective I
believe, and compromised intermediates cause immediate browser pushes
anyway.



Would there be support for this draft?

-tom

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] HSTS: Infinite max-age to address NTP spoofing attack?

[Tom Ritter]

On 7 November 2014 13:28, Xiaoyin Liu  wrote:
> For instance, if Twitter wants to gracefully switch to HTTP. It needs to
> send max-age=0 for twenty years in order to ensure that no one is locked
> out. But planning ahead twenty years is impossible. So for Twitter switching
> from twenty years to infinity doesn't add more risks.

With something concrete, Paypal just jumped to 2 years:
https://twitter.com/equalsJeffH/status/530840852243832833 Maybe Jeff
can weigh in on what it took to get to that confidence level and
whether he/they would rather have 'infinite'.

-tom

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Tom Ritter]

On 27 August 2014 05:46, Yoav Nir  wrote:
> At this stage, we can make editorial changes, but we cannot make significant
> changes on our own. We can withdraw the request to publish, and take it back
> to the working group, but I think that would be inadvisable.
>
> I think we should proceed, making only editorial changes, and changes
> resulting from discussion with IESG members.

If adding a note in 4.2 about includeSubdomains and PKP-RO (for
testing) counts as editorial, I think that is worthwhile.
Otherwise/regardless I also don't want to withdraw.

-tom

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Tom Ritter]

On 26 August 2014 17:10, Chris Palmer  wrote:
> OK, so, what do you want?
>
> Is it even possible for me to write text you would accept?

Just because I have a concern or preference doesn't mean I don't
really appreciate the work you've done. I do.

I'd like PKP-RO to be cached like PKP and applied the same way, absent
the connection termination (preference). After I realized the
includeSubdomains issue (concern), I want it even more for testing a
deployment than I want it for my prior attack detection arguments
(preference).

I've tried to find all the references someone (e.g. a reviewer) might
want changed to do this.  My suggestions:

--

The "max-age" directive is REQUIRED to be present within a "Public-
   Key-Pins" header field, and is OPTIONAL within a "Public-Key-Pins-
   Report-Only" header field.

Become

The "max-age" directive is REQUIRED to be present within the "Public-
   Key-Pins" and "Public-Key-Pins-Report-Only" header fields.

--

Note: There is no purpose to using the PKP-RO header without the
   report-uri directive.  User Agents MAY discard such headers without
   interpreting them further.

Become

Note: The only purpose to using the PKP-RO header without the
   report-uri directive is to include a max-age=0 to clear any previously
   saved PKP-RO directives.  After doing so, User Agents MAY discard
   such headers without interpreting them further.

--

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 process the Pins and directives given in the PKP-RO header.
   If the UA does process 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.

Become

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 and process the Pins and directives given in the PKP-RO header.
   If the UA does process 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.

--

Upon receipt of the PKP response header field, the UA notes the host
   as a Known Pinned Host, storing the Pins and their associated
   directives in non-volatile storage (for example, along with the HSTS
   metadata).  The Pins and their associated directives are collectively
   known as Pinning Metadata.

Become

Upon receipt of a PKP or PKP-RO response header field, the UA notes the host
   as a Known Pinned Host, storing the Pins and their associated
   directives in non-volatile storage (for example, along with the HSTS
   metadata).  The Pins and their associated directives are collectively
   known as Pinning Metadata.

--

It received the PKP response header field over an error-free TLS
  connection.

Become

It received the PKP or PKP-RO response header field over an error-free TLS
  connection.

--

If the PKP response header field does not meet all three of these
   criteria, the UA MUST NOT note the host as a Pinned Host.  A PKP
   response header field that meets all these critera is known as a
   Valid Pinning Header.

Become

If the PKP or PKP-RO response header field does not meet all three of these
   criteria, the UA MUST NOT note the host as a Pinned Host.  A response
   header field that meets all these critera is known as a Valid Pinning Header.

--

The UA need not note any Pins or other policy expressed in the PKP-RO
   response header field, except for the purpose of determining that it
   has already sent a report for a given policy.  UAs SHOULD make a best
   effort not to inundate report-uris with redundant reports.

be removed entirely. The final sentence is included previously as a
SHOULD at the end of 2.1.3

--
In Section 2.6:

Otherwise, the UA MUST
   treat this Pin Validation Failure as a non-recoverable error.

Become

Otherwise, if the Pinning Metadata indicates the policy was not set by
   the PKP-RO header, the UA MUST treat this Pin Validation Failure
   as a non-recoverable error.

--


I believe that Section 2.3.2, paragraph "If a host sets the PKP-RO
header..." is clear enough as is.

-tom

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Tom Ritter]

On 26 August 2014 16:38, Trevor Perrin  wrote:
> That's not completely true, because PKP affects Pin Validation of
> other connections, and PKP-RO doesn't.
>
> ...
>
> So Eric's point is valid: PKP-RO doesn't provide an administrator much
> confidence that their site is ready for PKP, and might even mislead
> them.

This is especially true if includeSubdomains is enabled. It'd be
common for that directive to apply to hosts that the -RO header would
not be included on. In PKP-RO, it would not be applied to them; in PKP
it would.

-tom

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Tom Ritter]

On 26 August 2014 15:51, Chris Palmer  wrote:
>> Requiring PKP-RO to be on every load would allow an attacker
>> to strip the header on the connections they MITM.
>
> Only if The Alice Foundation did not also use a regular PKP header.

Correct.

>> Letting it be cached
>> allows an organization to put a max-age of 45 days on it, without the
>> risk of bricking their site if they aren't administratively competent.
>>
>> Obviously an attacker can also block the reports from being sent, but
>> I'm hoping that the clause "In any case of report failure, the UA MAY
>> attempt to re-send the report later" will be considered in this case,
>> and that UAs will make an attempt at getting potentially blocked
>> reports out at a later date.
>
> Yeah, sort of. But don't think of PKP-RO as a defense against attacks,
> even if it might sometimes have that secondary benefit. It is
> primarily a debugging aid for The Alice Foundation and BobCorp to get
> PKP working. ("What all Trents do we need to trust, anyway?")

I'm not going to put words in your mouth, because different authors
have different opinions about things, but I will quote from another:

> Ryan Sleevi wrote 
> (http://lists.w3.org/Archives/Public/public-webcrypto-comments/2013Feb/0001.html)
>> I wrote:
>> 1. A large site that is commonly proxies by corporate and malicious
>> actors wishes to monitor how common this is done.  They place
>> javascript bindings in their code to view the user's certificate and
>> report the observed value.
>> Note this use case has already been performed by Facebook, who had to
>> resort to Flash to do so, because javascript did not provide the
>> functionality.
>
>Use report-uri with HPKP, in report-only mode

I don't consider PKP-RO as a defense, but as an attempt at detection
of attacks, with no risk of breaking your site.  It is extraordinarily
useful to be notified of attacks against your users, even if they are
not prevented. They help you understand where you should invest time
and money.

The foot-gun potential is very high with HPKP, we all know that.  It's
high enough to the point that many organizations, who have someone
maintaining a website part time (or outsource it) may forgoe PKP
entirely because it makes them nervous - but they would be happy to
deploy a no-risk PKP-RO.  But the benefit of doing so if it is not
being cached is extraordinarily low, to the point it's probably not
worth doing.

-tom

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Tom Ritter]

On 26 August 2014 14:36, Chris Palmer  wrote:
> On Mon, Aug 25, 2014 at 7:05 PM, Tom Ritter  wrote:
>
>>>> No, PKP-RO is not meant to be cached. In this respect, it behaves similar
>>>> to Content-Security-Policy's reporting mechanism.
>>>
>>> Ah, interesting. I'm curious why not? Is there no use-case for allowing
>>> "report-only" pins to be persisted?
>>
>> I think there definitely are, and I and most organizations I advise
>> would like that option.
>
> What would they get from it that they would not get from just
> consistently serving the PKP-RO header?

Well the whole threat model of HPKP (without preloading) is an
attacker that can MITM some TLS connections, but not all of them,
right?  Requiring PKP-RO to be on every load would allow an attacker
to strip the header on the connections they MITM. Letting it be cached
allows an organization to put a max-age of 45 days on it, without the
risk of bricking their site if they aren't administratively competent.

Obviously an attacker can also block the reports from being sent, but
I'm hoping that the clause "In any case of report failure, the UA MAY
attempt to re-send the report later" will be considered in this case,
and that UAs will make an attempt at getting potentially blocked
reports out at a later date.

-tom

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Tom Ritter]

On 25 August 2014 13:07, Eric Lawrence  wrote:
>> No, PKP-RO is not meant to be cached. In this respect, it behaves similar
>> to Content-Security-Policy's reporting mechanism.
>
> Ah, interesting. I'm curious why not? Is there no use-case for allowing
> "report-only" pins to be persisted?

I think there definitely are, and I and most organizations I advise
would like that option.

-tom

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] First Connection Active Attack in HPKP

[Tom Ritter]

On 28 April 2014 19:51, Chris Palmer  wrote:
> I see your point... is the attack so marginal that it doesn't matter
> either way? I'm not sure I feel strongly any more on this topic.

I would call the difference marginal only if the we never envision the
report having anything done with it except immediate sending.  If it's
stored for later, logged, a browser extension collects them all and
sends them out through Tor or some other mechanism... then I would say
it's not marginal.  And since those are possibilities, I would say it
would be better to remove the paragraph and not have different
behavior. It would also probably make the code simpler, too.

-tom

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

[websec] First Connection Active Attack in HPKP

[Tom Ritter]

Sorry to be second guessing you Chris, but wanted to ask about this change:
https://code.google.com/p/key-pinning-draft/source/detail?r=5810662a42e56938272d9db4b2e5373914b266f4

Let's say an active attacker does MITM on a client.  (That's the scenario
you reference, right?)  The client can have pins for the server or not.

If the client does have pins, the active attack fails and generates a
report event.  The attacker knows the attack fails because a) perhaps they
observe metadata about the report event being sent right away but more
concretely b) because their attack fails.

If the client doesn't have pins, the active attack succeeds.  The attacker
knows the attack succeeded and that the pinning wasn't effective because...
it succeeded.  Whether or not a report event is generated the attacker
knows it succeeded.  Furthermore, if an attacker is attacking the client
and wants to learn if it supports pinning or not, it can look at the User
Agent header, TLS handshake fingerprinting, or active javascript injection.

If the attack succeeds, and the attack already knows about it succeeding, I
don't understand the harm in generating a report event. Maybe the attack
will block it (and know it was generated), but maybe they won't and it will
get out.  Maybe the report will be held for some time and sent later.

-tom
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] Public-Key-Pins-Report-Only

[Tom Ritter]

On 5 April 2014 14:37, Trevor Perrin  wrote:
> I think your intent is that there's 2 different types of pins (regular
> and report-only), which don't interact.  I.e. setting max-age=0 on a
> regular PKP header doesn't clear PKP-RO pins, and vice versa.  And
> when contacting a pinned site, the UA might have to apply both pins to
> it.
>
> Seems reasonable, if other people agree.

That is my take on it as well, and what I desired.  I think the
wording needs to be clarified significantly however. All of the logic
around the interaction of PKP and PKPRO is buried in the report-uri
subsection.  I would suggest a new 2.3.2 and change the report-uri
section.  Textual Suggestions:

My thoughts on the report-uri section:



The OPTIONAL "report-uri" directive indicates the URI to which the UA
SHOULD report Pin Validation failures (). The UA POSTs the reports to the
given URI as described in .

When used in the Public-Key-Pins or Public-Key-Pins-Report-Only header,
the presence of a report-uri
directive indicates to the UA that in the event of Pin Validation failure it
SHOULD POST a report to the report-uri.  If the header is Public-Key-Pins,
the UA should do this in addition to
terminating the connection (as described in ).

Hosts may set report-uris that use HTTP, HTTPS, or other schemes. If the
scheme in the report-uri is HTTPS, UAs MUST perform Pinning Validation when
the host in the report-uri is a Known Pinned Host; similarly, UAs MUST apply
HSTS if the host in the report-uri is a Known HSTS Host.

Note that the report-uri need not necessarily be in the same Internet
domain or web origin as the Known Pinned Host.

UAs SHOULD make their best effort to report Pin Validation failures to
the report-uri, but may fail to report in exceptional conditions. For
example, if connecting the report-uri itself incurs a Pinning Validation
failure or other certificate validation failure, the UA MUST cancel the
connection (and MAY attempt to re-send the report later). Similarly, if
Known Pinned Host A sets a report-uri referring to Known Pinned Host B, and
if B sets a report-uri referring to A, and if both hosts fail Pin
Validation, the UA SHOULD detect and break the loop by failing to send
reports to and about those hosts.

UAs SHOULD limit the rate at which they send reports. For example, it
is unnecessary to send the same report to the same report-uri more than
once.








New 2.3.2

Interaction of Public-Key-Pins and Public-Key-Pins-Report-Only

A server MAY set both the Public-Key-Pins and Public-Key-Pins-Report-Only
headers simultaneously. The headers do not interact with one another but
the UA MUST process the Public-Key-Pins header and SHOULD process both.

The Public-Key-Pins header is processed as according to section 2.3.1.

When the Public-Key-Pins-Report-Only header is used with a report-uri, the
UA SHOULD POST reports for Pin Validation failures to the indicated
report-uri, although the UA MUST NOT enforce Pin Validation. That is,
in the event of Pin Validation failure when the host has set the
Public-Key-Pins-Report-Only header, the UA performs Pin Validation
only to check whether or not it should POST a report, but not for causing
connection failure.

Note: There is no purpose to using the Public-Key-Pins-Report-Only header
without the report-uri directive. User Agents MAY discard such headers
without interpretting them further.

If a Host sets the Public-Key-Pins-Report-Only header, the UA SHOULD note
the Pins and directives given in the Public-Key-Pins-Report-Only header as
specified by the max-age directive. If
the UA does note the Pins and directives in the Public-Key-Pins-Report-Only
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.

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. If the
UA does note the Pins and directives in the Public-Key-Pins-Report-Only
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.

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] Public-Key-Pins-Report-Only - attempt at summary

[Tom Ritter]

On 27 February 2014 16:07, Daniel Kahn Gillmor  wrote:
> On 02/27/2014 03:31 PM, Trevor Perrin wrote:
>> 1)  PKP-RO implements the full PKP semantics (i.e. is stored for max-age,
>> is applied to includeSubdomains), but only generates reports instead of
>> hard fails.  The browser would store PKP and PKP-RO pins in
>> separate/parallel stores, for example setting max-age=0 for a PKP pin would
>> not clear PKP-RO pins, and vice versa.
>>
>> 2)  PKP-RO is removed from the spec.
>>
>> 3) Your suggestion - have PKP-RO implement a reduced set of PKP semantics
>> (only check current connection).  I'm not sure about the usefulness of
>> that, and I worry site operators would be mislead by it.
>
> As someone who sometimes helps to operate and plan the operation of web
> sites, i don't think the semantics of (3) are misleading, but they're
> not particularly confidence-inspiring either.
>
> What is the goal of PKP-RO?  Is the goal to encourage adoption by giving
> site operators confidence in a proposed configuration or organizational
> workflow?

As I believe - this. PKP-RO doesn't enforce security for a site, and
while a PKP header MAY be saved for later reporting* - an attacker
performing a man-in-the-middle attack can block a PKP-RO assignment or
a PKP-RO report. (At least, right now, I have a suggestion for this
below.)

* From http://tools.ietf.org/html/draft-ietf-websec-key-pinning-11#section-2.1.3

So I feel it's primarily for testing a configuration and gaining
confidence in it before rolling it out.

> The real footgunnery with PKP will come during key transition/rollover
> (or switching CAs), as clients who have cached pins cope with the
> changes.   Using (3)-style PKP-RO to build confidence in an
> organizational workflow around this kind of transition event doesn't
> seem possible.

I agree.

So I'm for #1 - store it.  I have afew suggestions around fixing up
portions of the doc for this.

The PKP-RO header MUST be able to be cleared out at any time by
setting max-age=0 if the connection occurs over an error-free TLS
connect excepting any requirement of matching a key to a PKP-RO
header.  Explained, I should be able to clear out an old PKP-RO header
even if I set the hash to DEADBEEF and the max-age to a year.

The PKP-RO header reports MAY be stored for reporting at another time.
I don't think browsers will implement this right away, but down the
line I think it might turn into an actual security feature.  A report
SHOULD be generated and transmitted (or stored) before clearing out an
old policy.  (So bad is I get an extra report I ignore, good is that
an attacker can't definitively silence a report if it is stored for
later.)

When I recieve reports, I can tell what the PKP-RO policy was at the
time by examining the report.  Except that the report needs to have a
new field in there saying if it's mode is 'enforcement' or
'report-only'.  As a site operator, I can even go farther by
specifying a non-hash such as sha256=policytest20140301v1 - no one
will be able to gen a cert that hashes to a b64 representation of
that, and it lets me track my policy deployments if I like.

-tom

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] WGLC for draft-ietf-websec-key-pinning-10

[Tom Ritter]

On Feb 19, 2014 6:05 PM, "Chris Palmer"  wrote:
> > And that deployment would actually be made more confusing, not less, by
> > having two analogous headers, named in the same pattern, that behave
> > differently - I think that's likely to cause as much confusion as
anything
> > else.
>
> Yeah, I see that. I think I'll have to change the text to allow the
> CSP-style enforce 1 policy, report on another behavior.
>
> So, how about this:
>
> 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 and

"And the pins" is a typo. I'm not clear what note means in this context.
You probably mean "not ignore", but I don't know the least ambiguous verb
to use? In any event, I like the sentiment.

> the Pins and directives given in the Public-Key-Pins-Report-Only header.
If
> the UA does note the Pins and directives in the
Public-Key-Pins-Report-Only
> 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.

(Sent on a phone)
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] Pre-loaded pins vs dynamic pins

[Tom Ritter]

On 19 February 2014 16:14, Chris Palmer  wrote:
> On Wed, Feb 19, 2014 at 12:09 PM, Yoav Nir  wrote:
>> Does anyone (and that includes the authors) object to relaxing the 
>> requirements in section 2.7, so that the choice of when the static pins are 
>> believed to have been observed is left to the implementer?  If not, we'll 
>> resolve it that way.
>
> I don't object; I like that well enough.

Seconded/Thirded/Fourthed

-tom

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] WGLC for draft-ietf-websec-key-pinning-10

[Tom Ritter]

On Feb 7, 2014 8:47 PM, "Chris Palmer"  wrote:
>
> Oops, I forgot one thing:
>
> On Fri, Feb 7, 2014 at 5:12 AM, Tom Ritter  wrote:
>
> > "If a Host sets both the Public-Key-Pins header and the Public-Key-
> >Pins-Report-Only header, the UA MUST NOT enforce Pin Validation, and
> >MUST note only the pins and directives given in the Public-Key-Pins-
> >Report-Only header."
> >
> > I thought we were following the CSP model, where you can enforce one
> > policy, but test a second.
>
> Honestly, I think that's likely to be too complicated. I want to
> prioritize ease of deployment (which includes a simple-to-state policy
> like the above, and failing open when not unreasonably unsafe), and
> I'd like for the implementation not to get too much more complicated.

I suppose. I think the extra  implementation complication is in
conditionally applying code rather than having to write additional code,
which strike me as different, but you would know better than me.

And that deployment would actually be made more confusing, not less, by
having two analogous headers, named in the same pattern, that behave
differently - I think that's likely to cause as much confusion as anything
else.

I imagine someone like Twitter, with its multiple pinned CAs, would have a
really good use case for being able to apply and test two different
policies.

But, I also am anxious to get this out in the field - if anyone thinks
similarly, they can speak up.

-tom
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] WGLC for draft-ietf-websec-key-pinning-10

[Tom Ritter]

" 5. If a PKP header field contains any directive(s) the UA does not
   recognize, the UA MUST ignore the those directives."

Typo.



"If a Host sets both the Public-Key-Pins header and the Public-Key-
   Pins-Report-Only header, the UA MUST NOT enforce Pin Validation, and
   MUST note only the pins and directives given in the Public-Key-Pins-
   Report-Only header."

I thought we were following the CSP model, where you can enforce one
policy, but test a second.



Figure 3 shows some example response header fields using the pins
   extension (folded for clarity).

   "d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM="
   "E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g="
   Public-Key-Pins: max-age=3000;
   pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM=";
   pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g=";

I think some base64 got added accidentally at the top.



"UAs MUST NOT heed http-equiv="Public-Key-Pins" attribute settings on
elements [W3C.REC-html401-19991224] in received content."

It might be pedantic, but perhaps 'or http-equiv="Public-Key-Pins-Report-Only"'?



UAs MUST recognize and "sha256".

Typo



'Pins' vs 'pins'

Pedantry, but the noun pins is inconsistently capitalized through the document.



Reporting Pin Validation Failure

The JSON report omits directives (such as max-age and
includeSubDomains) that are likely to be relevant.
It also omits superfluous certificates included in the chain that can
be relevant. (In certificate validation testing, it's common to bypass
it by including a superfluous chain that triggers a logic error. This
would help diagnose these types of attacks.)



"The known-pins are the Pins that the UA has noted for the Known
   Pinned Host.  They are provided as an array of strings with the
   syntax:

   known-pin = token "=" quoted-string
Figure 6: Known Pin Syntax
"

I think this needs clarification (or fixing).  'Array of strings' +
token=quoted-string.  ["pin-sha256="base64==""] obviously doesn't
work. An example JSON post would be cool.



Public-Key-Pins: pin-sha256="ABC..."; pin-sha256="DEF..."; includeSubDomains

Figure 7: example.com Valid Pinning Header

To make it 'valid' should it include max-age=123...?



"Here are two attack scenarios."

You actually list four. (Two of which have empty top-level bullets.)



IANA Considerations

This omits Public-Key-Pins-Report-Only




-tom
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] HPKP: The strict directive and TLS proxies

[Tom Ritter]

On 29 November 2013 17:39, Trevor Perrin  wrote:

> On Fri, Nov 29, 2013 at 2:15 PM, Tom Ritter  wrote:
> > On 29 November 2013 15:24, Trevor Perrin  wrote:
> >>
> >>  * Why is there a "Public-Key-Pins-Report-Only" header instead of a
> >> "report-only" directive?  Most of the document is written as if there
> >> was a single "PKP header field", so a directive would make more sense.
> >
> >
> > If it becomes a directive, we should be sure that we can still apply two
> > headers, one more loose in enforcing mode, one stricter in report only
> mode.
>
> Would you expect both headers to be noted?
>
> The current spec doesn't support that.  It specifies 2 different (and
> incompatible) ways of handling this case:
>
>  - 2.1.3: "If a Host sets both the Public-Key-Pins header and the
> Public-Key-
> Pins-Report-Only header, the UA MUST NOT enforce Pin Validation, and
> MUST note only the pins and directives given in the Public-Key-Pins-
> Report-Only header."
>
>  - 2.3.1: "If a UA receives more than one PKP header field in an HTTP
> response message over secure transport, then the UA MUST
> process only the first such header field."
>


Oh yea. Heh.  Why is that?  CSP supports an enforcing header and a
reporting header, and both of them are applied simultaneously. I would
expect the same from HPKP.

-tom
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] HPKP: The strict directive and TLS proxies

[Tom Ritter]

On 29 November 2013 15:24, Trevor Perrin  wrote:

>  * Why is there a "Public-Key-Pins-Report-Only" header instead of a
> "report-only" directive?  Most of the document is written as if there
> was a single "PKP header field", so a directive would make more sense.
>

If it becomes a directive, we should be sure that we can still apply two
headers, one more loose in enforcing mode, one stricter in report only
mode.

-tom
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] HPKP: The strict directive and TLS proxies

[Tom Ritter]

On 11/19/2013 3:36 PM, Yoav Nir wrote:
>> As far as the laptop moving between home and work... I get the
>> impression this situation may be regarded as a 'failure' of the
>> protocol. That is, we have unintentionally broke something.  I disagree.
>> I think the situation has worked as desired.
> 
> It's the other way around. The desktop that remains at the office and keeps 
> ignoring the strict pins is the failure.


Ah, I agree with that, also.  I was anticipating an argument that the
laptop had been 'broken' by the migrating.



> So the benevolent TLS proxy should note the "strict" directive and block the 
> connection by itself? It makes sense, but that would require an upgrade of 
> the TLS proxies. Changing client behavior would work with the proxies that 
> are deployed now.


Not necessarily.  Really I meant that I, as the maintainer of the SSL
MITM device at FooCorp could decide "Employees aren't allowed to use
personal WebMail at work" and then enforce that with blocking.

Auto-Blocking based off 'strict' would absolutely require upgrades, but
that wasn't my meaning.


>> I expect that Firefox and Google may even continue to preload entries in
>> their browsers that apply the 'strict' directive specifically to provide
>> websites the power to assert their right to a MitM-free connection. I
>> know several websites who would like to exercise that right.
>>
> 
> What? And have their sites not work in all the places that have newer 
> firewalls?  I doubt it.

/shrug

I can hope.  :)

-tom

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] HPKP: The strict directive and TLS proxies

[Tom Ritter]

Hm.  Interesting predicament.  Two thoughts:

If the goal is to allow clients to note and obey the 'strict' directive
even in the face of a SSL Interception proxy... what you propose won't
work. The proxies will be built to just remove the strict directive, or
the header all together.

If the organization running the proxy wanted to block access to the site
in question, they would do so. If they want to monitor ongoing access,
they will strip the directive/header so the clients continue to connect.
If they are ambivalent - 'access it or not, we don't care, but must
monitor you if you do' - the stripping feature may or may not be enabled.

What you propose would only help in the latter case, it will not
actually provide more security if the website considers the proxy to be
an adversary. And if they add the strict header, I would imagine that
the website does consider them to be an adversary, or at least that they
do not wish the connection to succeed..

So I don't think what you propose is worthwhile, specifically because it
does add risk via sites bricking themselves, while not improving
security considerably.




As far as the laptop moving between home and work... I get the
impression this situation may be regarded as a 'failure' of the
protocol. That is, we have unintentionally broke something.  I disagree.
I think the situation has worked as desired.

Because if we replace the players with a rogue government performing TLS
MitM, with the specific goal of isolating clients from receiving
up-to-date security policies... we would declare this same situation a
success.

I don't see a way to reconcile the two situations, as they behave almost
exactly the same.

TLS Proxies add a third player into what was previously a (primarily)
two-party protocol*. I think the strict directive preserves the
reasonable property that any one of the three parties can choose not to
participate based on the settings of the protocol.
 - The TLS proxy can block access or choose not to intercept
 - The user can not visit the site
 - The site can declare "I don't want anyone else seeing the data I
consider to be for the user's eyes only"

I expect that Firefox and Google may even continue to preload entries in
their browsers that apply the 'strict' directive specifically to provide
websites the power to assert their right to a MitM-free connection. I
know several websites who would like to exercise that right.


-tom

* Yes yes, CAs make 3, but that's PKIX, not TLS.

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] Consensus call: Issue #57 (max-max-age)

[Tom Ritter]

On 7 May 2013 03:13, Yoav Nir  wrote:
> How should we handle the max-max-age issue:
>  (1) No hard limits, but allow UAs to limit the pin time. Suggest a month
>  (2) Set a hard limit of one month in the RFC. Longer pins are truncated.
>  (3) No hard limits, but allow the UA to skip hard-fail if a pin hasn't been 
> observed for some time (like a month)
>  (4) Adopt some gradual confidence-building scheme a-la-TACK.
>
> "None of the above" is possible, but MUST come with argument and proposed 
> text.


None of the above:  No hard limits, leave limiting the pin time
unspecified, make no suggestion.  I don't believe any text changes are
necessary.

I think UAs that are sufficiently worried about websites bricking
themselves come up with creative solutions that work well for them,
but may not be applicable to others.  (Chrome's will (or would) expire
hardcoded pins if there hasn't been a Chrome update in a month - they
could do the same for max-ages.)  I don't like the idea of suggesting
that UAs unilaterally override a site's possible desire to pin for
more than 1 month.

-tom.
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

[websec] HPKP Report Only Mode and Browser Extensions

[Tom Ritter]

I hear more and more talk about HPKP being used primarily in
Report-Only mode.  I think that's fair, as website operators are very
*very* nervous about bricking themselves.  But it also takes away the
ability of users to be proactive about these (possible) violations.

How do people feel about the following addition to the "Reporting Pin
Validation Failure" section (probably under a new sub-section):

  If a UA provides extensibility points to be used
  by third party extensions or plugins, it [MAY?/SHOULD?]
  provide extensibility points relating to failures in
  both enforcement and Report Only mode.

I envision a browser extension (which is naturally an opt-in
mechanism) that flags Report Only violations so users are aware of
them, and can investigate.  I envision another one, perhaps run by the
EFF, Google, or other trustworthy organization that actually sends
these reports anonymized to a central database (besides the
report-uri) where volunteers or employees could review them for
suspicious entries.

-tom
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #55: Clarify that the newest pinning information takes precedence

[Tom Ritter]

" The UA MUST evict all expired Known Pinned Hosts if at any time, an
expired Known Pinned Host exists in the cache"

I use rrdtool to keep 5 years of statistics for my server.  Once, I
accidentally set the date forward, to 2038, wiping out my statistics -
there was no way to recover, because rrdtool dutifully wiped all this
expired data.

Using the word 'evict' seems particularly dangerous, for both active
ntp attacks, and accidental wiping.

-tom
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] Issue 55 - Key pinning should clarify that the newest pinning information takes precedence

[Tom Ritter]

On 6 March 2013 14:34, Ryan Sleevi  wrote:
> I think the real answer should be that preloading shouldn't be part of the
> spec, as it really is an implementation-specific behaviour. Certainly,
> it's based on our experiences in Chrome/Chromium, and it does provide an
> additional measure of security for the initial connection, but it doesn't
> really tie into the semantics of the header at all.
>
> Different applications - including such like Firefox - have already
> expressed interest in pursuing different schemes for preloading and the
> maintenance of such lists. Certainly, we've looked at alternatives
> ourselves. Our thinking is that we should avoid baking such behaviours
> into a spec, and instead focus solely on the header and observation
> aspects.
>
> Unlike the header - which is presumably provided to all user agents and
> uniform implementation expected - preloading is (at least, today) about a
> relationship between the site operator and individual user agents, so
> there's already a communication channel. If other implementations pursue
> different schemes - eg: such as crawling and noting pins - then they may
> have vastly different needs/requirements, but the overall semantics of the
> header itself remains the same.


Fair enough. I hope a browser will be willing to fiddle with their
preloading mechanism if it's found to cause pain, and I hope any site
owner would not put in preloaded pins with a browser that couldn't
amend them easily.

I'll only mention for consideration rewording the line to say "the
newest information available for the host":

UAs MUST use the newest information available for the host -- built-in
or set via Valid
   Pinning Header -- when performing Pin Validation.

This may guide things better without being overly restrictive.

-tom
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] Issue 52 - Key pinning draft should clarify max-age as required

[Tom Ritter]

No objection to closing it out.

On 4 March 2013 19:56, Ryan Sleevi  wrote:
> This was one of the outstanding issues from draft-03, raised in
> http://trac.tools.ietf.org/wg/websec/trac/ticket/52
>
> The Chrises and I believe this has been addressed sufficiently in
> draft-04, through the clarifications in
> http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-2.1.1 and
> http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-2.3.1
>
> Are there any objections to closing this out?
>
>
>
>
> ___
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] Issue 55 - Key pinning should clarify that the newest pinning information takes precedence

[Tom Ritter]

On 4 March 2013 19:57, Ryan Sleevi  wrote:
> The authors belief is that the issues that arise from either
> implementations are artifacts of the implementation and distribution of
> preloaded pins, rather than an issue intrinsic to this specification. That
> is, the "correct" answer is that the preloaded pin list should be updated
> for Site 1 - however that information is distributed between the site
> operator and the creator of the preloaded pin list.
>
> Are there concerns with this interpretation, or can we close out Issue 55?

I guess I'm just confused.  I agree it's rife for implementation
differences, but I either
A) Incorrectly parse this as punting on guidance that would (try to)
achieve parity across implementations and prevent yet another thing
that webmasters need to understand when requesting preloading in
multiple browsers
b) Correctly parse it as such, but don't understand why you would punt
on expressing a standard behavior instead.

-tom
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] Issue 56 - specify includeSubDomains for key pinning

[Tom Ritter]

On 4 March 2013 19:58, Ryan Sleevi  wrote:
> Is the added language acceptable? Are there any concerns with the
> validation/processing model that would prevent us from closing out this
> issue?

It took me a while to get it (so maybe a clarification appendix would
be good?), but I think I do and I think it works.

Although, I suppose there's no real support for a mechanism where
exmaple.com has includeSubdomains that applies to a, b, c.example but
d.example says "max-age=0".  D will wind up being pinned regardless.
I think that's okay, just noting it.



As an aside, Section 2.3.1 says
"Note the host as a Known HSTS Host if it is not already so noted"

I think that should be "Known Pinned Host"?  I thought we were
separating Require-SSL from Require-These-Keys.

-tom
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] Issue 54 - Adding a report-only mode

[Tom Ritter]

On 4 March 2013 20:09, Ryan Sleevi  wrote:
> I'd like to solicit feedback and make sure that both the discussions from
> Atlanta and from the list have been accurately captured. Are there
> concerns with a Report-Only mode that have not been accurately captured?

Obviously I wasn't in Atlanta, but I feel if you're sending the known
pins in the report (and you should) you should send the whole policy
as you know it, including directives, and some mechanism for max-age
that says 'when I think this will expire'.  Maybe even 'when I got
this directive' (if available) and 'where i got this directive from'
(preloaded vs header).

port should be an integer or a string, but one or the other. Why have
it be ambiguous?

-tom
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] Issue 53 - Key pinning should clarify status of pin validation with private trust anchors

[Tom Ritter]

On 4 March 2013 19:57, Ryan Sleevi  wrote:
> While there is an open question as to whether or not such user-agent
> behaviour is appropriate to specify here, does the group feel the proposed
> text sufficiently addresses the issue as originally raised?

I think it does, although I'm very curious about two points:

 - will implementations respect 'strict'?
 - who if any of the sites that have led the way on HSTS/pinning
(Google, Twitter) will enable strict

I guess we'll have to wait and see.

-tom
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #54: Specify a report-only mode

[Tom Ritter]

>>  On Thu, Oct 18, 2012 at 4:56 PM, websec issue tracker
>>  What are people's thoughts on this?

It hurts me to say so, because it's going to be more work and
complication and delay - but I agree a reporting system should be
added.

>>  The reporting interface must be one that is easy for site operators to
>>  implement — writing code to collect the reports should not be a huge
>>  burden for developers. Perhaps a simple JSON blob:
>>
>>  {
>>"pin-validation-succeeded": (true|false),
>>"expected-pins": [ "sha1/blahblah", "sha256/foobar", ... ],
>>"validated-chain": [ "PEM blob of EE", "PEM blob of intermediate",
>>  ..., "PEM blob of anchor" ]
>>  }

I like this, although I would include the entire PKP header, the Host
header, and request URI.

On 18 October 2012 20:40, Ryan Sleevi  wrote:
>   - Should the origin of the report URI be constrained the the origin of
> the target URI?

No, you should be allowed to specify a third party domain.  I could
easily see a third party service collecting these reports as a free or
paid service.  Google Webmaster Tools may even grow into collecting it
and CSP violations.

>   - Should the report URI be allowed to specify HTTPS?

Yes.  This is potentially sensitive information, and we would like it
to be protected in transit.

>   - If the report URI specifies HTTPS, and the report URI origin is the
> same as the target URI, but the report URI violates either the PKP or
> PKP-Report-Only policy, should the report still be submitted?

Honestly I don't see why not.  If it is an attacker, the attacker will
know the user rejected the TLS connection, and will have a good idea
it was because of pinning.  So what's the harm in telling them the
additional information.  Vs if it is a legit screw-up by the site,
they would still like to have the information.

> - Is there a blacklist or whitelist of headers that should be used to
> prevent against abuse or compromise. For example, presumably including
> cookies in the report submission for an invalid PKP over the same
> connection that generated the invalid PKP would be bad, as it may
> (will) lead to the compromise of the users' data.

I don't think any headers other than the PKP, Host, and URL would be needed.

>   - If the report contains validated certificates, what should the format
> be? draft-josepfsson-pkix-textual [3] may be of normative use here.

I have no opinion.

-tom
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] Fwd: New Version Notification for draft-ietf-websec-key-pinning-03.txt

[Tom Ritter]

On 18 October 2012 21:15, Chris Palmer  wrote:
> I think it's reasonable enough. However I did add this:
>
> """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. The UAs MUST ignore Public-Key-Pins response header fields
> received on HTTP (non-HTTPS) connections and on HTTPS connections that
> are not error-free."""
>
> to (hopefully) resolve this:
>
>> Similarly, I wonder if there was some situation that could result in
>> an attacker-induced 'errored' TLS connection that still sent the
>> header, resulting in the data being discarded...
>
> Thoughts?


Sorry, but I think that introduces more confusion.  Point 1 includes a
criteria and a "Do Something if not Criteria" but the following
paragraph after the Criteria also includes a "Do Something if not
Criteria".  I would suggest moving the "do something" out of the first
criteria.

I would suggest the following, which moves the 'do something' out of
criteria 1, clarifies that the discarding action only applies to
currently Pinned Hosts, and states explictly that when we say
"error-free TLS" this includes the validation in Section 2.4 if
applicable.


The UA MUST observe these conditions when noting a host:

   o  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. If the host is a Pinned Host, this includes the
  validation added in Section 2.4

   o  The UA MUST note the pins if and only if the TLS connection was
  authenticated with a certificate chain containing at least one of
  the SPKI structures indicated by at least one of the given
  fingerprints.  (See Section 2.4.)

   o  The UA MUST note the pins if and only if the given set of pins
  contains at least one pin that does NOT refer to an SPKI in the
  certificate chain.  (That is, the host must set a Backup Pin; see
  Section 3.1.)

   If the Public-Key-Pins response header field does not meet all three
   of these criteria, the UA MUST NOT note the host as a Pinned Host.
   A Public-Key-Pins response header field that meets all these critera is
   known as a Valid Pinning Header.

   The UAs MUST ignore Public-Key-Pins response header fields received on
   connections that do not meet the first criteria. If the UA recives
   a Public-Key-Pins header from a Pinned Host that meets the first
   criteria, but not the following two, the UA MUST discard any previously
   set Pinning Metadata for that host in its non-volatile store.



>> 2.5: "Pin Validity Times"
>>
>> I find the "current + current - initial" / "(b) the amount of time the
>> pin has been noted" item confusing, and am not sure what it means from
>> reading only the draft.  If I'm not the only one, it might be worth
>> clarifying.
>
> Yes, even after a lot of thought I am still undecided about this. I
> see several possible approaches:
>
> (a) simply have the validity time be the same as for HSTS;
> (b) the same as HSTS but with a 30-day maximum;
> (c) the current attempt to mirror TACK, except clarified and with examples; or
> (d) something else.
>
> Of these, I think I currently like (b) best. Thoughts?

I think A.  I believe (without evidence) there are institutions that
would eventually like to use this that have customers that work with
them on a quarterly or annual basis.  Likewise, I believe (without
evidence) that a institution who was risk adverse would mitigate that
risk by pinning to several large CA roots, not by saying "Oh well our
customers can't access us for the next 30 days, but it's only 30 days
who cares - but 60, that would be unacceptable!"

I do like TACK's notion of 'growing' out pins but only in a "That
sounds like a feature we're anticipating people wanting" way.  If
people actually hold off on deploying this because of that and that
alone, it SHOULD be possible to add a new directive, ignored by older
browsers who don't implement it.

Public-Key-Pins: max-age=600; grow-to=86400;
pin-sha1="4n972HfV354KP560yw4uqe/baXc=";

The spec should probably note that directives not understood should be
ignored, and not invalidate the header, to allow for future expansion.
 Right?

> I think you mean "clears dynamic pins"?

Yes, dynamic pins.

> I don't consider the implicit tracking cookie problem to be solvable.
> I think EFF's Panopticlick conclusively shows that it cannot be
> solved.
> ...
> I suppose we could press the Safe Browsing list into service for this
> (and data and API for that are open), but it's a stretch. SB is about
> malware and phishing, which is a different thing than implicit
> tracking.

I was actually saying "Chrome shouldn't ship preloaded pins for
Marketing Firms, because if a MF sends Pins to a user in Incognito
Mode, then the user closes Incognito Mode - MF can learn that a user
is a repeat visitor even though they visited in Incognito Mode."  But
AFAICT that would be all the information 

Re: [websec] Fwd: New Version Notification for draft-ietf-websec-key-pinning-03.txt

[Tom Ritter]

Some musings after reading again:

Section 2.3 "Noting Pins":

I wonder if it is worth moving "The UAs MUST ignore Public-Key-Pins
response header fields received on HTTP (non-HTTPS) connections."
outside the criteria to be unambiguous that a client should not
"discard any previously set Pinning Metadata" if it receives the
header over HTTP.  Or if it's reasonable enough to assume no one would
get confused.

Similarly, I wonder if there was some situation that could result in
an attacker-induced 'errored' TLS connection that still sent the
header, resulting in the data being discarded...

Section 2.4: "Validating Pinned Connections":

   For the purposes of Pin Validation, the UA MUST ignore
   certificates who SPKI cannot be taken in isolation and superfluous
   certificates in the chain that do not form part of the validating
   chain.

I know I just modified this, but the second phrase just hit me.
Because path construction is non-standard, could a client wind up in a
situation where the site pinned to CA_Alice, with the intended path
CA_Alice -> CA_Bob -> Intermediate -> Leaf; but because CA_Bob was
trusted, the ultimate validating chain was simply CA_Bob ->
Intermediate -> Leaf?  I'm not sure what the right way to counteract
that would be...

2.5: "Pin Validity Times"

I find the "current + current - initial" / "(b) the amount of time the
pin has been noted" item confusing, and am not sure what it means from
reading only the draft.  If I'm not the only one, it might be worth
clarifying.

2.6.  "Interactions With Preloaded Pin Lists"

If closing private browsing mode or clearing saved data also clears
preloaded pins (and I think it should), this would cause a revert to
the preloaded pins, which may break sites.  A workaround may be to
disable a preloaded pin if a new pin is seen, and keep that disabled
even after the saved data wipe/private browsing mode close.  To
prevent using this as a backdoor into tracking, the preloaded pins
should be sanity checked for "Is this organization likely to abuse the
feature."



Again, excited about this - thanks for the work.

-tom
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] [saag] Pinning

[Tom Ritter]

I don't know IETF procedure for making changes, but one of the
outstanding issues I don't think has been resolved with
draft-ietf-websec-key-pinning-02 is inherited DSA parameters.  I
raised this issue here:
http://www.ietf.org/mail-archive/web/websec/current/msg01027.html with
suggested verbiage.

-tom

On 11 August 2012 16:37, Yoav Nir  wrote:
> Hi Chris
>
> I've removed SAAG from CC, trimmed most of your message, and re-arranged the 
> rest. Hope you don't mind…
>
> On Aug 11, 2012, at 1:20 AM, Chris Palmer wrote:
>
>> Additionally, HPKP and TACK might converge, more or less. I have plans
>> to publish a new HPKP I-D that borrows some of TACK's pin activation
>> and expiration ideas, for example.
>
> 
>
> Just as a reminder, HPKP is now a working group draft. As such, change 
> control is with the WG. Changes that change the rules for activation and 
> expiration should be proposed and discussed on the list first.
>
> Having said that, we are pretty far from last call on key-pinning, so I think 
> it would be OK to publish a version -03 with such proposed changes, as long 
> as those changes are clearly marked as not being the result of WG consensus.
> 
>
> As an individual, I understand the limitations of the "spare public key" 
> approach of the current HPKP. It's an administrative hassle to generate n 
> spare keys and keep them safe, and if you have n+1 key compromise events 
> within the max-age time, your site is blocked. But it does have the big 
> advantage that the server side can be deployed *now* with no additional 
> software. Until I see how those borrowed ideas can help with these issues, I 
> prefer HPKP.
>
>> So ultimately I do think we should decide on either HPKP or TACK, but
>> that we should make that decision after there has been some real-world
>> deployment experience with both (or, sadly, real-world non-deployment
>> of one or both).
>
> Well, there's WG deciding, and there's the market deciding. The IETF can 
> publish both approaches (as either proposed standard or experimental) and the 
> one (if any) that the market prefers can later be upgraded to standard (or it 
> can stay at proposed anyway)
>
> Yoav
> ___
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] handling STS header field extendability

[Tom Ritter]

On 10 August 2012 17:52, Chris Palmer  wrote:
> Please forgive my ignorance, but do LockCA and/or LockEV offer any
> functionality that you can't already get with public key pinning as
> currently specified? You can pin to a given CA's public key(s), and
> you can pin to any given EV issuers' public keys.

I can't think of one for Lock CA; but LockEV could be useful for sites
that want to deploy some additional measure, but can't/don't want to
a) commit to a CA or b) enumerate all possible EV authorities.  It
should be ('should be', not 'is') more difficult to get a fraudulent
EV certificate through trickery or treachery than a DV certificate.

I don't think browsers differentiate between OV and DV in any
meaningful way, but I could be wrong.

-tom
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

[websec] Outstanding Issues on draft-ietf-websec-key-pinning-01

[Tom Ritter]

In 2.3, I believe

If the Public-Key-Pins response header field does not meet all four
   of these criteria

should be "all three of these criteria" by my bullet-point count.

To close up the hole with inherited parameters, in 2.2, prior to the
"We pin public keys" note, add:

  If the SubjectPublicKeyInfo of a certificate is incomplete when taken
  in isolation, such as when holding a DSA key without domain parameters,
  a public key pin cannot be formed.

And in 2.4, adding a phrase to the parenthetical comment in the big paragraph :

   If the connection has no errors, the UA will then apply a new
   correctness check: Pin Validation.  To perform Pin Validation, the UA
   will compute the fingerprints of the SPKI structures in each
   certificate in the host's validated certificate chain.  (The UA
   ignores certificates whose SPKI cannot be taken in isolation and
   superfluous certificates in the chain that do not form part
   of the validating chain.)  The UA will then check that the set of
   these fingerprints intersects the set of fingerprints in that host's
   Pinning Metadata.  If there is set intersection, the UA continues
   with the connection as normal.  Otherwise, the UA MUST treat this Pin
   Failure as a non-recoverable error.

Finally, I'd suggest the following change to 2.3.1, clarifying it's
required-ness and a max-age of 0.

2.3.1.  max-age

   max-age specifies the number of seconds, after the reception of the
   Public-Key-Pins HTTP Response Header, during which the UA regards the
   host as a Pinned Host.  The delta-seconds production is specified in
   [rfc-2616].

   max-age is a required attribute. If omitted, 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.

   If max-age is set to 0, the UA MUST likewise discard any previsouly
   set Pinning Metadata.

I won't be insulted if you dislike my wording, but I think this is a
complete summary of raised oustanding issues on -01.

-tom
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Tom Ritter]

On Nov 17, 2011, at 5:03 PM, Adam Barth wrote:
> Support.

+1

-tom
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] New draft of HTTP header-based public key pinning

[Tom Ritter]

My notes:

I believe the BNF (pseudo-BNF?) is incorrect:

Public-Key-Pins = "Public-Key-Pins" ":" LWS directives

   directives  = max-age LWS ";" LWS fingerprints
 / fingerprints LWS ";" LWS max-age

   max-age = "max-age" LWS "=" LWS delta-seconds

   pins= "pins" LWS "=" LWS fingerprints

   fingerprints= fingerprint
 / fingerprint "," fingerprints

   fingerprint = fp-type "-" base64-digits

   fp-type = "sha1"
 / "sha256"

I believe 'directives' should replace "fingerprints" with "pins":

   directives  = max-age LWS ";" LWS pins
 / pins LWS ";" LWS max-age



I think this paragraph is misworded:

UAs MUST have a way for users to clear current pins that were set by
   HSTS.  UAs SHOULD have a way for users to query the current state of
   Pinned Hosts.

Instead of HSTS, should that be "Public Key Pinning"?  If not, pins
set during HSTS must be flagged and treated differently - why?



Miscellany:

 - There is no directive or suggestion to User Agents about saving or
not saving pins received in a private browsing mode.  Maybe there
shouldn't be, but if a User-Agent does save them, the same 304/ETag
trick malicious sites use to track users can be created using certs
and subdomains.
 - The "Pinning Self-Signed End Entities" section was a bit confusing,
I had to read it a couple times to be sure you were talking about a
server's self-signed cert, and not a client cert.
 - The Pin-Break mechanism gets more complicated which each revision.
I know it's being shopped around for both this and the approach to put
pinning in the TLS layer (TACK), but does its removal implies pin
break codes are not intended to go into the final version of this
document, or will it be added later after the first bit is worked out?


Thanks Chris(es)!

-tom
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Tom Ritter]

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
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] separate pinning header (was: Pinning and beyond...)

[Tom Ritter]

On 14 October 2011 18:05, =JeffH  wrote:
> from  :
>
> Thoughts?

I agree.  Separating it into a header may also enable it to find its
way into other protocols that travel over TLS, and reuse some of the
same parsing/validation code.

-tom
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] Certificate Pinning via HSTS

[Tom Ritter]

I echo Marsh's question.  Does a x509 Key Fingerprint include
basicConstraints?  I couldn't imagine a scenario where an attacker could get
his own cert signed by a leaf cert of a website - but I also couldn't
imagine New York getting hit by an earthquake ;)

Other observations:

I find the Revocation section very confusingly written.

> "In the event of a mismatch, clients must check whatever revocation
mechanism is available and attempt to discover whether the certificate with
the mismatching fingerprint has been revoked."

What is the definition of mismatch?  I interpreted it as no cert in the
chain contains a fingerprint which matches one of the fingerprints in the
pin list (supplied via prior pinned directive, or preloaded list).
Therefore all certificates in the chain supplied by the site are
mismatching.  But seeing if they are revoked is useless, I want to check the
pinned list to see if any in the pin list is revoked, so I can reevaluate
the pinned list and possibly downgrade the site to 'Known HSTS Host'.  But
the pin list only contains fingerprints - how do I check if a cert is
revoked by fingerprint?


The "Interactions With Built-in HSTS Lists" section is does not cover UA
updates.  Should a UA update with new pin information overwrite pin
information previously validly supplied by a site?


Finally, I'm of the opinion that all SSL Certificate information should be
exposed as javascript properties by browser.  That's a bit out of scope, so
I'll dial it back and say while we're working on HSTS, HSTS information
should be exposed as a read-only javascript property.  It doesn't need to be
structured, the entire contents of the header is sufficient, similar to
document.cookie.  This would allow at least two more (optional) defensive
practices:

1) Plugin/Extension/Greasemonkey authors could produce something like
HTTPSEverywhere or NoScript that could preload pins in a method similar to
preloaded pins in a UA.  If a site sent a pin list that didn't match the
preloaded pin list, the extension could show a warning, error, or some
alert.  Although similar to preloaded pins, this would not require a UA to
do work, nor would it require a UA to supply a user interface to bulk-load
pins.

2) Site authors could include checks in javascript to check their pinned
list.  While this *is* an arms race, and any javascript that is already
being middled by an attacker *could* be rewritten - in practice, javascript
can be sufficently obfuscated to raise the barrier to exploitation (see
gmail's javascript for example).

-tom
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec