On Monday 21 March 2016 12:35:25 Peter Gutmann wrote: > Hubert Kario <hka...@redhat.com> 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
