Re: [Perc] AD Evaluation of draft-ietf-perc-srtp-ekt-diet-08

[Ben Campbell <[e-mail]>]

The PR looks good to me. Once submitted with the PR applied,I think this is ready for IETF LC, subject to coordination with the framework and double drafts. Please submit when you are ready.

I do have a few that I do not expect to cause document changes:


> On Oct 9, 2018, at 2:06 PM, Richard Barnes <[e-mail]> wrote:
> 
> Thanks for the review, Ben.  I've posted a PR with responses; notes inline below...
> 
> https://github.com/ietf/perc-wg/pull/161 <https://github.com/ietf/perc-wg/pull/161>
> 

[...]

> 
> - “ The receiver may want to have a sliding window to retain old SRTP
>    Master Keys (and related context) for some brief period of time, so
>    that out of order packets can be processed as well as packets sent
>    during the time keys are changing.”
> 
> See comment to §4.2.2, step 6. “may want” seems weak given that the sender SHOULD keep using the old key for a period of time.
> 
> Revised this as noted above, though note that MAY WISH TO is defined in RFC 6919.

Sure, put a normative reference to RFC 6919 in there. The resulting downref discussion on the telechat should be fun. ;-)

> 
> 
> §4.7: “A new sender SHOULD send a packet containing the FullEKTField as soon as possible...”
> 
> Why not MUST? Would it ever make sense not to do this? It seems like the mechanism doesn’t work very well otherwise.
> 
> How would you comply with a "MUST ... as soon as possible"?  I don't think we want to dictate a schedule here, but I've added a note that packet loss can result if you don’t.

I note that “SHOULD ... as soon as possible” has somewhat the same issue. But adding the note addresses my concern.

[...]
> 
> 
> *** Editorial Comments: ***

[...]

> 
> 
> - Step 6: s/crypto/cryptographic
> 
> Disagree.

Really? I’m not going to push the point, but I’m curious why? Especially since the financial industry is doing it’s best to steal “crypto”. But now I wonder if I’ve missed some subtle difference of definition.

[...]