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 >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
