[Emu] Murray Kucherawy's No Objection on draft-ietf-emu-eap-tls13-13: (with COMMENT)

Murray Kucherawy has entered the following ballot position for draft-ietf-emu-eap-tls13-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to

Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

On Tue, Jan 5, 2021 at 8:31 AM Alan DeKok wrote: > On Jan 5, 2021, at 11:13 AM, Mohit Sethi M > wrote: > > > > Hi Alan, > > > > Cleaning up the email. The current draft says the exporter should be > called once as: > > > >>Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", > >>

Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

pedantically, because I think that there is much confusion here. Let me go back to the whole sentence: Alan> Therefore, we need an explicit signal to the EAP-TLS layer that the Alan> EAP-TLS method has finished. Discussion on the list went back and Alan> forth between CloseNotify and sending

Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

On 1/3/21 10:38 PM, Martin Thomson wrote: On Mon, Jan 4, 2021, at 17:18, Joseph Salowey wrote: # Key Schedule The other thing I observe is the way that this slices up the exporter output. This was something that old versions of TLS did, but TLS 1.3 did away with. Though RFC 5216 did this,

Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

On Tue, Jan 05, 2021 at 11:12:21AM -0500, Alan DeKok wrote: > On Jan 5, 2021, at 11:05 AM, Michael Richardson wrote: > > > > Alan DeKok wrote: > >> Therefore, we need an explicit signal to the EAP-TLS layer that the > > > > Do you mean, "to the EAP layer"? > > s/EAP-TLS layer/EAP/ ?? > > If

Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

On Tue, Jan 5, 2021 at 8:14 AM Mohit Sethi M wrote: > Hi Alan, > Cleaning up the email. The current draft says the exporter should be > called once as: > >Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", >Type-Code, 128) > > and then split the 128 i

Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

On Jan 5, 2021, at 11:13 AM, Mohit Sethi M wrote: > > Hi Alan, > > Cleaning up the email. The current draft says the exporter should be called > once as: > >>Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", >>Type-Code, 128) >> > and then split

Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

Hi Alan, Cleaning up the email. The current draft says the exporter should be called once as: Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", Type-Code, 128) and then split the 128 into MSK (64) and EMSK (64). As said, from initial glance, it seem

Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

On Jan 5, 2021, at 11:05 AM, Michael Richardson wrote: > > Alan DeKok wrote: >> Therefore, we need an explicit signal to the EAP-TLS layer that the > > Do you mean, "to the EAP layer"? > s/EAP-TLS layer/EAP/ ?? If the EAP-TLS layer allows TLS negotiation OR EAP-Success, then it's possible t

Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

Alan DeKok wrote: > Therefore, we need an explicit signal to the EAP-TLS layer that the Do you mean, "to the EAP layer"? s/EAP-TLS layer/EAP/ ?? > EAP-TLS method has finished. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Wo

Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

Since there was a question upthread about what the exporter tags should be; the draft picks them and sends email to tls-reg-rev...@ietf.org requesting them. See https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#exporter-labels Pretty easy. _

Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

On Jan 5, 2021, at 4:47 AM, Mohit Sethi M wrote: > What I am gathering is that this commitment message should instead be > made into a confirmation message, i.e. it should only be sent after > receiving TLS Finished from the client? This would result in one extra > round trip to both figure 1 a

Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

On Jan 5, 2021, at 10:05 AM, Mohit Sethi M wrote: > This sounds reasonable. I was initially hesitant to change because we have > working implementations. Nothing has been published in an official release. So we have some time. But I'm at the point now where I'd like to release the next ver

Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

Hi Joe, On 1/5/21 8:44 AM, Joseph Salowey wrote: On Mon, Jan 4, 2021 at 6:08 AM Alan DeKok mailto:al...@deployingradius.com>> wrote: On Jan 3, 2021, at 10:44 PM, Martin Thomson mailto:m...@lowentropy.net>> wrote: > # Key Schedule > > The other thing I observe is the way that this slices up the

[Emu] Robert Wilton's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS)

Robert Wilton has entered the following ballot position for draft-ietf-emu-eap-tls13-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https:/

Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

Hi again, The following issues are related but not exactly the same: 1. indication from the server that the handshake is complete and it is okay to tear down the tunnel 2. indication from the server that no more post-handshake messages (containing NewSessionTicket or something else) will be sent