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 <[email protected]> Date: Wednesday, 18 September 2019 at 15:21 To: "[email protected]" <[email protected]>, EMU WG <[email protected]> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 Resent from: <[email protected]> Resent to: John Mattsson <[email protected]>, <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/emu
