Subject: Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3

From: Eric Rescorla <[email-masked]>
Date: Sat, 3 May 2014 16:31:56 -0700

The following pull request is intended to execute this change:

https://github.com/tlswg/tls13-spec/pull/37

I'll merge it in on Tuesday. Please let me know before then if
this seems substantially wrong. As usual, minor editorial issues
can be done by pull requests.

Note that we also need to determine a new MTI cipher suite
(https://github.com/tlswg/tls13-spec/issues/32) since the
previous one uses static RSA. I've left that as a TODO for now.

-Ekr

On Sat, Apr 26, 2014 at 8:24 AM, Joseph Salowey (jsalowey) <
[email-masked]> wrote:

> The discussion on this list and others supports the consensus in IETF 89
> to remove RSA key transport cipher suites from TLS 1.3.  The Editor is
> requested to make the appropriate changes to the draft on github.
>
> More discussion is needed on both DH and ECDH are used going forward and
> on if standard DHE parameters will be specified.
>
> Joe
> [For the chairs]
> On Mar 26, 2014, at 11:43 AM, Joseph Salowey (jsalowey) <
> [email-masked]> wrote:
>
> > TLS has had cipher suites based on RSA key transport (aka "static RSA",
> TLS_RSA_WITH_*) since the days of SSL 2.0.   These cipher suites have
> several drawbacks including lack of PFS, pre-master secret contributed only
> by the client, and the general weakening of RSA over time.  It would make
> the security analysis simpler to remove this option from TLS 1.3.  RSA
> certificates would still be allowed, but the key establishment would be via
> DHE or ECDHE.  The consensus in the room at IETF-89 was to remove RSA key
> transport from TLS 1.3.  If you have concerns about this decision please
> respond on the TLS list by April 11, 2014.
> >
> > Thanks,
> >
> > Joe
> > [Speaking for the TLS chairs]
> > _______________________________________________
> > TLS mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 05 May 2014 09:28:23 +0200

> can be done by pull requests.

Shouldn't such a change depend on a fix to the compatibility issues
present in the DHE ciphersuites? Otherwise it just makes ECDHE the only
key exchange in TLS that can be made compatible with random peers.

Elliptic curves are good, but it would be nice to have non-ECC key
exchanges as well.

regards,
Nikos

---

From: Kurt Roeckx <[email-masked]>
Date: Mon, 5 May 2014 19:00:29 +0200

> Elliptic curves are good, but it would be nice to have non-ECC key

I was under the impression that there was also a proposal to use
known DHE primes so that there is no requirment to verify them.

I'm not sure this is written down somewhere, but I think that we
only want to use things where the verification is very simple.

Kurt

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 5 May 2014 10:23:37 -0700

You're probably thinking of:
http://tools.ietf.org/html/draft-gillmor-tls-negotiated-dl-dhe-02

This seems like a reasonable kind of thing for the WG to
consider, but my impression was that the WG consensus
was to remove static RSA unconditionally. Certainly, it would
be reasonable to argue that we should address this issue prior
to final publication, however.

-Ekr

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 05 May 2014 13:25:30 -0400

> Elliptic curves are good, but it would be nice to have non-ECC key

I agree with this sentiment, and hope that folks will review my proposal
for improvements to the discrete log DHE key exchange:

 https://datatracker.ietf.org/doc/draft-gillmor-tls-negotiated-dl-dhe/

If you're thinking of other compatibility issues with DHE ciphersuites
aren't covered by that draft, please let me know, i'd like to try to
improve the situation.

I would be happy to have the draft worked on by this WG if people here
think it's useful to the protocol.

(note also that these improvements to DL-DHE do not need to wait until
TLS 1.3 to be useful)

	--dkg

---

From: Kurt Roeckx <[email-masked]>
Date: Mon, 5 May 2014 19:46:14 +0200

> to final publication, however.

I'm not sure what you mean with "static RSA".  It's my
understanding that this proposal is about removing the RSA key
exchange and only using something like DHE and ECDHE.  That draft
would still be valid and useful if RSA key exchanges are dropped.

Kurt

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 5 May 2014 10:48:51 -0700

On Mon, May 5, 2014 at 10:46 AM, Kurt Roeckx <[email-masked]> wrote:

> exchange and only using something like DHE and ECDHE.

Correct. I mean "RSA key exchange". My point was that my impression of
WG consensus was that we were to remove RSA key exchange regardless
of the fate of Daniel's draft.

>  That draft

Yes, I agree. I'm merely saying that I don't think it's a precondition to
merging this pull request.

-Ekr

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 06 May 2014 11:13:18 +0200

> consider,

I believe that this draft addresses the existing concerns with the DH
ciphersuites I'm aware of, and would be very good if the TLS WG would
adopt it.

regards,
Nikos

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 6 May 2014 15:25:14 +0000

> ciphersuites I'm aware of, and would be very good if the TLS WG would

Other collections of DHE groups work in a subgroup of order "q",
where log(q) ~ 2^{security factor}.  This speeds up the arithmetic.
(Squares can be reduced modulo the much smaller q).  Is there a
reason to avoid those?  Problems with constant-time implementation?
Other concerns?

-- 
	Viktor.

---

From: Watson Ladd <[email-masked]>
Date: Tue, 6 May 2014 08:51:33 -0700

> reason to avoid those?  Problems with constant-time implementation?

How do you know I in fact gave you an element of that subgroup? The
obvious fixes are all very slow.
Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 06 May 2014 18:44:31 +0200

On Tue, 2014-05-06 at 15:25 +0000, Viktor Dukhovni wrote:

> (Squares can be reduced modulo the much smaller q).

I think the speed up in that case is because the exponent x is selected
to be in the range (1,q-1). The modular reduction is again mod p.

>   Is there a

This is another valid approach. Note however, that in the groups
described in the draft there is a suggested key size which speeds the
calculations similarly.

regards,
Nikos