Subject: [TLS] call for consensus: changes to IANA registry rules for cipher suites

From: Sean Turner <[email-masked]>
Date: Tue, 29 Mar 2016 21:53:13 -0400

Hi!

In Yokohama, we discussed changing the IANA registry assignment rules for cipher suites to allow anyone with a stable, publicly available, peer reviewed reference document to request and get a code point and to add an “IETF Recommended” column to the registry.  This change is motivated by the large # of requests received for code points [0], the need to alter the incorrect perception that getting a code point somehow legitimizes the suite/algorithm, and to help implementers out.  We need to determine whether we have consensus on this plan, which follows:

1. The IANA registry rules for the TLS cipher suite registry [1] will be changed to specification required.

2. A new “IETF Recommended” column will be added with two values: “Y” or “N”.  Y and N have the following meaning:

 Cipher suites marked with a “Y” the IETF has consensus on
 and are reasonably expected to be supported by widely
 used implementations such as open-source libraries.  The
 IETF takes no position on the cipher suites marked with an
 “N”.  Not IETF recommended does not necessarily (but can)
 mean that the ciphers are not cryptographically sound (i.e.,
 are bad).  Cipher suites can be recategorized from N to Y
 (e.g., Curve448) and vice versa.

3. We will add a “Note" to the IANA registry itself (i.e., on [0]) that matches the above so that the same information is available to those who don’t read the IANA considerations section of the RFC.

Please indicate whether or not you could support this plan.

Thanks,

J&S

[0] In the last year, the chairs have received requests for:

PSK: https://datatracker.ietf.org/doc/draft-mattsson-tls-ecdhe-psk-aead/
AES-OCB: https://www.ietf.org/archive/id/draft-zauner-tls-aes-ocb-03.txt
Kcipher2: https://datatracker.ietf.org/doc/draft-kiyomoto-kcipher2-tls/
dragonfly: https://datatracker.ietf.org/doc/draft-ietf-tls-pwd/
NTRU:  http://www.ietf.org/id/draft-whyte-qsh-tls12-01.txt
JPAKE: not sure they got around to publishing a draft.

[1] https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 30 Mar 2016 05:06:15 +0000

Strongly support this.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 30 Mar 2016 08:29:42 +0300

Hi Sean

I also strongly support this.  I’m just wondering how we plan to enforce the "stable, publicly available, peer reviewed reference” part. As your examples below show, the reference tends to be an I-D. That’s stable and publicly available, but we have no idea if it’s peer reviewed or who the author’s peers are.

