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

2016-11-13 Thread Daniel Migault 
done.

Thanks for the review!

Yours

Daniel

On Tue, Nov 8, 2016 at 1:07 AM, Ilari Liusvaara 
wrote:

> On Mon, Nov 07, 2016 at 10:16:13PM -0500, Daniel Migault wrote:
> > Hi,
> >
> > The current draft is only considering TLS1.2. TLS1.3 is only mentioned
> for
> > advocating AEAD.
> >
> > Do you think we should add text that details how to proceed with TLS1.3 ?
> > If so what do you think of the following text ?
>
> That is, I think the dependency on TLS 1.3 should be downgraded to
> informative (unless that has already been done).
>
> >
> > Yours,
> > Daniel
> >
> >The assigned code points are only expected to be used for TLS1.2.
> >TLS1.3 does not follow the same name convention.  Instead TLS1.3
> >cipher suites are designated according to the AEAD suite as well as
> >the hash function used.  The current combination of AEAD algorithms
> >and Hash fucntion are already defined in TLS.1.3 so there is no need
> >to add additional cipher suites for TLS1.3.
>
> Seems reasonable.
>
> >Instead, in order to used the following ECDHE_PSK authentication
> >method.  TLS1.3 uses a combination of the "key_share" and
> >"psk_key_exchange_modes" extentions. "psk_key_exchange_modes"
> >extension sets its mode to psk_dhe_ke.  The "key_share" extention
> >contains a KeyShareEntry structure that carries the ECDHE parameters.
> >
>
> I think 'used the following' -> 'use the' and first period should be
> comma.
>
>
> -Ilari
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2016-11-07 Thread Ilari Liusvaara 
On Mon, Nov 07, 2016 at 10:16:13PM -0500, Daniel Migault wrote:
> Hi,
> 
> The current draft is only considering TLS1.2. TLS1.3 is only mentioned for
> advocating AEAD.
> 
> Do you think we should add text that details how to proceed with TLS1.3 ?
> If so what do you think of the following text ?
 
That is, I think the dependency on TLS 1.3 should be downgraded to
informative (unless that has already been done).

> 
> Yours,
> Daniel
> 
>The assigned code points are only expected to be used for TLS1.2.
>TLS1.3 does not follow the same name convention.  Instead TLS1.3
>cipher suites are designated according to the AEAD suite as well as
>the hash function used.  The current combination of AEAD algorithms
>and Hash fucntion are already defined in TLS.1.3 so there is no need
>to add additional cipher suites for TLS1.3.

Seems reasonable.

>Instead, in order to used the following ECDHE_PSK authentication
>method.  TLS1.3 uses a combination of the "key_share" and
>"psk_key_exchange_modes" extentions. "psk_key_exchange_modes"
>extension sets its mode to psk_dhe_ke.  The "key_share" extention
>contains a KeyShareEntry structure that carries the ECDHE parameters.
> 

I think 'used the following' -> 'use the' and first period should be
comma.


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2016-11-07 Thread Daniel Migault 
Hi,

The current draft is only considering TLS1.2. TLS1.3 is only mentioned for
advocating AEAD.

Do you think we should add text that details how to proceed with TLS1.3 ?
If so what do you think of the following text ?

Comments are welcome!


Yours,
Daniel

   The assigned code points are only expected to be used for TLS1.2.
   TLS1.3 does not follow the same name convention.  Instead TLS1.3
   cipher suites are designated according to the AEAD suite as well as
   the hash function used.  The current combination of AEAD algorithms
   and Hash fucntion are already defined in TLS.1.3 so there is no need
   to add additional cipher suites for TLS1.3.

   Instead, in order to used the following ECDHE_PSK authentication
   method.  TLS1.3 uses a combination of the "key_share" and
   "psk_key_exchange_modes" extentions. "psk_key_exchange_modes"
   extension sets its mode to psk_dhe_ke.  The "key_share" extention
   contains a KeyShareEntry structure that carries the ECDHE parameters.



On Tue, Oct 18, 2016 at 12:31 PM, Ilari Liusvaara 
wrote:

> On Tue, Oct 18, 2016 at 04:22:59PM +, 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
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2016-10-18 Thread Ilari Liusvaara 
On Tue, Oct 18, 2016 at 04:22:59PM +, 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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2016-10-18 Thread Xiaoyin Liu 
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:s...@sn3rd.com>
Sent: Tuesday, October 18, 2016 9:19 AM
To: Daniel Migault<mailto:daniel.miga...@ericsson.com>
Cc: tls@ietf.org<mailto:tls@ietf.org>
Subject: Re: [TLS] early IANA code point assignment request for 
draft-ietf-tls-ecdhe-psk-aead



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 <daniel.miga...@ericsson.com> 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
>
> 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};
>
>
>
> On Sun, Oct 9, 2016 at 7:11 PM, Martin Thomson <martin.thom...@gmail.com> 
> wrote:
> I'm mainly just looking to economize on different configurations.
>
> On 9 October 2016 at 16:32, John Mattsson <john.matts...@ericsson.com> wrote:
> > 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" <tls-boun...@ietf.org
> > on behalf of martin.thom...@gmail.com> 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 <n...@redhat.com>
> >>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
> >>> TLS@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/tls
> >>
> >>___
> >>TLS mailing list
> >>TLS@ietf.org
> >>https://www.ietf.org/mailman/listinfo/tls
> >
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2016-10-18 Thread Sean Turner 
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  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
> 
> 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};
> 
> 
> 
> On Sun, Oct 9, 2016 at 7:11 PM, Martin Thomson  
> wrote:
> I'm mainly just looking to economize on different configurations.
> 
> On 9 October 2016 at 16:32, John Mattsson  wrote:
> > 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"  > on behalf of martin.thom...@gmail.com> 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 
> >>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
> >>> TLS@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/tls
> >>
> >>___
> >>TLS mailing list
> >>TLS@ietf.org
> >>https://www.ietf.org/mailman/listinfo/tls
> >
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2016-10-17 Thread Daniel Migault 
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.

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};

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  wrote:

