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

[Ben Campbell <[e-mail]>]

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