There is a TLS working group draft on importing external PSKs for use with
TLS - https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-01.
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?

Thanks,

Joe

On Fri, Sep 20, 2019 at 3:42 AM John Mattsson <john.mattsson=
[email protected]> 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 <[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
>
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu

Reply via email to