Subject: Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt

From: John Mattsson <[email-masked]>
Date: Sun, 9 Oct 2016 06:59:20 +0000

Hi Dan, Sean, Nikos,

First, let me state that I think requiring 128-bit key management for
AES-128 is quite reasonable.

HTTP/2 [RFC7540] also has some related text in Section 9.2.1 that applies
when TLS is used for HTTP/2. "Endpoints MAY treat negotiation of key sizes
smaller than the lower limits as a connection error (Section 5.4.1
<https://tools.ietf.org/html/rfc7540#section-5.4.1>) of type
INADEQUATE_SECURITY."

I think this is a question for TLS in general,
draft-ietf-tls-ecdhe-psk-aead should just follow what the TLS WG decides
as the general way forward. Wether that is MAY/SHOULD/SHALL treat groups
with insufficient security as an error.

I think the real problem here are TLS libraries supporting 1024 MODP and
160 ECC at all, support for these should have been removed before 2010.
Nikos [0] recommends a RCF forbidding weak elliptic curves from TLS 1.2
(i.e. WeakDH DieDieDie!!!). I think this is a great idea and much better
than bundling it into a code-point assignment RFC. (My current plans for
the next update of 3GPP’s TLS and DTLS profiles is simply to forbid
support of anything weaker than 2048 MODP and 255-bit ECC).

[0]. https://mailarchive.ietf.org/arch/msg/tls/4PZsc_Dy-aT299BYrlBKvZs0BOQ

Cheers,
John

On 11/07/16 22:26, "TLS on behalf of Dan Harkins" <[email-masked] on
behalf of [email-masked]> wrote:

>
>  I'm glad I have to opportunity to make you happy Sean :-)
>
>On Mon, July 11, 2016 7:40 am, Sean Turner wrote:
>> I think I can take this bit:
>>
>> On Jul 10, 2016, at 06:51, Peter Dettman
>><[email-masked]>
>> wrote:
>>>
>>> I'm also curious whether there is a precedent in other RFCs for an
>>> explicit minimum curve bits, or perhaps a de facto implementer's rule?
>>
>> I'd be happy to be wrong here. but to my knowledge no there's not been
>> an explicit minimum for curve bits.  There have however been similar (at
>> least in my non-cryptographer mind) for RSA key sizes so if we wanted to
>> define an explicit minimum curve bits then we could.
>
>  draft-ietf-tls-pwd-07 includes a RECOMMENDED practice of ensuring
>the curves used provide commensurate strength with the ciphersuite
>negotiated. Section 10, "Implementation Considerations", says:
>
>   It is RECOMMENDED that implementations take note of the strength
>   estimates of particular groups and to select a ciphersuite providing
>   commensurate security with its hash and encryption algorithms.  A
>   ciphersuite whose encryption algorithm has a keylength less than the
>   strength estimate, or whose hash algorithm has a blocksize that is
>   less than twice the strength estimate SHOULD NOT be used.
>
>  And I would like to take this opportunity to remind everyone that
>the only difference between TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256
>and TLS_ECCPWD_WITH_AES_128_GCM_SHA256 is that the latter is resistant
>to dictionary attack and the former is not.
>
>  regards,
>
>  Dan.
>
>
>
>_______________________________________________
>TLS mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/tls

---

From: John Mattsson <[email-masked]>
Date: Sun, 9 Oct 2016 07:04:14 +0000

Hi Peter,

Yes, it should end with ...SHA384. We will fix this in the next update.
(Related question from Martin Thompson can be found in [0])

Cheers,
John

[0] https://www.ietf.org/mail-archive/web/tls/current/msg21517.html

On 10/07/16 12:51, "TLS on behalf of Peter Dettman" <[email-masked]
on behalf of [email-masked]> wrote:

>Hi,
>I've just implemented these ciphersuites in BouncyCastle TLS, and have a
>couple of questions:
>
>In Section 3., should
>
>   TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 = {0xTBD,0xTBD};
>
>end with ...SHA384 instead?
>
>   For the AES-256 cipher suites, the TLS PRF with SHA-384 as the hash
>   function SHALL be used and Clients and Servers MUST NOT negotiate
>   curves of less than 384 bits.
>
>requires SHA384 as the PRF, and I don't know what else SHA256 could
>refer to for an AEAD ciphersuite.
>
>Regards,
>Pete Dettman
>On 28/05/2016 12:19 AM, [email-masked] wrote:
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts
>>directories.
>> This draft is a work item of the Transport Layer Security of the IETF.
>> 
>>         Title           : ECDHE_PSK with AES-GCM and AES-CCM Cipher
>>Suites for Transport Layer Security (TLS)
>>         Authors         : John Mattsson
>>                           Daniel Migault
>> 	Filename        : draft-ietf-tls-ecdhe-psk-aead-00.txt
>> 	Pages           : 7
>> 	Date            : 2016-05-27
>> 
>> Abstract:
>>    This document defines several new cipher suites for the Transport
>>    Layer Security (TLS) protocol.  The cipher suites are all based on
>>    the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key
>>    (ECDHE_PSK) key exchange together with the Authenticated Encryption
>>    with Associated Data (AEAD) algorithms AES-GCM and AES-CCM.  PSK
>>    provides light and efficient authentication, ECDHE provides perfect
>>    forward secrecy, and AES-GCM and AES-CCM provides encryption and
>>    integrity protection.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/
>> 
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-tls-ecdhe-psk-aead-00
>> 
>> 
>> Please note that it may take a couple of minutes from the time of
>>submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>

---

From: Daniel Migault <[email-masked]>
Date: Mon, 17 Oct 2016 13:16:27 -0400

Hi,

I am not very clear on how to update the text of the draft. The problem
seems to me that code point restriction are hard to implement. As a result,
the session is aborted with - insufficient_security(71) or equivalent -
when the code point does not match the security strength. I am encline to
think that we should also provide some profiles that achieve 128/256 bit
security. These profiles may be described in this document or in another
document more related to cryptographic recommendation. What would be the
most appropriated way to move forward ?

BR,
Daniel

---

From: Daniel Migault <[email-masked]>
Date: Mon, 24 Oct 2016 11:22:06 -0400

Hi,

My understanding is that the updated version should not introduce any
profile. Am I correct ?

BR,
Daniel

On Mon, Oct 17, 2016 at 1:16 PM, Daniel Migault <[email-masked]