Reviewer: Sean Turner
Review result: Has Nits
Hi! Thanks for the well written draft. I really liked Appendix B that includes
the tried but discarded designs.
Issue worth discussing (and it might be a short discussion):
Are there any instructions that the DEs needs to make sure that this registry
is not populated with PQ-wanna-be Transforms? E.g., I show up my shiny new (and
supposedly) PQ resistant alg and the DE says ....
Nits:
The use of “we” is a style thing that I would change, but if the WG/IESG are
good with it I can get on board too.
s1.2, last para: “require such a requirement” is a bit awkward. How about “have
such a requirement” or “levy such a requirement”?
s2, hybrid: I think you might want to include some words by what you mean by
“hybrid”? Maybe as simple as copy some of the text from the 1st para of s3.1
forward, “when multiple key exchanges are performed and the calculated shared
key depends on all of them”.
s3.1, s/Note that with this semantics,/Note that with these semantics,
s4.1:
s/must/MUST in the DE instructions?
s/addition,any/addition, any
s5:
s/dwarfed/ with thwart or mitigate
s/the data need to remain/the data needs to remain
A.1:
s/as follows/as follows.
s/SKEYSEED(1) …. )./SKEYSEED(1) … )
s/{SK_d(1) … SPIr)./{SK_d(1) … SPIr)
Is this missing:
The updated SKEYSEED value is then used to derive the following
keying materials
between these two lines:
SKEYSEED(2) = prf(SK_d(1), SK(2) | Ni | Nr)
{SK_d(2) | SK_ai(2) | SK_ar(2) | SK_ei(2) | SK_er(2) | SK_pi(2) |
SK_pr(2)} = prf+ (SKEYSEED(2), Ni | Nr | SPIi | SPIr)
A.4:s/a security association/an IKE SA
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
