>[Joe] Moving away from SHA-1 is a good idea as it will only raise questions >moving forward. For TLS 1.3 I think you could use the same text, but I would >look to Jorge to make sure we get it correct for PEAP. TEAP should also use >the Hash from HKDF in TLS 1.3.
I am not a TLS terminology expert so please go with whatever the group thinks is best. If for TEAP we are using "For TLS 1.3 the hash function used is the same as the ciphersuite hash function negotiated for HKDF in the key schedule.", then I’d be fine with something similar for PEAP. Jorge From: Joseph Salowey <j...@salowey.net> Sent: Wednesday, September 2, 2020 8:53 AM To: Alan DeKok <al...@deployingradius.com> Cc: John Mattsson <john.matts...@ericsson.com>; Jorge Vergara <jover...@microsoft.com>; emu@ietf.org Subject: Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-01.txt On Wed, Sep 2, 2020 at 7:54 AM Alan DeKok <al...@deployingradius.com<mailto:al...@deployingradius.com>> wrote: On Sep 2, 2020, at 3:30 AM, John Mattsson <john.matts...@ericsson.com<mailto:john.matts...@ericsson.com>> wrote: >> 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. Yes. Any suggested text? I'm not overly familiar with TLS 1.3, so I don't want to suggest the wrong thing. [Joe] I think you should treat them as 3 distinct cases to make sure it is clear. For TLS 1.3 I like John's second phrasing better as it aligns better with TLS 1.3 terminology: "For TLS 1.3 the hash function used is the same as the ciphersuite hash function negotiated for HKDF in the key schedule." (section 7.1 of 8446) >> 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. Can we use the same hash functions as above? If so, what would the text look like? [Joe] Moving away from SHA-1 is a good idea as it will only raise questions moving forward. For TLS 1.3 I think you could use the same text, but I would look to Jorge to make sure we get it correct for PEAP. TEAP should also use the Hash from HKDF in TLS 1.3. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org<mailto:Emu@ietf.org> https://www.ietf.org/mailman/listinfo/emu<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femu&data=02%7C01%7Cjovergar%40microsoft.com%7Ce9ca671b636744277cb408d84f58487c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346587886062328&sdata=l8ieJEByAeR%2F4Nvmhs0heTW900Gx9Q1i%2BvoF1rDUPII%3D&reserved=0>
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
