Hi Daniel, Please submit a revised draft with the changes below.
Thanks, Joe On Tue, Mar 21, 2017 at 11:08 AM, Daniel Migault < daniel.miga...@ericsson.com> wrote: > Hi, > > Thank you for the review and comments received. Given the discussion our > understanding was that the consensus was to remove CCM-256 so that suites > defined by the document apply both for TLS1.2 as well as for TLS1.3. The > draft available on github [1 > <https://github.com/mglt/draft-ietf-tls-ecdhe-psk-aead/blob/master/draft-ietf-tls-ecdhe-psk-aead>] > has been updated as follows: > > > 1. Why does TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 use SHA256 instead > of SHA384 like the other 256 bit cipher suites? (From Russ Housley) > > MGLT: This was a mistake in the IANA section. The cypher suite was correct > in the remaining text. However, the current version does not consider > anymore CCM-256* which also solves this issue. > > 2. Since the security considerations mention passwords (human chosen > secrets) it should mention dictionary attacks. (From Russ Housley) > > MGLT: The issue of human chosen passwords and dictionary attacks has been > mentioned in the security consideration with the following text: > > """ > Use of Pre-Shared Keys of limited entropy may allow an active > attacker attempts to connect to the server and tries different keys. > For example, limited entropy may be provided by using short PSK in > which case an attacker may perform a brute-force attack. Other > example includes the use of a PSK chosen by a human and thus may be > exposed to dictionary attacks. > """ > > > 3. Section 2 and 3 of the document contains more detail about TLS 1.3 > than necessary. > > Section 2: This document only defines cipher suites for TLS 1.2, not TLS > 1.2 or later. A subset of equivalent cipher suites is defined in the TLS > 1.3 specification. > > MGLT: CCM-256 has been removed from the specification so that suites can > be defined for TLS 1.2 as well as TLS1.3. The following text is considered. > > """ > This document defines new cipher suites that provide Pre-Shared Key > (PSK) authentication, Perfect Forward Secrecy (PFS), and > Authenticated Encryption with Associated Data (AEAD). The cipher > suites are defined for version 1.2 of the Transport Layer Security > (TLS) [RFC5246] protocol, version 1.2 of the Datagram Transport Layer > Security (DTLS) protocol [RFC6347], as well as version 1.3 of TLS > [I-D.ietf-tls-tls13]. > """ > > Section 3 and 4: Maybe replace the last 2 paragraphs with an addition to > section 4 that states: > > "TLS 1.3 and above name, negotiate and support a subset of these cipher > suites in a different way." (TLS 1.3 does not support > TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 and TLS_ECDHE_PSK_WITH_AES_256_ > CCM_8_SHA256) > > MGLT: As CCM-256 has been removed, we do not have to deal with the > situation where TLS1.3 only considers a subset of the suites defined for > TLS1.2. > > The following sentence in section 3 clarifies that codes points are only > defined for TLS1.2: “””The assigned code points can only be used for TLS > 1.2.”””. The description of the TLS1.3 negotiation has been limited in > section 4 to the following sentence: “””TLS 1.3 and above version, > negotiate and support these cipher suites in a different way.””” > > 4. Section 3 should contain a bit more detail about relationship to 4492 > bis and RFC 4279: > > Something like the following may be enough. > > "This messages and pre-master secret construction in this document are > based on [RFC4279]. The elliptic curve parameters used in in the > Diffie-Hellman parameters are negotiated using extensions defined in > [4492-bis]." > > MGLT: The sentence mentioned above has been added with [4492-bis] > mentioned as normative. > “”” > Messages and pre-master secret construction in this document are > based on [RFC4279]. The elliptic curve parameters used in in the > Diffie-Hellman parameters are negotiated using extensions defined in > [I-D.ietf-tls-rfc4492bis]. > “”” > > [1] https://github.com/mglt/draft-ietf-tls-ecdhe-psk-aead/blob/ > master/draft-ietf-tls-ecdhe-psk-aead > > Yours, > Daniel and John > > > On Tue, Feb 21, 2017 at 1:22 PM, Joseph Salowey <j...@salowey.net> wrote: > >> Here are the open issues for draft-ietf-tls-ecdhe-psk-aead >> >> 1. Why does TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 use SHA256 instead >> of SHA384 like the other 256 bit cipher suites? (From Russ Housley) >> >> 2. Since the security considerations mention passwords (human chosen >> secrets) it should mention dictionary attacks. (From Russ Housley) >> >> 3. Section 2 and 3 of the document contains more detail about TLS 1.3 >> than necessary. >> >> Section 2: This document only defines cipher suites for TLS 1.2, not TLS >> 1.2 or later. A subset of equivalent cipher suites is defined in the TLS >> 1.3 specification. >> >> Section 3 and 4: Maybe replace the last 2 paragraphs with an addition to >> section 4 that states: >> >> "TLS 1.3 and above name, negotiate and support a subset of these cipher >> suites in a different way." (TLS 1.3 does not support >> TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 and TLS_ECDHE_PSK_WITH_AES_256 >> _CCM_8_SHA256) >> >> 4. Section 3 should contain a bit more detail about relationship to 4492 >> bis and RFC 4279: >> >> Something like the following may be enough. >> >> "This messages and pre-master secret construction in this document are >> based on [RFC4279]. The elliptic curve parameters used in in the >> Diffie-Hellman parameters are negotiated using extensions defined in >> [4492-bis]." >> >> Thanks, >> >> Joe >> >> >> >> >> _______________________________________________ >> 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