One other thing, in some of the links you pasted below you give a specific draft version (like https://www.ietf.org/archive/id/draft-zauner-tls-aes-ocb-03.txt) while for the others you give the generic version (like https://datatracker.ietf.org/doc/draft-ietf-tls-pwd/). The former is stable but the latter is not. Are the authors free to keep modifying the specification after getting the code point?

Yoav

> On 30 Mar 2016, at 4:53 AM, Sean Turner <[email-masked]> wrote:
> 
> Hi!
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 30 Mar 2016 02:23:27 -0400

> Please indicate whether or not you could support this plan.

I support this plan.

  --dkg

---

From: Dmitry Belyavsky <[email-masked]>
Date: Wed, 30 Mar 2016 14:27:57 +0300

Dear Sean,

I support the plan in general, but I think that we need to separately
indicate
that a particular algorithm/ciphersuite is not just "Not recommended" but
found insecure.

Thank you!

On Wed, Mar 30, 2016 at 4:53 AM, Sean Turner <[email-masked]> wrote:

> Hi!
>
> In Yokohama, we discussed changing the IANA registry assignment rules for
> cipher suites to allow anyone with a stable, publicly available, peer
> reviewed reference document to request and get a code point and to add an
> “IETF Recommended” column to the registry.  This change is motivated by the
> large # of requests received for code points [0], the need to alter the
> incorrect perception that getting a code point somehow legitimizes the
> suite/algorithm, and to help implementers out.  We need to determine
> whether we have consensus on this plan, which follows:
>
> 3. We will add a “Note" to the IANA registry itself (i.e., on [0]) that
> matches the above so that the same information is available to those who
> don’t read the IANA considerations section of the RFC.
>
> [1]
> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4
>
>

-- 
SY, Dmitry Belyavsky

---

From: Henrick Hellström <[email-masked]>
Date: Wed, 30 Mar 2016 13:40:24 +0200

On 2016-03-30 13:27, Dmitry Belyavsky wrote:
> that a particular algorithm/ciphersuite is not just "Not recommended"
> but found insecure.

This does indeed sound reasonable.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 30 Mar 2016 10:33:09 -0500

> Please indicate whether or not you could support this plan.

I support this plan (with the expectation that the IANA "specification
required" rules take precedence over the informal text in this mail
about a "stable, publicly available, peer reviewed reference document",
as Yoav noted as a potential issue).

I am not sure that we want to be in the business of explicitly marking
things as insecure other than our own RFCs, though -- there could be an
implication of more review than is actually the case, which is what this
proposal is trying to get rid of.

-Ben

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 30 Mar 2016 08:37:33 -0700

I am in favor of this.

---

From: Henrick Hellström <[email-masked]>
Date: Wed, 30 Mar 2016 18:03:21 +0200

> proposal is trying to get rid of.

So how about explicitly marking things as "obsolete" instead?

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 30 Mar 2016 12:05:26 -0400

> proposal is trying to get rid of.

I think i agree with Ben here: if we have a tri-state:
approved/not-approved/known-bad, then the people will infer that the
not-approved ciphersuites are better than the known-bad ones, which
isn't necessarily the case.

I think i'd rather see it stay at "approved/not-approved"

      --dkg

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 30 Mar 2016 16:08:31 +0000

> I think i'd rather see it stay at "approved/not-approved"

There is also the concern that various parties (e.g., national crypto) can get upset by this kind of thing.  Which is why I prefer "approved/no-comment" as the dividing line.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 30 Mar 2016 19:32:54 +0300

> On 30 Mar 2016, at 7:05 PM, Daniel Kahn Gillmor <[email-masked]> wrote:
> 
> I think i'd rather see it stay at "approved/not-approved”

+1

Nothing will ever be marked as known-bad unless it’s in widespread use. Nobody’s ever going to write a die-die-die document for some homebrew cipher or even for a national cipher unless something really spectacular happens. I’d rather not have them marked as “neutral”, which implies they are better than RC4’s “known-bad”. 

Besides, what about 3DES? For limited amounts of data it works perfectly fine if you follow all the CBC caveats, but with high-speed high-volume connections, you’ll have to rekey often. And there are faster, better alternatives. Do we mark it as “known-bad”? It’s certainly not broken the way RC4 is. I’d rather we not go there.

Yoav

---

From: Sean Turner <[email-masked]>
Date: Wed, 30 Mar 2016 14:03:39 -0400

I apologize in advance; this is about process so it’s long.

> I also strongly support this.  I’m just wondering how we plan to enforce the "stable, publicly available, peer reviewed reference” part. As your examples below show, the reference tends to be an I-…

Note that I think both the cipher suite assignment specification and the algorithm specification need to be "stable, publicly available, peer reviewed reference.” Normally, the former informatively refers to the latter. [0]  The algorithm specification is not always an RFC, but the cipher suite assignment specifications have been; this plan changes that under certain circumstances (see below).

As far as stable and publicly available are concerned, these are part of the process now, as specified in [1] (and if the update ever gets done in [2]):

  Values and their meanings must be
  documented in a permanent and readily available public
  specification, in sufficient detail so that interoperability
  between independent implementations is possible.  When used,
  Specification Required also implies use of a Designated
  Expert, who will review the public specification and
  evaluate whether it is sufficiently clear to allow
  interoperable implementations.  The intention behind
  "permanent and readily available" is that a document can
  reasonably be expected to be findable and retrievable long
  after IANA assignment of the requested value.  Publication
  of an RFC is an ideal means of achieving this requirement,
  but Specification Required is intended to also cover the
  case of a document published outside of the RFC path.

This definition gives power/discretion to the designated expert (it’s ekr btw).  We can:

a) defer to the expert's judgement (some of what they are to do is in [1][2]), or
b) write some rules for the IANA considerations section that they’ll follow.

