Re: [Emu] EAP-TLS and TLS alerts

Hi, I personally fine with writing MUST send an Error alert if the WG wants that. This would maybe help with using close_notify as an alternate success indication. The most pressing question regarding alerts is if EAP-TLS can force the TLS implementation to not use close_notify in any situatio

Re: [Emu] Session tickets in TLS 1.3

Hi, I made several updates to the text based on your comments. My earlier comments on the early ticket was wrong, it is not a bug. The ticket in OpenSSL is still valid but the server does cannot calculate the PSK before it has received the client Finished. All message flows are correct. There

Re: [Emu] EAP-TLS and TLS alerts

On Feb 5, 2021, at 2:53 PM, Alan DeKok wrote: > The TLS layer generally *will* produce TLS alerts. The application has the > choice whether or not to send them. i.e. it should just discard the TLS > alerts, and instead send EAP-Failure. Typo, sorry. It "could" discard the TLS alert and se

Re: [Emu] Session tickets in TLS 1.3

On Feb 5, 2021, at 2:25 PM, John Mattsson wrote: > > Not sure that OpenSSL current default behavior is interesting for the draft. I'm not sure what that means. Do we want to ignore the dominant TLS library? And make the draft *incompatible* with it? Or is OpenSSL *wrong*? i.e. does

Re: [Emu] EAP-TLS and TLS alerts

On Feb 5, 2021, at 2:46 PM, John Mattsson wrote: > > I see now that the two paragraphs you send seems to be contradicting each > other > > https://tools.ietf.org/html/rfc8446#section-2 > > A failure of the handshake or other protocol error triggers the > termination of the connection, opt

Re: [Emu] EAP-TLS and TLS alerts

Hi, I see now that the two paragraphs you send seems to be contradicting each other https://tools.ietf.org/html/rfc8446#section-2 A failure of the handshake or other protocol error triggers the termination of the connection, optionally preceded by an alert message (Section 6). https://

[Emu] EAP-TLS and TLS alerts

Hi, Alerts are definitly not mandatory in TLS 1.3. Adding a note stating that alerts are not mandatory seems like a good idea. But "suggests" seems like the wrong word and optional != SHOULD. I would like more feedback from other people before adding new requirements on TLS. Can an application

Re: [Emu] Session tickets in TLS 1.3

Not sure that OpenSSL current default behavior is interesting for the draft. None of the Tickets in the draft are invalid. The tickets in Figure 2 are different messages. Sending a ticket with Finished after asking for client auth seems like a implementaion bug. As far as I understand, a ser

[Emu] EAP-TLS and TLS alerts

I was discussing this offline with Jorge, who noticed that in TLS, alerts are SHOULD and not MUST: https://tools.ietf.org/html/rfc8446#section-2 A failure of the handshake or other protocol error triggers the termination of the connection, optionally preceded by an alert message (Sect

Re: [Emu] Session tickets in TLS 1.3

On Feb 5, 2021, at 10:42 AM, John Mattsson wrote: > The resumption_master_secret includes the client finished so the client in > your handshake with client authentication should not be able to reconnect, if > it can it is an OpenSSL bug. Alternatively the server did not ask for client > authen

[Emu] Session tickets in TLS 1.3

Some quick comments below: Alan DeKok wrote: >So it's possible for a malicious client to get the ticket, and close the >connection without >sending a client cert. Then, if the EAP server doesn't >destroy the ticket, the client can >reconnect. The resumption_master_secret includes the client f

[Emu] Planned minor changes for EAP-TLS 1.3 -15

Hi, I re-read all the mails written on the EMU list the last month to see if any comments and suggestions had been forgotten. Based on that, the following smaller changes were added to the GitHub version and are planned for the next version: - Added references to ietf-emu-tls-eap-types as sugg

Re: [Emu] Way Forward for EAP-TLS 1.3

Hi Joe, Good initiative. 1. To have an alternate success indication is new. The requirement needs to be the possibility to have an _protected_ success indication. This is requires in at least IEEE 802. It seems to be a weakness in the IEEE 802 spec, but EAP-TLS simply has to align with this. I

[Emu] Session tickets in TLS 1.3

I've been rooting through the specs, TLS library implementations, and various other online things. I think there are issues with session tickets and TLS 1.3. These issues haven't been brought up in detail before (that I recall) Applications cannot control when the TLS layer sends session

Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

On Feb 4, 2021, at 9:22 AM, John Mattsson wrote: > I think the major decision for the EMU WG to make going forward is to agree > if EAP-TLS 1.3 MUST have an alternative success indication. RFC 5216 does not > discuss the EAP state machine at all, but in TLS 1.2 the server finished can > be use