Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)

[Eric Rescorla <[e-mail]>]

On Wed, May 24, 2017 at 6:00 AM, Daniel Migault <[e-mail]
> 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-mail]> 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