Hi Alan, I added references to RFC 8446 Section 8.1, and 8.2, and 4.2.11. Agree that they are good to point out.
I am not sure about the other suggestions, I am hesitant to discuss anything detailed about TLS 1.3 that does not have a specific connection to EAP-TLS or are useful for users of EAP-TLS. My feeling is that adding some extension, but not other would be even more confusing. The diagrams are there to show the message flows, which have a strong connection to the EAP state machine. For other details I think implementors have to read RFC 8466. /John -----Original Message----- From: Alan DeKok <al...@deployingradius.com> Date: Wednesday, 18 September 2019 at 15:21 To: "draft-ietf-emu-eap-tl...@ietf.org" <draft-ietf-emu-eap-tl...@ietf.org>, EMU WG <email@example.com> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 Resent from: <alias-boun...@ietf.org> Resent to: John Mattsson <john.matts...@ericsson.com>, <mo...@piuha.net> Resent date: Wednesday, 18 September 2019 at 15:21 Just re-reading the text on PSK, I noticed a few things. The text in Section 2.1.2 talks about PSK, the session ticket, and a "key_share" extension. The accompanying diagram doesn't include any of those. I suggest updating the diagram to include them. As a related note, if the PSK *is* in the resumption cache, but the key is wrong, the cache entry should not be discarded. Otherwise an attacker can disable caching for *all* users. This issue could be clearer in this document. Perhaps it would be useful to add a short note in Section 5 about security of resumption. It should reference RFC 8446 Section 8.1, and 8.2, which discuss this issue. Also, Section 4.2.11 of that document has an "Implementor's note:" which is important. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu