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

[Sean Turner]

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

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


___
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

[Aaron Zauner]

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

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


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

[Peter Gutmann]

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

[Dan Harkins]

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 unauthenticated nature of the TLS connection and sends
>> 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).

  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.



___
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

[Peter Gutmann]

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 vendors have chosen not to
support it.  As a result, they abandoned the use of TLS altogether and went
with SSH.

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

[Salz, Rich]

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

___
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

[Watson Ladd]

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

Why can't embedded devices use certificates?



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

___
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

[Dan Harkins]

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.


___
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

[Salz, Rich]

>   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

[Andrei Popov]

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:tls-boun...@ietf.org] On Behalf Of Stephen Farrell
Sent: Thursday, March 31, 2016 10:52 AM
To: Hannes Tschofenig ; Salz, Rich 
; Kaduk, Ben ;  

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.
> 
> 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
> 
> On 03/31/2016 07:25 PM, Salz, Rich wrote:
>>> 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 folks.
>>
>> --
>> Senior Architect, Akamai Technologies
>> IM: richs...@jabber.at Twitter: RichSalz
>>
>>
> 
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.i
> etf.org%2fmailman%2flistinfo%2ftls=01%7c01%7cAndrei.Popov%40micro
> soft.com%7cf32d2e5ac29e49c2d49308d3598d2ad3%7c72f988bf86f141af91ab2d7c
> d011db47%7c1=%2bqpo4fWxLXAhxEZHhv7A9A1BvA60qYUIX0Ds3GWn7WA%3d
> 

___
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

[Stephen Farrell]

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.
> 
> 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
> 
> On 03/31/2016 07:25 PM, Salz, Rich wrote:
>>> 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 folks.
>>
>> --  
>> Senior Architect, Akamai Technologies
>> IM: richs...@jabber.at Twitter: RichSalz
>>
>>
> 
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 



signature.asc
Description: OpenPGP digital signature
___
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

[Eric Rescorla]

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 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
>
> On 03/31/2016 07:25 PM, Salz, Rich wrote:
> >> 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 folks.
> >
> > --
> > Senior Architect, Akamai Technologies
> > IM: richs...@jabber.at Twitter: RichSalz
> >
> >
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
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

[Hannes Tschofenig]

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

On 03/31/2016 07:25 PM, Salz, Rich wrote:
>> 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 folks.
> 
> --  
> Senior Architect, Akamai Technologies
> IM: richs...@jabber.at Twitter: RichSalz
> 
> 



signature.asc
Description: OpenPGP digital signature
___
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

[Salz, Rich]

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

--  
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz


___
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

[Hannes Tschofenig]

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




signature.asc
Description: OpenPGP digital signature
___
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

[Benjamin Kaduk]

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

On 03/31/2016 12:08 PM, Hannes Tschofenig wrote:
> 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 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 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).
>> 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.
>>
>>> 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 ...".
>>>
>> 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
>>

___
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

[Eric Rescorla]

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 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
>
> On 03/31/2016 12:08 PM, Hannes Tschofenig wrote:
> > 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 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 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).
> >> 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.
> >>
> >>> 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 ...".
> >>>
> >> 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
> >>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
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

[Hannes Tschofenig]

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



signature.asc
Description: OpenPGP digital signature
___
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

[Benjamin Kaduk]

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

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.

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

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

___
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

[Salz, Rich]

> 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: richs...@jabber.at Twitter: RichSalz

___
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

[Hannes Tschofenig]

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


On 03/31/2016 06:03 PM, Benjamin Kaduk wrote:
> 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 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
> 
> 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.)
> 
>> good item for making a judgement. I realy find document authors who have
>> less interest to get their stuff deployed.
> 
> ...but I do agree that predictions of the future do not make good
> criteria here.
> 
>> 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.
> 
> 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.
> 
>> 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.
>>
> 
> 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
> 



signature.asc
Description: OpenPGP digital signature
___
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

[Benjamin Kaduk]

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

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

> good item for making a judgement. I realy find document authors who have
> less interest to get their stuff deployed.

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

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

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.

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

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

___
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

[Salz, Rich]

> 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 
grey.  Or gray.  (See what I mean?:)
___
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

[Dang, Quynh (Fed)]

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: Sean Turner; 
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:
> 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
>
> [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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

___
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

[Salz, Rich]

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

[Stephen Farrell]

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

[Eric Rescorla]

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

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

-Ekr




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.
>
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
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

[Bill Frantz]

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


___
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

[Benjamin Kaduk]

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

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

>
>
> 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):

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

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

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

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

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 “Y” cipher suite because we 
> only expect all implementations to support these cases.

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

___
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

[Dave Garrett]

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 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.
> > 
> > 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"
> 
> Then how should ciphersuites with explicit diediedie RFCs (currently
> RC4) be presented?

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

___
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

[Ilari Liusvaara]

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 more review than is actually the case, which is what this
> > 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"

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


-Ilari

___
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

[Sean Turner]

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


___
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

[Sean Turner]

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

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

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 

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

[Yoav Nir]

> 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
>> implication of more review than is actually the case, which is what this
>> 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”

+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

___
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

[Salz, Rich]

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

[Daniel Kahn Gillmor]

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

___
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

[Henrick Hellström]

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.


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

___
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

[Eric Rescorla]

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 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
>
> [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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
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

[Benjamin Kaduk]

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


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

___
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

[Henrick Hellström]

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.

___
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

[Dmitry Belyavsky]

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 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
>
> [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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
SY, Dmitry Belyavsky
___
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

[Yoav Nir]

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  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
> 
> [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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
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

[Salz, Rich]

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

[Sean Turner]

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

[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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls