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 >> users that the Host is no longer a Known Pinned Host. >> >> 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. 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. >> -- 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. 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. >> 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. 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 _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
