Thank you Ben and Jari. The updates will appear shortly int he new version.
Best regards, Kathleen On Sun, Feb 18, 2018 at 12:32 PM, Ben Campbell <b...@nostrum.com> wrote: > Thanks, Jari, this all looks good to me. > > Ben. > >> On Feb 18, 2018, at 5:46 AM, Jari Arkko <jari.ar...@piuha.net> wrote: >> >> Hi Ben, >> >> And thanks for your feedback. >> >>> First bullet point: "or other new concerns." makes this very open ended. Is >>> this planned to be a standing working group? If not, can we put some >>> constraints around "other new concerns”? >> >> Understood. >> >> Note that the sentence starts with “Update the security considerations…” >> so the goal of these updates is about discovering new vulnerabilities and >> the like; not any random other concerns. That being said, the text already >> covers new vulnerabilities, so may be this is merely unnecessary text. >> >> How about the following text: >> >> OLD: >> Update the security >> considerations relating to EAP TLS, to document the implications >> of using new vs. old TLS version, any recently gained new >> knowledge on vulnerabilities, and the possible implications of >> pervasive survellaince or other new concerns. >> >> NEW: >> >> Update the security >> considerations relating to EAP TLS, to document the implications >> of using new vs. old TLS version, any recently gained new >> knowledge on vulnerabilities, and the possible implications of >> pervasive surveillance. >> >> (Also updates a typo.) >> >>> The prohibition against obsoleting RFCs seems harsh. It's possible to >>> require >>> backwards compatibility without this restriction. I think it should be up to >>> the working group to decide whether work can be better organized using >>> updates >>> or bis-drafts. >> >> There was a detailed discussion among the participants about this aspect and >> a reasonable, strong opinion that the current EAP-TLS RFC remain as >> the primary, and that the new RFC would be an update to it when it comes >> to TLS 1.3. >> >> That being said, hmm… even my own draft for EAP-AKA’ bis currently says >> “Obseletes RFC 5448 (if approved”)… so… how about this: >> >> OLD: >> >> The current RFCs shall not be obsoleted but >> rather updated with either new information or instructions on >> what is needed, for instance, to employ a new TLS version. >> >> NEW: >> >> The current EAP-TLS RFCs shall not be obsoleted but >> rather updated with either new information or instructions on >> what is needed, for instance, to employ a new TLS version. >> >>> -3rd paragraph: "And the >>> understanding of security threats in today's Internet evolves as >>> well,..." >>> >>> I suggest dropping “And" >> >> Yes. >> >> For Kathleen’s benefit, listing this in OLD/NEW style: >> >> OLD: >> >> And the >> understanding of security threats in today's Internet evolves as >> well, which has driven some of the evolution in these underlying >> technologies. >> >> NEW: >> >> The >> understanding of security threats in today's Internet evolves as >> well, which has driven some of the evolution in these underlying >> technologies. >> >>> -- 2nd bullet: This is a bit hard to parse. I suggest: >>> >>> OLD: >>> Update the EAP-AKA' specification (RFC 5448) to ensure that its >>> capability to provide a cryptographic binding to network context >>> stays in sync with what updates may come to the referenced 3GPP >>> specifications through the use of EAP in 5G. >>> NEW: >>> Update the EAP-AKA' specification (RFC 5448) to ensure that its >>> capability to provide a cryptographic binding to network context >>> stays in sync with any 5G related updates to the referenced 3GPP >>> specifications. >> >> Seems good. Thanks. >> >>> Same bullet point: The second paragraph seems out of place; was it intended >>> to >>> be its own bullet point? >> >> I don’t have a strong opinion, but the two somewhat separate issues >> were listed under the same bullet item since both of them should >> go into the same draft (rfc5448bis). The EAP TLS bullet item >> does the same thing, i.e., update tech + describe new knowledge >> of vulnerabilities. >> >>> 4th bullet point: The second sentence seems like a non-sequiter. I suggest a >>> top-level bullet point for "Analyzing opportunities to improve privacy..." >> >> I’d be fine with that. Suggested text: >> >> OLD: >> >> - Develop an extension to EAP-AKA' such that Perfect Forward Secrecy >> can be provided. There may also be privacy improvements that >> have become feasible with the introduction of recent identity >> privacy improvements in 3GPP networks. >> >> NEW: >> >> - Analysing opportunities to improve privacy in EAP-AKA’. >> >> Develop an extension to EAP-AKA' such that Perfect Forward Secrecy >> can be provided. >> >> There may also be other privacy improvements that >> have become feasible with the introduction of recent identity >> privacy improvements in 3GPP networks. >> >> Jari >> > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > -- Best regards, Kathleen _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
