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

Hi Sean I also strongly support this. I’m just wondering how we plan to enforce the "stable, publicly available, peer reviewed reference” part. As your examples below show, the reference tends to be an I-D. That’s stable and publicly available, but we have no idea if it’s peer reviewed or who

Re: [TLS] Resumption and Forward Secrecy, 0-RTT and Safety

On Mon, Mar 28, 2016 at 3:49 PM, Ryan Hamilton wrote: > ​We (Chrome) definitely want this (sending cookies in 0-RTT requests), and > are doing this today with QUIC (which we can't wait to TLS 1.3-ify). ​ > I went to RealWorldCrypto 2016 and saw the TLS track and all of the

Re: [TLS] Narrowing the replay window

On Wed, Mar 30, 2016 at 12:52:23PM +1100, Martin Thomson wrote: > On 30 March 2016 at 12:49, Colm MacCárthaigh wrote: > > But isn't that too late? If you have to wait for the client finished message > > before you can even decrypt the 0RTT section; what's the benefit? it's not

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

在 16-3-30 下午12:17， "Peter Bowen" 写入: >It doesn't seem to be clearly spelled out: is the "charging GW" a >system that can read data passing between the client and server but >cannot modify it? If so, do I have it right that you are trying to >design an extension that allows

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

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

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

It doesn't seem to be clearly spelled out: is the "charging GW" a system that can read data passing between the client and server but cannot modify it? If so, do I have it right that you are trying to design an extension that allows the client to send a message that can be observed but not

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

On 30 March 2016 at 15:04, Dacheng Zhang wrote: > 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

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

On 30 March 2016 at 14:59, Eric Rescorla wrote: > I meant "would work with TLS 1.3". I don't believe it will work with TLS 1.2 > even > with EMS because (even with the MAC) the SI extension is bound to the > ClientHello > which is replayable in 1.2 because it contains public

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

I meant "would work with TLS 1.3". I don't believe it will work with TLS 1.2 even with EMS because (even with the MAC) the SI extension is bound to the ClientHello which is replayable in 1.2 because it contains public information, with the only non-fixed information being the random. However in

Re: [TLS] Narrowing the replay window

On 30 March 2016 at 14:18, Colm MacCárthaigh wrote: > though I'll note that it relies on basically a Mac-Then-Encrypt > construction. I don't think that the right term to apply here. This isn't record protection. The MAC authenticates the handshake here, then we use AEAD for

Re: [TLS] Narrowing the replay window

On Tue, Mar 29, 2016 at 6:52 PM, Martin Thomson wrote: > On 30 March 2016 at 12:49, Colm MacCárthaigh wrote: > > But isn't that too late? If you have to wait for the client finished > message > > before you can even decrypt the 0RTT section; what's

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

Hi! In Yokohama, we discussed changing the IANA registry assignment rules for cipher suites to allow anyone with a stable, publicly available, peer reviewed reference document to request and get a code point and to add an “IETF Recommended” column to the registry. This change is motivated by

Re: [TLS] Narrowing the replay window

On 30 March 2016 at 12:49, Colm MacCárthaigh wrote: > But isn't that too late? If you have to wait for the client finished message > before you can even decrypt the 0RTT section; what's the benefit? it's not > "0RTT" any more. There is a Finished message in the client's first

Re: [TLS] Narrowing the replay window

On Tue, Mar 29, 2016 at 6:25 PM, Martin Thomson wrote: > On 30 March 2016 at 11:30, Colm MacCárthaigh wrote: > > * How is the elapsed time on the wire authenticated? can't an attacker > > modify it and replay? > > It is authenticated by virtue of

Re: [TLS] Narrowing the replay window

On 30 March 2016 at 12:45, Kyle Nekritz wrote: > The time since the client hello was sent/received can still be used if it is > stored after opening the connection. Only if we introduce an inconsistency by asking for different handling in different circumstances. I agree that

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

Hi, Ekr: Thanks for reviewing the draft and the comments. Please see my reply inline please. 发件人: Eric Rescorla 日期: 2016年3月30日 星期三 上午7:21 至: dacheng de 抄送: Eric Mill , Dave Garrett , tls

Re: [TLS] Tickets and cross protocol attacks

On 30 March 2016 at 05:00, David Benjamin wrote: > On the server, OpenSSL already includes the version in the SSL_SESSION > structure, and recent enough versions of it will not accept sessions at the > wrong version NSS too. This is the right thing, I think. I have no

Re: [TLS] Narrowing the replay window

On Tue, Mar 29, 2016 at 4:37 PM, Martin Thomson wrote: > On 30 March 2016 at 06:53, Colm MacCárthaigh wrote: > > It's likely I'm misunderstanding, but I'll ask to clear it up. Does this > > proposal imply that a 0RTT section can only be sent within a

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

I have taken an initial look at this document, but I find myself confused about the security model. Specifically, you say that you can't use SNI because customers will lie and insert the SNI for service A in the ClientHello when going to service B. However, I don't see how this token stops that,

[TLS] Key separation and privacy

Dear TLS Working Group, this message relates mostly to (real-world) privacy, so I'd be particularly grateful for comments from people concerned with that. The TRON workshop [1] re-initiated a discussion about the handling of keys among cryptography researchers involved with TLS. Although there

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

On Tue, Mar 29, 2016 at 10:14 AM, Wan-Teh Chang wrote: > On Tue, Mar 29, 2016 at 6:11 AM, Sean Turner wrote: > > > > 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

Re: [TLS] Tickets and cross protocol attacks

On Tue, Mar 29, 2016 at 12:57 PM Subodh Iyengar wrote: > Recent attacks like SLOTH, DROWN, PCKS1.5 padding oracles have shown that > attacks on previous version of TLS can be used to attack new version of > TLS. > > One thing that is not mandated by TLS 1.3 is separation of

Re: [TLS] Narrowing the replay window

I think this will better account for the round trip delay if the elapsed_time is defined on the client as the time since the request for the session ticket (in other words, the time since the client hello was sent). That way both the server computed time and the client reported time will

[TLS] Tickets and cross protocol attacks

Recent attacks like SLOTH, DROWN, PCKS1.5 padding oracles have shown that attacks on previous version of TLS can be used to attack new version of TLS. One thing that is not mandated by TLS 1.3 is separation of session tickets and session ids between TLS protocols. For example a client could use

Re: [TLS] Publishing draft-ietf-tls-56-bit-ciphersuites as Historic

On Tuesday 29 March 2016 15:09:16 Yoav Nir wrote: > > On 29 Mar 2016, at 2:15 PM, Hubert Kario wrote: > > > > On Friday 25 March 2016 22:07:02 Yoav Nir wrote: > >>> On 25 Mar 2016, at 8:16 PM, Yuhong Bao > >>> wrote: > >>> > >>> I wonder if it

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

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

Re: [TLS] Publishing draft-ietf-tls-56-bit-ciphersuites as Historic

> On 29 Mar 2016, at 2:15 PM, Hubert Kario wrote: > > On Friday 25 March 2016 22:07:02 Yoav Nir wrote: >>> On 25 Mar 2016, at 8:16 PM, Yuhong Bao >>> wrote: >>> >>> I wonder if it would be possible to publish >>> draft-ietf-tls-56-bit-ciphersuites

Re: [TLS] Diffie-Hellman: value of Z - the shared secret - without leading zero octets

Bill Cox writes: >I spent 2 weeks last year tracking down a flaky bug that only occurs once in >every 256 connection: the leading 0 byte was no longer being stripped in a >code change I ported from OpenSSL master, and only Maria DB ran random tests >enough to trigger this

Re: [TLS] Publishing draft-ietf-tls-56-bit-ciphersuites as Historic

On Friday 25 March 2016 22:07:02 Yoav Nir wrote: > > On 25 Mar 2016, at 8:16 PM, Yuhong Bao > > wrote: > > > > I wonder if it would be possible to publish > > draft-ietf-tls-56-bit-ciphersuites as Historic (in the sense of RFC > > 6101). It would start with > >

[TLS] Narrowing the replay window

https://github.com/tlswg/tls13-spec/pull/437 In short, have the client report the time since it received the configuration. Then have the server reject early data if the time doesn't match. I think that this is a relatively easy change to make. Now, your exposure to replay is much less. It's

Re: [TLS] Resumption and Forward Secrecy, 0-RTT and Safety

On 29 March 2016 at 19:21, Karthikeyan Bhargavan wrote: > Note that choosing the expiry/rollover period also determines the replay > window, I think that we can fix that one easily, as I suggested in an earlier mail. I plan to open a PR that does that.