What we did in IPsec in RFC-tp-be 8221 is the following. This (including the
IoT marker) is also going to appear in the IANA registry:
+-------------------------+------------+---------+----------------+
| Name | Status | AEAD | Comment |
+-------------------------+------------+---------+----------------+
| ENCR_DES_IV64 | MUST NOT | No | UNSPECIFIED |
| ENCR_DES | MUST NOT | No | [RFC2405] |
| ENCR_3DES | SHOULD NOT | No | [RFC2451] |
| ENCR_BLOWFISH | MUST NOT | No | [RFC2451] |
| ENCR_3IDEA | MUST NOT | No | UNSPECIFIED |
| ENCR_DES_IV32 | MUST NOT | No | UNSPECIFIED |
| ENCR_NULL | MUST | No | [RFC2410] |
| ENCR_AES_CBC | MUST | No | [RFC3602][1] |
| ENCR_AES_CCM_8 | SHOULD | Yes | [RFC4309](IoT) |
| ENCR_AES_GCM_16 | MUST | Yes | [RFC4106][1] |
| ENCR_CHACHA20_POLY1305 | SHOULD | Yes | [RFC7634] |
+-------------------------+------------+---------+----------------+[1] - This requirement level is for 128-bit and 256-bit keys. 192-bit keys remain at the MAY level. (IoT) - This requirement is for interoperability with IoT. Only 128-bit keys are at the given level. IPsec sessions may have very long lifetime and carry multiple packets, so there is a need to move to 256-bit keys in the long term. > On 4 Oct 2017, at 5:54, Eric Rescorla <e...@rtfm.com> wrote: > > Generally I tend to agree we should remove these, but as Jim said, there are > reasons where I guess they make sense. Could we add a "Special Circumstances" > marking? > > -Ekr > > > On Tue, Oct 3, 2017 at 3:53 PM, Sean Turner <s...@sn3rd.com > <mailto:s...@sn3rd.com>> wrote: > In the IANA registries draft > (https://github.com/tlswg/draft-ietf-tls-iana-registry-updates > <https://github.com/tlswg/draft-ietf-tls-iana-registry-updates>), we’ve added > a recommended column to the Cipher Suites (CSs) registry (and some others). > Right now, the criteria for getting a recommended mark is AEAD ciphers with > strong authentication standards track ciphers. While that’s great generally, > the list we’ve got five CSs that gave Joe and I pause: > > TLS_DHE_RSA_WITH_AES_128_CCM_8 > TLS_DHE_RSA_WITH_AES_256_CCM_8 > TLS_PSK_DHE_WITH_AES_128_CCM_8 > TLS_PSK_DHE_WITH_AES_256_CCM_8 > TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 > > The CCM_8 CSs have a significantly truncated authentication tag that > represents a security trade-off that may not be appropriate for general > environment. In other words, this might be great for some IoT device but we > should not generally be recommending these. > > We’re recommending that these five suites be dropped from the recommended > list. Please let us know what you think. > > J&S > (editor hats on) > _______________________________________________ > TLS mailing list > TLS@ietf.org <mailto:TLS@ietf.org> > https://www.ietf.org/mailman/listinfo/tls > <https://www.ietf.org/mailman/listinfo/tls> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
