On Feb 6, 2021, at 12:33 AM, John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org> wrote: > I made several updates to the text based on your comments.
I'll go through GitHub to figure out what those were... > 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. OK, that's good. > All message flows are correct. There is no single way how TLS 1.3 works. It > is completely up to the implementation. The server can send 0 or 20 tickets. > It can send them together with the server Finished, or in one or more > separate flights. 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. > I updated the draft to make it clear that all the message flows are examples. > Some of the figure texts appeared like there was only one way the message > flow could look like, which is basically never the case in TLS 1.3. > > I removed the text in the draft on pre-computation of PSK. That is covered in > RFC 8446. I added text stating that the NewSessionTicket can be sent with the > server Finished or later so that does not come as a suprise. > > I updated the resumption to send the NewSessionTicket together with Finished. > The draft now gives examples of NewSessionTicket in the first server flight > and NewSessionTicket in the second server flight. I have some minor feedback, mostly nits: ... In the case where EAP-TLS server authentication is unsuccessful and the EAP-TLS peer sends a TLS Error alert, the conversation will appear as shown in 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? I recognize that the "will appear" text is taken from RFC 5216 and therefore isn't new. But given the discussion in the working group, some additional explanation would help implementors. Further, there are significantly more variants of TLS 1.3 flows than for TLS 1.2. 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. ... 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. ... 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 Finished message. Sending it later adds additional round trips for no benefit. ... decscribed in <xref target="RFC3748"/> and Section 5.5 of <xref target="RFC5216"/>, the only information that is integrity and replay protected in EAP-TLS are the parts of the TLS Data that TLS protects Typo: "described" 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. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
