Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
I am aware that Openssl has support for external PSK. The Selfie attack was demonstrated using this Openssl implementation: https://eprint.iacr.org/2019/347 However, the github issue you posted is still helpful. If I understand the resolution of this issue: Openssl will first check for a valid external PSK before checking for resumption PSKs. I think we can include EAP-TLS-PSK without major changes to the current document. I only want to ensure that EAP-TLS-PSK does not leave any implementation ambiguities. --Mohit On 10/10/19 7:18 PM, John Mattsson wrote: > Mohit Sethi M mailto:mohit.m.se...@ericsson.com wrote: > >> Can you give an example of an existing TLS 1.3 deployment that offers both >> resumption PSKs and external PSKs? > Don’t know if it is deployed anywhere, but OpenSSL supports resumption of PSK > sessions. There was a bug that stopped it from working that was patched 12 > months ago. > https://github.com/openssl/openssl/issues/7433 > > > ___ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> On 11 Oct 2019, at 16:09, Michael Richardson wrote: > > So, can wired just be a degenerate version of wifi, where there can be only > one "ESSID", and there are no beacons to consider? On the whole that has been my thought. But it is a matter of which mechanism to degenerate to. Is it TLS-PSK? eDPP++? TLS with naked public keys++? And again, this is the on-prem case. For cloud, we are well along. Eliot signature.asc Description: Message signed with OpenPGP ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Eliot Lear wrote: >> Eliot Lear wrote: >>> 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. >> >> okay, so why do you prefer PSK? > I do not. But we need to have *a* flow for on prem onboarding. > TLS-PSK is one approach, but there are others. I just want a > discussion before we nail this down, as I wrote. >> >>> 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. >> >> I don't understand this. Are you saying that because it's wired, >> people do not expect to scan anything? > No quite the opposite- I’m saying that there is at least one way to do > this with Wifi, but no way to do this for wired right now, an we need > one. So, can wired just be a degenerate version of wifi, where there can be only one "ESSID", and there are no beacons to consider? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> On 11 Oct 2019, at 13:04, Michael Richardson wrote: > > > Eliot Lear wrote: >> 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. > > okay, so why do you prefer PSK? I do not. But we need to have *a* flow for on prem onboarding. TLS-PSK is one approach, but there are others. I just want a discussion before we nail this down, as I wrote. > >> 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. > > I don't understand this. > Are you saying that because it's wired, people do not expect to scan > anything? No quite the opposite- I’m saying that there is at least one way to do this with Wifi, but no way to do this for wired right now, an we need one. Eliot > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works| network architect [ > ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails > [ > signature.asc Description: Message signed with OpenPGP ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Eliot Lear wrote: > 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. okay, so why do you prefer PSK? > 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. I don't understand this. Are you saying that because it's wired, people do not expect to scan anything? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
