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

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.



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

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.



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



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

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.


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


-- 
Website: http://hallambaker.com/