Re: [TLS] In-handshake CertificateRequest and 0-RTT

On Wed, May 11, 2016 at 9:25 PM Martin Thomson wrote: > I think that this is a fine way to simplify, but I have a wrinkle to add. > > I would rather this be formulated as: a client cannot authenticate > using Certificate[+Verify] unless the server does so first. > >

[TLS] In-handshake CertificateRequest and 0-RTT

The 0-RTT handshake originally had two places with a client Certificate + CertificateVerify: in the 0-RTT flow and in the second Finished block in response to a server CertificateRequest. We've dropped the first now. I propose we drop the second too. Client auth with 0-RTT is solely carried over

Re: [TLS] PR#449

This change has a non-obvious consequence for server implementation complexity. I don't have an especially good alternate proposal though. Putting ticket_age in EncryptedExtensions means there are two ways a server may reject 0-RTT. It might reject ClientHello because the ticket is invalid (or if

[TLS] Updated TLS Cached Info Document

Hi all I have just posted an updated version of the TLS Cached Info document reflecting the discussions from the last IETF meeting (and the feedback received from Karthik before) regarding the size of the fingerprint. The fingerprint is not truncated anymore, which reflects what we had in an

[TLS] I-D Action: draft-ietf-tls-cached-info-23.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 : Transport Layer Security (TLS) Cached Information Extension Authors : Stefan Santesson

[TLS] PR#449

https://github.com/tlswg/tls13-spec/pull/449 In Buenos Aires, we agreed to add EncryptedExtensions from the client in 0-RTT to carry the ticket age/elapsed_time. I have written this up in the PR above. Comments welcome. Target Merge date: Friday. -Ekr