I think that a) has worked in the past and would continue to work in the future, but b) couldn’t hurt. If we go for a) then if the expert is ever unsure, they can just ask the AD/WG chair/community for guidance [3][4].  Beware that the text for b) will be like a bright light for process moths [5].

As far as peer review, this is where the silent “c” in team comes to play (c is for community).  If the expert is not sure, then they'd ask the AD/WG chair/community for guidance.  We could also use b) to provide some rules, which could include references to BCP 61 [6] (and for MTI algs [7]).

> One other thing, in some of the links you pasted below you give a specific draft version (like https://www.ietf.org/archive/id/draft-zauner-tls-aes-ocb-03.txt) while for the others you give the gen…

Sorry I wasn’t clear.  The references I listed were not supposed to imply stability they were just the list of cipher suites Joe and I have received requests from over the past year.   I don’t think that authors are free to keep modifying their specification after getting a code point, because of the Specification Required definition [8].

Some other things we should be clear on:

1. All of the drafts referenced and the future drafts requesting code points do *not* need to come through the WG.  But, I do think drafts that want a “Y” need to come through, and we shouldn’t kid ourselves most folks will want the “Y”.  How does this sound (here I assume the algorithms are already published elsewhere i.e., this is just for the assignments):

a) For MTI and “Y” requests,
a.1) requester’s publish individual draft,
a.2) requester’s ask for wg adoption,
a.3) wg chairs do adoption call,
a.4) wg does its thing on wg draft,
a.5) ietf does its thing, and
a.6) iana (assigns #s) & rfc editor (publishes) do their things.

b) For all others: 
b.1) request is submitted to IANA, WG, WG chair, AD,
b.2) request is redirected to designated expert,
b.3) designated experts reviews request:
-- if good-to-go designated expert tells IANA to assign code point (goto b.4)
-- if not-good-to-go for an obvious reasons the designated expert rejects the request with some rationale (and probably lets the sec ADs know about it)
-- if not-good-to-go for all other reasons the designated expert asks (expert's choice depending on the situation) AD/WG chairs/community for guidance
b.4) iana makes assignment and includes the cipher suite assignment specification reference in the registry (and possibly the rfc editor does their thing if an RFC is being published)

Early assignment rules can still apply to a) and b).

2. As far as draft-ietf-tls-pwd, we need to decide whether it should continue as a WG draft or free Dan to pursue other publication avenues.

3. We should avoid a long list of “updates” to TLS1.3 RFC#-to-be when new cipher suites get added.  Drafts should only include an “updates” header if we’re modifying the MTIs or we’re adding a new “Y” cipher suite because we only expect all implementations to support these cases.

4. WRT language -  I’m assuming we’d continue to have English versions of the algorithm specification.

spt

[0] One reason is that the CFRG doesn’t publish standards track RFC so the references to algorithm specifications that come through the CFRG need to be informative.

[1] https://datatracker.ietf.org/doc/rfc5226/

[2] https://datatracker.ietf.org/doc/draft-leiba-cotton-iana-5226bis/

[3] No worries - there is of course process to replace rouge experts, for experts to appeal said decision [3a], etc.

[3a] Section 6.5.1 of https://datatracker.ietf.org/doc/rfc2026/

[4] If history is any guide, I doubt the TLS mailing list is going to go away even if the WG closes (e.g., mailing lists for stalwarts like PKIX, SMIME, SSH are still around).

[5] Note that I very much want to avoid the following very deep and very dark rat hole: establishing an IANA registry of approved reference organizations/sites/etc. that the expert can refer to for a “free pass” org/sites/etc. {rant: [~5~]}

[~5~] { rant: If we do go down this rat hole, I’ve got some specific organizations in mind that we should ban from ever being included in this list until they publicly state that they’ll allow normative references to IETF RFCs in their documents/standards/etc. And, now that I think about it maybe we’d include some country’s too. (I warned you it was a rant) }

