Hi Peter, thanks for trying to work out suitable text.
On 11/26/2014 03:46 AM, Peter Saint-Andre - &yet wrote: >> Picking a "foo" I'd suggest adding this to 4.2 maybe >> >> "There are some environments that have hardware support for >> AES-CCM but not AES-GCM. Where interoperability with such >> devices is needed, the TLS_ECDHE_ECDSA_WITH_AES_128_CCM >> ciphersuite is RECOMMENDED. There may also be niches where >> this kind of device cannot use that ciphersuite perhaps >> because they do not public key cryptography at all - this >> BCP does not cover those niches." > > I haven't seen substantive comments on this proposal. One possible reason for not getting these substantive comments is that the relevant community is just not on this mailing list. There are other groups, such as DICE, where these folks hang around. > > Simplifying further, I suggest: > > Some devices have hardware support for AES-CCM but not AES-GCM. > There are even devices that do not public key cryptography at all. > This BCP does not cover such devices. It is not clear what this BCP is not covering. Is it not covering devices that do not even do public key crypto, is the statement focused on devices that have hardware support for AES-CCM, or both? If an IoT device does not have hardware support for AES-CCM does the UTA document then apply? It would also be nice to include a reference to the DTLS profile document for the interested reader. (The DTLS profile document also references the UTA BCP...) Just to explain you a bit more about the concern I have. I am worried that readers less involved in the IETF process (i.e., the audience I am dealing with) suddenly sees 4 recommendations for TLS/DTLS. They will get confused. They get info about MTI from the TLS spec, one from CoAP (if they use CoAP or some other application protocol), another one from the UTA BCP document, and yet another from the DTLS profile. Unfortunately, most of the recommendations contradict each other. The underlying problem is that certain parts of the spec require changes over time while others do not. The MTI for ciphersuites seems to change somewhat frequently and issuing a new RFC ever time an old ciphersuite becomes out-dated seems to be a challenge. (Of course, the UTA BCP nor the DTLS profile document aim to tackle that problem; just saying...) In any case, getting the embedded community to use standardized, off-the-shelf security protocols is an up-hill battle. Adding confusion isn't going to make it easier for us. Ciao Hannes
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
