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

From: Eric Rescorla Date: Thursday, 4 February 2021 at 15:32 To: John Mattsson Cc: EMU WG , Benjamin Kaduk , "TLS@ietf.org" Subject: Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT) On Thu, Feb 4, 2021 at 6:29 AM Eric Rescorla

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

On Thu, Feb 4, 2021 at 6:29 AM Eric Rescorla wrote: > > > On Thu, Feb 4, 2021 at 12:57 AM John Mattsson > wrote: > >> Hi, >> >> >> >> I think the idea of a new TLS extension to make TLS 1.3 and EAP-TLS >> interact better is a very promising idea. This would probably take some >> time to get

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

On Thu, Feb 4, 2021 at 12:57 AM John Mattsson wrote: > Hi, > > > > I think the idea of a new TLS extension to make TLS 1.3 and EAP-TLS > interact better is a very promising idea. This would probably take some > time to get specified and implemented so it is probably a future >

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

Hi, I think the idea of a new TLS extension to make TLS 1.3 and EAP-TLS interact better is a very promising idea. This would probably take some time to get specified and implemented so it is probably a future optimization/simplification rather that something EAP-TLS 1.3 should wait for. An

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

On Mon, Feb 1, 2021 at 8:23 PM Benjamin Kaduk wrote: > On Mon, Feb 01, 2021 at 07:09:14AM -0500, Alan DeKok wrote: > > On Jan 31, 2021, at 9:16 PM, Benjamin Kaduk wrote: > > > That's a scenario that I was starting to puzzle over this weekend as > well > > > -- with EAP-Success "completely

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

On Mon, Feb 01, 2021 at 07:09:14AM -0500, Alan DeKok wrote: > On Jan 31, 2021, at 9:16 PM, Benjamin Kaduk wrote: > > That's a scenario that I was starting to puzzle over this weekend as well > > -- with EAP-Success "completely unauthenticated", it would be fairly easy > > for an on-path attacker

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

On Mon, Feb 01, 2021 at 02:52:58PM -0500, Alan DeKok wrote: > On Feb 1, 2021, at 1:30 PM, Joseph Salowey wrote: > > [Joe] This could also address the early export of keys before the peer is > > authenticated. RFC 5216 provides a canonical way to create these IDs, but > > I'm not sure anyone

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

On Mon, Feb 1, 2021 at 12:04 PM Alan DeKok wrote: > On Feb 1, 2021, at 3:00 PM, Joseph Salowey wrote: > > [Joe] What purpose is the CloseNotify serving? RFC 5216 does not require > CloseNotify. > > With TLS 1.2, the server sends TLS Finished to the client *after* it > sees the client cert. >

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

On Feb 1, 2021, at 2:48 PM, Jorge Vergara wrote: > > There has been a lot of discussion on the ending of the handshake that I hope > I have parsed. Here is my perspective as an client implementor (not an > author): > > > 1. I don't see a strict requirement for an authenticated signal at the

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

On Feb 1, 2021, at 3:00 PM, Joseph Salowey wrote: > [Joe] What purpose is the CloseNotify serving? RFC 5216 does not require > CloseNotify. With TLS 1.2, the server sends TLS Finished to the client *after* it sees the client cert. With TLS 1.3, the server sends TLS Finished to the client

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

On Mon, Feb 1, 2021 at 11:55 AM Alan DeKok wrote: > On Feb 1, 2021, at 2:32 PM, Joseph Salowey wrote: > > > > > > > > On Mon, Feb 1, 2021 at 11:25 AM Alan DeKok > wrote: > > On Feb 1, 2021, at 11:26 AM, Eric Rescorla wrote: > > > Yes, this is what I have in mind. So, maybe there's never any

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

On Feb 1, 2021, at 2:32 PM, Joseph Salowey wrote: > > > > On Mon, Feb 1, 2021 at 11:25 AM Alan DeKok wrote: > On Feb 1, 2021, at 11:26 AM, Eric Rescorla wrote: > > Yes, this is what I have in mind. So, maybe there's never any need for the > > server to say "I won't say anything more" after

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

