>>> 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. > I can tell you what Windows is doing for TLS 1.2; and Windows interops with > all the TEAP implementations that I know of, so others are likely doing the > same. We're using the MAC function in the case of a CBC block cipher suite, > or PRF hash function in the case of an AEAD cipher suite. Yes, it's > unspecified, but I believe most TLS libraries abstracts the difference away, > so it went unnoticed. I imagine it may have gone unnoticed by other > implementations as well. Should we document this behavior for TLS 1.2 in the draft? I.e. the PRF hash function in HMAC mode for AEAD cipher suites and the MAC function for non-AEAD cipher suites. >> 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. > We agree to changes in this area to the extent that WG feels they are > necessary. I don't have the cryptanalysis background to weight heavily in on > what the right thing to do is, but have no objection to moving away from SHA1. > Rather than locking in another dependency such as SHA256, I wonder if this > calculation should also use a hash function derived from the TLS handshake? That is a much better idea! It is not necessary to update any TEAP TLS 1.2 code, but it definitely feels like a worthwhile thing to do when the implementation is anyway updated for TLS 1.3. -----Original Message----- From: Emu <emu-boun...@ietf.org> On Behalf Of Alan DeKok Sent: Tuesday, September 1, 2020 1:59 PM To: John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org> Cc: emu@ietf.org Subject: Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-01.txt 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://protect2.fireeye.com/v1/url?k=1e1c2e57-40bcec12-1e1c6ecc-8692dc8284cb-890ef1f2fc081407&q=1&e=b42cb8cd-b2ad-4018-b532-f8328271bffc&u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fwww.ietf.org%252Fmailman%252Flistinfo%252Femu%26amp%3Bdata%3D02%257C01%257Cjovergar%2540microsoft.com%257C3beed6d0ea854ee4414c08d84eb9eec0%257C72f988bf86f141af91ab2d7cd011db47%257C1%257C0%257C637345907781097079%26amp%3Bsdata%3D%252Bs%252FarBWgPHSNgKG8rbLN0kB2hbr77aYRP35L9O2rgZc%253D%26amp%3Breserved%3D0 _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
