ietf
[Top] [All Lists]

Re: Last Call: <draft-farrell-perpass-attack-02.txt> (Pervasive Monitoring is an Attack) to Best Current Practice

2014-01-01 13:16:02
On 02/01/2014 00:41, Yoav Nir wrote:
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. 

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




<Prev in Thread] Current Thread [Next in Thread>