Hi Joe,

> On 7 Oct 2019, at 02:42, Joseph Salowey <j...@salowey.net> 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.


> 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=40ericsson....@dmarc.ietf.org 
> <mailto:40ericsson....@dmarc.ietf.org>> 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 <al...@deployingradius.com 
> <mailto:al...@deployingradius.com>>
> Date: Wednesday, 18 September 2019 at 15:21
> To: "draft-ietf-emu-eap-tl...@ietf.org 
> <mailto:draft-ietf-emu-eap-tl...@ietf.org>" 
> <draft-ietf-emu-eap-tl...@ietf.org 
> <mailto:draft-ietf-emu-eap-tl...@ietf.org>>, EMU WG <emu@ietf.org 
> <mailto:emu@ietf.org>>
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> Resent from: <alias-boun...@ietf.org <mailto:alias-boun...@ietf.org>>
> Resent to: John Mattsson <john.matts...@ericsson.com 
> <mailto:john.matts...@ericsson.com>>, <mo...@piuha.net 
> <mailto: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 <mailto:Emu@ietf.org>
> https://www.ietf.org/mailman/listinfo/emu 
> <https://www.ietf.org/mailman/listinfo/emu>
> _______________________________________________
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu

Attachment: signature.asc
Description: Message signed with OpenPGP

Emu mailing list

Reply via email to