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

[Mohit Sethi M <[e-mail]>]

Hi Ben,

On 1/29/21 8:32 PM, Benjamin Kaduk wrote:

Hi Alan,

I see that the thread is continuing and that perhaps my reply will even
become stale as I write it, but I'm replying to your note instead of the
tip of the thread because it has good context for making some broader
points that I would like to make.

On Sat, Jan 23, 2021 at 05:28:10PM -0500, Alan DeKok wrote:


  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.



My understanding of the discussions involving the TLS WG are that we forked
off into two sub-threads: one about the use of TLS Exporters for key
derivation (the one this is a reply to), that largely concluded with
agreement on a simple change to make, and the other sub-thread about the
protocol element known in -13 as the "commitment message".

With respect to the exporter usage, I do see you had asked about using the
type-code as the exporter context value that Martin didn't see much value
in, but I am willing to accept that as a boon for safety of portability to
other TLS-using EAP mechanisms.  (I do note that the current editor's copy
shows calls to TLS-Exporter() with only two arguments, but three are
required; the construction there also seems to include a propspect for
violation of the requirement that "one label is not a prefix of any other
label" when both regular one-byte and extended type codes are used, but if
the type code is meant to be the context argument I believe that risk goes
away.)

RFC 5705 says:

   If no context is provided, it then computes:

           PRF(SecurityParameters.master_secret, label,
               SecurityParameters.client_random +
               SecurityParameters.server_random
               )[length]

   If context is provided, it computes:

           PRF(SecurityParameters.master_secret, label,
               SecurityParameters.client_random +
               SecurityParameters.server_random +
               context_value_length + context_value
               )[length]


We use only two arguments and say "No context data is used in the TLS exporter interface.". We could show the context argument as empty in the calls to make things clearer. By the way, this is what is done by TEAP also. RFC 7170 says "TEAPv1 makes use of the TLS Keying Material Exporters defined in [RFC5705] to derive the session_key_seed.  The label used in the derivation is "EXPORTER: teap session key seed".  The length of the session key seed material is 40 octets.  No context data is used in the export process."

The change of moving the type-code from the context to the label was made based on your review (comments from Martin) and the fact that some libraries such as wolfssl don't support passing a context (so far). See: https://w1.fi/cgit/hostap/tree/src/crypto/tls_wolfssl.c#n1996



With respect to the "commitment message", I thought we had a discussion
that revealed that the mechanism in the -13 could not fulfil its stated
purpose, and that also called into question whether that stated purpose was
actually the right thing that the protocol needed.  My understanding,
therefore, was that the TLS WG could not contribute further insight until
there was a revised proposal from people who understand the needs of the
EAP-TLS protocol from TLS that would both satisfy the needs of EAP and
actually be achievable.



  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.



I think this is becaues the TLS WG members (in aggregate) do not have a
clear picture of what property or properties EAP-TLS will require from TLS
that led to the need for an additional message when using TLS 1.3 as
opposed to the RFC 5216 case with TLS 1.2.  The prospect of an
"authenticated signal from TLS to EAP-TLS that the authentication completed
successfully" was mentioned, but I did not have the sense that there was
universal agreement of that as the sole relevant property.

I think there was a misunderstanding that an authenticated signal of authentication completed was needed. Only a signal of no more post handshake messages was needed. I think Alan's summary might also explain the situation better.

--Mohit





  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?



Well, the text of the -13 contains a protocol mechanism that cannot deliver
its stated purpose, so I will continue to hold a Discuss position if that
remains.  One Discuss ballot does not have to block the work indefinitely
(the shepherding AD can request a different IESG balloting procedure be
used), and I leave it between the WG and Roman whether to attempt that
route.  It is perhaps possible that (as John noted downthread) the text
about the commitment message was badly written, and that just changing the
surrounding description could work, but that gets back to the question I
mentioned above of what properties EAP-TLS actually requires from TLS.

-Ben



* 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]><mailto:[e-mail]> wrote:

On Jan 11, 2021, at 7:08 PM, Martin Thomson <[e-mail]><mailto:[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://urldefense.com/v3/__https://tools.ietf.org/html/draft-dekok-emu-tls-eap-types-00__;!!GjvTz_vk!BN9rm7SoWGOKFjfY7fFgpHjeV58wJeRS31O8qeE3B4tZbNy-zWi1yMwNRryTgg$

 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.




_______________________________________________
TLS mailing list
[e-mail]<mailto:[e-mail]>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!BN9rm7SoWGOKFjfY7fFgpHjeV58wJeRS31O8qeE3B4tZbNy-zWi1yMwitxxMCA$



_______________________________________________
Emu mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/emu