Re: Adding Security Considerations regarding interception to p1

Hi Stephen,

On Fri, Sep 20, 2013 at 11:50:27AM +0100, Stephen Farrell wrote:
> > I find it better, but I'm still worried about promoting TLS to fix this
> > with half a solution because we present TLS as a drop-in fix which is not
> > true. 
> 
> That seems purely pejorative to me. In practice, TLS is the too
> that's available here. Ignoring that because its imperfect would
> be dumb.

That's not my point, my point is that it's fairly possible to use TLS as
badly as clear text, providing no security at all with the difference that
you feel secure. And to me, feeling secure is much worse than not feeling
secure.

> > I think there is nothing wrong in saying that TLS completely addresses
> > the issues only when reciprocal authentication is used (ie where the client
> > can be trusted as well), and most of the issues (especially related to web
> > browsing) when the server's authentication is enforced on the client. 
> 
> I have no idea what you mean. Are you saying that client-auth is
> required in order to do better with privacy?

Not privacy, but security in general. And in some cases it can even be about
privacy. When my tax office requires my cert to log in, I'm more confident
that I'm the only one to be able to consult my account than if it only
requires my previous tax amount.

> That'd seem like a load of nonsense, so I guess you're not saying that.

For the general web I'm not saying that.

> > Also
> > we must not forget that this will probably be the last spec of HTTP/1.1 and
> > that it will live forever. Who knows if TLS will still exist in 10 years ?
> 
> Now that's definite nonsense. The probability that HTTP (of any
> version) will be protected only using technology that's not
> genetically related to TLS in 2023 can only be reasonably
> estimated at zero.

Maybe in 2013 we'll be saying everywhere "please stop using TLS, it's totally
dead and cracked, disable it by default from browsers" as we used to say about
SSLv2 for a long time. Except that if a standard recommends a precise
implementation, it creates confusion and discredits all the standard. I'd
rather say "use encryption and authentication which at this time is provided
by TLS when properly deployed" than "use TLS".

> > We killed SSLv2 pretty quickly for example. That's why I'd rather talk about
> > the principles than explicitly suggesting protocols that we might regret
> > later (though they should be cited as examples).
> > 
> > Passive interception on the web is just a detail IMHO. 
> 
> Recent events would seem to indicate otherwise unless you consider
> all of Snowdonia to be a "detail".

I don't know, I've never heard about "Snowdonia", all I can find is
related to a city. However, my point remains that many times, passive
interception already requires active interception (presenting yourself
as the gateway), which is true in switched networks. Right now it's
enough to just route the traffic, but it's not harder to proxy it
when you can route it. And students with nothing to do on their holidays
will quickly come with an easy to use tool. Look how Firesheep appeared!
Who would have imagined that it was possible to sniff from a browser!

> I would love to see this WG do a great job of helping folks to
> deploy HTTP1.1 over TLS better.

That's my goal as well, and I think that telling them that using TLS
*correctly* is a solution is fine, but making them believe that "just
switching to TLS" is the solution is worse than the current solution.

> It should though at least
> acknowledge the issues and the major countermeasure that does
> get deployed and encourage that. And I think text along the
> lines Mark initially suggested, or some of the reasonable
> alternative suggestions, seems like the minimum that needs to
> be done.

Yes very likely, which is why I've been proposing some ideas which
I know are not properly worded, but try to help spot the correct line
between the two.

Regards,
Willy

Received on Friday, 20 September 2013 16:30:43 UTC