[6] https://datatracker.ietf.org/doc/rfc3365/

[7] https://datatracker.ietf.org/doc/draft-rsalz-drbg-speck-wap-wep/

[8] I’m sure this rule has been broken at some point in the past, but it’s not one I’m advocating that we break it on a regular basis.

---

From: Sean Turner <[email-masked]>
Date: Wed, 30 Mar 2016 14:06:53 -0400

> as Yoav noted as a potential issue).

Technically, the “specification required” rules are the IETF’s [0][1], but yeah these rules win over this email thread all day everyday.

spt

[0] https://datatracker.ietf.org/doc/rfc5226/
[1] https://datatracker.ietf.org/doc/draft-leiba-cotton-iana-5226bis/

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 30 Mar 2016 22:20:08 +0300

> I think i'd rather see it stay at "approved/not-approved"

Then how should ciphersuites with explicit diediedie RFCs (currently
RC4) be presented?

-Ilari

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 30 Mar 2016 15:44:59 -0400

> Then how should ciphersuites with explicit diediedie RFCs (currently

i'd say that they are "not-approved", clearly. :)

We don't represent those RFCs in any way at all right now, and yet they
seem to have some kind of social impact.

I observe that we have a "notes" column in the ciphersuite registry
currently, which indicates one or more RFCs related to the ciphersuite
in question:

I'm a little disappointed that RFC 7465 ("Prohibiting RC4 ciphersuites")
isn't listed in the Notes column for all ciphersuites using RC4.
Perhaps that change needs to be made as well?

    --dkg

---

From: Yoav Nir <[email-masked]>
Date: Wed, 30 Mar 2016 23:26:10 +0300

> On 30 Mar 2016, at 10:44 PM, Daniel Kahn Gillmor <[email-masked]> wrote:
> 

That brings up another question. How do things move from “approved” to “not-approved”? Does it require a diediedie document? What happens when we decide that 3DES is just too limited and there’s not good reason to use it, but there’s really no security issue with using it?

Yoav

---

From: Dave Garrett <[email-masked]>
Date: Wed, 30 Mar 2016 16:32:02 -0400

> Then how should ciphersuites with explicit diediedie RFCs (currently

A tri-state that might be more acceptable would be approved/not-approved/amended, where "amended" indicates an RFC released after the initial specification that is considered mandatory. This would be both diediedie RFCs as well as any sort of less severe update, without as much implication that "not-approved" automatically implies safety.

Dave

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 30 Mar 2016 16:11:37 -0500

> I apologize in advance; this is about process so it’s long.

It seems correct and reasonably comprehensive.

> I think that a) has worked in the past and would continue to work in the future, but b) couldn’t hurt. If we go for a) then if the expert is ever unsure, they can just ask the AD/WG chair/community…

I feel like (b) will probably result in a lot of time on the list
getting the text "just so"; perhaps that time would be better spent
elsewhere.  That said, I'm happy to help with the editing of such text...

> 1. All of the drafts referenced and the future drafts requesting code points do *not* need to come through the WG.  But, I do think drafts that want a “Y” need to come through, and we shouldn’t kid…

I agree ... the chairs should use their power to turn things away
judiciously :)

> b.1) request is submitted to IANA, WG, WG chair, AD,

That's "one of the above", I presume?

> Early assignment rules can still apply to a) and b).

Sounds good to me.

> 2. As far as draft-ietf-tls-pwd, we need to decide whether it should continue as a WG draft or free Dan to pursue other publication avenues.

No opinion at present.

> 3. We should avoid a long list of “updates” to TLS1.3 RFC#-to-be when new cipher suites get added.  Drafts should only include an “updates” header if we’re modifying the MTIs or we’re adding a new…

I support this, yes -- long "updates" lists can be annoying for the reader.

> 4. WRT language -  I’m assuming we’d continue to have English versions of the algorithm specification.

If we are using IANA as a service for the global Internet, it is not
entirely clear to me that we need to insist on English versions of the
"specification required" document ... though the capabilities of the
designated expert might affect what would in practice get approved.

