On Jun 13, 2022, at 3:57 PM, Russ Housley <[email protected]> wrote: > > Major concerns: > > Section 3, 3rd para: It is unclear to me what "relevant resumption and/or EAP > type" means. Please expand this discussion.
In context: As a result, implementations MUST check for application data once the TLS session has been established. This check MUST be performed before proceeding with another round trip of TLS negotiation. If application data is available, it MUST be processed according to the relevant resumption and/or EAP type. The intent here is to say "if there's application data, just use that". I think the reference to "resumption" is superfluous, and can be removed or clarified. Perhaps: As a result, implementations MUST check for application data once the TLS session has been established. This check MUST be performed before proceeding with another round trip of TLS negotiation. If application data is received by the EAP peer, any session tickets offered by the supplicant MUST be ignored, and resumption MUST NOT take place. The interpretation and processing of application data is dependent on the EAP type which has been negotiated. On receiving application data, an EAP implementation MUST follow the relevant specification (defined by the EAP type) for processing that application data. We didn't need similar text for TTLS / PEAP / FAST, because application data was always interpreted as that particular EAP type. We need some clarifying text here, because we're talking about TLS-based EAP types in general, and not any specific type. I'm not sure how to clarify this any more, otherwise than by deleting the text. > Minor concerns: > > Section 2 says: > > There remain some differences between EAP-TLS and other TLS-based EAP > methods which necessitates this document. The main difference is > that [RFC9190] uses the EAP-TLS Type (value 0x0D) in a number of > calculations, whereas other method types will use their own Type > value instead of the EAP-TLS Type value. This topic is discussed > further below in Section 2. > > I assume this should be a forward pointer to Section 2.1. Sure. > Section 2.1 uses || to indicate concatenation, but Section 2.2 uses |. > Please pick one. RFC 9190 uses ||, so we'll stick with that. The text in Section 2.2 was lifted from RFC 7170, which uses | > > Section 2.1 says: > > ... There does not > appear to be compelling reasons to make the labels method-specific, > when they can just include the logical Type in the key derivation. > > I think it would be more clear to say that the inclusion of the logical Type > makes the result method-specific. OK. I'll update the text. > > Nit: The author on the title page should be "A. DeKok" Fixed, thanks. Alan DeKok. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
