Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

[Peter Gutmann]

Watson Ladd  writes:

>As written supporting this draft requires adopting the encrypt-then-MAC
>extension. But there already is a widely implemented secure way to use MACs
>in TLS: AES-GCM. 

This is there as an option if you want it.  Since it offers no length hiding,
it's completely unacceptable to some users, for example one protocol uses TLS
to communicate monitoring commands to remote gear, they're very short and
fixed-length, different for each command, so if you use GCM you may as well be
sending plaintext.  In addition GCM is incredibly brittle, get the IV handling
wrong and you get a complete, catastrophic loss of both integrity and
confidentiality.  The worst that happens with CBC, even with a complete abuse
like using an all-zero IV, is that you drop back to ECB mode.

>Likewise, this draft modifies the way the master secret is computed, despite
>a widely implemented different solution to the problem, namely the EMS triple
>handshake fix. 

Firstly, that solves an entirely different problem, and secondly I don't
recall ever seeing EMS support in any embedded device, it may be widely
implemented in Windows and OpenSSL but I don't know how much further it goes.

>The use of uncompressed points makes off-curve attacks much easier than with
>compressed points. 

Everything uses uncompressed points at the moment without any problems, and
compressed points are patented.

>The analysis of TLS 1.3 is just wrong. TLS 1.3 has been far more extensively
>analyzed then TLS 1.2. 

As the rationale points out, the mechanisms in SSL were also very heavily
analysed when they were released.  It didn't protect the protocol from 20
years of subsequent attacks, which we've leared about over those 20 years of
implementation and deployment experience.  With TLS 1.3 we have zero
implementation and deployment experience.  Do you really believe there will
never be any attacks on it after it's rolled out?

Peter.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Simple, secure 0-RTT for the masses

[Ilari Liusvaara]

On Wed, Mar 16, 2016 at 08:12:48AM -0400, Colm MacCárthaigh wrote:
> On Wed, Mar 16, 2016 at 4:17 AM, Ilari Liusvaara 
> wrote:
> >
> > - Duplication of 0-RTT data into 1-RTT data of _different_ connection.
> >
> 
> I think using a different content type solves this; the early data is
> illegal in the 1-RTT phase and the content type would distinguish it.

Nope, this can not be realistically solved, _even_ with server state
(the 0-RTT to 0-RTT duplication is unsolveable without state, but can
be solved with server state).
 

> As an aside: an application protocol where latency is so sensitive that
> 0RTT is attractive would hardly have its own back-and-forth with banners in
> the first place.

The problem is that such banners would not be bound to the TLS connection
in any way, which causes problems (TLS has no facility to transport data
from application inside extension).


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2?

[Martin Rex]

Colm MacCárthaigh wrote:
> 
> But I take the point that AEAD modes are harder for programmers to screw
> up; and that does have value.

Though it is a pretty flawed assumption.

I've seen an AEAD cipher implementation fail badly just recently (resulting
in corrupted plaintext that went unnoticed within TLS--MACing the ciphertext
is obviously a pretty dumb idea), something that is *MUCH* more unlikely
to happen to any cipher suites using GenericBlockCipher PDU.

Pretty much all of othe known crypto attacks are highly theoretical and
meaningless in practice, whereas corrupted plaintext is an immediate
real pain in the ass.

I'm glad that the problem was spotted before the affected code was shipped.

-Martin

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2?

[Peter Gutmann]

Martin Rex  writes:

>Though it is a pretty flawed assumption.
>
>I've seen an AEAD cipher implementation fail badly just recently (resulting
>in corrupted plaintext that went unnoticed within TLS--MACing the ciphertext
>is obviously a pretty dumb idea), something that is *MUCH* more unlikely to
>happen to any cipher suites using GenericBlockCipher PDU.

There have been many more failures with GCM, the most notorious being Colin
Percival's tarsnap, where a single missed operation (increment the IV)
resulted in a total loss of security.  Colin is a very experienced crypto
developer, so its not like this was some beginner mistake.  This is why I
referred to GCM as "brittle", you can be about as abusive as you like with CBC
and the worst you get is degradation to ECB, while with GCM you make one
mistake and you get a catastrophic loss of security.

Peter.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2?

[Colm MacCárthaigh]

On Wed, Mar 16, 2016 at 2:14 PM, Paterson, Kenny 
wrote:

> Much better would be implementing an optional padding feature for the AEAD
> modes. Something like this draft proposes:
>
> https://tools.ietf.org/html/draft-pironti-tls-length-hiding-02


I hadn't seen that! I wonder is there an appetite here for including more
robust LH in TLS1.2 in some form? I mean a real one; as in - let's it get
it into servers and browsers sooner than TLS1.3.

-- 
Colm
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

[Hubert Kario]

On Friday 18 March 2016 08:57:26 Peter Gutmann wrote:
> Watson Ladd  writes:
> >Likewise, this draft modifies the way the master secret is computed,
> >despite a widely implemented different solution to the problem,
> >namely the EMS triple handshake fix.
> 
> Firstly, that solves an entirely different problem, and secondly I
> don't recall ever seeing EMS support in any embedded device, it may
> be widely implemented in Windows and OpenSSL but I don't know how
> much further it goes.

it may solve a different problem, but its solution is a superset of what 
you propose

I haven't seen support for X9.42 DHE parameters or selective mixing in 
of them to master secret in embedded devices either...

you modify behaviour of Master Secret calculation one way or another, 
let's do this in a way that is interoperable with other implementations, 
not add a third way to do that

also, if it really is supposed to be Long Term Support, why it doesn't 
say anything about implementation explicitly being able to handle big 
key sizes? both RSA and DHE?

I might have missed, but where is the specification of the acceptable 
signature algorithms (hash especially) on Server and Client Key Exchange 
messages?

Finally, I'd prefer the tls-lts to mostly say "see those other 
extensions? I really do mean it" + some pleasantries like the "no 
rehandshake".
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls