Hi, Thanks Joe for making such very clear and concrete issues on GitHub!
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues I have made a single PR addressing all the currently listed issues in the way suggested by Joe. https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/83/files - Does PR #83 address the currently listed issues? - Are there any other remaining issues that are not listed on GitHub? Cheers, John From: Emu <emu-boun...@ietf.org> on behalf of Alan DeKok <al...@deployingradius.com> Date: Monday, 14 June 2021 at 02:22 To: Joseph Salowey <j...@salowey.net>, EMU WG <emu@ietf.org> Subject: Re: [Emu] draft-ietf-emu-eap-tls13-16.txt On Jun 13, 2021, at 7:49 PM, Joseph Salowey <j...@salowey.net> wrote: > [Joe] The existing text already refers to relying on the underlying TLS > version negotiation. Yes. I was trying to address the confusion between version negotiation and other handshake negotiation. > [Joe] I don't see a problem with covering new TLS handshake messages in the > document, however they are covered somewhat inconsistently. Perhaps we > should cover them all in a "new handshake messages section". My point was that if the EAP layer doesn't need to do anything with those new handshake messages, then there isn't a need to mention them in the specification. > TLS 1.3 introduces several new handshake messages including > HelloRetryRequest, NewSessionTicket, KeyUpdate. In general, these messages > will be handled by the underlying TLS libraries and are not visible to > EAP-TLS, however there are a few things to note. > > The HelloRetryRequest is used by the server to reject the parameters offered > in the ClientHello and suggest new parameters. When this message is > encountered it will increase the number of round trips used by the protocol. If that's the only change, then I would suggest there's no need for a section dedicated to HelloRetryRequest. Perhaps just saying "there are a number of new messages in TLS 1.3 which affect round trips, but the EAP layer doesn't have to do anything other than exchange more TLS messages". > [Joe] OK how about adding: > > "An example of limiting network access would be to invoke a vendor's walled > garden or quarantine network functionality." Sounds good. > >> I don't understand why it's necessary to include discussion of TLS > >> negotiation in EAP, when that negotiation does not affect EAP in any way. > > See above. > > In short: TLS version negotiation does affect EAP-TLS. HelloRetryRequest > messages do not. > > [Joe] The EAP TLS layer needs to know which TLS version was negotiated. > HelloRetryRequests affect the number of round trips in the exchange, but are > opaque with respect to EAP-TLS. Yes. I was confused at Section 2.1.6. which essentially says "HelloRetryRequest is a new TLS message, here's a diagram of using it with EAP-TLS". As an implementor, the immediate question is "What do I *do* with this message?" and the answer is essentially "nothing". Pretty much every other section in the document says "this is new in TLS 1.3, and here's how to handle it". > [Joe] HelloRetryRequest is a feature of the underlying TLS library so the > RFC8446 Should determine the underlying behavior, specifying a different > behavior is problematic. Sure. > >> The updated text is clearer, but still does not address some of the > >> questions raised below about calling this out as a new requirement from > >> 5216, and what happens in an HA environment. > > Please let us know a good reference to "implementation and > > interoperability experience." about the upper limit on EAP packet > > exchanges. This would also be useful for draft-ietf-emu-eaptlscert. > > I posted references on this list previously: > > https://mailarchive.ietf.org/arch/browse/emu/?qdr=y > > [Joe] I think this is the wrong link. Yes. The new mail archive interface is substantially worse than the older "mailman" interface. It's difficult to follow threads, quickly search by dates, etc. In any case, this is the previous message: https://mailarchive.ietf.org/arch/msg/emu/y3d6KGFeImAeSLEqF6XqVMev2Zc/ > >>> Requiring a supplicant to be configured with a peer name is a new > >>> requirement from RFC 5216, and isn't called out as such. > > I agree with you that we could benefit from more clarification on > > relationship between section 2.2 and 5.2 of this draft vs. the old RFC > > 5216. Do you have a suggestion how best to split the text and reflect > > the updates to RFC5216? > > Updating 2.2 with a note after the text on page 18 seems best: > > While this requirement to verify domain names is new, and was not mentioned > in [RFC5216], it has been widely implemented in EAP peers. As such, we > believe that this section contains minimal new interoperability or > implementation requirements on EAP peers. > > [Joe] This does not seem to add to the specification. I agree that text doesn't add any new requirements to the specification. However, it's useful to make a note for implementors that while Section 2.2. is officially a new requirement in theory, there is little to do in practice, because implementations already meet these requirements. There has been similar text in many other specifications. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
