Re: [TLS] History of TLS analysis (was Re: TLS 1.2 Long-term Support Profile draft posted)

[Watson Ladd <[e-mail]>]

On Fri, Mar 18, 2016 at 4:31 PM, Peter Gutmann
<[e-mail]> wrote:
> Watson Ladd <[e-mail]> writes:
>
>>Then use a padding extension that solves all problems, instead of relying on
>>a side effect of CBC mode.
>
> It's not a "side-effect of CBC mode", CBC mode allows padding packets, GCM
> doesn't, see Colm MacCárthaigh's recent post on the topic.

GnuTLS is the only implementation that pads to more than 16 byte boundaries
>
>>Why do we want this to look different from TLS, instead of a subset of widely
>>deployed things ala UTA?
>
> CBC mode ciphers have been part of TLS since SSL 2.0 (AFAIK) in 1994, I don't
> know if SSL2 allowed for packet padding but 3.0 certainly did, so it's hardly
> a major change.

It's not the CBC modes that's the change, but the EtM extension.
>
>>What is your master secret change solving?
>
> Preventing manipulation of DH/ECDH parameters.

It's not immediately clear that it does so correctly. All data that
affects the interpretation must be in the master secret, and I think
that includes some data you haven't yet hashed. EMS we know gets this
right.
>
>>Your draft claims that verifying signatures before sending will address an
>>ECC security threat. I don't see what threat that addresses
>
> The fact that ECC algorithms are extremely vulnerable to fault attacks, and a
> single faulty signature can leak the private key, at which point its game
> over.

The same fault attack commonly works on embedded implementations for
ECDH. Except here the attacker just sends a point off the curve,
instead of inducing a fault in the signature routine. RSA signatures
with CRT optimization (commonly used on embedded devices) is also
vulnerable to similar fault attacks. I'm really not sure why you're
ignoring wrong-curve attacks on cached ephemerals: just add a
recommendation to not cache ephemerals.

>
> I don't really know how to say the following without it sounding like an ad
> hominem attack, but how much do you really know about real-world deployment
> issues for this stuff?  You seem to be arguing for all sorts of personal
> preferences based on, I dunno, abstract theorising, but you appear to be
> totally unaware of actual real-world issues.  What I'm trying to figure out
> is, how seriously am I supposed to take your comments?  Do you actually have
> any real-world deployment experience with using this stuff in the field?

Given that I'm proposing subsetting what existing implementations
already do, instead of implementing new extensions, I find it
remarkable you're arguing that my proposal is harder to deploy. As for
what I know, I'm listed in the release notes of several TLS
implementations.

>
> Peter.



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.