W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: MLS or TLS? There is more than one encryption option.

From: Phillip Hallam-Baker <hallam@gmail.com>
Date: Fri, 15 Nov 2013 23:56:48 -0500
Message-ID: <CAMm+LwhzOs9KdsvCKTtDRFWXHm4-zgPUQ0jM+Vh2eg7g-e5M1A@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On Fri, Nov 15, 2013 at 7:34 PM, Stephen Farrell

> On 11/16/2013 12:15 AM, Phillip Hallam-Baker wrote:
> > On Fri, Nov 15, 2013 at 6:37 PM, Stephen Farrell
> > <stephen.farrell@cs.tcd.ie>wrote:
> >
> >>
> >> Phill,
> >>
> >> I *know* you know better than to use terms like "weak TLS"
> >> which you *know* is purely rhetorical and doesn't help here
> >> at all. There is no "weak" variant of anything that's been
> >> put on the table by anyone credible, nor does that adjective
> >> really make sense when put in front of any cryptographic
> >> protocol. This discussion needs more precision and not less.
> >>
> >> If you mean unauthenticated TLS then say so.
> >
> >
> > Laking authentication means that it only prevents passive attack. Ergo it
> > is weaker.
> No. Firstly, there was a proposal for doing an unauthenticated
> mode of TLS for http:// URIs, which now (unfortunately IMO)
> seems sidelined. If you want to descend to ridiculously coarse
> terminology, then that'd be "stronger" than the status quo ante.
> Nobody has suggested changes that affect https:// URIs at all
> so you're attacking a proposal that simply hasn't been made.
> Mark's subsequent proposal is to in fact run TLS as-is, with
> the only change being that http:// URIs will (somehow) all be
> re-directed to https:// URIs. While I don't like that so much,
> it actually involves no unauthenticated TLS at all.

Then maybe I am reading in more to some of the arguments than the people
behind them intend.

What is worrying me is the idea that we have to do something about
pervasive monitoring and this is so important that it blocks all other
security concerns. First do no harm.

> >> If your claim
> >> is that that is "weaker" than server-authenticated TLS then
> >> presumably you think that is in turn "weaker" than mutually
> >> authenticated TLS, which is obviously a dumb argument, so
> >> I conclude your phraseology can only be useless rhetoric.
> >>
> >
> > Using terms like 'dumb' in that fashion is probably against the diversity
> > policy.
> So bite me:-) Actually though its not. I said your argument was
> dumb and why.

My point was that equating a particular disability with stupidity is non-PC
these days.

> > TLS with either CA issued certificates or out of band trust configuration
> > is a practical widely deployed technology. This proposed 'no
> > authentication' TLS is not.
> Disagree, to an extent. Yes had httpbis wanted to do unauth
> TLS beneath http:// URIs then there would be some new stuff.
> But its pretty much the same as using self-signed certs, so
> there is actually plenty of real experience with deploying
> that.

That is what I was thinking last week.

I am not so happy now having read the discussion.

> > And removing certificates from TLS would not? I think that would require
> > rather more of an upheaval than you imagine.
> >
> > And HTTP + TLS + PKIX is hardly a trivial stack to implement. Care to
> > implement that in VLSI logic?
> I've no idea what you mean, but I think that's ok.

We have quite a few HTTP/1.1 implementations in very low level technology.
It appears in industrial controllers in microcode.

I don't think we can expect people to do ASN.1 in microcode.

> Defining a new protocol is not a trivial exercise but in my experience
> > attempting to remove core functionality from an existing protocol is far
> > more difficult and complex. If that was not the case we could make PKIX a
> > LOT simpler, and the same goes for SMTP and pretty much every stack we
> have.
> Possible.

> >> someone else to define an "MLS" that used WebCrypto
> >> then I'd be all for it, if the right people were involved
> >> and if it had a chance to be deployed.)
> >>
> >> Having said that, you're by no means the only person
> >> who's been waffling on this topic. As far as I can
> >> see there's an inverse relationship between the level
> >> of rhetoric used and the attention that should be
> >> paid to posts on this list in the last few days.
> >>
> >
> > I have running code, that is hardly waffle.
> I did not say that you always waffled. I maintain that your
> use of terms like "weak TLS" is waffle.

Well maybe there will be sufficient commitment to security to do it right.
But looking at the fanatical obsession here with shaving milliseconds off
round trips I suspect that it is going to be very hard to avoid performance
being put ahead of security.

My bottom line is do TLS right or not at all. If people decide TLS is too
much then we should make sure it has a different name at the very least. I
do not want to see HTTP/2.0 TLS everywhere as an excuse to weaken the
SSL/TLS brand.

Website: http://hallambaker.com/
Received on Saturday, 16 November 2013 04:57:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:19 UTC