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

[Hubert Kario <[e-mail]>]

On Monday 21 March 2016 12:35:25 Peter Gutmann wrote:
> Hubert Kario <[e-mail]> writes:
> >Note that I asked for "being able to handle", not "selects and uses".
> 
> The issue here is that a Cortex M3 isn't going to be able to handle
> RSA-2048, no matter what an RFC says :-).  That's what the "ability
> of the hardware to deal with large keys" was meant to say.

even 10 seconds to establish a session that is then kept up for days 
and/or uses session resumption is something many environments would be 
able to handle.

If your hardware really can't do anything better than 2048 bit RSA, it's 
not LTS, it's a crippled embedded system, and it definitely shouldn't 
get a stamp of approval "good for next X0 years" or anything similar 
like a LTS moniker would imply.

Also, you're explicitly saying that this proposal is limiting the TLS 
parameter set to "known-good subset". 1024 bit RSA and DHE are not 
known-good, if Cortex M3 really can't handle RSA-2048, for crypto it's 
as good as a coaster already.

the system is only as strong as the weakest link

> When I've run into upper limits, it's almost always because the
> hardware can't go much beyond the given upper-limit value (Sun's Java
> implementation with its braindamaged 1024-bit upper limit for DLP
> keys was a notable exception).  So I could perhaps say something like
> "implementations SHOULD handle key sizes of up to 2048 bits, and MAY
> expect to see key sizes up to 4096 bits" or something similar.

there's a similar limit in NSS with client certificates, although I 
don't remember the exact number now, I'm quite sure that a 8k key would 
get rejected.

> >no, it's not, not in TLSv1.2. If it does override section 7.4.1.4.1.
> >of RFC 5246, you need to be explicit about it.
> 
> Maybe I'm missing something here, but the text that refers to signing
> with "RSA-SHA-256" and "ECDSA-P256-SHA-256" seems to be pretty
> unambiguous.  Is there something else I need to add there?

it doesn't explain where this "RSA-SHA-256" is used. IMHO it is 
ambiguous.

The "no MAC truncation" is also not explicit about what the sizes should 
be.

> >The implementation will need to interoperate with normal (i.e.
> >already deployed) TLS 1.2 implementations anyway, why prevent code
> >reuse?
> Right, and if you need that you can include all the extensions you
> want.  If you only need TLS-LTS, you can leave them out.

my point is, that the code path of the tls-lts extension should check 
the sanity of extensions passed and abort if anything is not according 
to the LTS when LTS is supposed to be enforced.

in other words, LTS should be an addition to already existing code, not 
a replacement.

You may be dealing with hardware that often requires careful pruning of 
code base to make it fit. Thing is, that there are also millions of 
devices which can handle full OpenSSL/PolarSSL/etc. just fine. And for 
those it's better if the code paths used are the same or as similar as 
possible in all situations. Any other approach leads to subtle and hard 
to find bugs. Exactly what we don't want to see in LTS code.

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