Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

[Eliot Lear <[e-mail]>]

Hi Joe,

> On 7 Oct 2019, at 02:42, Joseph Salowey <[e-mail]> wrote:
> 
> 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 <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.


Before we nail this down, it seems like we need to have a discussion about how best to onboard wired IoT devices in particular from an on-prem view.  The issue here is that EAP-TLS-PSK is useful for that purpose, as we discussed.  Now there is nothing particularly special about PSK and we could run with a naked public key pair as well in 1.3, but we have to choose something.  The fundamental question is what does a manufacturer stamp into the device and what is placed on a label.  We have a running example of DPP doing this for wireless with public key code, but that doesn’t get us to proper onboarding for wired – the signaling just isn’t there.

Also, maybe it’s me, but I remain uncomfortable about this group constraining TLS 1.3.

Eliot

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