On Feb 1, 2021, at 1:30 PM, Joseph Salowey wrote: > [Joe] This could also address the early export of keys before the peer is > authenticated. RFC 5216 provides a canonical way to create these IDs, but I'm > not sure anyone follows it today FreeRADIUS does not officially expose Peer-Id or

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

u] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT) On Mon, Feb 1, 2021 at 11:25 AM Alan DeKok mailto:al...@deployingradius.com>> wrote: On Feb 1, 2021, at 11:26 AM, Eric Rescorla mailto:e...@rtfm.com>> wrote: > Yes, this is what I h

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

On Mon, Feb 1, 2021 at 11:25 AM Alan DeKok wrote: > On Feb 1, 2021, at 11:26 AM, Eric Rescorla wrote: > > Yes, this is what I have in mind. So, maybe there's never any need for > the server to say "I won't say anything more" after just one round trip? > > I think so, yes. > > That means of

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

On Feb 1, 2021, at 11:26 AM, Eric Rescorla wrote: > Yes, this is what I have in mind. So, maybe there's never any need for the > server to say "I won't say anything more" after just one round trip? I think so, yes. That means of course EAP-TLS will always require 4.5 round trips. Alan

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

On Mon, Feb 1, 2021 at 9:12 AM Benjamin Kaduk wrote: > Hi Alan, > > I'll second the thanks for putting this together; I think it covers the > important open points. > > I did belatedly remember one more thing that is perhaps not critical, but > would also be good to get an answer for: > > On

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

Hi Alan, I'll second the thanks for putting this together; I think it covers the important open points. I did belatedly remember one more thing that is perhaps not critical, but would also be good to get an answer for: On Fri, Jan 29, 2021 at 03:00:51PM -0500, Alan DeKok wrote: [...] > >

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

On Mon, Feb 1, 2021 at 8:22 AM Alan DeKok wrote: > On Feb 1, 2021, at 11:09 AM, Eric Rescorla wrote: > > That's not what I'm proposing. I'm only talking about the case where the > server says this after flight (2). > > OK, my misreading of the text. > > > Right. But close_notify is the

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

On Feb 1, 2021, at 11:09 AM, Eric Rescorla wrote: > That's not what I'm proposing. I'm only talking about the case where the > server says this after flight (2). OK, my misreading of the text. > Right. But close_notify is the message that more matches the TLS semantics. I agree. >

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

On Mon, Feb 1, 2021 at 7:42 AM Alan DeKok wrote: > On Feb 1, 2021, at 9:55 AM, Eric Rescorla wrote: > > Let's take the second case first. If the server is sending (or > > potentially sending) post-handshake messages after the client's second > > flight (e.g., after reading its certificate),

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

On Feb 1, 2021, at 9:55 AM, Eric Rescorla wrote: > Let's take the second case first. If the server is sending (or > potentially sending) post-handshake messages after the client's second > flight (e.g., after reading its certificate), then it can easily send > a close_notify after sending all of

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

>Asking as the author of a TLS library that has always done this, why would > you stop immediately after the Finished and leave metadata messages sitting unread in the input stream? Was it just some arbitrary implementation decision, or is there a technical reason for it? The

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

On Fri, Jan 29, 2021 at 12:02 PM Alan DeKok wrote: > This is a new message to summarize history, requirements, etc. for > EAP-TLS and TLS 1.3. The focus here is the requirements for EAP-TLS, and > how the 0x00 commitment message versus CloseNotify meets those. I'll > ignore the exporter

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

On Jan 31, 2021, at 9:16 PM, Benjamin Kaduk wrote: > That's a scenario that I was starting to puzzle over this weekend as well > -- with EAP-Success "completely unauthenticated", it would be fairly easy > for an on-path attacker to send the EAP-Success the EAP peer was expecting > and make the

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

