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

From: "Dan Harkins" <[email-masked]>
Date: Sun, 3 Apr 2016 18:24:03 -0700 (PDT)

Hi Sean,

  In general I support this but....

  A stable, publicly available document is basically an RFC.
So when the TLS WG says no that means asking an AD to sponsor
or putting it into the Independent Stream process. So what it
looks like you're doing is punting this problem into the lap of
whoever is gonna be the Independent Stream Editor for this stuff
because he or she will start getting a steady stream of requests
for publication of documents  describing a fabulous new TLS
ciphersuite after the ADs tell everyone to "pound sand".

  I wonder if you have thought this through or prepped the
stuckee?

  regards,

  Dan.

On Tue, March 29, 2016 6:53 pm, Sean Turner 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:
>
> 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
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 4 Apr 2016 02:24:14 +0000

>   A stable, publicly available document is basically an RFC.

Not always; ISO et al.

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 4 Apr 2016 05:51:53 -0700 (PDT)

>>   A stable, publicly available document is basically an RFC.

  That's why I said "basically"; it's a qualifier.

  But keep in mind what kind of stable, publicly available
document needs to be published: a description not of the algorithm
but of how that algorithm get crammed into the TLS exchange.
(For example, not RFC 7539 which describes chacha20+poly1305 as
a glot but draft-ietf-tls-chacha20-poly1305 which says how to cram
that glot into TLS). So even if some one/company was able to get a
National Body to push in in ISO I doubt ISO would entertain
documents whose content was "cram alg described elsewhere into
TLS like this" with changes to ServerKeyExchange etc.

  Dan.

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 4 Apr 2016 07:05:35 -0700 (PDT)

On Thu, March 31, 2016 10:51 am, Stephen Farrell wrote:
>
> 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).

  That's because you incorrectly define "interop" as talking to
random servers on the Internet. This browser-centric mode of thinking
causes you to reject cipher suites that the browser/webserver
community does not have any interest in.

  There are use cases where some app doesn't want to talk to random
servers on the Internet. It wants to talk to a set of specific servers
providing a specific stream of information unique to the app-- think
of some network monitoring or RF-quality app that provides sensing
data to servers and also sucks down neighbor air quality information
as it roams around. There are IoT use cases where devices just want
to talk to each other, not random servers on the Internet.

  The browser community wants 0-RTT; I don't give a damn about 0-RTT.
I want a PAKE (specifically TLS-pwd); the browser community doesn't
give a damn about PAKEs. We are both right. Because we have different
requirements.

> 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.

  Fewer is better... for one set of requirements, there's no reason to
have umpteen (> 2) ways of meeting the requirements. But to approach
this issue as if there is only one set of requirements (being able
to talk to random web servers on the Internet) is to cram a multiplicity
of differently shaped pegs into the proverbial round hole.

  regards,

  Dan.

---

From: Watson Ladd <[email-masked]>
Date: Mon, 4 Apr 2016 07:17:37 -0700

> give a damn about PAKEs. We are both right. Because we have different

Why can't embedded devices use certificates?

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 4 Apr 2016 14:30:42 +0000

>   That's why I said "basically"; it's a qualifier.

I know; I was trying to emphasize, not correct :).
 
>   But keep in mind what kind of stable, publicly available document needs to
> be published: a description not of the algorithm but of how that algorithm
> get crammed into the TLS exchange

 That is a good point.  But most offerings we have seen so far are about national bulk encryption ciphers and not, say, new key-exchange methods (GOST the only one so far?).  Of course that might change.

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 4 Apr 2016 07:36:35 -0700 (PDT)

> Why can't embedded devices use certificates?

  Code bloat for a one-off enrollment protocol, no way to authenticate
to obtain the certificate, and the continued lack of that Global PKI
that was supposed to take care of everything and that is currently 20
years late in being delivered.

  Actually, that's not quite right. Some do use certificates...wrongly.
Usually what happens is the server generates a self-signed certificate
and the apps are given some "username" and "password" and the app
ignores the unauthenticated nature of the TLS connection and sends
the u/p credential on through.

  Dan.

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 4 Apr 2016 14:39:47 +0000

>Why can't embedded devices use certificates?

Because they have neither a DNS name nor a fixed IP address.  I ran into this
just last week with a customer, they couldn't use certs for their embedded
devices and couldn't use PSK because the browser vendors have chosen not to
support it.  As a result, they abandoned the use of TLS altogether and went
with SSH.

Peter.

---

