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

[Alan DeKok <[e-mail]>]

  We're approaching 2 weeks since the last discussion of this topic.  This document has been in development for 3 years.  We desperately need to finish it.  IMHO waiting another 6 months is not an option.  Even 3 would be worrying.

  We have multiple inter-operable implementations which have implemented draft-13.  That work over the last few months have resulted in implementors making plans to do beta testing in the next few weeks.  Those plans have been put on indefinite hold, due to the recent request for changes.

  I understand getting feedback from the TLS WG is useful.  But I would prefer to have consensus on a *solution*. Right now, we just have a series of proposed changes, with little to no discussion.

  We're getting to the point where we have to ship code as promised to customers soon (weeks, not months).  We therefore need consensus, as soon as possible.

  My preference is to implement draft-13.  We know the code works.  People are ready to ship it.  Any changes will add not just more months of standard discussion, but more months of interoperability testing.

  If there is no progress in EMU, we're looking at September for first betas.  With no guarantee that there won't be further changes made after that.

  So the question is:

* are the draft-13 0x00 byte and exporter *terrible* enough to delay the standard another 6 months?

* if the answer is "no", then we can ship now.

* if the answer is 'yes", then the next question is "when can we get this finalized?"  "March" would be late.  "July" is a major problem.

> On Jan 12, 2021, at 10:22 AM, Alan DeKok <[e-mail]> wrote:
> 
> On Jan 11, 2021, at 7:08 PM, Martin Thomson <[e-mail]> wrote:
>> I was not exactly.  I was thinking that EAP-TLS uses the unadorned string and other usages (that need a different MSK) define their own string as needed.
> 
>  Which is largely what was done for <= TLS 1.2.
> 
>  That choice made implementations more difficult.  Not impossible, but annoying.  The other TLS-based EAP types are generally implemented as variants of EAP-TLS.  They re-use much of the EAP-TLS code.  So every difference is more code, and more things to test.
> 
>> Though what you describe would scale more, if the ordinality of that scale is bounded by RFC numbers, defining the extra strings would not be that hard.  You could provide some sort of infrastructure in the form of a recommended label prefix if you are concerned about misuse.
> 
>  I'm not sure EAP-TLS is the place to make recommendations for other EAP types.  There is a draft to deal with other EAP types:
> 
> https://tools.ietf.org/html/draft-dekok-emu-tls-eap-types-00
> 
>  It's pretty trivial.  Adding more complexity is annoying, but not much worse than that.
> 
>  My preference is to remain with the EAP type as the context.  The code is simple, and it's easy to understand.  But if it causes issues with TLS review, we can change it.
> 
>  Alan DeKok.
>