> 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

Attachment: signature.asc
Description: Message signed with OpenPGP

Emu mailing list

Reply via email to