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.


-----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

Reply via email to