Subject: [TLS] TLS 1.3 Recommended ECC curve for 192-bit security

From: John Mattsson <[email-masked]>
Date: Mon, 12 Oct 2015 09:01:43 +0000

I think the selection of MTI Cipher Suites (Section 8.1 of draft-ietf-tls-tls13-09) is excellent, but I am missing a recommended ECC curve for the “SHOULD” cipher suites. Little benefit of using AES-256 with P-256 or curve25519. Shouldn’t there be a SHOULD implement ECC curve giving at least 192-bit security? E.g.

"These cipher suites SHOULD support both digital signatures and key exchange with secp384r1 (NIST P-384)."

Cheers,
John

JOHN MATTSSON
MSc Engineering Physics, MSc Business Administration and Economics
Ericsson IETF Security Coordinator
Senior Researcher, Security

Ericsson AB
Ericsson Research
Färögatan 6
SE-164 80 Stockholm, Sweden
Phone +46 10 71 43 501
SMS/MMS +46 76 11 53 501
[email-masked]<mailto:[email-masked]>
www.ericsson.com<http://www.ericsson.com/>

[http://www.ericsson.com/]<http://www.ericsson.com/>

This Communication is Confidential. We only send and receive email on the basis of the terms set out atwww.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>

---

From: Michał Staruch <[email-masked]>
Date: Mon, 12 Oct 2015 11:34:10 +0200

We already have "SHOULD support key exchange with X25519" in this section,
so people implementing it should have no problems with adopting X448
<https://tools.ietf.org/html/draft-irtf-cfrg-curves-10#section-6.2> to
achieve ~224 bit security where it's needed (and better performance than
P-384).

On Mon, Oct 12, 2015 at 11:01 AM, John Mattsson <[email-masked]>
wrote:

> I think the selection of MTI Cipher Suites (Section 8.1 of
> draft-ietf-tls-tls13-09) is excellent, but I am missing a recommended ECC
> curve for the “SHOULD” cipher suites. Little benefit of using AES-256 with
> P-256 or curve25519. Shouldn’t there be a SHOULD implement ECC curve giving
> at least 192-bit security? E.g.
>
> *JOHN MATTSSON*
> *MSc Engineering Physics, MSc Business Administration and Economics*
>
> *Ericsson IETF Security Coordinator*
> * Senior Researcher, Security*
>
>
> Ericsson AB
> Ericsson Research
> Färögatan 6
> [email-masked]
>
> www.ericsson.com
>
>
>
>  <http://www.ericsson.com/>
>
>
>
> This Communication is Confidential. We only send and receive email on the
> basis of the terms set out atwww.ericsson.com/email_disclaimer
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

-- 

Pozdrawiam | Best Regards

Michał Staruch | Information Security Officer

ul. Sienkiewicza 9, 65-001 Zielona Góra

[email-masked]

Find us on Bloomberg CKPL <GO>
 <https://cinkciarz.pl>

*Cinkciarz.pl Sp. z o.o.*

*Siedziba:* ul. Sienkiewicza 9, 65-001 Zielona Góra

*Biuro PL:* Al. Jerozolimskie 123A, 00-965 Warszawa

*Biuro UK:* The Broadgate Tower, 20 Primrose Street, London EC2A 2EW

*Biuro USA:* 401 North Michigan Avenue, Chicago, Illinois, 60611

*Sekretariat:* +48 726 666 655 | *Infolinia:* +48 68 410 99 50

[email-masked] | https://cinkciarz.pl

KRS 0000364722 | Kapitał zakładowy 23.263.500 zł

REGON 080465538 | NIP 9291830388

Audited by: Grant Thornton

Treść tej wiadomości zawiera informacje poufne, przeznaczone tylko dla
adresata. Udostępnianie, ujawnianie, powielanie, rozpowszechnianie bądź
powoływanie się na jakikolwiek jej fragment przez inne osoby jest
zabronione. W razie przypadkowego otrzymania tej wiadomości prosimy o
powiadomienie o tym nadawcy oraz trwałe jej usunięcie. Informacje zawarte w
tej wiadomości mogą być objęte tajemnicą zawodową lub chronione innymi
przepisami prawnymi. Nadawca nie bierze odpowiedzialności za jakiekolwiek
szkody spowodowane wirusem komputerowym przetransmitowanym w tej
wiadomości.  Poglądy i opinie przedstawione w tej wiadomości są wyłącznie
poglądami i opiniami jej autora i niekoniecznie reprezentują poglądy i
opinie firmy.

