On Sep 1, 2020, at 12:05 PM, John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org> wrote: > > I have reviewed draft-ietf-emu-tls-eap-types-01. Looks good. Two crypto > related comments below: > > - "MAC is the MAC function negotiated in TLS 1.3." > > There is no MAC function negotiated in TLS 1.3. Also, a modern TLS > implementation would not negotiate any MAC funtion in TLS 1.2 as they would > use an AEAD. There is however a cipher suite hash algorithms that is used in > HMAC mode. Maybe something like > > "Compound-MAC = HMAC( CMK, BUFFER ) > > Where HMAC uses the Hash algorithm for the handshake." > > or > > "Compound-MAC = HMAC( CMK, BUFFER ) > > Where the Hash function used by HKDF is the cipher suite hash algorithm"
OK. > This raises the question what TEAP TLS 1.2 implementations do today? Are they > only using outdated and non-secure cipher suites or are they doing something > unspecified to derive Compound-MAC with an AEAD cipher suite? It's not clear. I'd have to double-check hostap, which is the only publicly available TEAP implementation I know of. > Anyway, how to calculate Compound-MAC with an AEAD algorithm needs to be > specified for TLS 1.2 as well. I think the scope of the document need to be > expanded slightly. Or punt on TEAP entirely, and leave it to a TEAP-bis document. > - "For PEAP, some derivation use HMAC-SHA1 [PEAP-MPPE]. There are no > known security issues with HMAC-SHA1. In the interests of > interoperability and minimal changes, we do not change that > definition here." > > While it is true that there are no known practical attacks against HMAC-SHA1, > most modern protocols like TLS 1.3 forbid all uses of SHA-1, governments are > recommending phasing out use of HMAC-SHA1 in e.g. IKEv2, and many buyers of > security equipment thinks that everything with SHA-1 is very weak. To me it > feels strange to force future implementations to continue support of SHA-1 > when it is completely removed from TLS 1.3. Enforcing SHA-256 when TLS 1.3 is > used seems like the easy way forward. It is probably much harder to do at a > later stage. Realistically, PEAP is a vendor-defined protocol. It is not under the change control of the IETF. If the vendor agrees to this change, then it's possible. Otherwise we're stuck with what we have. > Editorials: > > - "in Section Those" > - formatting of the list in section 5 I'll fix that, thanks. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
