Xiaoyin Liu | 7 Nov 07:56 2014

HSTS: Infinite max-age to address NTP spoofing attack?

 I recently read the slides "Bypassing HTTP Strict Transport Security" by
Jose Selvi.[1] It seems to me that one way to address NTP spoofing attack
on HSTS is to allow sites to specify HSTS policies that never expire (i.e.
infinite max-age), so that the enforcement of HSTS does not depend on the
system time.
 
So I want to propose a update to RFC 6797 to define a new directive called
"infinite" (or something else). When a UA sees this directive, max-age
should be ignored and HSTS should always be enforced until users clear the
cache or the server sends a valid STS header without "infinite" directive.
 
The new header field will look like:
  Strict-Transport-Security: max-age=31536000; infinite
 
Of course, many websites will be unwilling to set infinite max-age, so this
attack is not completely addressed. However, I think this new directive
should help a lot, because some websites, especially those that need to
send and receive sensitive information, such as online banking, are very
unlikely to revert to HTTP in the future. Also, a very long max-age, such
as 20 years used by Twitter, is effectively infinite, but long max-age is
subject to the NTP attack, while an explicit "infinite" is not.
 
Any comments on this? Thanks!
 
Best,
Xiaoyin
[1] https://www.blackhat.com/docs/eu-14/materials/eu-14-Selvi-Bypassing-HTTP-Strict-Transport-Security-wp.pdf
<div><div dir="ltr">&nbsp;I recently read the slides "Bypassing HTTP Strict Transport Security" by <br>Jose Selvi.[1] It seems to me that one way to address NTP spoofing attack <br>on HSTS is to allow sites to specify HSTS policies that never expire (i.e. <br>infinite max-age), so that the enforcement of HSTS does not depend on the <br>system time.<br>&nbsp;<br>So I want to propose a update to RFC 6797 to define a new directive called <br>"infinite" (or something else). When a UA sees this directive, max-age <br>should be ignored and HSTS should always be enforced until users clear the <br>cache or the server sends a valid STS header without "infinite" directive.<br>&nbsp;<br>The new header field will look like:<br>&nbsp; Strict-Transport-Security: max-age=31536000; infinite<br>&nbsp;<br>Of course, many websites will be unwilling to set infinite max-age, so this <br>attack is not completely addressed. However, I think this new directive <br>should help a lot, because some websites, especially those that need to <br>send and receive sensitive information, such as online banking, are very <br>unlikely to revert to HTTP in the future. Also, a very long max-age, such <br>as 20 years used by Twitter, is effectively infinite, but long max-age is <br>subject to the NTP attack, while an explicit "infinite" is not.<br>&nbsp;<br>Any comments on this? Thanks!<br>&nbsp;<br>Best,<br>Xiaoyin<br>[1] <a href="https://www.blackhat.com/docs/eu-14/materials/eu-14-Selvi-Bypassing-HTTP-Strict-Transport-Security-wp.pdf">https://www.blackhat.com/docs/eu-14/materials/eu-14-Selvi-Bypassing-HTTP-Strict-Transport-Security-wp.pdf</a><br>
</div></div>
Anne van Kesteren | 29 Oct 19:55 2014
Picon

HSTS at DNS level

Is there some way we could add an annotation to DNS that makes it
clear a given domain for the purposes of HTTP is only available over
port 443 using TLS? DNS can be easily spoofed of course so you also
want HSTS, but perhaps it would be sufficient to be able to disable
port 80 entirely.

--

-- 
https://annevankesteren.nl/

Hodges, Jeff | 17 Oct 02:22 2014
Picon

wrt closing the websec WG (was: DISCUSS positions on draft-ietf-websec-key-pinning

On 10/11/14, 1:03 PM, "Barry Leiba" <barryleiba <at> computer.org> wrote:

>  The working group will officially remain open until the RFC is
>published, after which I'll close it, but will leave the mailing list
>open for any continued discussion.

Yes, please do leave the mailing list open, the Web is a percolating pot
and there may well be more protocol-level security stuff boiling over into
IETF territory (I don’t have a firm example right now, but something along
the lines of defining more generic policy-expression format(s) is not hard
to imagine), and so perhaps similar to what we did with HTTP-State, who
knows, we might have a need to re-spin it up.

Thanks,

=JeffH

_______________________________________________
websec mailing list
websec <at> ietf.org
https://www.ietf.org/mailman/listinfo/websec
IETF Secretariat | 13 Oct 17:13 2014
Picon

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

IESG has approved the document and state has been changed to Approved-announcement sent
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/

Jeffrey Walton | 14 Oct 18:33 2014
Picon

Question on Pinning Overrides

Section 2.7 states:

   UAs MAY choose to implement additional sources of pinning
   information, such as through built-in lists of pinning information.
   Such UAs should allow users to override such additional sources,
   including disabling them from consideration.

>From section 2.7, I understand a _user_ can provide an override to a
_preloaded_ pinset. But I don't see where a user is provided the
authority to override a non-preloaded pinset. And I don't see where an
external entity is provided authority to override a preloaded or
non-preloaded pinset.

Is this correct?

If correct, shouldn't the user be allowed to override both preloaded
and non-preloaded pinsets?

If correct, won't that break Chrome with respect to
http://www.imperialviolet.org/2011/05/04/pinning.html (see section
"What about MITM proxies, Fiddler etc?")?

The IESG | 13 Oct 17:13 2014
Picon

Protocol Action: 'Public Key Pinning Extension for HTTP' to Proposed Standard (draft-ietf-websec-key-pinning-21.txt)

The IESG has approved the following document:
- 'Public Key Pinning Extension for HTTP'
  (draft-ietf-websec-key-pinning-21.txt) as Proposed Standard