This is a confidential e-mail intended solely for the use of the entity or
the individual to whom it is addressed. Unauthorized publication, use,
dissemination or disclosure of this message, either in whole or in part is
strictly prohibited. If you have received this message in error please send
it back to the sender and delete it. It may also be privileged or otherwise
protected by work product immunity or other legal rules. The company
accepts no liability for any damage caused by any virus transmitted by this
e-mail. Any views or opinions presented in this e-mail are solely those of
the author and do not necessarily represent those of the company.

---

From: John Mattsson <[email-masked]>
Date: Mon, 12 Oct 2015 09:47:41 +0000

From: Michał Staruch <[email-masked]<mailto:[email-masked]>>
Date: Monday 12 October 2015 11:34
To: John Mattsson2 <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [TLS] TLS 1.3 Recommended ECC curve for 192-bit security

>We already have "SHOULD support key exchange with X25519" in this section,

Yes, but X25519 is also only providing 128-bit security (or 127.5).

>so people implementing it should have no problems with adopting X448<https://tools.ietf.org/html/draft-irtf-cfrg-curves-10#section-6.2> to achieve ~224 bit security where it's needed (and >better performance than P-384).

People will probably not have any problems adopting X448, P-384, or brainpoolP384r1. The problem is that different libraries may support different curves and start diverging. Stating SHOULD support for TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 without specifying a matching ECC curve is just half of what is needed for interoperability.

The sentence "These cipher suites SHOULD support both digital signatures and key exchange with X448.” would be equally good.

On Mon, Oct 12, 2015 at 11:01 AM, John Mattsson <[email-masked]<mailto:[email-masked]>> wrote:
I think the selection of MTI Cipher Suites (Section 8.1 of draft-ietf-tls-tls13-09) is excellent, but I am missing a recommended ECC curve for the “SHOULD” cipher suites. Little benefit of using AES-256 with P-256 or curve25519. Shouldn’t there be a SHOULD implement ECC curve giving at least 192-bit security? E.g.

Cheers,
John

JOHN MATTSSON

Ericsson AB
Ericsson Research
Färögatan 6

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls

--

[email-masked]<mailto:[email-masked]>

[Cinkciarz.pl Sp. z.o.o]<https://cinkciarz.pl>

Cinkciarz.pl Sp. z o.o.

Siedziba: ul. Sienkiewicza 9, 65-001 Zielona Góra

Biuro PL: Al. Jerozolimskie 123A, 00-965 Warszawa

Biuro UK: The Broadgate Tower, 20 Primrose Street, London EC2A 2EW

Biuro USA: 401 North Michigan Avenue, Chicago, Illinois, 60611

Sekretariat: +48 726 666 655 | Infolinia: +48 68 410 99 50

[email-masked]<mailto:[email-masked]> | https://cinkciarz.pl

[Oficjalny sponsor Reprezentacji Polski w piłce nożnej]

Treść tej wiadomości zawiera informacje poufne, przeznaczone tylko dla adresata. Udostępnianie, ujawnianie, powielanie, rozpowszechnianie bądź powoływanie się na jakikolwiek jej fragment przez inne osoby jest zabronione. W razie przypadkowego otrzymania tej wiadomości prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. Informacje zawarte w tej wiadomości mogą być objęte tajemnicą zawodową lub chronione innymi przepisami prawnymi. Nadawca nie bierze odpowiedzialności za jakiekolwiek szkody spowodowane wirusem komputerowym przetransmitowanym w tej wiadomości.  Poglądy i opinie przedstawione w tej wiadomości są wyłącznie poglądami i opiniami jej autora i niekoniecznie reprezentują poglądy i opinie firmy.

This is a confidential e-mail intended solely for the use of the entity or the individual to whom it is addressed. Unauthorized publication, use, dissemination or disclosure of this message, either in whole or in part is strictly prohibited. If you have received this message in error please send it back to the sender and delete it. It may also be privileged or otherwise protected by work product immunity or other legal rules. The company accepts no liability for any damage caused by any virus transmitted by this e-mail. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company.

---

From: Sean Turner <[email-masked]>
Date: Mon, 12 Oct 2015 09:18:30 -0400

It is interesting to note that in discussing update IPSec’s RFC 4307 somebody suggested making 192 a MAY because folks only use 128/256 [1].

spt

[1] http://mailarchive.ietf.org/arch/msg/ipsec/1F5h4j-dP5dLPCCAqg4iqgjjYFE

On Oct 12, 2015, at 05:01, John Mattsson <[email-masked]> wrote:

> <13DEFB94-F735-49B0-8196-BDB5C9017A32[3].png>
> 
> JOHN MATTSSON
> <D377E800-0A1A-43D3-AF5E-165F697789B5[3].png>
>  
> This Communication is Confidential. We only send and receive email on the basis of the terms set out atwww.ericsson.com/email_disclaimer
>

---

From: Yoav Nir <[email-masked]>
Date: Mon, 12 Oct 2015 17:31:12 +0300

True, but that is about key length for AES specifically, not security in general.  The Suite-B recommendations also have the AES key at 256 bits for the higher level but it’s paired with SHA-384.

Yoav

> On Oct 12, 2015, at 4:18 PM, Sean Turner <[email-masked]> wrote:
>

---

From: John Mattsson <[email-masked]>
Date: Mon, 12 Oct 2015 16:49:46 +0000

The statement i [1] is about AES, and is very true. AES-192 is very seldom
used, and people tend to jump directly to AES-256.

For ECC curves, the opposite is true, people tend to use P-384 instead of
P-521. Most likely because of that P-384 is used in suite B. According to
[2], Google Chrome recently dropped support of P-521.

[2] 
https://support.globalsign.com/customer/portal/articles/1995283-ecc-compati
bility

The security level of the AES_256_GCM_SHA384-algorithms is clearly no more
than 192 as SHA-384 is used.

On 12/10/15 15:18, "Sean Turner" <[email-masked]> wrote:

>It is interesting to note that in discussing update IPSec’s RFC 4307
>somebody suggested making 192 a MAY because folks only use 128/256 [1].
>
>spt
>
>>draft-ietf-tls-tls13-09) is excellent, but I am missing a recommended
>>ECC curve for the “SHOULD” cipher suites. Little benefit of using
>>AES-256 with P-256 or curve25519. Shouldn’t there be a SHOULD implement
>>ECC curve giving at least 192-bit security? E.g.
>> 
>> This Communication is Confidential. We only send and receive email on
>>the basis of the terms set out atwww.ericsson.com/email_disclaimer
>>

---

From: Quynh Dang <[email-masked]>
Date: Mon, 12 Oct 2015 13:02:16 -0400

Hi John,

Sha384 in the ciphersuite is the hash function to be used in hmac, not
signatures, and the security of this hmac depends on the strenght of the
hmac key and the tag size.

Regards,
Quynh.
On Oct 12, 2015 12:50 PM, "John Mattsson" <[email-masked]>
wrote:

> >[1]
> http://mailarchive.ietf.org/arch/msg/ipsec/1F5h4j-dP5dLPCCAqg4iqgjjYFE
> >

---

From: John Mattsson <[email-masked]>
Date: Mon, 12 Oct 2015 17:08:29 +0000

Yes, my fault.

From: Quynh Dang <[email-masked]<mailto:[email-masked]>>
Date: Monday 12 October 2015 19:02
To: John Mattsson2 <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Sean Turner <[email-masked]<mailto:[email-masked]>>
Subject: Re: [TLS] TLS 1.3 Recommended ECC curve for 192-bit security

Hi John,

Sha384 in the ciphersuite is the hash function to be used in hmac, not signatures, and the security of this hmac depends on the strenght of the hmac key and the tag size.

Regards,
Quynh.

On Oct 12, 2015 12:50 PM, "John Mattsson" <[email-masked]<mailto:[email-masked]>> wrote:
The statement i [1] is about AES, and is very true. AES-192 is very seldom
used, and people tend to jump directly to AES-256.

[2]

On 12/10/15 15:18, "Sean Turner" <[email-masked]<mailto:[email-masked]>> wrote:

>On Oct 12, 2015, at 05:01, John Mattsson <[email-masked]<mailto:[email-masked]>>
>wrote:
>
>> www.ericsson.com<http://www.ericsson.com>
>>
>>
>>the basis of the terms set out atwww.ericsson.com/email_disclaimer<http://atwww.ericsson.com/email_disclaimer>
>>