Re: [Emu] [TLS] 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 , "t...@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 mail

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

On Jan 29, 2021, at 5:35 PM, Jorge Vergara wrote: > > [Jorge] The diagrams in the draft mostly imply that the commitment message > being the last thing sent, after any NewSessionTicket. As stated, this is > problematic since the TLS stack may re-order these, and the NewSessionTicket > may have

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

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

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 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

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

Re: [Emu] [TLS] 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: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

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 because it has good context for making some broader points that I would li

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

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

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

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

ergara -Original 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

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

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 this topic. This document has been in

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 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 imp

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

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

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

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

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 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 cli

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

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

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

Re: [Emu] [TLS] 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: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

On Mon, Jan 04, 2021 at 02:44:01PM +1100, Martin Thomson wrote: > > I would instead either prohibit the use of application data outright or say > that it carries no semantics unless otherwise negotiated. The current design > has the effect of rendering application data unusable, so perhaps the

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 10:26:40AM +1100, Martin Thomson wrote: > On Mon, Jan 4, 2021, at 21:01, Mohit Sethi M wrote: > > > I have a much simpler one: the EAP layer has a signal that the > > > protocol is complete: EAP-Success > > Alan Dekok explained in a separate email thread why this is not

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

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

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

On Mon, Jan 4, 2021, at 21:01, Mohit Sethi M wrote: > > I have a much simpler one: the EAP layer has a signal that the > > protocol is complete: EAP-Success > Alan Dekok explained in a separate email thread why this is not the > case > (https://mailarchive.ietf.org/arch/msg/emu/uMNKV_vfov7ASo

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

Re: [Emu] [TLS] 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: [Emu] [TLS] 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: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

Top posting to explain the need for a reliable notification of protocol completion: On 1/4/21 5:44 AM, Martin Thomson wrote: I have a much simpler one: the EAP layer has a signal that the protocol is complete: EAP-Success Alan Dekok explained in a separate email thread why this is not the cas

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

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

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

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 think that Ben's concerns about the Commitment Message are justified, but aren't as bad a layering violation as observed (almost). It w