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

[Ben Campbell <[e-mail]>]

Oops, missed a comment: Can we get an updated address and affiliation for Dan Wing?

Thanks!

Ben.

> On Aug 9, 2018, at 5:28 PM, Ben Campbell <[e-mail]> wrote:
> 
> Hi,
> 
> This is my AD Evaluation of draft-ietf-perc-srtp-ekt-diet-08.
> 
> The document is mostly in good shape. It’s easy to read and understand. However, I have a few substantive comments/questions and some editorial comments. I would like to at least discuss the substantive comments before going to IETF LC.
> 
> Thanks!
> 
> Ben.
> 
> ----------
> 
> *** Substantive Comments: ***
> 
> 
> §3: Is there a reason not to use the RFC 8174 boilerplate? There are at least a few instances of lowercase keywords in places that don’t seem intended as normative.
> 
> §4.2.1, first paragraph: Is there never a situation where you send neither version?  Also, did I miss a description of the purpose and semantics for ShortEKTField, other than “send it when you don’t send the full version”?
> 
> §4.2.2, step 3: "If the EKT decryption operation returns an authentication failure, then the packet processing stops.”
> 
> ... and then what?
> 
> - Step 6: "This applies in transforms such as [ I-D.ietf-perc-double] for replacing just half the key, but SHOULD return a processing error otherwise.”
> 
> I don’t understand that sentence. Is the point to say that using a “too short” key to replace part of the old key is only valid for perc-double or similar transforms, and receiving one in other contexts is an error?
> 
> - Next Sentence: "Outbound packets SHOULD continue to use the old SRTP Master Key for 250 ms after” Does that imply a normative requirement for recipients to keep old keys around for at least that long? There’s currently an implementation suggestion about that, but it doesn’t use MUST or SHOULD.
> (Editorial: The sentence seems to belong in the “outbound” section, not the “inbound” section.)
> 
> §4.3:
> 
> - “ This ciphertext value MAY be cached by an SRTP
>   receiver to minimize computational effort by noting when the SRTP
>   master key is unchanged and avoiding repeating the steps defined in .”
> 
> Are we really talking about the recipient? How would the recipient know that the key has not changed without processing the ciphertext value? (Also, the sentence is unfinished--maybe the answer would be clear if the rest of the sentence came out of hiding :-) )
> 
> - “ 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.
> 
> §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.
> 
> §6, first paragraph: “or other” - what other?
> 
> - paragraph 8: “ An endpoint MUST NOT encrypt more than T different FullEKTField values using the same EKTKey.”
> 
> Is there a reciprocal requirement for decryption?
> 
> - last paragraph: “...SHOULD be limited using the ekt_ttl”
> 
> Why not MUST?
> 
> §7.3: Should this cite RFC 5246 instead of RFC 4366?
> 
> *** Editorial Comments: ***
> 
> §2: “...each endpoint picks there own SRTP master key...:
> s/their/its
> 
> §4.1, first paragraph: Please reference figures by number. I can imagine some future RFC rendering failing to  maintain the relative positions.  (This occurs a few times throughout the document.)
> 
> §4.2.2, step 3:
> Should "The EKTCiphertext authentication is checked and is decrypted” be something like “
> The EKTCiphertext field authentication is checked and its contents decrypted” I assume you don’t mean to say its authentication is decrypted.
> 
> Also, there’s a number of occurrences of “The [fieldname]...” that should probably say “The [fieldname] field...”
> 
> - Step 6: s/crypto/cryptographic
> 
> - Step 7: is the replay protection part relevant to the step?
> 
> §4.3, third paragraph: This is the first mention of ekt_ttl. It would help to have a brief explanation or at least a forward reference.
> 
> §4.6: s/ “other specification” / “another specification” ; or “other specifications”
> 
> §4.7, third paragraph: Both occurrences of “which” need preceding commas.
> 
> §5.2, paragraph after figure 4: “ ... the extensions defined in this session allows the DTLS server...”
> Defined in this “session” or this “section”?
> 
> §, paragraph 7: “... causing the receiving system will decrypt...”
> s/will/to
> 
> 
> 
>