Re: [TLS] Call for consensus: Removing DHE-based 0-RTT

On Thu, Mar 31, 2016 at 8:39 PM, Hugo Krawczyk wrote: > > > On Tue, Mar 29, 2016 at 9:11 AM, Sean Turner wrote: > >> All, >> >> To make sure we’ve got a clear way forward coming out of our BA sessions, >> we need to make sure there’s consensus on a couple

Re: [TLS] Call for consensus: Removing DHE-based 0-RTT

On Tue, Mar 29, 2016 at 9:11 AM, Sean Turner wrote: > All, > > To make sure we’ve got a clear way forward coming out of our BA sessions, > we need to make sure there’s consensus on a couple of outstanding issues. > So... > > There also seems to be (rougher) consensus not to

Re: [TLS] 回复： A TLS extension transfering service indication information

发件人: Eric Rescorla 日期: 2016年3月31日 星期四 下午9:54 至: dacheng de 抄送: Eric Mill , Dave Garrett , tls , "刘大鹏(鹏成)" 主题: Re: [TLS] 回复： A TLS extension transfering service

Re: [TLS] AD review of draft-ietf-tls-falsestart-01

On Mar 24, 2016, at 05:56, Stephen Farrell wrote: > > > Hiya, > > Thanks for the speedy response... > > Again #3 below is what I care about, the other stuff isn't > a big deal. > > On 24/03/16 00:38, Bodo Moeller wrote: >> "Stephen Farrell"

Re: [TLS] Call for consensus: Removing 0-RTT client auth

On 03/31/2016 12:21 PM, Eric Rescorla wrote: > > > On Thu, Mar 31, 2016 at 10:17 AM, Benjamin Kaduk > wrote: > > On 03/31/2016 12:13 PM, Eric Rescorla wrote: >> >> >> On Thu, Mar 31, 2016 at 10:08 AM, Benjamin Kaduk >>

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: Removing 0-RTT client auth

On Thu, Mar 31, 2016 at 10:17 AM, Benjamin Kaduk wrote: > On 03/31/2016 12:13 PM, Eric Rescorla wrote: > > > > On Thu, Mar 31, 2016 at 10:08 AM, Benjamin Kaduk < > bka...@akamai.com> wrote: > >> On 03/31/2016 12:02 PM, Bill Cox wrote: >> >> On Thu, Mar 31,

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: Removing DHE-based 0-RTT

Hi Ekr, > > The only way to do 0-RTT would be with a PSK (in both PSK and > > PSK-(EC)DHE modes). > > I see. This is, of course, a bit unfortunate. > > > Can you expand on why? The general sense of the discussion was that they > offered similar properties. > The PSK-ECDHE mode

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] 0RTT and HelloRetryRequest (Re: Narrowing the replay window)

On Thu, Mar 31, 2016 at 12:18:45PM +1100, Martin Thomson wrote: > On 31 March 2016 at 09:59, Eric Rescorla wrote: > >> Option 2 suits best if we consider HelloRetryRequest to be a DoS feature > >> exclusively or at least primarily. But we have other reasons for it and I > >> don't

Re: [TLS] Call for consensus: Removing DHE-based 0-RTT

On Thu, Mar 31, 2016 at 8:33 AM, Hannes Tschofenig < hannes.tschofe...@gmx.net> wrote: > Hi Ekr, > > > On 03/31/2016 05:05 PM, Eric Rescorla wrote: > > Hannes, > > > > No, the proposal is to remove both EC and non-EC DHE 0-RTT profiles. > > > > The only way to do 0-RTT would be with a PSK (in

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: Removing DHE-based 0-RTT

Hi Ekr, On 03/31/2016 05:05 PM, Eric Rescorla wrote: > Hannes, > > No, the proposal is to remove both EC and non-EC DHE 0-RTT profiles. > > The only way to do 0-RTT would be with a PSK (in both PSK and > PSK-(EC)DHE modes). I see. This is, of course, a bit unfortunate. > However, this would

Re: [TLS] Call for consensus: Removing DHE-based 0-RTT

Hannes, No, the proposal is to remove both EC and non-EC DHE 0-RTT profiles. The only way to do 0-RTT would be with a PSK (in both PSK and PSK-(EC)DHE modes). However, this would include PSKs established via a previous session, i.e., resumption-PSK. -Ekr On Thu, Mar 31, 2016 at 5:20 AM,

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: Removing 0-RTT client auth

Hi Sean, we at ARM would find it somewhat unfortunate to remove the client authentication feature from the 0-RTT exchange since this is one of the features that could speed up the exchange quite significantly and would make a big difference compared to TLS 1.2. For the IoT use cases we need