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
_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass
