Subject: [TLS] Mail regarding draft-ietf-tls-tls13

From: Ben Personick <[email-masked]>
Date: Tue, 12 Jun 2018 20:15:04 +0000

Dear Sirs at the IETF,
(My apology for the long email, I did not have time to write a shorter one)
  We are currently evaluating when to begin offering ECC Certificates based cypto on our websites.

  Despite the advantages to doing this in TLS 1.2, there is a lot of push-back to wait until we "have to support it" once the TLS 1.3 draft is published, and the option to use it becomes available.

  I have read some articles saying the draft is approved, but on looking it seems not to be, I am a little unsure why the draft has been stuck in this seemingly nearly finished but not quite ready state for 3 months.

  Surely if there were some way I could move this project forward I would, but I am not an IETF member, so it seems my only option is to politely enquire with you and note that at least some of us are stuck using only RSA crypto until such time as this draft gets finished, and provides us with the needed emphasis to push our organizations to implement ECC cert cryptos "in preparation to support tls 1.3" as it will actually be a standard.

  I have been pushing for us to begin to proffer ECC certificate based crypto for some time, but until TLS 1.3 is finally accepted as a standard we will continue to see a lot of push-back here, and I suspect this is not unique to our organization, and is likely partially responsible for strangely the slow adoption on the ECDSA cipher support.

  Do we have any realistic Idea of when this proposal will become approved?

 Knowing it is happening, will give me the push I need to get us to buy an implement an ECC Certificate alongside our RSA Cert as we move forward so that we can be "ready for tls 1.3"

Thanks,

Ben

---

From: Sean Turner <[email-masked]>
Date: Sat, 16 Jun 2018 23:04:40 -0400

> On Jun 12, 2018, at 16:15, Ben Personick <[email-masked]> wrote:
> 

The draft has been approved by the IESG.  Once a draft is approved it moves over to the RFC editor (and there’s some IANA review too); here’s a link to the RFC editorial process [0]; here’s a link to their publication queue [1].  3 months is about what I expected in terms of wait post approval.  We’re nearly there.

spt

[0] https://www.rfc-editor.org/pubprocess/
[1] https://www.rfc-editor.org/current_queue.php

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 16 Jun 2018 23:31:42 -0400

> On Jun 12, 2018, at 4:15 PM, Ben Personick <[email-masked]> wrote:
> 
> Despite the advantages to doing this in TLS 1..2, there is a lot of push-back to wait until we “have to support it” once the TLS 1.3 draft is published, and the option to use it becomes available.

I am puzzled why you feel you have to support ECC certificates with
TLS 1.3, and yet not for TLS 1.2?  RSA certificates continue to be
supported in TLS 1.3, and ECDSA certificates are well supported in
TLS 1.2.

Are you referring to deploying ECC certificates in your server
software, or interoperating with ECC servers in your client software?

If the latter, then indeed you should start to support servers that
can only present ECDSA, rather than RSA, certificates.  And do so
with both TLS 1.2 and TLS 1.3, it is not clear why you'd wait for
TLS 1.3 to be published.  (We can party when it comes out, but that
should not IMHO hold up implementations of ECDSA support).

-- 
-- 
	Viktor.

---

From: Ben Personick <[email-masked]>
Date: Mon, 18 Jun 2018 13:10:55 +0000

Hello Viktor,

  Thanks for your thoughtful reply.

  I haven't read the draft itself, only the articals which point to it.

  There is a common thread circulating, that all support for RSA Certificates/Ciphers are dropped in TLS 1.3.

  As I wrote in the last email, I am aware we can implemenet ECC certs and ciphers in TLS 1.2, along side RSA certs/ciphers, however there is a consistent fear of breaking what already works by moving onto offering both an ECC and RSA certificate and corrosponding ciphers.

  If TLS 1.3 does support RSA certs, that removes the drive to begin offering ecdhe_ecdsa alongside ecdhe_rsa, which essentially moves it back to the "Do not need to implement pile", which will not tick forward into the "must implement" pile until it is absolutely required.

I was sincerely hoping to be able to use the expected "end of ths RSA Cert" to move us there in preparation of supporting TLS 1.3 and for once be ahead of the curve instead of implemementing what seems to be superiod encryption methods much later.

Ben

________________________________
From: Viktor Dukhovni <[email-masked]>
Sent: Saturday, June 16, 2018 11:31 PM
To: Ben Personick
Cc: [email-masked]
Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13

--
--
        Viktor.

---

From: Ben Personick <[email-masked]>
Date: Mon, 18 Jun 2018 13:11:29 +0000

Hello Sean

  Thanks for the explination. :)

Ben

________________________________
From: Sean Turner <[email-masked]>
Sent: Saturday, June 16, 2018 11:04 PM
To: Ben Personick
Cc: [email-masked]
Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13

spt

[0] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fpubprocess%2F&data=02%7C01%7Cben.personick%40iongroup.com%7Ca655a0eeead9423fbd0408d5d3ff13d0%7C768fe7d4ebee41a79851d5825ecdd396%7C0%7C1%7C636648014877571083&sdata=P7w%2BqRt4H8tqJaRkG%2FoQJg8%2FJMDABTe6BAcgx33JWEU%3D&reserved=0
[1] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fcurrent_queue.php&data=02%7C01%7Cben.personick%40iongroup.com%7Ca655a0eeead9423fbd0408d5d3ff13d0%7C768fe7d4ebee41a79851d5825ecdd396%7C0%7C1%7C636648014877571083&sdata=IxdHA4%2FTBCy%2BugEOcO37Rx4nDiRXOCSIAQOLlXtVSmQ%3D&reserved=0

---

From: Tony Arcieri <[email-masked]>
Date: Mon, 18 Jun 2018 08:36:00 -0700

On Mon, Jun 18, 2018 at 6:30 AM Ben Personick <[email-masked]>
wrote:

> There is a common thread circulating, that all support for RSA
> Certificates/Ciphers are dropped in TLS 1.3.
>

RSA certificates will continue to work in TLS 1.3+.

What will not be supported in TLS 1.3+ is RSA key transport / key
encipherment (which lacks forward secrecy, among other problems). However,
this is a property of how the protocol does key exchange / key agreement
and has nothing to do with certificates.

-- 
Tony Arcieri

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 18 Jun 2018 12:32:54 -0400

> On Jun 18, 2018, at 9:10 AM, Ben Personick <[email-masked]> wrote:
> 

This is not the case.

> As I wrote in the last email, I am aware we can implemenet ECC certs and ciphers in TLS 1.2, along side RSA certs/ciphers, however there is a consistent fear of breaking what already works by movin…

You should at least support verifying ECDSA certificates on the client
side, some servers your client software might connect to may have only
ECDSA certificates.  On the server side you can continue to use RSA
certificates if you wish.  While ECDSA is faster on the server, there
are still some clients (perhaps yours among them) that only support RSA,
and so you'd need to have both RSA and ECDSA certificates, which is
operationally a bit more challenging.

-- 
	Viktor.

---

From: Tony Arcieri <[email-masked]>
Date: Mon, 18 Jun 2018 12:46:27 -0700

On Mon, Jun 18, 2018 at 12:12 PM Ben Personick <[email-masked]>
wrote:

>   So essentially TLS 1.3 drops support for DH/DHE ciphers on RSA keys, but
> willl otherwise work as expected?
>

DH/DHE ciphers are orthogonal to RSA key transport/encipherment. The latter
uses the RSA algorithm for encryption, without any DH(E) algorithm
whatsoever, and that is what is no longer supported in TLS 1.3.

-- 
Tony Arcieri

---

From: Ben Personick <[email-masked]>
Date: Mon, 18 Jun 2018 19:10:05 +0000

Hello Viktor,

  I am only concerned with offereing newer , faster, and more secure cipher suites on our web application, so that as clients have the ability to use them they can begin to do so.

  Our LB offers a method to present baoth an RSA and ECC cert at thw aame time, at the cost of buying both each year.

  I can only support ecdsa_rsa unless I have an ECC certificate to support ecsda_ecsde ciphers.

  Since TLS 1.3 will continue to allow ecdsa_rsa ciphers, there will be no push to move towards offering them, because of various 'reasons'.

Ben

________________________________
From: Viktor Dukhovni <[email-masked]>
Sent: Monday, June 18, 2018 12:32
To: Ben Personick
Cc: TLS WG
Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13

This is not the case.

--
        Viktor.

---

From: Ben Personick <[email-masked]>
Date: Mon, 18 Jun 2018 19:12:10 +0000

Hello Tony,

  So essentially TLS 1.3 drops support for DH/DHE ciphers on RSA keys, but willl otherwise work as expected?

Ben

________________________________
From: Tony Arcieri <[email-masked]>
Sent: Monday, June 18, 2018 11:36
To: Ben Personick
Cc: <[email-masked]>
Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13

On Mon, Jun 18, 2018 at 6:30 AM Ben Personick <[email-masked]<mailto:[email-masked]>> wrote:
There is a common thread circulating, that all support for RSA Certificates/Ciphers are dropped in TLS 1.3.

What will not be supported in TLS 1.3+ is RSA key transport / key encipherment (which lacks forward secrecy, among other problems). However, this is a property of how the protocol does key exchange / key agreement and has nothing to do with certificates.

--
Tony Arcieri

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 19 Jun 2018 00:04:23 -0400

> On Jun 18, 2018, at 3:12 PM, Ben Personick <[email-masked]> wrote:
> 

No, it drops support for *non* (EC)DHE RSA ciphers,
keeping *only* the (EC)DHE RSA ciphers, for specific
FFDHE groups (as before) specific ECDHE curves.

Note that (IIRC) the TLS 1.3 implementation in OpenSSL 1.1.1
will not include support the TLS 1.3 finite-field DHE groups,
and so TLS 1.3 interoperability with OpenSSL *requires* ECDHE
support.  If your implementation offers TLS 1.3, but offers
no ECDHE signature algorithms, the handshake will (IIRC) likely
fail.

So what's becoming effectively mandatory with TLS 1.3 is
ECDHE key agreement, not ECDSA certificates, though TLS 1.3
clients really should also support connections to servers that
have ECDSA P-256, P-384, P-521, Ed25519 and Ed448 certificates.
But servers can stick with RSA certificates so long as they
are willing to do ECDHE key agreement.

-- 
	Viktor.

---

From: Hubert Kario <[email-masked]>
Date: Tue, 19 Jun 2018 12:22:54 +0200

>   I can only support ecdsa_rsa unless I have an ECC certificate to support

that is software limitation, not protocol limitation
 
>   Since TLS 1.3 will continue to allow ecdsa_rsa ciphers, there will be no
> push to move towards offering them, because of various 'reasons'.

technically, there are no ecdsa_rsa, ecdhe_rsa or ecdhe_ecdsa ciphers in TLS 
1.3, the signature over key exchange is guided by the signature_algorithms 
extensions only, cipher suite does not influence it

> > As I wrote in the last email, I am aware we can implemenet ECC certs and
> > ciphers in TLS 1.2, along side RSA certs/ciphers, however there is a
> > consistent fear of breaking what already works by moving onto offering
> > both an ECC and RSA certificate and corrosponding ciphers.

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 19 Jun 2018 15:06:44 +0000

>  Since TLS 1.3 will continue to allow ecdsa_rsa ciphers, there will be no push to move towards offering them, because of various 'reasons'.

I think you mean ECDH with RSA.  But yes, that’s a common situation, few organizations pay to add security until they’re “forced” to do so.  You’re not alone.

---

From: Ben Personick <[email-masked]>
Date: Tue, 19 Jun 2018 15:17:26 +0000

Hi Rich,
  Yes, I meant ECDHE_ECDSA and ECDHE_RSA are both supported in TLS 1.3, I’d been lead to believe that all RSA based ciphers were not supported.

 Having seem some further responses, it appears it is only the NON ECDHE RSA Based ciphers which are having support dropped in TLS 1.3

  Ie all Non-Elliptic Curve Diffie Hellman ciphers ( eg AES-256 w/o DH, with DH or EDH/DHE, but not ECDHE_RSA)

  And yeah, it’s been my experience everywhere, but I was pretty pumped up to have a better reason to push to start implementing ECDHE_ECDSA Ciphers in addition to our existing Ciphers.
Ben
From: Salz, Rich [mailto:[email-masked]]
Sent: Tuesday, June 19, 2018 11:07 AM
To: Ben Personick <[email-masked]>; TLS WG <[email-masked]>
Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 19 Jun 2018 13:07:17 -0400

> On Jun 19, 2018, at 11:17 AM, Ben Personick <[email-masked]> wrote:
> 

I may have been too cryptic.  When I wrote (EC)DHE I meant both DHE and ECDHE.
However, some (early) implementations may only support ECDHE with TLS 1.3.
IIRC, OpenSSL 1.1.1 does not yet support the TLS 1.3 DHE groups.  So
interoperability if you only support DHE may be problematic.

-- 
	Viktor.

---

From: [email-masked] (Martin Rex)
Date: Wed, 20 Jun 2018 01:06:40 +0200 (CEST)

Ben Personick <[email-masked]> wrote:
> Despite the advantages to doing this in TLS 1.2, there is a lot of
> push-back to wait until we "have to support it" once the TLS 1.3 draft
> is published, and the option to use it becomes available.

Honestly, why would you want to do this?

ECC/RSA Dual Cert setups a cryptographically a bad idea, and a real
nuisance for interoperability.

