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. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
