Hi Martin, Niko, Thanks for the comment. Regarding Martin comment, I agree the text should not comment the SHAX as these are defined by the cipher suites. What is not clear to me is how the reference to DH should be handled. I also did not feel that the provided text provides different recommendations for the AES-128 / AES-256.
This is the text I would propose then. Please let me know if it catches your comments and feel free to comment on it. Regarding Niko, my understanding is that the WG preferred not to have the definition of profiles in this document. I am not sure you wanted the text to be removed as MUST NOT was to normative or if you would like no recommendation at all. The reason I would rather advocate for recommendation is that ECDHE does not specify an algorithm with a specific security. As a result, I would rather provide some guide lines to avoid weak authentication being used with high long AES keys. Yours, Daniel -- Text -- When choosing AES-128 cipher suites, servers SHOULD select a key exchange that is at least 224 bits for cipher suites that use ephemeral elliptic curve Diffie-Hellman (ECDHE)[RFC4492]. When choosing AES-256 cipher suites, servers SHOULD select a key exchange that is at least 384 bits for cipher suites that use ephemeral elliptic curve Diffie-Hellman (ECDHE)[RFC4492]. TLS enable curve negotiation but not for code point. This makes restrictions on code points hard to implement. As a result Endpoints MAY treat negotiation of key sizes smaller than the lower limits as a connection error of type insufficient_security(71) for TLS 1.2 and TLS 1.3. On Tue, Nov 8, 2016 at 3:24 AM, Nikos Mavrogiannopoulos <n...@redhat.com> wrote: > On Mon, 2016-11-07 at 22:09 -0500, Daniel Migault wrote: > > Hi, > > > > Please find the text I propose. Let me know if you have any comment > > regarding the proposed text. Unless I receive comment on it, the text > > will be publish as soon as draft submission is possible. > > > > Yours, > > Daniel > > > > The cipher suites defined in this document are based on the AES- > > GCM > > and AES-CCM Authenticated Encryption with Associated Data (AEAD) > > algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM, AEAD_AES_128_CCM, > > and > > AEAD_AES_256_CCM defined in [RFC5116], AEAD_AES_128_CCM_8 and > > AEAD_AES_256_CCM_8 defined in [RFC6655]. > > > > For the AES-128 cipher suites, the TLS Pseudorandom Function (PRF) > > with SHA-256 as the hash function SHALL be used and Clients and > > Servers MUST NOT negotiate curves of less than 255 bits. > > Sorry for not getting back into previous discussions. My comment as > before would be to remove the text "Clients and Servers MUST NOT > negotiate curves of less than 255 bits." > > I find that unrelated to the purpose of the text which is define code > points for certain ciphersuites, and no other code points for TLS set > such restrictions (DH bits, or curves). Alternatively if with this > document you want to create a profile of TLS (e.g, like SuiteB rfc > does), which sets options which are more than just ciphersuites then > just be clear about it. > > That is, say this document creates a profile of TLS named XXX which if > used, the clients and servers which conform to it must negotiate the > ciphersuites defined above and must not negotiate curves of less than > 255 bits. > > regards, > Nikos > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
