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

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.


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

> What attacks does mutual authentication protect against that server-only
> auth does not? If TLS was widely used as the control against those attacks
> then I would use the term weaker. But since it is not I don't consider that
> to be an issue.
> 
> Server auth is not a casual feature of TLS, it was the original purpose of
> the protocol.

Yes. But there's been no credible (or any?) proposal to change
that for https:// URIs.

>> I also think "MLS or TLS" is a false dichotomy if its being
>> setup that way.
>>
>> TLS is a practical widely deployed technology, with flaws,
>> sure, but there is no credible alternative for HTTP security
>> and TLS is in fact good enough, though we can improve it
>> as well.
>>
> 
> 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.

>> A putative application layer security mechanism like "MLS"
>> could be useful, but a) is mythical today so would have
>> to be defined, implemented, deployed, debugged etc before
>> it'd be worth thinking about comparing its properties to
>> those of TLS, and b) would involve significant changes to
>> both browsers and server-side web application frameworks,
>>
> 
> 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.

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

>> (not the folks here), and c) would in large part
>> contradict the efforts underway on WebCrypto, unless it
>> was built on that. So, as an alternative that's worth
>> considering now, that's nonsense.
>>
> 
> I think the question is where you put the WebCrypto, whether it is
> something that is only visible in Javascript or a feature that can be
> invoked via HTTP.
> 
>  (Don't get me wrong, if it made sense for the IETF or
> 
>> 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.

> OK I am only doing
> authentication of HTTP sessions right now but doing encryption against the
> shared secret is a trivial additional complexity that the code was doing
> before I took it out.
> 
> 
>> Finally, sorry to pick on you Phill, but in contrast
>> to others who've been coming out with security-gibberish
>> I know you know this stuff better. (And you're a serial
>> offender in the court of rhetoric as well, so I hope
>> you don't mind so much being called out for it:-)
>>
> 
>  Since rhetoric is the process of rational argument, I am not sure what the
> alternative is you suggest.

The alternative I suggest is to be precise and lose the
overblown language. For you, me and everyone else.

S.


> 
>

Received on Saturday, 16 November 2013 00:34:51 UTC