Re: [perpass] Traffic peeking

[S Moonesamy <[e-mail]>]

Hi Iain,


Thanks for the feedback.

At 14:37 24-11-2013, Learmonth, Iain Ross wrote:
> >   In 2007, Dan Shumow and Niels Ferguson discussed about the
> >   possibility of a backdoor in a Dual Elliptic Curve  pseudorandom
> >   number generator [Rump].
>
>I'm not sure how this paragraph is relevant to the rest of the 
>draft. You only discuss the use of encryption, not particular schemes.

The sentence is more of a lead-in to standardization of encryption 
schemes.  Discussing about particular schemes is like jumping into 
the solution.  I'll look into the above again once the SAAG minutes 
are published.


> >   Entities exchanging traffic over the Internet should assume that any
> >   traffic which is not encrypted will be intercepted given that peeking
> >   is irresistible.
>
>This should probably be re-worded to be something like "any traffic 
>which is not encrypted should be assumed to be compromised". Let's 
>be honest, they're not capturing and storing every single bit of 
>traffic, they definitely don't have the capacity for that.

In my humble opinion it is more complicated than that.  I agree that 
not all traffic is being captured and stored.  The usage of the term 
"meta-data" within the IETF is different from that used in other 
venues.  The reduction in what could be stored is 1:150 (unverified 
information).  I'll go with the wording you proposed as it is a better fit.

> > The Hypertext Transfer Protocol (HTTP) [RFC2616] is widely used to
> > access the web.   The protocol is sometimes used to provide web access
> > to email.  Section 15 of RFC 2616 [RFC2616] does not provide any
> > guidance about encrypting the traffic generated by the protocol.
>
>This is currently being discussed by httpbis[1] and any discussion 
>related to the use of encryption with HTTP should be had there.

I avoided mentioning protocols which are work in progress, i.e. what 
is being discussed in HTTPBIS.

>The other protocols will be discussed by the new uta (Using TLS in 
>Applications) working group[2].

I don't recall joining that mailing list.  I'll take a look at it.

>Other bits in general, there's a lot of talking about state 
>sponsered surveillence, but there are other problems too. Botnets 
>with nodes operating behind firewalls can sniff the wires, rouge 
>sysadmins, anyone who can poison BGP tables, etc.

In a way the above highlights the problem.  The discussion has been 
focused on state sponsored surveillance while there has been little 
discussion of the other problems.

>Encryption is also only half the solution, the other half is 
>authentication as if you're sending your data encrypted straight to 
>the NSA while they MitM you, you've solved nothing.

The problem with authentication is that it can cause a problem for 
anonymity.  Every solution comes with its share of problems.  The 
draft does not discuss the entire matter as an IETF security 
problem.  It recognizes that some of issues are related to 
policy.  If you put policy in a protocol people won't like it.  The 
people will find a way around that and you won't like that.

>Given that one of the stated tasks for the uta working group is:
>
>"- Specify a set of best practices for TLS clients and servers, 
>including but not
>limited to recommended versions of TLS, using forward secrecy, and one or more
>ciphersuites and extensions that are mandatory to implement."
>
>I believe that this draft would be more suited to be being discussed there.

Although the draft mentions some application protocols it isn't 
specific to applications.  I doubt that that proposed working group 
would take up the draft.

Regards,
S. Moonesamy