On Fri, Jan 29, 2021 at 11:34 AM Mohit Sethi M <mohit.m.sethi= 40ericsson....@dmarc.ietf.org> wrote:
> 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 > [Joe] If this implements the derivation RFC 5216. It's not clear that function will give you the right output with TLS 1.3 since we are now using exporters. Perhaps they provide an exporter interface which should be used instead. Personally, I think including the method byte in the context is a bit less error prone and straight forward then including it in the label. > > 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 <al...@deployingradius.com> > <al...@deployingradius.com> wrote: > > On Jan 11, 2021, at 7:08 PM, Martin Thomson <m...@lowentropy.net> > <m...@lowentropy.net> 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 > listTLS@ietf.orghttps://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!BN9rm7SoWGOKFjfY7fFgpHjeV58wJeRS31O8qeE3B4tZbNy-zWi1yMwitxxMCA$ > > _______________________________________________ > Emu mailing listEmu@ietf.orghttps://www.ietf.org/mailman/listinfo/emu > > _______________________________________________ > Emu mailing list > e...@ietf.org > https://www.ietf.org/mailman/listinfo/emu >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