-Ben

---

From: Bill Frantz <[email-masked]>
Date: Wed, 30 Mar 2016 14:42:57 -0700

+1 for the change.

On 3/30/16 at 1:26 PM, [email-masked] (Yoav Nir) wrote:

>That brings up another question. How do things move from 
>“approved” to “not-approved”? Does it require a 
>diediedie document? What happens when we decide that 3DES is 
>just too limited and there’s not good reason to use it, but 
>there’s really no security issue with using it?

Certainly for downgrading any widely deployed algorithm, e.g. 
RC4, there needs to be a IETF process. The RFC process works, so 
we don't need to invent a new wheel. Therefore a diediedie RFC 
seems the logical choice.

I hope algorithms don't get on the approved list unless they are 
likely to be widely deployed. (But I expect to see counter-arguments.)

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | gets() remains as a monument | Periwinkle
(408)356-8506      | to C's continuing support of | 16345 
Englewood Ave
www.pwpconsult.com | buffer overruns.             | Los Gatos, 
CA 95032

---

From: Rick van Rein <[email-masked]>
Date: Thu, 31 Mar 2016 00:49:43 +0200

Hello,

> In Yokohama, we discussed changing the IANA registry assignment rules
> for cipher suites

Has a similar thing been discussed for TLS Extensions as well?  That
list now requires "IETF Consensus", and it doesn't even have Private and
Experimental allocations, let alone a portion with "Specification Required".

It can be difficult to get enough traction on this busy list for an
extension that is only useful in a niche (which could be said of my
draft-vanrein-tls-symmetry that gained no response at all) that is
however very interesting in such a niche.

-Rick

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 31 Mar 2016 00:16:48 +0100

(with no hats, except the one irritated with loadsa ciphersuites:-)

On 30/03/16 21:26, Yoav Nir wrote:
> That brings up another question. How do things move from “approved” 
> to “not-approved”? Does it require a diediedie document? What
> happens when we decide that 3DES is just too limited and there’s not
> good reason to use it, but there’s really no security issue with
> using it?

How about starting from the smallest possible set with "Y" in
the IETF recommended column? And then focus on keeping that set
as small as possible and actively not letting it grow.

Let's *pretty please* take this opportunity to prune the stupid
list of nearly 350 all ostensibly but so not equal ciphersuites
down to the smallest list that can reasonably be recommended.
Measurements seem to have indicated that just a handful is all
that really needs to be very widely supported.

That will require folks here to not mess about and to resist the
set of people who want ciphersuite foo because it's important to
just them and a few others.

Remember: Sean's proposed text, is to limit the "Y" to stuff that
we do expect to, and want to, see widely or very widely implemented
and deployed.

If this WG fail to take this opportunity to fix the 350 ciphersuite
stupidity then that'll be a pretty clear fail in which we'll all
(me included) have sadly partaken. Let's fix that eh?

S.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 30 Mar 2016 16:22:56 -0700

> that really needs to be very widely supported.

We already have a proposal for this. Please see:
http://tlswg.github.io/tls13-spec/#iana-considerations

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 31 Mar 2016 00:26:32 +0100

> http://tlswg.github.io/tls13-spec/#iana-considerations

I like, support and will buy that a beer:-)

Thanks,
S.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 31 Mar 2016 12:22:21 +1100

> Cipher suites marked with a “Y” the IETF has consensus on

As long as that consensus is for the "Y", then this is a great plan.

I think that there's consensus on a lot of "N" entries too.  However,
if there is any dispute or doubt, it's still "N".

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 31 Mar 2016 15:45:46 +0200

Hi Sean,

What is the requirement for adding a spec to the list with the value
IETF Recommended = "Y" (or to change an entry from "Y" to "N")?

You mention two conditions:

 * IETF has consensus
 * Are reasonably expected to be supported by widely used
implementations such as open-source libraries

Of course, with all our work we expect them to be supported by widely
used implementations. The future is unpredicable and therefore not a
good item for making a judgement. I realy find document authors who have
less interest to get their stuff deployed.

