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

[Eric Rescorla]

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 of outstanding issues.
>> So...
>>
>> There also seems to be (rougher) consensus not to support 0-RTT via DHE
>> (i.e., semi-static DHE) in TLS 1.3 at this time leaving the only 0-RTT mode
>> as PSK. The security properties of PSK-based 0-RTT and DHE-based 0-RTT are
>> almost identical,
>
>
> ​I am not offering an opinion about what the WG should decide regarding
> keeping
> DHE-based 0-RTT in the base TLS 1.3 document, but just wanted to note that
> the
> above claim "The security properties of PSK-based 0-RTT and DHE-based
> 0-RTT are
> almost identical" is not quite right (nothing I say here is new, I just
> felt
> that I had to "object" to this statement as written).
>
> There are some significant differences - in some cases even "fundamental
> differences" - between keeping secret state (in the PSK case) and keeping
> non-secret state (in the DHE case) or even not keeping state at all (in the
> DHE case) and retrieving the server key g^s from some external source (with
> integrity but not secrecy).  In addition, using DHE 0-RTT would require the
> client to send a key share g^x leading to a PFS 1-RTT exchange while with
> PSK
> it may be "tempting" to omit PFS.
>

The current plan of record is to allow the server to specify which cipher
suites it is
willing to accept, so it could refuse this



Moreover,  if the server's configuration
> key g^s is refreshed often (say each 5 minutes) then the g^xs key used by
> the
> client to protect its 0-RTT data already has some good level of forward
> secrecy (the attacker has a 5 minute window to find s and after that
> forward
> security is guaranteed).  The latter point touches on an important aspect
> which is the key management complexity of ticket encryption/decryption keys
> (as needed in the PSK case) vs managing secret DH key s (in the DHE case).
> I am not sure what would be done better (more secure) in practice.
>

Can you expand on the difference here? Say that the server implements
tickets
by storing a DH private key and then encrypting the ticket under the
corresponding
public key. How does this provide different PFS properties?

-Ekr


> But really it seems that the discussion boils down to identifying cases of
> enough interest where avoiding the original 1-RTT trip for establishing a
> session ticket is important. I am puzzled by the fact that the Google team
> seems ok with something that essentially voids the main feature and design
> basis of of QUIC.
>
> Hugo​
>
> ​​
>
>> but 0-RTT PSK has better performance properties and is simpler to specify
>> and implement. Note that this does not permanently preclude supporting
>> DHE-based 0-RTT in a future extension, but it would not be in the initial
>> TLS 1.3 RFC.
>>
>> If you think that we should keep DHE-based 0-RTT please indicate so now
>> and provide your rationale.
>>
>> J
>>
>> ___
>> 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
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Hugo Krawczyk]

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 support 0-RTT via DHE
> (i.e., semi-static DHE) in TLS 1.3 at this time leaving the only 0-RTT mode
> as PSK. The security properties of PSK-based 0-RTT and DHE-based 0-RTT are
> almost identical,


​I am not offering an opinion about what the WG should decide regarding
keeping
DHE-based 0-RTT in the base TLS 1.3 document, but just wanted to note that
the
above claim "The security properties of PSK-based 0-RTT and DHE-based 0-RTT
are
almost identical" is not quite right (nothing I say here is new, I just felt
that I had to "object" to this statement as written).

There are some significant differences - in some cases even "fundamental
differences" - between keeping secret state (in the PSK case) and keeping
non-secret state (in the DHE case) or even not keeping state at all (in the
DHE case) and retrieving the server key g^s from some external source (with
integrity but not secrecy).  In addition, using DHE 0-RTT would require the
client to send a key share g^x leading to a PFS 1-RTT exchange while with
PSK
it may be "tempting" to omit PFS.  Moreover,  if the server's configuration
key g^s is refreshed often (say each 5 minutes) then the g^xs key used by
the
client to protect its 0-RTT data already has some good level of forward
secrecy (the attacker has a 5 minute window to find s and after that forward
security is guaranteed).  The latter point touches on an important aspect
which is the key management complexity of ticket encryption/decryption keys
(as needed in the PSK case) vs managing secret DH key s (in the DHE case).
I am not sure what would be done better (more secure) in practice.

But really it seems that the discussion boils down to identifying cases of
enough interest where avoiding the original 1-RTT trip for establishing a
session ticket is important. I am puzzled by the fact that the Google team
seems ok with something that essentially voids the main feature and design
basis of of QUIC.

Hugo​

​​

> but 0-RTT PSK has better performance properties and is simpler to specify
> and implement. Note that this does not permanently preclude supporting
> DHE-based 0-RTT in a future extension, but it would not be in the initial
> TLS 1.3 RFC.
>
> If you think that we should keep DHE-based 0-RTT please indicate so now
> and provide your rationale.
>
> J
>
> ___
> 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] 回复： A TLS extension transfering service indication information

[Dacheng Zhang]

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



On Wed, Mar 30, 2016 at 10:40 PM, Dacheng Zhang
 wrote:
> Thanks again for your comments. See my reply inline please. ^_^
>> 
>> I'm not following. If you trust the device, then why do you need any kind of
>> cryptographic
>> authentication on the token.
>> 
>> Dacheng：Let assume we trust the device. But the APP use a SNI to indicate the
>> service that the APP intends to access. Because the SNI is static which may
>> not be changed for months, it is easier for attackers who monitor the network
>> to get the SNI and use it to gain benefit. We need a securer solution. As I
>> have mentioned in my previous email, this solution will make such attacks
>> more difficult. By the way, SNI is not designed for this purpose, we need to
>> do some additional work to address this issue, right?
> 
> Again, you need a threat model. It sounds like you both do and do not trust
> the client
> 
> Dacheng: Threat model will be provided. Actually，we don’t try to protect
> against the compromise of client. Or the scenario where an APP against another
> one on the same device. This solution is used to protect against the attackers
> who are able to monitoring the communication between the client and the server

I'll await this.

 
> 
>> 
>> Hmm... I'm not at all sure that TLS should address this problem. However, my
>> review
>> was directed to whether your proposed solution even works on its own terms.
>> 
>> Dacheng: That is why we need to raise the discussion here. It would be great
>> if this issue could be considered by TLS WG.
> 
> I don't find this to be a very compelling use case and I don't think it's
> really appropriate to
> try to solve it at the TLS layer. If you want to have secure flow
> identification you should
> do it at the IP or TCP layers.
> 
> Dacheng:Ok, this requirement is quite strong. We need a solution to address
> this issue if we want to use TLS to secure our APPs deployed on hundreds o
> millions o mobile devices.  Also，China mobile and Huawei are working with us
> on this issue.

No, you only need it if you want to use a specific charging model.

Dacheng This is an important business model which will benefit both
customers and ICPs. But we cannot support it for the moment when we use TLS
to secure the traffic.


> Could you please tell me why it is better to address this issue at the IP or
> TCP layer. To the best of my knowledge. There is no space in IPv4 herders to
> insert any extensions. There are length limit in TCP options. In addition, TCP
> is implemented in kernel mode. It will cost more if we try to address this
> issue at the TCP or IP layer.

I think the architectural reasons here are pretty clear. IP is the common
network transport
layer, not TLS. Also, IPv6 has extension headers.

Dacheng: I consulted this to a lot of people. It seems they think in a
different way. The deployment of changes in TCP or IP are much more
difficiult. Currently, IPv4 rather than IPv6 is being used. This means our
online system still not be able to support this charging model for multiple
years. In addition, IP is at network layer protocol，while this work is about
providing information which indicate how to charge a flow. The work related
with a flow should be done at the transport layer or higher. Please correct
me if I am wrong.This issue is raised because the widely usage of TLS. If
Ipsec will be used to secure the communication between mobile and cloud. We
need to  address it at the IP layer. ^_^

-Ekr


> Look forward to more discussions. ^_^
> 
> Cheers
> 
> Dacheng
 
 
>>> 
>> 
> 



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

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

[Sean Turner]

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" :
>> 
>>> (1) Why experimental? Wouldn't this be better as info
>>> and documented as "here's a spec for a thing that's
>>> widely deployed." I fear we may get questions like
>>> "what's the experiment?", "where's this going in
>>> future?" if this aims for experimental, and info may
>>> avoid that esp if we really want people to move to
>>> TLS1.3. I also didn't see list discussion about what
>>> kind of RFC to aim for, but maybe it was discussed at
>>> a meeting or interim? (Apologies if I missed that in
>>> my scan of the list.)
>> 
>> I'm myself torn between "Experimental" and "Informational" (certainly not
>> "Historic" because the spec has not been superseded by a more recent one
>> and is not obsolete for any other reason [
>> https://tools.ietf.org/html/rfc2026#section-4.2.4], unless we somehow
>> manage to complete TLS 1.3 standardization before this). Taking into
>> account how False Start is actually deployed (and taking into
> 
> Right. TLS1.3 will hopefully make this historic, so we could just
> park this in the RFC editor queue and have both RFCs emerge on the
> same day with this one as Historic. With did that with DKIM (4871)
> and DomainKeys (4870, Historic) for example. Note that I'm not arguing
> for doing that, just raising the option if that's what the WG want
> and if the list hasn't discussed it. I assume though that the WG
> don't want to take this route so no need to discuss it more in that
> case.
> 
>> account that
>> we expect it to eventually be replaced by a TLS 1.3 mechanism) and how our
>> I-D is cited in research papers on TLS, "Experimental" sounds right to me:
>> the spec really is part of a research and development effort [
>> https://tools.ietf.org/html/rfc2026#section-4.2.4]. "Informational"
>> wouldn't be wrong either.
> 
> I think the latter matches much better myself, as there really is
> no experiment being done here and we're not gonna develop this any
> more once TLS1.3 is done, but whatever - I'm ok with saying that
> the WG just wanted experimental. But you'll likely get asked this
> again and again. At least we can now point at this thread and say
> that it was discussed on the list though. (Which was partly why I
> asked:-)
> 
> It'd be no harm though if a couple of others chimed in on this
> just to there's recorded opinion from more than just the AD and
> an author.
> 
> We can change to informational at the end of LC if need be, i.e.,
> there's no need to hold stuff up for that and such a change then
> doesn't add any delay.


This draft started out as Informational and then we switched it Experimental.  
The WG has not considered whether we should publish this should go Historic 
now, be held and publish as Historic later, etc.

How do folks feel about Historic vs Experimental vs Informational?

If we’re going to move it to Historic, then we’ve got a couple of options:

0) As described above: Get it approved by the IESG, hold it in RFC editor’s 
queue, and publish it as historic at the same time TLS 1.3 is published.

1) Approve it, get it published, and then make it Historic with another draft.

2) Approve it, get it published, and then make it Historic with an IESG 
initiated Protocol Action, which is a message that the IESG initiates 
requesting the status be changed similar to an IETF but requires no draft.

(there’s probably some other options like an adding an IESG note/new section 
that says “this goes to historic when TLS 1.3 is published, but I think the 
above three options seem more realistic.)

Option 0 is probably the least amount of work.  We just hold it, but in some 
sense I kind of tend to think that we’re punishing the authors.  There’s 
nothing they’ve really got to do, but it feels somehow like we’re hitting them 
upside the head with the process two-by-four.

Option 1 would be a total PITA.  People say that we can get a draft published 
quickly if we (the royal we) really want to, but my experience is otherwise.

Option 2 is something that I don't think we had in our toolkit when DKIM was 
being worked on.  The draft gets published the authors can move on and we (the 
process moths) can make sure the draft gets moved to Historic.  

What do the WG members think about the options of moving to historic?  
Personally, I’d advocate option 2 because it keeps the work load on the 
chairs/AD :)

~snipped 2~

>> 
>>> (3) Why is there no description of the reasons for all
>>> the MUST only use whitelisted  and for the choices
>>> that are whitelisted?  Wouldn't omitting that tend to
>>> lead people to use this more badly?
>> 
>> Well, I tried to capture the general reasoning in the spec -- but not the
>> detailed reasons for the specific choices 

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

[Benjamin Kaduk]

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
>> > wrote:
>>
>> On 03/31/2016 12:02 PM, Bill Cox wrote:
>>> On Thu, Mar 31, 2016 at 5:17 AM, Hannes Tschofenig
>>> >> > wrote:
>>>
>>> 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.
>>>
>>>
>>> Client certs can still be used with PSK 0-RTT, but only on
>>> the initial 1-RTT handshake.  it is up to the client to
>>> ensure that the security of the resumption master secret
>>> (RMS) is solid enough to warrant doing 0-RTT session
>>> resumption without re-verification of the client cert. 
>>
>> That seems to rule out most corporate uses of client certs
>> [for 0-RTT client authentication], since I doubt anyone will
>> be interested in trusting that the client does so properly.
>>
>>
>> Do those servers generally carry over client auth through resumption?
>>
>
> I don't know, offhand.  I just wanted to point out that for one
> sizeable use case for client certs in general (not considering
> 0RTT), this proposed scheme does not seem useful.  It may still be
> useful in other use cases, of course.
>
>
> I'm really not following you here.
>

Sorry.  I did not really make a very clear point.

> My point is that for TLS 1.2 there are two categories of servers that
> do client auth:
>
> - Those which carry over client auth through resumption
> - Those which do not
>
> The former should be equally happy (modulo all the concerns about
> replay, etc.) to carry over
> client auth through 0-RTT resumption. The latter will presumably not
> be but can do 1-RTT.
> The question then becomes how large the two populations are.
>

I guess I was thinking about the latter, and trying to note (but not
actually doing so) that they would have to do 1-RTT.

I think this subthread has outlived its useful existence...

-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

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

[Eric Rescorla]

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, 2016 at 5:17 AM, Hannes Tschofenig <
>> hannes.tschofe...@gmx.net> wrote:
>>
>>> 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.
>>>
>>
>> Client certs can still be used with PSK 0-RTT, but only on the initial
>> 1-RTT handshake.  it is up to the client to ensure that the security of the
>> resumption master secret (RMS) is solid enough to warrant doing 0-RTT
>> session resumption without re-verification of the client cert.
>>
>>
>> That seems to rule out most corporate uses of client certs [for 0-RTT
>> client authentication], since I doubt anyone will be interested in trusting
>> that the client does so properly.
>>
>
> Do those servers generally carry over client auth through resumption?
>
>
> I don't know, offhand.  I just wanted to point out that for one sizeable
> use case for client certs in general (not considering 0RTT), this proposed
> scheme does not seem useful.  It may still be useful in other use cases, of
> course.
>

I'm really not following you here.

My point is that for TLS 1.2 there are two categories of servers that do
client auth:

- Those which carry over client auth through resumption
- Those which do not

The former should be equally happy (modulo all the concerns about replay,
etc.) to carry over
client auth through 0-RTT resumption. The latter will presumably not be but
can do 1-RTT.
The question then becomes how large the two populations are.

-Ekr


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

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

[Hannes Tschofenig]

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 is less useful for the IoT space because you get the
overhead of the public key crypto without actually most of the benefits.
If you already go that step then I would recommend to use raw public
keys instead.

But since you clarified the question about the use of out-of-band
provisioned PSKs below it just means that someone using public key-based
authentication will have more roundtrips (compared to the PSK case).

> 
> 
> > However, this would include PSKs established via a previous session,
> > i.e., resumption-PSK.
> 
> Only established in previous sessions or also distributed out-of-band
> (as it would be done with PSKs normally). The way you phrased it sounds
> like you want to exclude the out-of-band case and I wonder why.
> 
> 
> No, the out-of-band case is fine.
Ok. Good.

> 
> -Ekr

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

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

[Ilari Liusvaara]

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 think that DoS mitigation is a big factor for TCP.
> >
> >
> > I believe Option #2 is simplest.
> 
> I didn't mention this because I was composing on a phone at the time,
> but we have to decide whether to allow a second attempt at 0-RTT.  If
> we do, then the effect is a two round trip setback.  I think that the
> odds of this happening are small, so I'm OK with it, but I wanted to
> highlight that.

Not taking it could mix poorly with DTLS, as DTLS rejects need to be
stateless from server POV.


-Ilari

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

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

[Eric Rescorla]

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


>
> > However, this would include PSKs established via a previous session,
> > i.e., resumption-PSK.
>
> Only established in previous sessions or also distributed out-of-band
> (as it would be done with PSKs normally). The way you phrased it sounds
> like you want to exclude the out-of-band case and I wonder why.
>

No, the out-of-band case is fine.

-Ekr


