On Wed, May 24, 2017 at 6:00 AM, Daniel Migault <daniel.miga...@ericsson.com > wrote:
> Hi Eric, > > Thank you for your reviews. Please see my responses inline. If you agree > with the text I will update the draft. > > Yours, > Daniel > > On Mon, May 22, 2017 at 10:11 PM, Eric Rescorla <e...@rtfm.com> wrote: > >> Eric Rescorla has entered the following ballot position for >> draft-ietf-tls-ecdhe-psk-aead-04: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> The following text appears to have been added in -04 >> >> A server receiving a ClientHello and a client_version indicating >> (3,1) "TLS 1.0" or (3,2) "TLS 1.1" and any of the cipher suites from >> this document in ClientHello.cipher_suites can safely assume that >> the >> client supports TLS 1.2 and is willing to use it. The server MUST >> NOT negotiate these cipher suites with TLS protocol versions earlier >> than TLS 1.2. Not requiring clients to indicate their support for >> TLS 1.2 cipher suites exclusively through ClientHello.client_hello >> improves the interoperability in the installed base and use of TLS >> 1.2 AEAD cipher suites without upsetting the installed base of >> version-intolerant TLS servers, results in more TLS handshakes >> succeeding and obviates fallback mechanisms. >> >> This is a major technical change from -03, which, AFAIK, prohibited >> the server from negotiating these algorithms with TLS 1.1 and below >> and maintained the usual TLS version 1.2 negotiation rules. >> >> This is a very material technical change. I don't consider it wise, >> but in any case it would absolutely need WG consensus, which I >> don't believe that it has given the recent introduction. >> > > I agree that the text is a technical change, and that it may not be > appropriated to do so now. The reason I included it was that it was conform > to the previous text, but I agree that implicit assumption of version 1.2 > may need some additional discussion especially regarding RFC5246 Appendix > E. Unless you prefer further discussion I assume the text below address > your concern. > > <t>The cipher suites defined in this document MUST NOT be negotiated for > any version of (D)TLS other than TLS 1.2. Clients MUST NOT offer one of > these cipher suites with a (D)TLS version that differs from TLS 1.2. > Servers MUST NOT select one of these cipher suites with a TLS version that > differs from TLS 1.2. A client MUST treat the selection of these cipher > suites in combination with a version of TLS as an error and generate a > fatal 'illegal_parameter' TLS alert. </t> > Yes, this seems fine The discussion of dictionary attacks here seems inferior to that >> in 4279. In particular, you only need to actively attack one >> connection to capture the data you need for a brute force attack >> despite the text there referring to trying "different keys". >> Please correct that. >> >> I believe the text below address your concern: > > OLD: > <t>Use of Pre-Shared Keys of limited entropy may allow an active > attacker attempts to connect to the server and try different keys. > For example, limited entropy may be provided by using a short PSK in which > case an attacker may perform a brute-force attack. Another example > includes the use of a PSK chosen by a human which thus may be exposed to > dictionary attacks.</t> > > NEW: > <t>Pre-Shared Keys security relies on its associated entropy, and it is > RECOMMENDED to follow <xref target="4086"/> to ensure the PSK has enough > entropy. Possible reasons for low entropy includes PSK chosen by humans or > PSK of small length as well as using random generators with limited > entropy. </t> > > <t>PSK of limited entropy may allow an attacker to test different PSK > values against a valid output such as master secret or any output derived > from it. In this document, the master secret is generated using the PSK as > well as the ECDHE shared secret. The use of ECDHE limits the possibilities > of passive eavesdropping attackers, as the ECDHE shared secret is not > expected to be derived from the observed ECDH parameters. As a result, > passive eavesdropping is unlikely to happen, and the collection of all > necessary material relies on an active attack. > An active attacker may collect the necessary material by setting a TLS > session as a client with the legitimate server. One PSK is tested for each > session, and a match occurs when key exchange succeeds. On the other hand, > an active attacker may also consider gathering the necessary information > for offline computation. One way consists in getting a legitimate client to > establish a connection with the attacker. It is also assumed that the > client will accept the ECDH parameters authenticated by the attacker's > private key and finally returns the Finished message authenticating the > exchange. The attacker will be then in possession of all the necessary > information to perform a brute force attack.</t> > Is there a reason to not just point directly to the 4279 security considerations? - > > >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> The citations to TLS 1.3 still seem pretty muddled. I think you >> should just stop referencing and discussing 1.3. >> > > My understanding of your comment is that mentioning TLS 1.3 to further > insisting that the code point are not valid for TLS 1.3 is confusing. I > propose to: > > Explicitly mention the TLS version in the title: > > OLD title: > ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer > Security (TLS) > > NEW title: > ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer > Security (TLS) > > OLD Introduction: > > The cipher > suites are defined for version 1.2 of the Transport Layer Security > (TLS) [RFC5246 <https://tools.ietf.org/html/rfc5246>] protocol, version > 1.2 of the Datagram Transport Layer > Security (DTLS) protocol [RFC6347 <https://tools.ietf.org/html/rfc6347>], > as well as version 1.3 of TLS > [I-D.ietf-tls-tls13 > <https://tools.ietf.org/html/draft-ietf-tls-ecdhe-psk-aead-04#ref-I-D.ietf-tls-tls13>]. > > NEW introduction > > The cipher > suites are defined for version 1.2 of the Transport Layer Security > (TLS) [RFC5246 <https://tools.ietf.org/html/rfc5246>] protocol, version > 1.2 of the Datagram Transport Layer > Security (DTLS) protocol [RFC6347 <https://tools.ietf.org/html/rfc6347>]. > > > I suggest to keep the following text of the introduction: > > > AEAD algorithms that combine encryption and integrity protection are > strongly recommended for (D)TLS [RFC7525 > <https://tools.ietf.org/html/rfc7525>] and non-AEAD algorithms are > forbidden to use in TLS 1.3 [I-D.ietf-tls-tls13 > <https://tools.ietf.org/html/draft-ietf-tls-ecdhe-psk-aead-04#ref-I-D.ietf-tls-tls13>]. > The AEAD > algorithms considered in this document are AES-GCM and AES-CCM. The > use of AES-GCM in TLS is defined in [RFC5288 > <https://tools.ietf.org/html/rfc5288>] and the use of AES-CCM > is defined in [RFC6655 <https://tools.ietf.org/html/rfc6655>]. > > Yes, this seems fine. > I suggest to keep the following text of the Applicable versions sections, > as I believe the section discusses the cipher suites against all existing > TLS versions. In addition, it also justifies somewhat that we only defined > cipher suites that are compatible with TLS1.3. > > TLS version 1.3 and later negotiate these features in a different > manner. Unlike TLS 1.2, TLS 1.3 separates authentication and cipher > suite negotiation [I-D.ietf-tls-tls13 > <https://tools.ietf.org/html/draft-ietf-tls-ecdhe-psk-aead-04#ref-I-D.ietf-tls-tls13>] > Section 1.2 > <https://tools.ietf.org/html/draft-ietf-tls-ecdhe-psk-aead-04#section-1.2>. > TLS 1.3 supports > PSK with ECDHE key exchange and the cipher suites > TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, > TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 are part of the > specification. As a result, TLS 1.3 and higher versions, negotiate > and support these cipher suites in a different way. > > OK. > I suggest to remove the reference to TLS1.3 in the security considerations > > OLD > > The security considerations in TLS 1.2 [RFC5246 > <https://tools.ietf.org/html/rfc5246>], DTLS 1.2 [RFC6347 > <https://tools.ietf.org/html/rfc6347>], > TLS 1.3 [I-D.ietf-tls-tls13 > <https://tools.ietf.org/html/draft-ietf-tls-ecdhe-psk-aead-04#ref-I-D.ietf-tls-tls13>], > ECDHE_PSK [RFC5489 <https://tools.ietf.org/html/rfc5489>], AES-GCM [RFC5288 > <https://tools.ietf.org/html/rfc5288>], > and AES-CCM [RFC6655 <https://tools.ietf.org/html/rfc6655>] apply to this > document as well. > > NEW > > The security considerations in TLS 1.2 [RFC5246 > <https://tools.ietf.org/html/rfc5246>], DTLS 1.2 [RFC6347 > <https://tools.ietf.org/html/rfc6347>], > ECDHE_PSK [RFC5489 <https://tools.ietf.org/html/rfc5489>], AES-GCM [RFC5288 > <https://tools.ietf.org/html/rfc5288>],and AES-CCM [RFC6655 > <https://tools.ietf.org/html/rfc6655>] apply > to this document as well. > > >> S 2. >> I'm not sure that the discussion of the PRF is helpful here in >> mandating the non-use of these cipher suites with TLS 1.1 and >> below. >> > > I find the text useful as it gives an idea why even introducing AEAD in > TLS version lower than 1.2 is a bad idea, so I would prefer to keep it. The > text has been changed to > > OLD: > As such TLS 1.0 and TLS 1.1 should not be used with ECDHE_PSK. > > NEW: > As such, all ECDHE_PSK > ciphers, including those defined outside this document, SHOULD NOT be > negotiated in TLS versions prior to 1.2. > I don't think you should be levying a new normative requirement like this for other ciphers i this document -Ek r
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
