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