On Feb 1, 2021, at 1:00 AM, Joseph Salowey wrote: [ re: commitment message ] > [Joe] I'm not sure why it's needed. It's not clear to me why the peer can't > hold the TLS session open until it receives more TLS messages (handshake or > alert) or an EAP failure or EAP Success. I suspect

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

On Mon, Feb 01, 2021 at 06:21:16AM +, Peter Gutmann wrote: > Alan DeKok writes: > > >OpenSSL has a feature SSL_MODE_AUTO_RETRY which makes it process TLS messages > >*after* the Finished message. i.e. the Session Ticket, etc. When an > >application calls SSL_Read(), all of the TLS data is

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

Alan DeKok writes: >OpenSSL has a feature SSL_MODE_AUTO_RETRY which makes it process TLS messages >*after* the Finished message. i.e. the Session Ticket, etc. When an >application calls SSL_Read(), all of the TLS data is processed, instead of >just the "TLS finished" message. They've made this

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

On Sun, Jan 31, 2021 at 6:17 PM Benjamin Kaduk wrote: > On Sun, Jan 31, 2021 at 09:20:57AM -0500, Alan DeKok wrote: > > On Jan 29, 2021, at 5:00 PM, Joseph Salowey wrote: > > > DISCUSS: the EAP-TLS draft should also explain that session tickets > may be sent either before or after the 0x00

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

Hi Alan, With my apologies to everyone on the thread for so many mails in succession... On Fri, Jan 29, 2021 at 02:09:09PM -0500, Alan DeKok wrote: > On Jan 29, 2021, at 1:32 PM, Benjamin Kaduk wrote: > > With respect to the exporter usage, I do see you had asked about using the > > type-code

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

Hi Mohit, The quoting in your note is not coming across usefully in my MUA, so I'm trimming to (what I think are) just your remarks without other history. On Fri, Jan 29, 2021 at 07:34:42PM +, Mohit Sethi M wrote: > Hi Ben, > > RFC 5705 says: > >If no context is provided, it then

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

On Sun, Jan 31, 2021 at 09:20:57AM -0500, Alan DeKok wrote: > On Jan 29, 2021, at 5:00 PM, Joseph Salowey wrote: > > DISCUSS: the EAP-TLS draft should also explain that session tickets may be > > sent either before or after the 0x00 octet. Does the packet flow look any > > different for the

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

On Jan 29, 2021, at 5:00 PM, Joseph Salowey wrote: > DISCUSS: the EAP-TLS draft should also explain that session tickets may be > sent either before or after the 0x00 octet. Does the packet flow look any > different for the two cases? If so, what does that mean? > > [Joe] I believe the flow

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

2:00 PM To: Alan DeKok Cc: EMU WG ; Benjamin Kaduk ; Martin Thomson ; Subject: Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT) HI Alan, THanks for this message, comments inline below: On Fri, Jan 29, 2021 at 12:02 PM Alan DeKok mailt

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

HI Alan, THanks for this message, comments inline below: On Fri, Jan 29, 2021 at 12:02 PM Alan DeKok wrote: > This is a new message to summarize history, requirements, etc. for > EAP-TLS and TLS 1.3. The focus here is the requirements for EAP-TLS, and > how the 0x00 commitment message

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

On Fri, Jan 29, 2021 at 11:34 AM Mohit Sethi M wrote: > Hi Ben, > On 1/29/21 8:32 PM, Benjamin Kaduk wrote: > > Hi Alan, > > I see that the thread is continuing and that perhaps my reply will even > become stale as I write it, but I'm replying to your note instead of the > tip of the thread

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

This is a new message to summarize history, requirements, etc. for EAP-TLS and TLS 1.3. The focus here is the requirements for EAP-TLS, and how the 0x00 commitment message versus CloseNotify meets those. I'll ignore the exporter changes here, as those are less controversial. The original

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

On Jan 29, 2021, at 1:32 PM, Benjamin Kaduk wrote: > With respect to the exporter usage, I do see you had asked about using the > type-code as the exporter context value that Martin didn't see much value > in, but I am willing to accept that as a boon for safety of portability to > other

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

Hi Alan, I see that the thread is continuing and that perhaps my reply will even become stale as I write it, but I'm replying to your note instead of the tip of the thread because it has good context for making some broader points that I would like to make. On Sat, Jan 23, 2021 at 05:28:10PM

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

> We need to get agreement on how to proceed here asap. I would like > implementors and security AD to agree on the way forward before submitting > -14. Four ways forward: > > A. Add (1) and (2) > B. Only add (1) > C. Only add (2) > D. Do not add (1) or (2) My preference is D. > Do we need to

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

On Jan 29, 2021, at 8:10 AM, Alan DeKok wrote: > Then our choices are: > > a) draft-13 in February. There are multiple interoperable implementations, > including Microsoft, FreeRADIUS, and hostap / wpa_supplicant. > > b) ??? in 2021. Typo: 2022. :(

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

On Jan 29, 2021, at 5:31 AM, John Mattsson wrote: > > I can live with any version, the important thing is that interoperable > implementations get shipped ASAP. This is important also for 3GPP as EAP-TLS > 1.3 is mandatory to support in 3GPP Rel-16 if EAP-TLS is supported. Then our choices

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

al Message- From: Emu On Behalf Of Alan DeKok Sent: Saturday, January 23, 2021 2:28 PM To: Martin Thomson Cc: ; EMU WG Subject: Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT) We're approaching 2 weeks since the last discussion of

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

: Saturday, January 23, 2021 2:28 PM To: Martin Thomson Cc: ; EMU WG Subject: Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT) We're approaching 2 weeks since the last discussion of this topic. This document has been in development

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

We're approaching 2 weeks since the last discussion of this topic. This document has been in development for 3 years. We desperately need to finish it. IMHO waiting another 6 months is not an option. Even 3 would be worrying. We have multiple inter-operable implementations which have

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

On Jan 11, 2021, at 7:08 PM, Martin Thomson wrote: > I was not exactly. I was thinking that EAP-TLS uses the unadorned string and > other usages (that need a different MSK) define their own string as needed. Which is largely what was done for <= TLS 1.2. That choice made implementations

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

On Mon, Jan 11, 2021, at 17:07, Joseph Salowey wrote: > > > On Thu, Jan 7, 2021 at 2:42 PM Martin Thomson wrote: > > Hi Joe, > > > > Thanks for doing this, I think that this is a distinct improvement (and I > > will take your word for the difficulties involved with further splits). > > >

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

On Jan 11, 2021, at 1:07 AM, Joseph Salowey wrote: > [Joe] I think you propose something like this instead (eliminating context): > > MSK = TLS-Exporter("EXPORTER_EAP_TLS_MSK-" + ASCII-Type-Code, 64) > > Where + is concatenation and ASCII-Type-Code is "13" > > the IANA section would

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

On Thu, Jan 7, 2021 at 2:42 PM Martin Thomson wrote: > Hi Joe, > > Thanks for doing this, I think that this is a distinct improvement (and I > will take your word for the difficulties involved with further splits). > > One point that I made poorly perhaps, and was dismissed, might be worth >

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

Hi Martin, Thanks for the quick response. On 1/8/21 10:25 AM, Martin Thomson wrote: > On Fri, Jan 8, 2021, at 18:54, Mohit Sethi M wrote: >> Thanks for pointing this out. I think Ben also mentioned this in his >> review. I am not sure if it is necessary to add the type-code to the >> label when

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

On Fri, Jan 8, 2021, at 18:54, Mohit Sethi M wrote: > Thanks for pointing this out. I think Ben also mentioned this in his > review. I am not sure if it is necessary to add the type-code to the > label when it is already part of the label string as 'EAP_TLS'. Other > TLS based EAP methods

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