>
> Ciao
> Hannes
>
> >
> > -Ekr
> >
> >
> > On Thu, Mar 31, 2016 at 5:20 AM, Hannes Tschofenig
> > > wrote:
> >
> > Hi Sean,
> >
> > just to make sure that I properly understand the question: You are
> > suggesting to remove the DHE support but not the ECDHE support from
> the
> > 0-RTT exchange.
> >
> > Removing the DHE support is fine for us (at ARM) since we are
> focused on
> > ECDHE for IoT devices. The DTLS/TLS profile and other IETF
> > specifications very much focused on ECDHE and do not consider the
> use of
> > DHE.
> >
> > Ciao
> > Hannes
> >
> >
> > On 03/29/2016 03:11 PM, 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 support 0-RTT via
> > > DHE  (i.e., semi-static DHE) in TLS 1.3 at this time leaving the
> only
> > > 0-RTT mode as PSK. The security properties of PSK-based 0-RTT and
> > > DHE-based 0-RTT are almost identical, but 0-RTT PSK has better
> > > performance properties and is simpler to specify and implement.
> Note
> > > that this does not permanently preclude supporting DHE-based 0-RTT
> in
> > > a future extension, but it would not be in the initial TLS 1.3 RFC.
> > >
> > > If you think that we should keep DHE-based 0-RTT please indicate so
> > > now and provide your rationale.
> > >
> > > J
> > >
> > > ___ 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
> >
> >
>
>
___
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: Removing DHE-based 0-RTT

[Hannes Tschofenig]

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 include PSKs established via a previous session,
> i.e., resumption-PSK.

Only established in previous sessions or also distributed out-of-band
(as it would be done with PSKs normally). The way you phrased it sounds
like you want to exclude the out-of-band case and I wonder why.

Ciao
Hannes

> 
> -Ekr
> 
> 
> On Thu, Mar 31, 2016 at 5:20 AM, Hannes Tschofenig
> > wrote:
> 
> Hi Sean,
> 
> just to make sure that I properly understand the question: You are
> suggesting to remove the DHE support but not the ECDHE support from the
> 0-RTT exchange.
> 
> Removing the DHE support is fine for us (at ARM) since we are focused on
> ECDHE for IoT devices. The DTLS/TLS profile and other IETF
> specifications very much focused on ECDHE and do not consider the use of
> DHE.
> 
> Ciao
> Hannes
> 
> 
> On 03/29/2016 03:11 PM, 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 support 0-RTT via
> > DHE  (i.e., semi-static DHE) in TLS 1.3 at this time leaving the only
> > 0-RTT mode as PSK. The security properties of PSK-based 0-RTT and
> > DHE-based 0-RTT are almost identical, but 0-RTT PSK has better
> > performance properties and is simpler to specify and implement. Note
> > that this does not permanently preclude supporting DHE-based 0-RTT in
> > a future extension, but it would not be in the initial TLS 1.3 RFC.
> >
> > If you think that we should keep DHE-based 0-RTT please indicate so
> > now and provide your rationale.
> >
> > J
> >
> > ___ 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
> 
> 



signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Eric Rescorla]

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, Hannes Tschofenig <
hannes.tschofe...@gmx.net> wrote:

> Hi Sean,
>
> just to make sure that I properly understand the question: You are
> suggesting to remove the DHE support but not the ECDHE support from the
> 0-RTT exchange.
>
> Removing the DHE support is fine for us (at ARM) since we are focused on
> ECDHE for IoT devices. The DTLS/TLS profile and other IETF
> specifications very much focused on ECDHE and do not consider the use of
> DHE.
>
> Ciao
> Hannes
>
>
> On 03/29/2016 03:11 PM, 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 support 0-RTT via
> > DHE  (i.e., semi-static DHE) in TLS 1.3 at this time leaving the only
> > 0-RTT mode as PSK. The security properties of PSK-based 0-RTT and
> > DHE-based 0-RTT are almost identical, but 0-RTT PSK has better
> > performance properties and is simpler to specify and implement. Note
> > that this does not permanently preclude supporting DHE-based 0-RTT in
> > a future extension, but it would not be in the initial TLS 1.3 RFC.
> >
> > If you think that we should keep DHE-based 0-RTT please indicate so
> > now and provide your rationale.
> >
> > J
> >
> > ___ 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
>
>
___
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: Removing 0-RTT client auth

[Hannes Tschofenig]

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 client authentication; I understand that
the situation may be somewhat different in the Web space.

So, I am not happy with the proposed change!

Ciao
Hannes


On 03/29/2016 02:59 PM, 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...
> 
> It seems that there is a clear consensus not to support 0-RTT client
> authentication in TLS 1.3 at this time.  If you think 0-RTT client
> authentication needs to be supported please indicate so now and
> provide your rationale.
> 
> J ___ 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