There is a TLS working group draft on importing external PSKs for use with
This draft can mitigate some of the issues with using external PSKs.

My suggesting is to leave the draft as is and deal with external PSKs as an
update to EAP-TLS 1.3 or as a separate method.

Is the current published version up to date with the rest of the comments?



On Fri, Sep 20, 2019 at 3:42 AM John Mattsson <john.mattsson=> wrote:

> 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 <>
> Date: Wednesday, 18 September 2019 at 15:21
> To: "" <>,
> EMU WG <>
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> Resent from: <>
> Resent to: John Mattsson <>, <>
> 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 mailing list

Reply via email to