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