On 18 October 2012 21:15, Chris Palmer <pal...@google.com> 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 a Marketing Firm would be
able to learn - binary visited or not.
BUT: Even if UAs did not ship pins for Marketing Firms, it wouldn't
matter because an attacker could use Cross Origin Img Loads with a
stolen certificate to learn the same amount of information (whether a
user visited in Incognito mode) about a valid, non-marketing site
(e.g. Abuse Counseling site).
> It could at best be a "UAs MAY choose to ignore HSTS and pinning
> metadata for certain sites... a mechanism to do so is beyond the scope
> of this I-D..." thing.
I recant, I don't think this is necessary, because the above is not
solvable in the technical constraints and Incognito Mode clears pins.
-tom
_______________________________________________
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec
