Subject: Re: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead

From: John Mattsson <[email-masked]>
Date: Sun, 9 Oct 2016 05:32:30 +0000

Hi Martin,

AES_256_CCM_8 was not in the first versions of the draft but added later
after request from IoT people (probably afraid of quantum computers).

While I think it makes very much sense to have short tags in wireless
radio, I do not know how large need there is for AES-256 in IoT for
constrained devices, or how large the need would be to truncate the tag in
these cases.

My current understanding is that Grover’s algorithm may never be more
cost-effective than a cluster of classical computers, and that quantum
computers therefore likely do not affect the lifetime of AES-128.

I do not have any strong opinions regarding keeping AES_256_CCM_8 or not.
We should not give the impression that AES-256 is needed for practical
resistance to quantum computers anytime soon, it is however a requirement
for use by US government. Agree that AES_128_CCM_8 and AES_256_CCM seems
like the best choices in most cases.

Cheers,
John

On 12/08/16 08:29, "TLS on behalf of Martin Thomson" <[email-masked]
on behalf of [email-masked]> wrote:

>Looking at those emails, I am prompted to wonder if anyone can justify
>the existence of a ciphersuite with a double-sized key and half-sized
>authentication tag.  RFC 6655 doesn't really explain how that is a
>useful thing.
>
>On 10 August 2016 at 19:33, Nikos Mavrogiannopoulos <[email-masked]>
>wrote:
>> On Tue, 2016-08-09 at 14:45 -0400, Sean Turner wrote:
>>> All,
>>>
>>> We've received a request for early IANA assignments for the 6 cipher
>>> suites listed in https://datatracker.ietf.org/doc/draft-ietf-tls-ecdh
>>> e-psk-aead/.  Please respond before August 23rd if you have concerns
>>> about early code point assignment for these cipher suites.
>>
>> I have previously raised an issue [0] on these ciphersuites. The same
>> requirement was noted also by Peter Dettman as something special in
>> [1]. However, there has been no reaction from the authors (now in CC).
>>
>> regards,
>> Nikos
>>
>> [0]. 
>>https://mailarchive.ietf.org/arch/msg/tls/4PZsc_Dy-aT299BYrlBKvZs0BOQ
>> [1]. 
>>https://mailarchive.ietf.org/arch/msg/tls/onEkdgH30eZgWs8v5Rp-CUqCHds
>>
>> _______________________________________________
>> 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: Mon, 10 Oct 2016 10:11:34 +1100

I'm mainly just looking to economize on different configurations.

---

From: Daniel Migault <[email-masked]>
Date: Mon, 17 Oct 2016 12:03:58 -0400

Hi,

I am not clear what the consensus is for the following points. Is there any
consensus for requesting the following ones?

BR,
Daniel

TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256   = {0xTBD; 0xTBD} {0xD0,0x01};
TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384   = {0xTBD; 0xTBD} {0xD0,0x02};
TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 = {0xTBD; 0xTBD} {0xD0,0x03};
TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA384 = {0xTBD; 0xTBD} {0xD0,0x04};
TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256   = {0xTBD; 0xTBD} {0xD0,0x05};
TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384   = {0xTBD; 0xTBD} {0xD0,0x06};

---

From: Russ Housley <[email-masked]>
Date: Mon, 17 Oct 2016 12:08:42 -0400

> TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA384 = {0xTBD; 0xTBD} {0xD0,0x04};

Russ

On Oct 17, 2016, at 12:03 PM, Daniel Migault <[email-masked]> wrote:

> Hi, 
> 
> I am not clear what the consensus is for the following points. Is there any consensus for requesting the following ones?
> 
> BR, 
> Daniel
> 
> On Sun, Oct 9, 2016 at 7:11 PM, Martin Thomson <[email-masked]> wrote:

---

From: Daniel Migault <[email-masked]>
Date: Mon, 17 Oct 2016 15:04:25 -0400

Hi,

We are discussing in the TLS wg assignment points for TLS PSK
authentication. We would like to understand if there is a specific interest
of the IoT community for the following suites.

Additional question might be whether AES_256_CCM_8_SHA384 is of interest
for an IoT use case.

Any feed back is appreciated. please provide them by the end of the week!

BR,
Daniel

On Mon, Oct 17, 2016 at 12:08 PM, Russ Housley <[email-masked]> wrote:

> I am not clear what the consensus is for the following points. Is there
> any consensus for requesting the following ones?
>
> BR,
> Daniel
>

---

From: Sean Turner <[email-masked]>
Date: Tue, 18 Oct 2016 09:19:15 -0400

I think there might be consensus to ask for code points but not early.  This draft can’t really proceed any faster than the TLS1.3 and 4492bis drafts.

spt

> On Oct 17, 2016, at 12:03, Daniel Migault <[email-masked]> wrote:
> 
> Hi, 
>

---

From: Xiaoyin Liu <[email-masked]>
Date: Tue, 18 Oct 2016 16:22:59 +0000

Why does this draft normatively depend on TLS 1.3, even if the cipher suites defined in this draft use the old syntax, which TLS 1.3 no longer uses?

Best,

Xiaoyin

From: Sean Turner<mailto:[email-masked]>
Sent: Tuesday, October 18, 2016 9:19 AM
To: Daniel Migault<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead

spt

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 18 Oct 2016 19:31:05 +0300

On Tue, Oct 18, 2016 at 04:22:59PM +0000, Xiaoyin Liu wrote:
> Why does this draft normatively depend on TLS 1.3, even if the
> cipher suites defined in this draft use the old syntax, which
> TLS 1.3 no longer uses?

I don't see any reason why it would normatively depend.

If it claims to be so, IMO that is a mistake and such reference should
be dropped (TLS 1.3 won't be able to use these anyway), or made in-
formative, in case the text wants to make a passing reference to TLS
1.3.

-Ilari