[TLS] I-D Action: draft-ietf-tls-tls13-17.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security of the IETF. Title : The Transport Layer Security (TLS) Protocol Version 1.3 Author : Eric Rescorla Filename

[TLS] draft-ietf-tls-tls-13-17 posted

Folks, I have just uploaded draft-ietf-tls-tls13-17. The major change in this draft is the removal of the 0-RTT Finished and resumption_context constructs and their replacement with the psk_binder. This has a number of side effects: - Binds in the original transcript into the resumed handshake

Re: [TLS] how close are we?

Since draft 17 has been posted, could we now resume this TLS 1.3 -> TLS 2.0 discussion? Xiaoyin From: Sean Turner Sent: Tuesday, October 11, 2016 11:31 PM To: tls@ietf.org Subject: Re: [TLS] how close are we? > On Oct 11, 2016, at 23:21, Peter G

[TLS] Fwd: I-D Action: draft-sandj-tls-iana-registry-updates-01.txt

All, Joe and I submitted a revised version that merged a PR from DKG and incorporated the recommended cipher suite list that was in a.4 of draft-ietf-tls-tls13-14 (and a couple of other tweaks). A repo for the draft can be found at: https://github.com/seanturner/draft-sandj-tls-iana-registry-up

Re: [TLS] draft-ietf-tls-tls-13-17 posted

Hello, It's great to see draft-17 being published. Thank you all for the effort. Maybe the addition of extensions field to the Certificate message got lost in the changelog? https://github.com/tlswg/tls13-spec/pull/654 My understanding has been that it was a post-16 change and it changes the wir

Re: [TLS] PR #699: Simplify traffic key expansion

Hi, While trying to implement NewSessionTicket, I have noticed that resumption_psk is derived from resumption_secret. Is there any need to expand resumption_psk from resumption_secret? To me, it is unclear why resumption_secret cannot be used directly as a psk, since the two values have the same

Re: [TLS] draft-ietf-tls-tls-13-17 posted

You're right. I just missed it. Added to the editor's copy. Thanks, -Ekr On Thu, Oct 20, 2016 at 12:43 PM, Kazuho Oku wrote: > Hello, > > It's great to see draft-17 being published. Thank you all for the effort. > > Maybe the addition of extensions field to the Certificate message got > lost i

Re: [TLS] Fwd: I-D Action: draft-sandj-tls-iana-registry-updates-01.txt

On 21 October 2016 at 05:15, Sean Turner wrote: > 1) I’d like to add something along the line of the following as a warning at > the top of the cider suite registry for those that simply go to the cipher > list and don’t read the RFCs: > > WARNING: Cryptographic algorithms will be broken >

Re: [TLS] PR #699: Simplify traffic key expansion

On 21 October 2016 at 06:52, Kazuho Oku wrote: > Is there any need to expand resumption_psk from resumption_secret? > > To me, it is unclear why resumption_secret cannot be used directly as > a psk, since the two values have the same lengths and since the secret > is only used for deriving the psk

Re: [TLS] I-D Action: draft-sandj-tls-iana-registry-updates-01.txt

> On Oct 20, 2016, at 19:04, Martin Thomson wrote: > > On 21 October 2016 at 05:15, Sean Turner wrote: >> 1) I’d like to add something along the line of the following as a warning at >> the top of the cider suite registry for those that simply go to the cipher >> list and don’t read the RFCs:

[TLS] SNI and Resumption/0-RTT

We used to explicitly say that you had to check SNI for 0-RTT (but didn't say anything about resumption). On the principle that 0-RTT and resumption should be the same I removed that, but it turns out that the document doesn't actually have any rule at all other than the one we've inherited from RF

Re: [TLS] SNI and Resumption/0-RTT

Ø With that said, it does seem like there might be situations where it Ø would be useful to allow resumption/0-RTT with different SNIs. What are some example situations where resumption with a different SNI is useful? Thanks, Andrei From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric R

Re: [TLS] SNI and Resumption/0-RTT

On Thu, Oct 20, 2016 at 5:43 PM, Andrei Popov wrote: > Ø With that said, it does seem like there might be situations where it > > Ø would be useful to allow resumption/0-RTT with different SNIs. > > What are some example situations where resumption with a different SNI is > useful > A system w

Re: [TLS] SNI and Resumption/0-RTT

Perhaps it’s OK to resume a session with a different SNI if in this session the server has proved an identity that matches the new SNI. In order to enforce this, the server would have to cache (or save in the ticket) a list of identities it presented in each resumable session… From: Eric Rescorl

Re: [TLS] SNI and Resumption/0-RTT

Yeah, it does seem a bit complicated :) -Ekr On Thu, Oct 20, 2016 at 6:00 PM, Andrei Popov wrote: > Perhaps it’s OK to resume a session with a different SNI if in this > session the server has proved an identity that matches the new SNI. > > In order to enforce this, the server would have

Re: [TLS] PR #699: Simplify traffic key expansion

Hi Martin, Thank you for your response. 2016-10-21 8:05 GMT+09:00 Martin Thomson : > On 21 October 2016 at 06:52, Kazuho Oku wrote: >> Is there any need to expand resumption_psk from resumption_secret? >> >> To me, it is unclear why resumption_secret cannot be used directly as >> a psk, since th

Re: [TLS] PR #699: Simplify traffic key expansion

On 21 October 2016 at 12:24, Kazuho Oku wrote: > That is the reason I thought it might be worthwhile to remove the > following formula in section 4.5.1: > >resumption_psk = HKDF-Expand-Label(resumption_secret, > "resumption psk", "", Hash.Length) > > and u

Re: [TLS] SNI and Resumption/0-RTT

So I think that the problem could be reduced in complexity. A little at least. The obvious consequence of changing SNI is that you end up somewhere different than last time. But we can still ensure that the connection is to the same peer. If the server remembered which certificate it used, and