Re: [websec] AD review of draft-ietf-websec-key-pinning-17

[Chris Palmer <[e-mail]>]

Thanks Barry, for your many excellent contributions. I've incorporated
most everything you and Yoav suggested. Some additional discussion
below:

On Thu, Jun 26, 2014 at 4:00 AM, Barry Leiba <[e-mail]> wrote:

> NEW
>    When a connection passes Pin Validation using the UA's noted pins
>    for the Host at the time, the Host becomes a Known Pinned Host.
>
>    According to rule 5, above, the UA MUST ignore pin-directives with
>    tokens naming hash algorithms it does not recognize.  If the set of
>    remaining effective pin-directives is empty, and if the Host is a
>    Known Pinned Host, the UA MUST cease to consider the Host as a Known
>    Pinned Host (the UA should fail open).  The UA SHOULD indicate to
>    users that the Host is no longer a Known Pinned Host.
> END
>
> On the last sentence, though, I'm really unsure: are we really giving
> UI advice in a protocol document?  Is that a good idea?  Do w have any
> sense that my mother will have the first idea what you're talking
> about when you indicate this to her?

We feel that the minimal UI currently implemented in Chrome is
necessary for at least developers, operators, and organizational IT
staff to debug and generally cope with pinning. (In Chrome, visit
https://pinningtest.appspot.com/ and chrome://net-internals/#hsts.) By
"users" we mean not only non-technical people, but technical people
also. It is indeed likely to be the case that non-technical users will
never see any of this UI or care about pinning, but site operators
certainly will.

Additionally, we want to leave open the possibility that pinning
status could be exposed to users in some way. For example, we expose
Certificate Transparency status in Chrome: Click on the Lock icon to
bring up what we call the Page Info Bubble, then click the Connection
tab. The phrase "...does [not] have public audit records" is our CT
UI. Obviously, this is more "technical user-facing", but that such
indicators may be important for pinning as they are for CT.

That said, I am open to softening the language further.

> -- Section 2.1.3 --
> What does it mean to use POST on a URI that isn't http or https?  What
> do you do with a wss URI, for example?

I don't think we've considered that. Perhaps we should simply specify
HTTP or HTTPS.

>    The UA MUST ignore all
>    expired Known Pinned Hosts from its cache if, at any time, an expired
>    Known Pinned Host exists in the cache.
>
> Eh?  I don't understand what this is trying to say.  Do you mean "MUST
> *remove* them from its cache?  What's with the "at any time" bit?
> Please try rephrasing this -- I don't understand it well enough to
> try.

I gave it a bit of a rewrite, see what you think.

>    Although the UA has previously received Pins at the HTTP layer, it
>    can and MUST perform Pin Validation at the TLS layer, before
>    beginning an HTTP conversation over the TLS channel.  The TLS layer
>    thus evaluates TLS connections with pinning information the UA
>    received previously, regardless of mechanism: statically preloaded,
>    via HTTP header, or some other means (possibly in the TLS layer
>    itself).
>
> Can you re-word this?  It seems very strained, and I don't understand
> it.  There's no background for telling me what the UA has previously
> received.  I thought Pins *only* happened with TLS, so how can they
> have been received without it?  And please avoid phrasing such as "can
> and MUST"; it if MUST, it clearly can, or else the MUST is
> meaningless.

I also re-worded this a bit.

> -- Section 2.7 --
> In the first sentence, again, you're giving UI advice, and advice that
> I find questionable.  This is an option that will *only* be applicable
> to expert users, and that won't be understood, much less used, by
> 99.999% of UA users (certainly not by my mother).  I can't imagine how
> such advice, well intentioned though it may be, merits a SHOULD.

As above, this might mean something like "your company's IT staff set
up pre-loaded pins for your internal mail servers" or "your company's
IT staff doesn't want to use the pre-loaded pins that come with Foo
Browser." Only the IT people are likely to noodle around in an
interface as rudimentary as chrome://net-internals/#hsts, and that is
OK.

Control of policy should rest in the hands of the device owner, not
the UA vendor — hence the SHOULD.

>    Because having a backup key pair is so important to recovery, UAs
>    MUST require that hosts set a Backup Pin. (See Section 2.5.)
>
> Unless I misunderstand, this requirement means that if my server
> doesn't send a backup pin, my server doesn't benefit from key pinning
> (it's as though I never included the header in the first place).  If
> that's not true, then Section 2.5 needs to be fixed to make it clear
> that failure to include a backup pin constitutes a validation failure.
>
> If that is true, then you're trading off recovery for security, and I
> expect the Security ADs to question that.  To head that off, it might
> be good to acknowledge that here, and perhaps to say a few more words
> about it.

Correct. We discussed this at length during the drafting of the
specification, and I'm happy with where we ended up. We are trading
off availability vs. extra-bonus-strong authentication. For pinning to
be viable in the topsy-turvy world of the internet, we have to do
something to help site operators from inadvertantly DoSing themselves.
The Backup Pin requirement gives us that, and also serves as a way for
the UA (which knows very little) to make some minimal run-time
determination of site operator maturity.

Publishing the new version of the draft momentarily...