On Jan 29, 2021, at 1:32 PM, Benjamin Kaduk <ka...@mit.edu> wrote: > 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.
OK. > (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.) The EAP type codes are one octet: 0x00 through 0xfd. The "expanded" type codes begin with 0xfe. So there is no prefix issue, even if the type codes form part of the label. That being said, using them as the context is preferred, I think. > 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. I'm less sure. There was a lot of discussion around a lot of things. Part of the issue seems to be that bits of the TLS state machine are underspecified so far as the EAP needs go. i.e. when Z happens, is A guaranteed to have happened before that? RFC 8446 is not clear. > 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. The issue is in part due to API limitations in OpenSSL. I will send a separate message summarizing the issues. > 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. I've had some further discussions and will send a separate message summarizing the issues. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
