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. 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 > > >