Elliptic Curve Crypto, when used with the design-flawed ECDSA digital
signature algorithm, might leak the private key within a few thousand
TLS full handshakes to a mere passive observer.

Support for EdDSA is somewhere between thin and non-existent still.

And for programmatic TLS clients, which take security serious, and
do not come with hundreds of public CA certificates preconfigured
as trusted, a sudden change of the TLS server certificate when
rearranging TLS cipher suites or when the underlying TLS implementation
starts include support for ECDSA certificates, can easily result
in a sudden unexpected loss of interop (missing trust).

Testing that you have the required trust properly configured for
*BOTH* TLS server certs is a royal pita, and _preparing_ for a TLS client
software update that adds support for ECDSA cipher suites is pretty
much impossible to test (unless you already have that implementation,
but that is not what I meant with preparing).

-Martin

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 20 Jun 2018 12:48:08 +0300

>   And yeah, it’s been my experience everywhere, but I was pretty pumped up to have a better reason to push to start implementing ECDHE_ECDSA Ciphers in addition to our existing Ciphers.

I made a list of all supported cryptographic algorithms in base
TLS 1.3:

- Algorithms marked with [W] are widely supported.
- If preshared keys are used, no signatures are used (ligtens load at
  cost of poor scalability).
- If preshared keys are used, those may be combined with asymmetric key
  exchange (or may be used alone, giving very light but poorly scalable
  key exchange).
- There are no-protocol level constraints on mixing and matching
  algorithms of different kinds (except symmetric cipher and handshake
  hash). The server might tweak relative preferences to try avoid wide
  mismatches in strength, but MUST enable full cartesian product.
- Most work in TLS 1.2 too, if supported:
  - The negotiation for classical Diffie-Hellman is broken in TLS 1.2,
    leading many clients to just disable classical Diffie-Hellman
    (1.3 fixes this issue).
  - Classical Diffie-Hellman can only be combined with RSA signatures
    (others can be combined with all signature types).

Asymmetric key exchanges:

- Elliptic-curve Diffie-Hellman using NIST P-256 curve[W]
- Elliptic-curve Diffie-Hellman ECDH using NIST P-384 curve[W]
- X25519 key exchange (a.k.a. Curve25519)[W]
- Elliptic-curve Diffie-Hellman ECDH using NIST P-521 curve
- X448 key exchange
- Diffie-Hellman with p=Pe(2048, 560316)
- Diffie-Hellman with p=Pe(3072, 2625351)
- Diffie-Hellman with p=Pe(4096, 5736041)
- Diffie-Hellman with p=Pe(6144, 15705020)
- Diffie-Hellman with p=Pe(8192, 10965728)

Where: Pe(n,x) = 2^n-2^(n-64)+{[2^(n-130)*e]+x}*2^64-1 (a n-bit
prime)

Signature algorithms:

- RSA-PSS using SHA-256 (using generic RSA or RSA-PSS keys)[W]
- RSA-PSS using SHA-384 (using generic RSA or RSA-PSS keys)[W]
- RSA-PSS using SHA-512 (using generic RSA or RSA-PSS keys)[W]
- ECDSA usign NIST P-256 curve and SHA-256[W]
- ECDSA usign NIST P-384 curve and SHA-384[W]
- ECDSA usign NIST P-521 curve and SHA-512[W]
- RSA PKCS#1v1.5 using SHA-256 (certificate signing only)[W]
- RSA PKCS#1v1.5 using SHA-384 (certificate signing only)[W]
- RSA PKCS#1v1.5 using SHA-512 (certificate signing only)[W]
- Ed25519
- Ed448

Symmetric algorithms:

- 128-bit AES in GCM mode with SHA-256 handshake hash.[W]
- 256-bit AES in GCM mode with SHA-384 handshake hash.[W]
- 256-bit Chacha20 and Poly1305 with SHA-256 handshake hash.[W]
- 128-bit AES in CCM mode with SHA-256 handshake hash.
- 128-bit AES in CCM(64-bit tag) mode with SHA-256 handshake hash.

-Ilari

---

From: Ben Personick <[email-masked]>
Date: Tue, 19 Jun 2018 17:10:44 +0000

Hi Victor,

  We've never supported DHE, and are skipping it to ECDHE as DHE is considered by our security scans to be too insecure (as our LB's implementation is capped at 1024 bit ephemerals)

________________________________
From: Viktor Dukhovni <[email-masked]>
Sent: Tuesday, June 19, 2018 1:07 PM
To: Ben Personick
Cc: TLS WG
Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13

--
        Viktor.