Re: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead
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
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
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
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
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 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 ___ 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
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
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 >> https://www.ietf.org/mailman/listinfo/tls >> > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailma
Re: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead
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
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
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
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
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
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
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
Re: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead
On 10 August 2016 at 04:45, Sean Turner wrote: > 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. Did that request provide justification? I know that we've done this a fair bit recently, but is there a reason why these can't wait for the docs to at least pass WGLC? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls