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 <emu@ietf.org>
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