Hi Ben, On 1/7/21 9:21 AM, Benjamin Kaduk wrote: > On Tue, Jan 05, 2021 at 10:41:50AM -0500, Alan DeKok wrote: >> 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

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

Hi Martin, Thanks for pointing this out. I think Ben also mentioned this in his review. I am not sure if it is necessary to add the type-code to the label when it is already part of the label string as 'EAP_TLS'. Other TLS based EAP methods should ideally register labels of the form

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

Hi Joe, Thanks for doing this, I think that this is a distinct improvement (and I will take your word for the difficulties involved with further splits). One point that I made poorly perhaps, and was dismissed, might be worth restating: MSK = TLS-Exporter("EXPORTER_EAP_TLS_MSK", Type-Code,

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

On Tue, Jan 05, 2021 at 10:41:50AM -0500, Alan DeKok wrote: > 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

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

On Jan 6, 2021, at 1:24 AM, Joseph Salowey wrote: > [Joe] I created a pull request > (https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/17) with the > proposed labels. Is this change going to cause significant problems for > implementation? After making this change: $ git diff

Re: [TLS] [Emu] 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: [TLS] [Emu] 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: [TLS] [Emu] 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: [TLS] [Emu] 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

Re: [TLS] [Emu] 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: [TLS] [Emu] 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

Re: [TLS] [Emu] 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

Re: [TLS] [Emu] 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

Re: [TLS] [Emu] 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: [TLS] [Emu] 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

Re: [TLS] [Emu] 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

Re: [TLS] [Emu] 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

Re: [TLS] [Emu] 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

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

On Mon, Jan 4, 2021 at 6:08 AM Alan DeKok wrote: > On Jan 3, 2021, at 10:44 PM, Martin Thomson 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

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

Hi Martin, Thanks for chiming in here; your insight has been quite helpful already. (I am going to reply to the thread in reverse order so as to not duplicate what you've already said.) On Tue, Jan 05, 2021 at 02:50:15PM +1100, Martin Thomson wrote: > Hi Alan, > > On Tue, Jan 5, 2021, at 14:05,

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

Hi Alan, On Tue, Jan 5, 2021, at 14:05, Alan DeKok wrote: > On Jan 4, 2021, at 6:26 PM, Martin Thomson wrote: > > Your point about reliability is confusing. I've read Section 4.2 of RFC > > 3748 and while it says "A peer MUST allow for this circumstance as > > described in this note.", I see

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

On Jan 4, 2021, at 6:26 PM, Martin Thomson wrote: > Your point about reliability is confusing. I've read Section 4.2 of RFC 3748 > and while it says "A peer MUST allow for this circumstance as described in > this note.", I see no explanation of how to concretely make that allowance. > Are

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

On Jan 4, 2021, at 9:40 AM, Eric Rescorla wrote: > That's easy enough to change at this state. The question is what are those > labels? > > They're just strings, so as long as they don't conflict, it's largely up to > the EAP WG. My point was more that we cannot afford to wait another

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

On Mon, Jan 4, 2021 at 6:08 AM Alan DeKok wrote: > On Jan 3, 2021, at 10:44 PM, Martin Thomson 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

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

On Jan 3, 2021, at 10:44 PM, Martin Thomson 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, EAP-TLS for TLS 1.3 doesn't need to.

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

On Mon, Jan 4, 2021, at 17:18, Joseph Salowey wrote: > [Joe] I'm not sure I remember correctly, but I think the commitment > message was to make the integration with EAP statement machine cleaner > and perhaps to future proof against additional messages sent after the > handshake. I tend to

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

Hi Martin, Thanks for taking a look at this, some comments below: On Sun, Jan 3, 2021 at 7:45 PM Martin Thomson wrote: > Hi All, > > Ben asked me to take a look at this draft and I think that the general > gist of Ben's comments need some careful consideration. > > # Commitment Message > > I