Subject: [TLS] Call for Consensus: ECC on standards track

From: Sean Turner <[email-masked]>
Date: Thu, 26 Jun 2014 01:50:39 +0100

WG Members,

Based on the mailing list discussion, the chairs believe that there is
strong support to publish TLS ECC Cipher Suites on the Standards
Track

- Should we include TLS ECC Cipher Suites for AES-GCM
  directly in the TLS 1.3 document (and hence on the Standards Track).

- Should we reclassify the TLS ECC Cipher Suites that correspond
  to currently recommended ciphers as  Standards Track. If there is
  general consensus for this, the chairs will solicit/develop a detailed
  proposals, but this will presumably include AES-GCM, not include
  RC4, and we'll have do debate AES-CBC.

Note that we are not currently calling for consensus on whether
ECC-based cipher suites should be MTI for TLS 1.3. We expect
that to be a topic of a separate discussion later in the TLS 1.3
process.

spt
[For the chairs]

---

From: Watson Ladd <[email-masked]>
Date: Wed, 25 Jun 2014 20:04:54 -0700

>   directly in the TLS 1.3 document (and hence on the Standards Track).

Yes, including Curve25519. (Why isn't the CFRG ready? It doesn't take
6 months to decide on the deposition of a single bit)
>   RC4, and we'll have do debate AES-CBC.

This is for TLS 1.2 and below, correct? What difference does this make
to anything being standards track or not?

Sincerely,
Watson Ladd

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

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

---

From: [email-masked] (Martin Rex)
Date: Thu, 26 Jun 2014 05:45:24 +0200 (CEST)

>   directly in the TLS 1.3 document (and hence on the Standards Track).

I believe this message is somehow falling short of the real situation.

rfc4492,  which specifies the use of ECC crypto with TLS is currently
an Informational document, i.e. the whole use of ECC in TLS is
limited audience rather than standards track.

Similarly, while AES-GCM with RSA and DHE_RSA key exchange (rfc5288)
is a standards track document today, AES-GCM with ECC (rfc5289)
is an informational document just like underlying rfc4492.

You would have to move the whole ECC for TLS stuff to standards track
before thinking about adding any cipher suites that depend on this
into the base TLS spec.

-Martin

---

From: Geoffrey Keating <[email-masked]>
Date: 25 Jun 2014 21:36:55 -0700

>   RC4, and we'll have do debate AES-CBC.

I support these proposals.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 25 Jun 2014 21:37:19 -0700

On Wed, Jun 25, 2014 at 8:45 PM, Martin Rex <[email-masked]> wrote:

> into the base TLS spec

Unless I am missing something, RFC 3967 permits normative references
from Standards Track RFCs to Informational RFCs, provided that those
issues are called out in IETF LC. So, I believe we could simply refer to
4492 from TLS 1.3 provided we follow the RFC 3967 Section 3.

However, this isn't the only alternative:
1.As the sense of the second question suggests, a potentially
more attractive avenue would be to produce a new document that
specified ECC w/ the current recommended set of symmetric ciphers
and advance that on the standard track.

2. If people don't feel like messing with the pre TLS 1.3 documents,
but do want ECC to be a basic part of 1.3 we could just import the
relevant sections of 4492 into TLS 1.3 (this might be desirable for
editorial reasons in any case) and just advance those pieces
on the standards track.

-Ekr

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 26 Jun 2014 04:41:04 +0000

> editorial reasons in any case) and just advance those pieces

Any chance that missing AECDH AEAD ciphersuites will be added?
Right now, I can have anon ECDHE (AECDH) key exchange or AEAD
symmetric crypto, but not both.

-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 25 Jun 2014 21:46:22 -0700

> symmetric crypto, but not both.

This certainly seems like something the WG could discuss, though
I think it's separable from the broader ECC question.

I've created a Github issue to track this topic so we don't lose it.
https://github.com/tlswg/tls13-spec/issues/50

-Ekr

---

From: [email-masked] (Martin Rex)
Date: Thu, 26 Jun 2014 07:34:43 +0200 (CEST)

> 4492 from TLS 1.3 provided we follow the RFC 3967 Section 3.

The copy of rfc3967 that I'm just looking at contains the following exclusion
(last paragraph of Section 3):

   This procedure should not be used if the proper step is to move the
   document to which the reference is being made into the appropriate
   category.  It is not intended as an easy way out of normal process.
   Rather, the procedure is intended for dealing with specific cases
   where putting particular documents into the required category is
   problematic and unlikely ever to happen.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 26 Jun 2014 05:40:01 -0700

On Wed, Jun 25, 2014 at 10:34 PM, Martin Rex <[email-masked]> wrote:

>    problematic and unlikely ever to happen

Yes, I have read that as well, but as a practical matter, we have done
normative downrefs to documents which in principle could have
been uplifted but in practice are not going to be, See, for instance
the case of 2818:
http://datatracker.ietf.org/doc/rfc2818/referencedby/

Also, see:
http://tools.ietf.org/html/rfc4897

However, as I said in my previous response, we can also publish
standards track documents which describe ECC without referring
to 4492, so I don't think this is really a problem procedurally if
the WG decides that what it wants is for ECC to be on the standards
track.

-Ekr