Subject: Re: [Emu] Question about draft-ietf-emu-eap-tls13-03 && application data

From: John Mattsson <[email-masked]>
Date: Thu, 31 Jan 2019 16:42:29 +0000

Hi Alan,

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. 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.

/John

---

From: Alan DeKok <[email-masked]>
Date: Thu, 31 Jan 2019 14:52:15 -0500

On Jan 31, 2019, at 11:42 AM, John Mattsson <[email-masked]> wrote:
> 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.