[TLS] I-D Action: draft-ietf-tls-iana-registry-updates-01.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 : D/TLS IANA Registry Updates Authors : Joe Salowey Sean Turner Filename

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

All, Joe and I updated the draft. GH repo is @: https://github.com/tlswg/draft-ietf-tls-iana-registry-updates Note that I’d to rewrite the introduction to be briefer and move the rationale for the changes to the section where the change is suggested. I think this will make it easier to review,

[TLS] I-D Action: draft-ietf-tls-tls13-20.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-tls13-20 is up

This version incorporates the WGLC feedback and discussions in Chicago. Changes in -20: - Add "post_handshake_auth" extension to negotiate post-handshake authentication (*). - Shorten labels for HKDF-Expand-Label so that we can fit within one compression block (*). - Define how RFC 7250 wor

[TLS] I-D Action: draft-ietf-tls-dtls13-00.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 Datagram Transport Layer Security (DTLS) Protocol Version 1.3 Authors : Eric Rescorla

Re: [TLS] WG Call for adoption of draft-rescorla-tls-dtls13

Draft submitted (it should be identical to the individual submission) -Ekr On Fri, Apr 7, 2017 at 2:14 PM, Sean Turner wrote: > It’s now the 7th so the call for adoption is complete. Though Ben was the > only commenter on list (and thanks Ben) there was definitely support for > adopting this

[TLS] Session ticket (re-)use in multi-process applications?

Unlike many/most browsers, Postfix makes each TLS connection from a separate smtp(8) client process. TLS session reuse is supported via a shared service process tlsmgr(8) which maintains a cache of saved sessions for peer destinations that have provided session resumption data (session tickets

Re: [TLS] Session ticket (re-)use in multi-process applications?

On Fri, Apr 28, 2017 at 11:20 AM, Viktor Dukhovni wrote: > > Unlike many/most browsers, Postfix makes each TLS connection from a > separate smtp(8) client process. > > TLS session reuse is supported via a shared service process tlsmgr(8) > which maintains a cache of > saved sessions for peer dest

[TLS] Key update routine

Hi Eric and everyone, Glad to meet you all here in this group. I've been working my way through the latest TLS 1.3 draft (the 20th), and I hope you wouldn't mind me putting in my 2p about the key update routine. While section 4.6.3 (Key and IV update) provides good insight as to what the imp

Re: [TLS] Key update routine

On Fri, Apr 28, 2017 at 07:41:59PM +0100, Ken Ivanov wrote: > Hi Eric and everyone, > > Specifically, while the spec instructs the party that receives a KeyUpdate > with its request_update set to update_requested to respond with its own > KeyUpdate with request_update set to update_not_requested,

Re: [TLS] Session ticket (re-)use in multi-process applications?

> On Apr 28, 2017, at 2:29 PM, Eric Rescorla wrote: > >> What does this mean in practice? What happens if Postfix continues to use >> the >> same ticket multiple times anyway? Will servers somehow invalidate the >> ticket >> after first use? Are the consequences of reuse more severe than wi

Re: [TLS] Key update routine

Hi Ilari I see your point, thank you. Maybe we shall think about replacing the MUST (in 'then the receiver MUST send a KeyUpdate of its own') with SHOULD then, not to lead the originator into confusion about the mutual nature of the key update, and treat the 'request_update' parameter as a sug

[TLS] Fwd: Publication has been requested for draft-ietf-tls-tls13-20

Note that I’ve requested Kathleen begin her AD review. For those not in the know about IETF process, there’s still a two-week IETF LC after Kathleen’s review so if anything earth shattering gets uncovered we can still address it before it gets to the IESG. spt > Begin forwarded message: > > F

Re: [TLS] WG review of draft-ietf-tls-rfc4492bis

Thanks to MT and Ben for their reviews. Joe and I have asked Kathleen to progress this draft towards the “approved” state. spt > On Apr 11, 2017, at 09:09, Sean Turner wrote: > > All, > > draft-ietf-tls-rfc4492bis has been revised since it left the WG and we agree > with Yoav’s statement at

Re: [TLS] WG Call for adoption of draft-rescorla-tls-dtls13

Thanks! spt > On Apr 28, 2017, at 12:50, Eric Rescorla wrote: > > Draft submitted (it should be identical to the individual submission) > > -Ekr > > > On Fri, Apr 7, 2017 at 2:14 PM, Sean Turner wrote: > It’s now the 7th so the call for adoption is complete. Though Ben was the > only comm

[TLS] GH repo for draft-rescorla-tls-dtls13

We’ve created a GH rep for the DTLS1.3 draft @ https://github.com/tlswg/dtls13-spec spt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead

The chairs are forwarding this document to our AD to progress towards publication. Cheers, Joe On Tue, Apr 11, 2017 at 8:21 AM, Joseph Salowey wrote: > Hi Daniel, > > Please submit a revised draft with the changes below. > > Thanks, > > Joe > > > On Tue, Mar 21, 2017 at 11:08 AM, Daniel Migaul