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

From: Daniel Migault <[email-masked]>
Date: Mon, 7 Nov 2016 22:09:40 -0500

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.

   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.

   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 TLS1.2 and
   TLS1.3.

On Mon, Oct 24, 2016 at 11:22 AM, Daniel Migault <
[email-masked]> wrote:

> 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]> wrote:
>
>> 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
>>
>>
>>
>> On Sun, Oct 9, 2016 at 2:59 AM, John Mattsson <[email-masked]
>> > wrote:
>>
>>> 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-aT299BYrl
>>> BKvZs0BOQ
>>>
>>>
>>>
>>> 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
>>>
>>> _______________________________________________
>>> TLS mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>
>>
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 8 Nov 2016 14:50:35 +1100

I don't understand this.  I have no problems with a recommendation
(i.e., SHOULD), but you will find that many implementations will not
comply with these requirements when pushed.

>    Servers MUST NOT negotiate curves of less than 255 bits.

This is two statements:

1. The PRF hash for these suites is SHA-256.  That's not a
requirement, you just define it, no 2119 language.

2. Using a weak key negotiation means that your key negotiation is the
weak point.  Here, my preference is to avoid stating a requirement,
but that's only because it's very hard to get right.  Otherwise, use a
SHOULD and copy from HTTP/2:

"When choosing these cipher suites, servers SHOULD select a key
exchange that is at least 2048 bits for cipher suites that use
ephemeral finite field Diffie-Hellman (DHE) [TLS12] and 224 bits for
cipher suites that use ephemeral elliptic curve Diffie-Hellman (ECDHE)
[RFC4492]."

Getting into the exact number of bits is a bit self-defeating.  4Q
isn't 255 bits.  25519 isn't either if you count them all.  Both seem
to be more than adequate in strength though.

>    curves of less than 384 bits.

As above, but with bigger numbers.

>    connection error of type insufficient_security(71) for TLS1.2 and

Nits: 'enables'; there is a space between "TLS" and the version number.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 08 Nov 2016 09:24:36 +0100

On Mon, 2016-11-07 at 22:09 -0500, Daniel Migault wrote:
> regarding the proposed text. Unless I receive comment on it, the text
> will be publish as soon as draft submission is possible.
> 
> Yours, 
> Daniel
> 

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

---

From: Daniel Migault <[email-masked]>
Date: Tue, 8 Nov 2016 03:50:51 -0500

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.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 08 Nov 2016 10:49:07 +0100

On Tue, 2016-11-08 at 03:50 -0500, Daniel Migault wrote:

> 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.  

That's a valid concern, but TLS doesn't have the notion of a security
level, and I am not sure that you can easily introduce it with a
ciphersuite point assignment rfc. With TLS you can easily use AES-256
with DHE-RSA with DH parameters of 4096-bits, signed with an RSA
certificate of 32-bits. One can use your draft with a 8-bit PSK, and
still be insecure despite the fact that you force a 256-bit curve or
better. When trying to ensure a consistent level you may likely need to
adjust the finished message size as well.

Nevertheless, I think to cover your goal, a security considerations
addition that makes apparent that in addition to the ciphersuite
parameters, the TLS protocol finished message size, the elliptic curves
used, and the size of the selected key define the security level of the
session.

regards,
Nikos

---

From: Daniel Migault <[email-masked]>
Date: Tue, 8 Nov 2016 05:08:08 -0500

If I understand correctly, you recommend something that is of the flavor in
the security recommendation section:

If that is correct I will propose some better text explaining why we can
hardly provide some better text, including the one provided by HTTP2.

Yours,
Daniel

---

From: Martin Thomson <[email-masked]>
Date: Wed, 9 Nov 2016 11:24:28 +1100

On 8 November 2016 at 21:08, Daniel Migault <[email-masked]> wrote:
> 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.

I really had a hard time parsing this.  You don't connect this to
Diffie-Hellman at all, but I think that is what you are talking about.
But if your point is that this is an ECDHE-specific draft, then you
don't need to say anything at all.

nit "TLS enables"

---

From: Daniel Migault <[email-masked]>
Date: Sun, 13 Nov 2016 21:43:41 -0500

I removed all these recommendations on 128/256 security. I believe this
address this thread.

I also believe a profile document would be useful and detail these details.
Do you have any opinion about such a document ?

Tank you for the feed backs!

Yours,
Daniel

On Tue, Nov 8, 2016 at 7:24 PM, Martin Thomson <[email-masked]>
wrote:

> restrictions