On Jan 1, 2014, at 12:32 PM, Russ White <russw(_at_)riw(_dot_)us> 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