(trimming down the CC list to EMU) > On Dec 1, 2017, at 8:16 AM, John Mattsson <john.matts...@ericsson.com> wrote: > > If RFC5216 actually said that it would be less of a problem, but RFC5216 has > a large amount of normative terminology that is correct for TLS 1.0 - 1.2, > but wrong for TLS 1.3.
Then the suggestion would be to write a document "EAP-TLS with TLS 1.3", that updates RFC 5216. The concern was (again), that the proposal was to *obsolete* 5216, and *replace* it with a mandate to use TLS 1.3. That's just not going to happen. > Yes, procedural aspects seem to be a large concern, but “obsolete” does not > forbid anyone from using EAP-TLS with TLS 1.0. The proposal mandated TLS 1.3. That *would* forbid usage of TLS 1.0. i.e. 5216 has MUST language which is now inappropriate for TLS 1.3, the proposal had MUST language which was inappropriate for TLS 1.0, 1.1, and 1.2. > E.g. TLS 1.3 obsoletes TLS 1.2, which obsoletes TLS 1.1 etc. but that does > not mean that people are forbidden to use TLS 1.2. If fact TLS provides a > versioning mechanism and the TLS working group is even planning TLS 1.2 > Long-term support. That said, I am perfectly fine with “update” if that is > what the mailing list wants, I will change "obsolete" to "update" in the -01 > version, and make it clear that in the text that the update is still > compatible with RFC5216 using TLS 1.0. If you're *adding* language which shows how to use TLS 1.3 with EAP-TLS, then the correct process is to "update" 5216. And the best way to do that is to just have a proposal describing how to use EAP-TLS with TLS 1.3. There's no need to change copy 5216 and edit it. You can just reference 5216, and describe the *differences* for TLS 1.3. > RFC5216, Section 2.5 defines that MSK, EMSK, and IV is derived with the > TLS-PRF, which is the right way to do it in TLS 1.0, TLS 1.1, TLS 1.2. TLS > 1.3 replaces the PRF with HKDF, thus requiring a new construction. How would > someone trying to implement TLS 1.3 with RFC5216 derive the keys? That's what standards are for... > I hope that the details above illustrate why I think an short document > describing how to use EAP-TLS with TLS 1.3 is needed. Which is why I was confused that the proposal *replaced* 5216 in it's entirety, and said that implementations MUST support TLS 1.3. > I will update the document aligning with the comments received: > > - "update" instead of "obsolete" and also making clear that an implamentation > following the document is still compatible with EAP-TLS with TLS 1.0 (up to > the application to decide). This means that the EAP-TLS with TLS 1.3 document > can be shorter totally avoiding overlap with RFC5216, only describing any > difference when usign TLS 1.3. > > - Highlight which parts relevant for EAP-TLS that changes in TLS 1.3 and why > an update is needed. > > - Add information on how Key_Material and IV is derived when using EAP-TLS > with TLS 1.3. Refering to RFC5216 for to get MSK, EMSK, etc, from > Keying_Material. That's the best approach. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
