Subject: [perpass] Traffic peeking

From: S Moonesamy <[email-masked]>
Date: Sun, 24 Nov 2013 12:29:17 -0800

Hello,

I posted a draft about traffic peeking [1].  Comments are welcome.

Regards,
S. Moonesamy

1. http://tools.ietf.org/html/draft-moonesamy-traffic-peeking-00

---

From: "Learmonth, Iain Ross" <[email-masked]>
Date: Sun, 24 Nov 2013 22:37:16 +0000

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

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

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

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

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.

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.

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.

Iain.

[1]: http://datatracker.ietf.org/wg/httpbis/charter/
[2]: http://datatracker.ietf.org/wg/uta/charter/

--
Iain R. Learmonth MBCS
Electronics Research Group
School of Engineering
University of Aberdeen
Kings College
Aberdeen
AB24 3UE

Tel: +44 1224 27 2799

The University of Aberdeen is a charity registered in Scotland No.SCO13683

________________________________________
From: perpass <[email-masked]> on behalf of S Moonesamy <[email-masked]>
Sent: 24 November 2013 20:29
To: [email-masked]
Subject: [perpass] Traffic peeking

Hello,

Regards,
S. Moonesamy

_______________________________________________
perpass mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/perpass

---

From: S Moonesamy <[email-masked]>
Date: Sun, 24 Nov 2013 16:10:16 -0800

Hi Iain,

Thanks for the feedback.

At 14:37 24-11-2013, Learmonth, Iain Ross wrote:
>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.

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

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

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

>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

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 25 Nov 2013 14:24:37 +0000

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

I don't believe a list was setup for that just yet. The
charter was sent out for review on the IETF list [1] on
Friday last.

I'd say discussion of that charter would be best done on
[email-masked] since its proposed as an APPS area
WG and the apps-discuss list is probably where there's
the best concentration of relevant expertise, so please
direct any substantive discussion there.

Assuming the WG gets approved, which I'd expect, we'll be
able to chalk that one up as having being sufficiently
triaged here:-)

S.

[1] http://www.ietf.org/mail-archive/web/ietf-announce/current/msg12140.html