Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Jorge Vergara <[e-mail]>]

> We need to get agreement on how to proceed here asap. I would like implementors and security AD to agree on the way forward before submitting -14. Four ways forward:
> 
> A. Add (1) and (2)
> B. Only add (1)
> C. Only add (2)
> D. Do not add (1) or (2)

My preference is D.

> Do we need to have a telephone meeting to discuss these things? We cannot have a formal interim meeting as that formally takes weeks to setup. This can also not wait until the next IETF. As soon as we agree on a way forward we can update and submit a new version within 24 h.

Totally open to this.

Jorge Vergara

-----Original Message-----
From: Alan DeKok <[e-mail]> 
Sent: Friday, January 29, 2021 5:10 AM
To: John Mattsson <[e-mail]>
Cc: Jorge Vergara <[e-mail]>; Martin Thomson <[e-mail]>; Benjamin Kaduk <[e-mail]>; Roman Danyliw <[e-mail]>; <[e-mail]> <[e-mail]>; EMU WG <[e-mail]>
Subject: Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

On Jan 29, 2021, at 5:31 AM, John Mattsson <[e-mail]> wrote:
> 
> I can live with any version, the important thing is that interoperable implementations get shipped ASAP. This is important also for 3GPP as EAP-TLS 1.3 is mandatory to support in 3GPP Rel-16 if EAP-TLS is supported.

  Then our choices are:

a) draft-13 in February.  There are multiple interoperable implementations, including Microsoft, FreeRADIUS, and hostap / wpa_supplicant.

b) ??? in 2021.

> The close_notity changes are not only positive as it sometimes introduce an additional roundtrip. The Commitment message can according to specification be sent with the server Finish even if some/most/all implementation does not seem to allow this. If the commitment message cannot be send with Finished in practice there is no difference in latency. Still a bit sad how poorly TLS 1.3 and EAP interacts.

  The TLS implementations largely assume that TLS is being used (a) over TCP, and (b) to exchange application data.  These assumptions *severely* limit the choices available for implementors of EAP-TLS.

  We can verify these assumptions by simply noting that many TLS implementations include native support for TLS over TCP.  While there have been assertions that TLS libraries also implement EAP, those assertions seem to be firmly outside of the bounds of reality.

> We need to get agreement on how to proceed here asap. I would like implementors and security AD to agree on the way forward before submitting -14. Four ways forward:
> 
> A. Add (1) and (2)
> B. Only add (1)
> C. Only add (2)
> D. Do not add (1) or (2)

  My strong preference is (D).

> I assume implementors (Alan, Jorge) are fine with all other changes since -13.

  Yes,

> Do we need to have a telephone meeting to discuss these things? We cannot have a formal interim meeting as that formally takes weeks to setup. This can also not wait until the next IETF. As soon as we agree on a way forward we can update and submit a new version within 24 h.

  TBH, implementors have already had multiple informal discussions and calls.  One more wouldn't make much difference.

  Alan DeKok