From: Watson Ladd <[email-masked]>
Date: Mon, 4 Apr 2016 08:24:39 -0700

> support it.  As a result, they abandoned the use of TLS altogether and went

Actually, PKI certs are not required. There is an extension to support
use of bare keys for authentication. And if you can provision with a
shared secret, you can provision with a private key.

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 4 Apr 2016 15:36:25 +0000

Watson Ladd <[email-masked]> writes:

>Actually, PKI certs are not required. There is an extension to support use of
>bare keys for authentication. And if you can provision with a shared secret,
>you can provision with a private key.

And how many browsers support that?

Peter.

---

From: Phil Lello <[email-masked]>
Date: Mon, 4 Apr 2016 16:50:40 +0100

> the u/p credential on through.

Isn't this use case more of an argument for an updated auth-digest to use
something better than MD5? I'm not convinced MITM is a real concern for a
typical IoT environment (however that's defined - I'm assuming http in a
domestic environment).

Best wishes,

Phil Lello

---

From: "Kaduk, Ben" <[email-masked]>
Date: Mon, 4 Apr 2016 16:35:33 +0000

On 4/4/16, 12:50, "Phil Lello" <[email-masked]> wrote:

>Isn't this use case more of an argument for an updated auth-digest to use something better than MD5? I'm not convinced MITM is a real concern for a typical IoT environment (however that's defined - I'm assuming http in a domestic environment).

Like RFC 7616?

-Ben

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 4 Apr 2016 10:36:46 -0700 (PDT)