Getting IETF consensus on specifications has turned to be easier than
most people expect and the IETF published RFCs that have not received a
lot of review. Large amount of review is not a pre-condition for consensus.

While your idea sounds good it suffers from practical issues. I am
worried that the process will not be too fair and may favor a certain
type of community.

Ciao
Hannes

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 31 Mar 2016 14:49:28 +0000

> What is the requirement for adding a spec to the list with the value IETF
> Recommended = "Y" (or to change an entry from "Y" to "N")?

I believe the primary concern is *not* to address IETF products, but rather non-IETF organizations that want a codepoint.

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Thu, 31 Mar 2016 14:54:46 +0000

Hi Sean and all,

I support the first condition: A spec gets a "Y" when it has the IETF consensus.

Regards,
Quynh. 

________________________________________
From: TLS <[email-masked]> on behalf of Hannes Tschofenig <[email-masked]>
Sent: Thursday, March 31, 2016 9:45 AM
To: Sean Turner; <[email-masked]>
Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites

Hi Sean,

 * IETF has consensus

Ciao
Hannes

---

From: Rick van Rein <[email-masked]>
Date: Thu, 31 Mar 2016 17:26:04 +0200

Hi,

In general I think this is a good form of relaxation.  However,
> Cipher suites marked with a “Y” the IETF has consensus on

An alternative could be to mark the entry with the RFC 5226 level of the
documentation, and indicate what levels are acceptable.  A black/white
distinction will probably lead to a lot of discussion, and different
implementation purposes could call for more subtlety.

> used implementations such as open-source libraries.

This is a vague one, and may unleash more discussion than it saves. 
Also, this should not turn into a suggestion of using implementations
rather than specifications as leading.  I've seen a lot of that around
Kerberos, where sane changes can get bogged down because there is (or
may be) an implementation that couldn't live with it.
> Please indicate whether or not you could support this plan.
Yes, in broad lines, but I have the noted concerns / suggestions.

-Rick

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 31 Mar 2016 15:49:45 +0000

> A black/white

I strongly thing it's the exact opposite.  A simple "yes an IETF WG came to consensus on this" is much simpler than trying to debate various shades of grey.  Or gray.  (See what I mean?:)

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 31 Mar 2016 11:03:14 -0500

> used implementations. The future is unpredicable and therefore not a

