Subject: Re: [Emu] Session tickets in TLS 1.3

From: John Mattsson <[email-masked]>
Date: Sun, 7 Feb 2021 11:11:14 +0000

Alan DeKok wrote:

>The document should explain this in detail, and suggest which message flows are preferred, and which >ones MUST be supported.  It should explain what happens when resumption is negotiated, and 20
>tickets are received by the peer.  What does that mean?  What does the peer do with them?  Why does >the server send them?  Which (if any) ticket is preferred?

>It is not helpful if a specification says "anything can happen".  The purpose of the specification is >to provide a guide for implementors and deployments.  This includes not just saying what *can* >happen.  But what *should* happen.  Why one thing is preferred over another.  Why certain protocol >choices were made.  So that readers of the document are informed as to what to do, and why they need >to do it.

This seem very much like TLS 1.3 details. I am not sure that EAP-TLS should answer these question, or that the EMU WG even has the competence. What you want is basically a description of the design choices in TLS 1.3 and guidance that TLS 1.3 itself decided to not give.

Have you a conrete example of something this is more important to give guidance about in EAP-TLS 1.3 than in TLS 1.3 in genereal?

Several reviewers the last month suggested the opposite, to completely remove all TLS 1.3 details and only describe the interactions between TLS 1.3 and EAP-TLS 1.3.....

>What does it mean to say "will" appear?  SHOULD the conversation look like that?  MUST it?  What >happens when the conversation doesn't appear like that?  What does it mean when the conversation >doesn't appear like that?

That is from the old version. Unfortunatly the EMU GitHub does not automatically generate txt and html after commits like most other repositories. As I do all my commits through the web interface, the only up to date version is the xml...

https://github.com/emu-wg/draft-ietf-emu-eap-tls13/blob/master/draft-ietf-emu-eap-tls13.xml

The current text is:

"Figure 2  shows an example message flow where EAP-TLS server authentication is unsuccessful and the EAP-TLS peer sends a TLS Error alert."

All sentences talking about the message flow figures have been rewritten in a similar way, i.e., "shows an example message flow". TLS 1.3 allows quite a lot of flexibility already now with NewSessionTicket, HelloRetryRequest, KeyUpdate, option errors, optional to accept resumption, etc. Future extensions might allow or restrict the flexibility.

> What does it mean if the NewSessionTicket message is sent later?  Is there an impact on the number > of round trips?  What is the RECOMMENDED approach?

>  Perhaps the NewSessionTicket message SHOULD be sent in the same EAP packet as the TLS Server 
> Finished message.  Sending it later adds additional round trips for no benefit.

I think the only difference would be if the server wants to put the client certificate in the ticket.

I am hesitant to add any recommendations for TLS 1.3 not specifically related to EAP-TLS. These are also things RFC 8446 leaves completely to the implementation.

>Further, there are significantly more variants of TLS 1.3 flows than for TLS 1.2.

Yes, for TLS 1.3 there are infinitly many valid message flows....

>These variants should be explained, along with suggestions and recommendations.  What does an EAP >peer do if it receives 20 session tickets?  Why would a server send 20 session tickets?

>Perhaps simply recommend that if possible, only one session ticket be sent by the EAP server.  And >that if the EAP peer receives multiple session tickets, it should only save one, and discard the >rest.  Which one doesn't matter.  If the EAP server sends multiple session tickets, it's the >responsibility of the EAP server to ensure that all are valid.

These are all things that should be handled by the TLS layer. Not sure EAP-TLS should or need to say anything about this. 

>...
>To enable resumption when using EAP-TLS with TLS 1.3, the EAP-TLS server MUST send one or more >Post-Handshake NewSessionTicket messages

>  I suggest limiting this to one. I suggest also saying that session tickets SHOULD NOT be sent >BEFORE the client cert is validated.  But that perhaps this is not always under the control of the >EAP layer.  And, that the EAP peer MUST ignore session tickets until after it has received the >"altSuccess" message from the EAP server.  Further, the EAP server MUST NOT cache or use any session >tickets sent by the TLS layer before the client certificate is validated.

I don't think EAP-TLS should make recommendations about internal TLS 1.3 unless necesary. Such recommendations would likely have to be checked with the TLS WG so that they make sense. 

Resticting things would make EAP-TLS incompatible with a lot of TLS implementation unless the default behaivior can be changed. Both of the following 

- I suggest limiting this to one.
- I suggest also saying that session tickets SHOULD NOT be sent >BEFORE the client cert is validated.

would not be aligned with OpenSSL default behavior as you described it.

>...
>The Post-Handshake NewSessionTicket message can be sent in the same flight as the TLS server Finished >or later.
>
>  What does it mean if the NewSessionTicket message is sent later?  Is there an impact on the number >of round trips?  What is the RECOMMENDED approach?
>
>  Perhaps the NewSessionTicket message SHOULD be sent in the same EAP packet as the TLS Server F>inished message.  Sending it later adds additional round trips for no benefit.

I would be fine with updating the examples to that the ticket is always send with the same flight as server finished. But this contradics what you said before "session tickets SHOULD NOT be sent >BEFORE the client cert is validated"...

> I would suggest adding text to note the the TLS alerts and close_notify are encrypted by the TLS >layer, and therefore meet the security and privacy requirements of altAccept and altReject of RFC > 4137.

To my knowledge RFC 4137 does not put any security and privacy requirements on altAccept and altReject. The only requirement at all is that RFC 3748 states:

"A method supporting protected result indications MUST indicate which result indications are protected, and which are not."

Protected result indicators are generally not needed for a secure implementation but it has been suggested that they are required for IEEE 802.

---

From: Alan DeKok <[email-masked]>
Date: Sun, 7 Feb 2021 07:04:14 -0500

On Feb 7, 2021, at 6:11 AM, John Mattsson <john.mattsson=[email-masked]> wrote:
> This seem very much like TLS 1.3 details.

  Does EAP-TLS interact with TLS?  (a) yes, in which case this spec should explain how TLS implementation choices affect EAP implementations.  Or (b) no, in which case it doesn't matter.

  As an implementor, some questions are absolutely critical.  e.g. "what do I do when I get 20 session tickets?".  These questions MUST be answered in the draft.  The alternative is an under-specified standard, and implementors doing random things, because the draft is silent.

  I'm quite frankly surprised that this suggestion would be controversial.

> I am not sure that EAP-TLS should answer these question, or that the EMU WG even has the competence. What you want is basically a description of the design choices in TLS 1.3 and guidance that TLS 1.3 itself decided to not give.

  No.

  EAP-TLS is describing a specific application TLS.  As such, it MUST document how it works, how it's implemented, and ideally also deployment considerations.  If this isn't clear to to you, I have to ask why you're authoring the document. These issues are completely fundamental to protocol implementations.

> Have you a conrete example of something this is more important to give guidance about in EAP-TLS 1.3 than in TLS 1.3 in genereal?

  See above.

> Several reviewers the last month suggested the opposite, to completely remove all TLS 1.3 details and only describe the interactions between TLS 1.3 and EAP-TLS 1.3.....

  Does that mean the EAP-TLS spec *won't* discuss how EAP-TLS works?  Because that's what you're saying.

  You're approaching this as a theoretical exercise in getting an RFC number.  I'm approaching it as an implementor who wants to write code that works, is interoperable, and gets users authenticated.

  Having the document be silent on critical issues will be an unmitigated disaster.  Experience with implementing and deploying other protocols shows that where the docs are silent, people make random implementation choices.  These choices lead to confusion, problems with inter-operability, and security vulnerabilities.

> All sentences talking about the message flow figures have been rewritten in a similar way, i.e., "shows an example message flow". TLS 1.3 allows quite a lot of flexibility already now with NewSessi…

  So we're documenting a protocol which can do anything.  Wonderful.

  What should an implementor do?  Anything.

  What should an implementor accept?  Anything.

  Why write documents at all, then?

  As a neutral example of *why* narrow specs are useful, I refer you to ISO 8601, where times can be represented in nearly any format.  To fix this (and make it USEFUL), we have RFC 3339, which specifies ONE format which is easy to implement, and easy to understand.

> I am hesitant to add any recommendations for TLS 1.3 not specifically related to EAP-TLS. These are also things RFC 8446 leaves completely to the implementation.

  Then I suggest following the guidance of implementors who say that these issues are critical for protocol adoption, implementation, inter-operability, and security.

> These are all things that should be handled by the TLS layer. Not sure EAP-TLS should or need to say anything about this. 

  I disagree so strongly that I have to ask why you're authoring this document.

  The TLS layer often does not cache session tickets.  Some applications (e.g. FreeRADIUS) can cache session tickets in a database, in order to address real-world issues like server failure.

  i.e. in high load environments, TLS session tickets can be cached in a clustered database, so that any RADIUS server can resume an EAP-TLS session which was initially authenticated elsewhere.

  Giving guidance to implementors is *critical*.  The contents of the document have real-world implications for cost, ease of deployment, etc.  Simply saying "anything can happen" is just not an option.

> would not be aligned with OpenSSL default behavior as you described it.

   And the problem with that is.... what, exactly?

   When a specification says SHOULD, it means SHOULD.  Implementations can (and will) ignore that, and behave differently.

   You're essentially saying here that you don't want a SHOULD in the document, because one implementation will ignore it.  That is very far from a convincing argument.

> I would be fine with updating the examples to that the ticket is always send with the same flight as server finished. But this contradics what you said before "session tickets SHOULD NOT be sent >B…

  Change that to "the session ticket should be sent with the altSuccess indicator"

  Alan DeKok.