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

On Apr 06, 2016, at 12:21, Aaron Zauner wrote: > > Hi, > >> On 30 Mar 2016, at 03:53, Sean Turner wrote: >> >> Hi! >> >> In Yokohama, we discussed changing the IANA registry assignment rules for >> cipher suites to allow anyone with a stable, publicly

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

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

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

Adam Langley 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

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

On Mon, April 4, 2016 8:50 am, Phil Lello wrote: > On Mon, Apr 4, 2016 at 3:36 PM, Dan Harkins wrote: > >> >> 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

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

Watson Ladd writes: >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

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

> > Not always; ISO et al. > > 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

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

On Mon, Apr 4, 2016 at 7:05 AM, Dan Harkins wrote: > > > 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.

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

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,

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

> A stable, publicly available document is basically an RFC. Not always; ISO et al. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

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

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

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

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

Hannes, Aside from JPAKE, which algorithms are you concerned about? -Ekr On Thu, Mar 31, 2016 at 10:40 AM, Hannes Tschofenig < hannes.tschofe...@gmx.net> 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

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

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

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

> Interesting idea. You see this IANA registry more as the mandatory to > 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

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

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

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

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

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

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 On Thu, Mar 31, 2016 at 10:14 AM, Benjamin Kaduk wrote: > Well, "most people [in the world" do

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

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 On 03/31/2016 06:52 PM, Benjamin Kaduk wrote: > On

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

On 03/31/2016 11:20 AM, Hannes Tschofenig wrote: > 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

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

> 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

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

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

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

On 03/31/2016 08:45 AM, Hannes Tschofenig wrote: > 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

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

> A black/white > distinction will probably lead to a lot of discussion, and different > implementation purposes could call for more subtlety. 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

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

Hi Sean and all, I support the first condition: A spec gets a "Y" when it has the IETF consensus. Regards, Quynh. From: TLS on behalf of Hannes Tschofenig Sent: Thursday, March 31, 2016 9:45 AM To:

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

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

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

On 31/03/16 00:22, Eric Rescorla wrote: > We already have a proposal for this. Please see: > http://tlswg.github.io/tls13-spec/#iana-considerations I like, support and will buy that a beer:-) Thanks, S. smime.p7s Description: S/MIME Cryptographic Signature

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

On Wed, Mar 30, 2016 at 4:16 PM, Stephen Farrell wrote: > > (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

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

+1 for the change. On 3/30/16 at 1:26 PM, ynir.i...@gmail.com (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

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

On 03/30/2016 01:03 PM, Sean Turner wrote: > I apologize in advance; this is about process so it’s long. > It seems correct and reasonably comprehensive. > This definition gives power/discretion to the designated expert (it’s ekr > btw). We can: > > a) defer to the expert's judgement (some of

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

On Wednesday, March 30, 2016 03:20:08 pm Ilari Liusvaara wrote: > On Wed, Mar 30, 2016 at 12:05:26PM -0400, Daniel Kahn Gillmor wrote: > > On Wed 2016-03-30 11:33:09 -0400, Benjamin Kaduk wrote: > > > I am not sure that we want to be in the business of explicitly marking > > > things as insecure

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

On Wed, Mar 30, 2016 at 12:05:26PM -0400, Daniel Kahn Gillmor wrote: > On Wed 2016-03-30 11:33:09 -0400, Benjamin Kaduk wrote: > > 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

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

On Mar 30, 2016, at 11:33, Benjamin Kaduk wrote: > > 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

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

I apologize in advance; this is about process so it’s long. On Mar 30, 2016, at 01:29, Yoav Nir wrote: > > 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

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

> On 30 Mar 2016, at 7:05 PM, Daniel Kahn Gillmor > wrote: > > On Wed 2016-03-30 11:33:09 -0400, Benjamin Kaduk wrote: >> 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 >>

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

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

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

On Wed 2016-03-30 11:33:09 -0400, Benjamin Kaduk wrote: > 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

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

On 2016-03-30 17:33, Benjamin Kaduk wrote: 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.

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

I am in favor of this. On Tue, Mar 29, 2016 at 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

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

On 03/29/2016 08: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”

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

On 2016-03-30 13:27, Dmitry Belyavsky wrote: 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. This does indeed sound reasonable.

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

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 wrote: > Hi! > > In Yokohama, we

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

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

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

Strongly support this. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

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

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