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

From: Chris Palmer <[email-masked]>
Date: Thu, 3 Jul 2014 20:52:28 -0700

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 <[email-masked]> 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...

---

From: Barry Leiba <[email-masked]>
Date: Fri, 4 Jul 2014 09:46:25 -0400

Hey, Chris.  Thanks for all the changes, and after I send this message
I'll request last call.  I think I'll make it a four-week last call,
because there won't be a telechat we can put it on until after that
anyway, so we might as well give people time during and after the IETF
meeting to comment.

The only thing we still have in contention is the UI advice, and I'm
not going to let that hold anything up at this point.  Further
comments:

>>    The UA SHOULD indicate to

On this, as well as the other points of UI advice (Section 2.7, at
least; I don't remember whether any others remain), I still think it's
not a good idea for the protocol spec to give UI advice, but I'm OK
with leaving it in if we don't use 2119 language for it.  2119 is
specifically for protocol interoperability issues.  So let's make the
SHOULDs be "should"s, and then see if anyone else raises an issue with
that.

> I don't think we've considered that. Perhaps we should simply specify

That's probably best, if we're not sure of the answer.  You can say
that extensions to this can specify how key pinning is used with other
protocols.

> determination of site operator maturity.

OK.  Enough said on this, then -- leave it as it is.

So: I'll wait a couple of hours to give you time to post one more
revision, if you want to make the changes above.  Whether or not you
do, I'll request the last call then.  (Please don't post a revision
after you see the last call requested... we can save the changes for
later, at that point.)

Again, thanks for all the work on this!

Barry

---

From: Chris Palmer <[email-masked]>
Date: Fri, 4 Jul 2014 10:46:49 -0700

> anyway, so we might as well give people time during and after the IETF

OK, sounds good. New version is on the way; as always, you can see the
diffs at https://code.google.com/p/key-pinning-draft/source/list.

Thanks again Barry, and everyone!

---

From: Barry Leiba <[email-masked]>
Date: Sun, 6 Jul 2014 09:58:47 -0400

> diffs at https://code.google.com/p/key-pinning-draft/source/list.

For everyone's info:
I did request last call on this on Friday, but, as it was a U.S.
holiday followed by a weekend, the Secretariat hasn't been there yet
to act on it.  Expect to see the last call message go out on Monday.

Barry