On Jan 31, 2019, at 11:42 AM, John Mattsson <john.matts...@ericsson.com> wrote: > > The mentioned requirement comes from Section 2.4 of RFC 5216, which states > that: > > "Since the ciphersuite negotiated within EAP-TLS applies only to the EAP > conversation, TLS ciphersuite negotiation MUST NOT be used to negotiate the > ciphersuites used to secure data." > > However, I do not really understand why such a requirement would be needed.
I'm not even sure what that phrase means. Secure *what* data? The only data in question is the EAP conversation. Which is what the cipher suite negotiation protects. > For instance, QUIC uses the TLS 1.3 handshake ciphersuite negotiation to > negotiate the algorithms used in QUIC. If this is a problem, we should > discuss if any updates are needed. I would expect that TLS negotiates cipher suites, and then uses those suites to exchange application data. Which is what we need here for other EAP types. And which is what I believe is what we already have. My $0.02 would be to figure out what that phrase in RFC 5216 means. I suspect it *doesn't* mean that TLS 1.3 can be used to negotiate the handshake, but then application data shouldn't be protected by TLS? That doesn't make sense... I'll also note that RC 5216 Section 2.4 mentions mandatory to implement ciphers, and this draft doesn't. It might be worth adding that, or adding a note referencing an appropriate section of RFC 8446. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
