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

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

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.

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

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

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:-)

S.


On 11/15/2013 10:25 PM, Phillip Hallam-Baker wrote:
> On Fri, Nov 15, 2013 at 3:18 PM, Poul-Henning Kamp <phk@phk.freebsd.dk>wrote:
> 
>> In message <CAMm+LwitCMbU5Xo_fpDfjZGkZEa9H=qgoe=
>> fneFN_SKFp2bTZg@mail.gmail.com>
>> , Phillip Hallam-Baker writes:
>>
>>> Now that we are going to be going for preventing pervasive surveillance,
>>
>> I hate to be the one to bring this up, but that is not in any way
>> shape or form inside the WG charter and not even remotely close to
>> any concensus I can detect.
>>
>> HTTP/2.0 should, according to common sense run on any byte-pipe, or
>> as the WG charter says it, somewhat more convoluted:
>>
>>         The Working Group will produce a specification of a new
>>         expression of HTTP's current semantics in ordered,
>>         bi-directional streams. As with HTTP/1.x, the primary target
>>         transport is TCP, but it should be possible to use other
>>         transports.
>>
>>         [...]
>>
>>         Explicitly out-of-scope items include:
>>
>>         * Specifying the use of alternate transport-layer protocols.
>>         Note that it is expected that the Working Group will work
>>         with the TLS working group to define how the protocol is
>>         used with the TLS Protocol; any revisions to RFC 2818 will
>>         be done in the TLS working group.
>>
>>
>> Your proposal may be good or bad, but it is simply not the right
>> place for it.
>>
> 
> The point of bringing it up here is because the fact this option exists has
> a big impact on the rationale being given for MUST USE TLS.
> 
> Where such a scheme would be specified is secondary. The point that is
> relevant to this working group is that discovering what the NSA was up to
> have caused some people to assert a new set of reasons for mandating TLS.
> 
> If we rule those reasons out of scope then the fact that they are better
> addressed in a different approach can also be left out of scope. But if
> people are going to be making the security case for weakened TLS everywhere
> then they are very relevant.
> 
> There are good reasons why everyone should use strong TLS. The problem I
> have with the TLS mandate is that the reasons advanced are not considered
> strong enough for mandating strong TLS and so there is pressure to weaken
> TLS.
> 
> I do not think that the HTTP/2.0 difficulty with bypassing legacy proxies
> is sufficient to justify accepting a weak TLS
> 
> I do not think that the understanding of the pervasive surveillance use
> case is mature enough to mandate any particular approach yet and certainly
> must not be used to justify weakening TLS.
> 
>

Received on Friday, 15 November 2013 23:37:44 UTC