> typical IoT environment (however that's defined - I'm assuming http in a

  First of all, what makes you think it's MD5 digest and not just
plaintext? And updated by whom? These are ad hoc constructions done
because the alternative is too onerous.

  As someone who has stolen wi-fi from the apt next door that was
protected by a PSK I would say that doing a dictionary attack in
a "domestic environment" is entirely plausible. If I have to do a
soft AP advertising the neighbor's SSID in order to lure a set-top
box or thermostat or whatever to connect to me then that's a very
low bar.

  regard,

  Dan.

---

From: Phil Lello <[email-masked]>
Date: Mon, 4 Apr 2016 18:46:12 +0100

> because the alternative is too onerous.

I didn't say that. I was suggesting using a standard HTTP digest mechanism
rather than sending a plaintext username/password. The IETF has already
updated HTTP digest, so there's no work.

> box or thermostat or whatever to connect to me then that's a very

Whilst you have my sympathy, I don't see how that's relevant; a dictionary
attack can be used just as easily against a TLS protected resource.
Securing the WiFi configuration so that devices connect to the correct one
is not a TLS issue.

Best wishes,

Phil Lello

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 4 Apr 2016 11:23:34 -0700 (PDT)

> Securing the WiFi configuration so that devices connect to the correct one

  I'm not asking for sympathy. I'm pointing out that your proposal
does not work.

  Mentioning the ease at which one can launch a dictionary attack
(regardless of the protocol) is relevant because you're proposing to
use a technique that is susceptible to dictionary attack (presumably,
but not necessarily, after misusing a certificate). As I mentioned, to
support this kind of use case I favor using a TLS cipher suite that
supports a PAKE  (draft-ietf-tls-pwd-07, for example). Using such a
cipher suite would mean that a dictionary attack cannot "be used just
as easily against a TLS protected resource."

  regards,

  Dan.

---

From: Adam Langley <[email-masked]>
Date: Tue, 5 Apr 2016 11:10:04 +0700

> support it.  As a result, they abandoned the use of TLS altogether and went

Ideas for supporting this case (i.e. the "I want to do HTTPS to my
router" problem) in browsers have done the rounds a few times. The
reason that nothing has happened is that it's a lot of work to do it
right and it's unclear that we would be able to get a useful mass of
devices supporting such a scheme. The mostly likely outcome seems to
be that we would end up with a complex addition that's rarely used and
thus doesn't justify the cost.

Cheers

AGL

-- 
Adam Langley [email-masked] https://www.imperialviolet.org

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 5 Apr 2016 09:55:08 +0000

Adam Langley <[email-masked]> writes:

>Ideas for supporting this case (i.e. the "I want to do HTTPS to my router"
>problem) in browsers have done the rounds a few times.

This isn't for HTTPS to a router, it's to SCADA devices.  The preferred
interface to them is HTTPS, but since browsers have refused to implement
anything other than cert-based TLS, there's nothing that can be done.

>The reason that nothing has happened is that it's a lot of work to do it
>right

How hard can it be to implement TLS-PSK?  I did it in a few hours in my crypto
library.

Peter.

---

From: Adam Langley <[email-masked]>
Date: Tue, 5 Apr 2016 21:42:21 +0700

> How hard can it be to implement TLS-PSK?  I did it in a few hours in my crypto

This is getting off topic (which is my fault) but, for us, it wouldn't
be "just" implementing PSK.

We would need to evangelise it sufficiently with enough vendors to
make sure that it would be used and that we were building the right
thing. (The solution might well not be just using PSK). Then we need
to implement it and get the UI right, try and get other browsers to
implement it, write specs, write test suites, write sample code for
all the vendors, deal with the resulting bugs in implementations and
many smaller things besides.

That's not to say that we wouldn't be willing to put the effort in,
but the demand hasn't been evinced yet.

Cheers

AGL

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 5 Apr 2016 09:36:02 -0700 (PDT)

> but the demand hasn't been evinced yet.

  Don't bother. It's unlikely to be used in a browser. This just
underscores the point I was making that people use TLS differently
for different things and the requirements are not the same. Just as
it doesn't make sense to force a browser to implement a PSK (or PAKE)
cipher suite, it doesn't make sense to force some device with a
limited UI that has no interest in accessing random web servers to
use a public key.

  regards,

  Dan.

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 6 Apr 2016 17:21:29 +0200

Hi,

> On 30 Mar 2016, at 03:53, 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:
> 
> 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:
> 
> 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.
> 

I maintain the OCB draft and I do support this idea. Sorry for joining this thread late. I did however vote on it during the meeting on monday.

What's still unclear to me from the discussion is what suites would get a Y or N and which suites won't. Are we just talking about WG consensus or does implementation-availability weigh in here? It's not perfectly clear to me how this would be decided; just because the IANA registry flags a certain suite as preferred doesn't mean it actually will be implemented, and vice-versa. Library authors sometimes implement algorithms out of pure interest and love for coding. I, too, think going beyond a simple Y/N would just further complicate things for implementers and people trying to understand the IANA registry.

Aaron

---

From: Sean Turner <[email-masked]>
Date: Wed, 6 Apr 2016 14:16:13 -0300

> What's still unclear to me from the discussion is what suites would get a Y or N and which suites won't. Are we just talking about WG consensus or does implementation-availability weigh in here? It…

What we’re talking about is IETF consensus (i.e., it’s got to get through an IETF LC which is slightly higher than just a WGLC), but we’d do a one sentence tweak to the TLS WG charter to make the TLS WG be the entity that determine whether there’s a Y or N.

A “Y” does not guarantee that it will be implemented and that’s why we put "and are reasonably expected to be supported by widely used implementations such as open-source libraries.”  Those are pretty good weasel words, but since there’s no protocol police we can’t really say they will be implemented.  On the other hand, open source implementations also have their own pressures they have to deal with that I’m not sure should automatically impact the list.  I also am worried about just adding algorithms that are in an open source implementation because I believe just about everybody that’s requested a code point starts the conversation out with “I’ve got this OpenSSL patch …. "

spt

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Wed, 6 Apr 2016 17:32:58 +0000

Hi Sean,

I would like to express my opinion again.

I think the first requirement is great and sufficient. 

I have great support, appreciation and respect for the open source communities. However, the second requirement means that an IETF consensus can have no values in theory and that sounds not right to me.

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,

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

On 03/30/2016 03:53 AM, Sean Turner wrote:
> [1] https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4
>
>

---

From: Sean Turner <[email-masked]>
Date: Wed, 6 Apr 2016 14:39:10 -0300

>  I wonder if you have thought this through or prepped the

During Wed’s session the chairs took the action to prep the “stuckee(s)”.  Those other stuckee(s) include:

- Our AD (Stephen for the next year): is following along.

- The Independent Stream Editor (ISE): I talked to Nevil Brownlee (often can be found during the IETF week by the RFC editor’s table) about the uptick in drafts coming his way.  The current backlog of ~5 didn’t seem to phase him.  He reminded me (as I mention at the TLS session) that there is also an ISE review that falls back on the community.  This review process can be greatly aided by noting the last bullet in the submission instructions found at [0]; tl;dr propose a competent reviewer to the ISE.

- The IANA protocol parameter folks: I also talked to Michelle and Amanda.  They are also comfortable with the change and adding the note in the registry.

spt

[0] https://www.rfc-editor.org/about/independent/