This document is the product of the Web Security Working Group.

The IESG contact persons are Barry Leiba and Pete Resnick.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/

Technical Summary

This spec 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.

Review and Consensus

Previous versions of this document received useful reviews on the 
mailing list. Many changes were introduced due to working group 
consensus, including to pin format, an includeSubdomains directive,
and interaction with private trust anchors. 

Some changes were proposed and rejected by the working group,
most notably named pins, a "strict" directive, and hard limits on the 
max-age directive. The consensus on these involved a long and hard 
discussion, but as chairs, Tobias and I believe that it is a regular
rather than rough consensus.

Two issues that were left for last were the interaction of pre-loaded
pins with noted pins, and the processing of report-only pins. There 
was a lot of controversy and a lot of back-and-forth about these 
issues. We believe that the current drafts represents the working
group's consensus, although at least one participant would have 
preferred a different outcome.

Personnel

Yoav Nir is the document shepherd. Barry Leiba is the responsible
Area Director.

IETF Secretariat | 11 Oct 21:52 2014
Picon

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

IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/

Kathleen Moriarty | 11 Oct 21:10 2014
Picon

Kathleen Moriarty's No Objection on draft-ietf-websec-key-pinning-21: (with COMMENT)

Kathleen Moriarty has entered the following ballot position for
draft-ietf-websec-key-pinning-21: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for the adjustments to address my concerns/questions.

Stephen Farrell | 9 Oct 14:42 2014
Picon
Picon

Stephen Farrell's Yes on draft-ietf-websec-key-pinning-21: (with COMMENT)

Stephen Farrell has entered the following ballot position for
draft-ietf-websec-key-pinning-21: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for clearing up my discuss points. One possible
remaining nit though:

- In 2.2 you say: "(1) the processing rules for HTTP
   request messages received over a secure transport (e.g.
   authenticated, non-anonymous TLS); "

Should the "e.g." be an "i.e." ? It's probably fine either
way but just wondered.

-- OLD comments below, didn't check 'em

abstract and elswhere: SubjectPublicKeyInfo doesn't usually
have spaces between the terms. No big deal. After the abstract
would a ref to 5280 be right for SPKI as well?

general: I think emphasising the backup pin requirement in the
intro would be good. It's a little hidden now and would be a
surprise to some I bet.

2.1 - pin-directive has the literal "pin-" but later you say
(in bullet #3) that directive names are case insensitive.  Does
that apply to "pin-" as well or not? 

2.1 - has some typos: reistry and hahs

2.1 - "Known Pinned Host" would be a fine term to define in a
section 1.1 that was renamed via s/Requirements
Language/Terminology/

2.1.1 - max-age is really defined against the time of reception
and not (in principle) from when its emitted?  I know that
makes no difference now, but with a sufficient latency (e.g.
Earth->Mars, min 4 mins, max 20 mins, and yes my DTN heritage
is showing:-) it could, just about. I think to be pedantically
correct, max-age ought be defined versus the time of emission
and not receipt.

2.1.2 - uses the term "Pinned Host" which is not the same as
the previously used "Known Pinned Host" - is the distinction
meant to be significant or is that a typo?

2.1.3/section 4 - shouldn't the potential DoS issues be
discussed for cases where report-uri != same-origin? E.g.  if
busy-site.example.net (is hacked and) sets report-uri to
victim.example.com (maybe with some HTML/JS that generates
loads of queries to the victimj) that'd be like getting /.'d I
think that's maybe worth noting in the security considerations
or in 2.1.3 where you (quite properly) say to rate-limit
reporting. If you'd rather not say why though, that's ok too.

Ted Lemon | 8 Oct 17:02 2014

Ted Lemon's No Objection on draft-ietf-websec-key-pinning-21: (with COMMENT)

Ted Lemon has entered the following ballot position for
draft-ietf-websec-key-pinning-21: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I've cleared my DISCUSS.   For the record, here it is, but there is no
further action required:

This mechanism relies on there being no MiTM attack from a compromised
signing key either prior to a legitimate pinning, or in a situation where
the host being "protected" doesn't actually do pinning.   I think this
should be mentioned in the security considerations section.   I raise
this to the level of DISCUSS because I think this actually creates a new
attack surface for government censorship: you MiTM the host you're
attacking, pin it to a cert signed using a compromised CA, and then that
UA can't communicate with the host again for the duration of the pin.

The scenario would be that the government has a transparent web cache in
the path between the host and the UA, and the web cache pins false cert
for hosts that are being censored.   Now even if the user sets up a
tunnel to bypass the transparent cache, they can't access the censored
site, so they conclude that the site is down and abandon the tunnel.   I
could easily see this being used in a scenario like the recent DNS
censorship in Turkey.

Setting a lower maximum pin age mitigates the damage of such attacks if
the user keeps the tunnel up for the duration of the pin, but I don't
think it's realistic to assume that they will.   I think that the only
way to mitigate this attack is to have a mechanism whereby conflicting
DANE TLSA information overrides the pin.   This would allow a site being
attacked in this way to securely inform the UA that the pin was invalid. 
 The government could of course prevent DNSSEC validation, but the UA
could take this as another signal to drop the pin: if the zone where the
TLSA record should be fails to validate (as opposed to isn't signed,
which wouldn't signify anything), the pin is likely a censorship attempt.

internet-drafts | 6 Oct 03:23 2014
Picon

New Version Notification - draft-ietf-websec-key-pinning-21.txt


A new version (-21) has been submitted for draft-ietf-websec-key-pinning:
http://www.ietf.org/internet-drafts/draft-ietf-websec-key-pinning-21.txt

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

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-ietf-websec-key-pinning-21

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

IETF Secretariat.


Gmane