I don't think it's universally true that we expect all our work to be
supported by widely used implementations.  Sometimes we standardize
things that are kind of niche cases and not expected to be widely used. 
(This also somewhat relates to the question, already raised, of how to
turn a 'Y' back to a 'N' for things we decide we don't like any more.)

> less interest to get their stuff deployed.

...but I do agree that predictions of the future do not make good
criteria here.

> lot of review. Large amount of review is not a pre-condition for consensus.

I think that documents introducing things that get a 'Y' should
explicitly say that in the IANA considerations, so the IETF consensus
explicitly includes support for the 'Y', and not all documents published
with IETF consensus need to go for the 'Y'.  Which is not to say that
putting in such an IANA considerations section will magically cause
people to read the document at IETF last call, of course, but I do have
confidence that the IESG (if no one else) will ask whether the TLS
working group has been consulted for something trying to set the 'Y' column.

> worried that the process will not be too fair and may favor a certain

At the risk of making predictions of the future, it's not clear to me
that the proposal will be any less fair than the current state of
affairs (which is not perfect, either).

-Ben

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 31 Mar 2016 18:20:02 +0200

Hi Ben,

just think about the mentioned JPAKE extension: what type of deployment
can you expect? It is something that Thread decided to use. Will Thread,
as a mesh networking technology, be successful and widely be deployed?
We don't know yet but if it becomes a technology of choice for use with
IEEE 802.15.4 then it will be fairly widely used in the IoT sector. I am
sure the authors of the Thread specifications (and the members of the
Thread consortium) expect their stuff to be widely used (in IoT -- not
on the Web).

Is this something that is good enough for this group? Web guys will
hardly care about it. A large part of the TLS group is focused on the
Web use only (at least that's my impression).

From the descriptions provided by Sean I don't know whether this is
something that would be a "Y" blessing or not. This is what I call
"sounds nice but ...".

Ciao
Hannes

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 31 Mar 2016 16:27:31 +0000

> 802.15.4 then it will be fairly widely used in the IoT sector. I am sure the
> authors of the Thread specifications (and the members of the Thread
> consortium) expect their stuff to be widely used (in IoT -- not on the Web).

They can get a code-point but not a Y since there is no IETF consensus/WG agreement.

Is this a problem? How and why?  Will a non-approval from IETF really hamper the acceptance and deployment since it's already on-track to be widely used?  I can't see why that would be true.

The only possible practical impact I can see is that someone like OpenSSL might not provide it.  But a Y doesn't guarantee we will, either.

	/r$ 

--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 31 Mar 2016 11:52:51 -0500

> Thread consortium) expect their stuff to be widely used (in IoT -- not

Well, for JPAKE in particular, my thoughts focus on my perception that
PAKE of any form is not really central to what TLS does.  Given that, I
personally would not advocate for a 'Y' for it, even knowing that it
might see wide use in IoT.

> something that would be a "Y" blessing or not. This is what I call

Well, I would expect the authors to put the 'Y' in their IANA
considerations text and see if anyone complained during the last calls. 
I further expect that some of the web-centric folks on this list would
complain and probably get the 'Y' removed, but I am not seeing why this
is problematic.

-Ben

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 31 Mar 2016 19:08:45 +0200

In essence you are saying that most people are not going to care about
the Y/N in the IANA table anyway. Somewhat similar to people not
understanding the difference between the different types of RFCs.

That sounds pragmatic.

Ciao
Hannes

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 31 Mar 2016 12:14:40 -0500

Well, "most people [in the world" do not care about any documents the
IETF puts out.  I am not sure what population of people you are actually
trying to make a statement about.

I am not confident that adding this column will actually have a useful
impact, but I think the experiment is worth performing.

-Ben

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 31 Mar 2016 17:17:46 +0000

> I am not confident that adding this column will actually have a useful impact,
> but I think the experiment is worth performing.

I am very confident it will help.  For example, it now becomes a reasonable position for most TLS stacks to include only Y ciphersuites in their default source or build or deploy methods.  It will also have an effect on reducing clientHello cipher list sizes.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 31 Mar 2016 10:17:57 -0700

The primary purpose of this compromise is to unjam the many requests for
code
points that otherwise clog the WG and expert review process. I believe it
will at
least do that.

-Ekr

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 31 Mar 2016 19:23:08 +0200

Hi Rich,

On 03/31/2016 07:17 PM, Salz, Rich wrote:
> I am very confident it will help.  For example, it now becomes a
> reasonable position for most TLS stacks to include only Y
> ciphersuites in their default source or build or deploy methods.  It
> will also have an effect on reducing clientHello cipher list sizes.

Interesting idea. You see this IANA registry more as the mandatory to
implement algorithm list (for Web apps).

Ciao
Hannes

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 31 Mar 2016 17:25:44 +0000

> implement algorithm list (for Web apps).

I don't.  But lots of outsiders do, and I know they exert pressure on various projects and TLS/AD "leadership".  I've only had a little bit of it via openssl compared to those folks.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 31 Mar 2016 19:40:31 +0200

I can see some value in having this IANA registry list for ciphersuites
in the way being proposed (even if it may be interpreted differently by
different audiences). There have been, of course, too many algorithms
used only in specific countries and those substantially increased the
ciphersuite list.

I am just a little bit worried that everything developed for the IoT
enviroment is quite likely labled as not recommended by the IETF in this
registry because of the Web focus in this group.

The JPAKE is the item that we are currently interested in because we
have contributed to the standardization work related to Thread and the
stack we had implemented. Of course, the remark that JPAKE might not be
a good fit for TLS 1.3 may be correct.

Ciao
Hannes

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 31 Mar 2016 10:42:52 -0700

Hannes,

Aside from JPAKE, which algorithms are you concerned about?

-Ekr

On Thu, Mar 31, 2016 at 10:40 AM, Hannes Tschofenig <
[email-masked]> wrote:

> > I don't.  But lots of outsiders do, and I know they exert pressure on
> various projects and TLS/AD "leadership".  I've only had a little bit of it
> via openssl compared to those folks.
> >
> > --

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 31 Mar 2016 18:51:44 +0100

If smaller devices don't use algorithms that can be used to talk to
random servers on the Internet, then they are choosing to not try to
get interop. That seems like a shame to me, unless there's a really
good reason and IMO, mostly there isn't, at the ciphersuite level. I
would hope we all won't make the GCM/CCM mistake again for example
(that "we" being roughly some combination of IETF/IEEE folks).

So I think the proposed change here, if it leads to fewer but more
ubiquitously deployed ciphersuites, will help smaller devices. And I
do think the IETF recommended column might lead us some way in that
direction.

Cheers,
S.

---

From: Rick van Rein <[email-masked]>
Date: Thu, 31 Mar 2016 20:16:54 +0200

Hi,

> registry because of the Web focus in this group.
RFC 5246 speaks of "Application Profiles" and it seems like this
discussion that started to simplify the WG load is now getting mixed
with that idea:

   In the absence of an application profile standard specifying
   otherwise, a TLS-compliant application MUST implement the cipher
   suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the
   definition).

The worry about IoT above makes me suspect there might be a use for an
IoT application profile, presumably geared towards simplicity and
compactness.  Such a profile could make its own choices, possibly as a
subset from the Y markers and possibly enhanced with industry-driven
desires.

-Rick

---

From: Andrei Popov <[email-masked]>
Date: Thu, 31 Mar 2016 18:28:21 +0000

I'm in favor of this change, as long as it's a binary Y/N. I believe that "Y" can only possibly mean that there is rough IETF consensus to adopt. "Y" cannot mean that this cipher is "cryptographically sound" or "secure", nor can it mean that the "Y" cipher suites are MTI.

The reason I'm in favor is because we can' block the world from implementing the cipher suites they want, even if we don't like what they want or don't have the bandwidth/motivation to analyze every proposal.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Thursday, March 31, 2016 10:52 AM
To: Hannes Tschofenig <[email-masked]>; Salz, Rich <[email-masked]>; Kaduk, Ben <[email-masked]>; <[email-masked]> <[email-masked]>
Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites

If smaller devices don't use algorithms that can be used to talk to random servers on the Internet, then they are choosing to not try to get interop. That seems like a shame to me, unless there's a really good reason and IMO, mostly there isn't, at the ciphersuite level. I would hope we all won't make the GCM/CCM mistake again for example (that "we" being roughly some combination of IETF/IEEE folks).

So I think the proposed change here, if it leads to fewer but more ubiquitously deployed ciphersuites, will help smaller devices. And I do think the IETF recommended column might lead us some way in that direction.

Cheers,
S.

On 31/03/16 18:40, Hannes Tschofenig wrote:
> I can see some value in having this IANA registry list for 
> ciphersuites in the way being proposed (even if it may be interpreted 
> differently by different audiences). There have been, of course, too 
> many algorithms used only in specific countries and those 
> substantially increased the ciphersuite list.
> 
> enviroment is quite likely labled as not recommended by the IETF in 
> this registry because of the Web focus in this group.
> 
> stack we had implemented. Of course, the remark that JPAKE might not 
> be a good fit for TLS 1.3 may be correct.
> 
> Ciao
> Hannes
> 
>>> Interesting idea. You see this IANA registry more as the mandatory 
>>> to implement algorithm list (for Web apps).
>>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.i
> etf.org%2fmailman%2flistinfo%2ftls&data=01%7c01%7cAndrei.Popov%40micro
> soft.com%7cf32d2e5ac29e49c2d49308d3598d2ad3%7c72f988bf86f141af91ab2d7c
> d011db47%7c1&sdata=%2bqpo4fWxLXAhxEZHhv7A9A1BvA60qYUIX0Ds3GWn7WA%3d
>