> On 30 Oct 2019, at 06:22, Joseph Salowey <j...@salowey.net> wrote: > > > > On Fri, Oct 11, 2019 at 7:34 AM Eliot Lear <l...@cisco.com > <mailto:l...@cisco.com>> wrote: > > > > On 11 Oct 2019, at 16:09, Michael Richardson <m...@sandelman.ca > > <mailto:m...@sandelman.ca>> 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. > > [Joe] We are currently in a holding pattern with EAP-TLS. It does not seem > right to delay it for functionality that we are not sure we have a use case > for. If a use case develops then we can publish an update to EAP-TLS 1.3. > Do we have a use case for EAP-TLS-PSK that is blocked in the current > situation? >
I would suggest that we do have a well-identified use case, although it has some issues, and that is IoT onboarding for on-prem equipment, as Owen described. I do not know if we will end up executing on that use case, but it is a use case. On the whole, the argument has to go the other way: why should we cripple a particular TLS method without strong justification? The more we specialize the longer it takes to deliver new services, and the harder they are to support. A fair argument, if it can be made, and I am not convinced it has been fully expressed, is the idea that there is no context by which one can separate fast restart and initial authentication. This is Alan’s concern. I’m not saying it’s without merit, but what I cannot yet see is whether it is an implementation or a protocol matter. Eliot > > > Eliot
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
