(While still on holiday...) On 01/01/2014 07:15 PM, Brian E Carpenter wrote: > On 02/01/2014 00:41, Yoav Nir wrote: >> On Jan 1, 2014, at 12:32 PM, Russ White <russw@xxxxxx> wrote: >> >>>> We should not approve an IETF policy statement >>>> until we have a good idea of the way we will use it. >>> I'm struggling a bit with this statement -- it seems just as broad as the >>> draft under discussion, and just as much of a "policy" as the draft under >>> discussion. >>> >>> What does a "good idea," actually mean? >> >> I guess a "good idea" would be a checklist for document authors, document shepherds, and IESG members on what they need to consider in a document to ascertain whether it complies with this BCP nn. > > IMHO that is exactly the wrong goal for this draft, which is a statement of > aspiration. I would expect the checklist to come from much more technical > documents to be developed over time. > > I'm close to concluding that the present draft should not be a BCP at all, > just as RFC 1984 and RFC 2804 were not BCPs. Since it is derived from an > IAB-organised plenary, why not just make it an IAB stream Informational > document co-signed by the IESG? (With a few cosmetic text changes.) > Just get it published so that we can do the real work, as Randy says. I disagree. I think if we constantly desist in taking any action because there are inevitably a number of nay-sayers, then we've lost. And in this particular case, a BCP is exactly the right thing. (I'll respond in more detail tomorrow, but do have to say that there looks to be a lot of repetition in the last day's mails.) S. > > Brian > >> We know what to look for in a security review. We know somewhat less well, but in a vague way what to look for in terms of privacy. I have no idea what to look for to counteract pervasive surveillance. Just as an example, let's look at a particular draft, and assume that it is ready for last call, and I need to write the shepherd's write-up. >> >> I'll choose draft-ietf-httpauth-hoba-02. >> >> The draft is about an authentication method for HTTP, where an asymmetric per-origin key pair is used to authenticate the user (or rather, the user agent) to an HTTP server. >> >> So now we have to make assumptions about our pervasive surveyor (is that the word?): >> 1. Can they decrypt TLS? >> 2. Can they see the plaintext of the authentication process? >> 3. Can they see the plaintext of the registration process? >> 4. Can they retrieve the public key database at the server? >> 5. Can they plant entries in the public key database, using perhaps the procedure in section 6.2, allowing them to impersonate the user? >> >> If they can do #1, they may be able to do #2 and #3, and then #4 is superfluous. If they have access to the public key (through #3 or #4) and access to the authentication plaintext (#2) then they can track where the user is logging in from. >> >> There are so many capabilities we can imagine that the nation state adversary may have, and we only have a vague notion of what information must be prevented from leaking to such an adversary. I don't think that I can check a document to make sure it won't be smacked down in IETF LC or at the IESG for not complying with BCP nn. >> >> Also, what if we can hide more information out of a protocol, but at the expense of another roundtrip or more processing power. Who gets to balance the two goals? >> >> Yoav >> >> >> >