> I would like to see these included:
>
> TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256   = {0xTBD; 0xTBD} {0xD0,0x01};
> TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384   = {0xTBD; 0xTBD} {0xD0,0x02};
>
>
> I am fine with including these as well if someone wants to use them:
>
> TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256   = {0xTBD; 0xTBD} {0xD0,0x05};
> TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384   = {0xTBD; 0xTBD} {0xD0,0x06};
>
>
> I do not really see a reason to include the ones with the shorter MAC:
>
> 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};
>
>
> Russ
>
>
> On Oct 17, 2016, at 12:03 PM, Daniel Migault 
> 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
>
> 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};
>
>
>
> On Sun, Oct 9, 2016 at 7:11 PM, Martin Thomson 
> wrote:
>
>> I'm mainly just looking to economize on different configurations.
>>
>> On 9 October 2016 at 16:32, John Mattsson 
>> wrote:
>> > 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" <
>> tls-boun...@ietf.org
>> > on behalf of martin.thom...@gmail.com> 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 
>> >>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/d
>> oc/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
>> >>> TLS@ietf.org
>> >>> https://www.ietf.org/mailman/listinfo/tls
>> >>
>> >>___
>> >>TLS mailing list
>> >>TLS@ietf.org
>> >>https://www.ietf.org/mailman/listinfo/tls
>> >
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>>

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

2016-10-17 Thread Russ Housley 
I would like to see these included:

> TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256   = {0xTBD; 0xTBD} {0xD0,0x01};
> TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384   = {0xTBD; 0xTBD} {0xD0,0x02};

I am fine with including these as well if someone wants to use them:

> TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256   = {0xTBD; 0xTBD} {0xD0,0x05};
> TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384   = {0xTBD; 0xTBD} {0xD0,0x06};

I do not really see a reason to include the ones with the shorter MAC:

> 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};

Russ


On Oct 17, 2016, at 12:03 PM, Daniel Migault  
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
> 
> 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};
> 
> 
> 
> On Sun, Oct 9, 2016 at 7:11 PM, Martin Thomson  
> wrote:
> I'm mainly just looking to economize on different configurations.
> 
> On 9 October 2016 at 16:32, John Mattsson  wrote:
> > 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"  > on behalf of martin.thom...@gmail.com> 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 
> >>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
> >>> TLS@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/tls
> >>
> >>___
> >>TLS mailing list
> >>TLS@ietf.org
> >>https://www.ietf.org/mailman/listinfo/tls
> >
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2016-10-17 Thread Daniel Migault 
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};



On Sun, Oct 9, 2016 at 7:11 PM, Martin Thomson 
wrote:

> I'm mainly just looking to economize on different configurations.
>
> On 9 October 2016 at 16:32, John Mattsson 
> wrote:
> > 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" <
> tls-boun...@ietf.org
> > on behalf of martin.thom...@gmail.com> 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 
> >>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
> >>> TLS@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/tls
> >>
> >>___
> >>TLS mailing list
> >>TLS@ietf.org
> >>https://www.ietf.org/mailman/listinfo/tls
> >
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2016-10-09 Thread Martin Thomson 
I'm mainly just looking to economize on different configurations.

On 9 October 2016 at 16:32, John Mattsson  wrote:
> 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"  on behalf of martin.thom...@gmail.com> 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 
>>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
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>
>>___
>>TLS mailing list
>>TLS@ietf.org
>>https://www.ietf.org/mailman/listinfo/tls
>

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2016-10-08 Thread John Mattsson 
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"  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 
>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
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>
>___
>TLS mailing list
>TLS@ietf.org
>https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2016-09-21 Thread Peter Gutmann 
Speaking of early assignments for code points, it'd be about time for one
for TLS-LTS as well, otherwise it'll end up with the de facto 0x42 hard-
coded into various implementations.  So could I get an IANA early assignment
for that?

Peter.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2016-08-12 Thread Martin Thomson 
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  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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2016-08-10 Thread Nikos Mavrogiannopoulos 
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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2016-08-09 Thread Sean Turner 
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-ecdhe-psk-aead/.  
Please respond before August 23rd if you have concerns about early code point 
assignment for these cipher suites. 

J
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls