Subject: [AVTCORE] Review of draft-ietf-avtcore-cryptex

From: Bernard Aboba <[email-masked]>
Date: Mon, 9 Aug 2021 12:45:08 -0700

Review of draft-ietf-avtcore-cryptex-02
Reviewer: Bernard Aboba
Verdict: Ready with Issues

Section 4

"In order to determine whether this mechanism defined in this
   specification is supported, this document defines a new "a=cryptex"
   Session Description Protocol (SDP) [RFC4566] attribute to indicate
   support.  This attribute takes no value, and can be used at the
   session level or media level.  Offering this attribute indicates that
   the endpoint is capable of receiving RTP packets encrypted as defined
   below."

[BA] I think this section needs a bit more text to explain the negotiation.

When you say "indicate support", does this mean
"I prefer to use cryptex on sending and also support receiving"?

I think you need to say a bit more about media-level negotiation.
IMHO, media-level negotiation does not make sense when bundling audio/video
(you might explain why), so this is really only for the case where audio
and video are sent on separate ports.  But even in that case, I have
questions about the meaning.

Lets say that an Offer includes "a=cryptex" on one m-line but not another,
and the Answer includes "a=cryptex" on the m-line that included it in the
Offer, but not on the other m-line.

Does this mean that the Offerer cannot send cryptex on the other m-line?

The Answerer indicated that it supported cryptex on the other m-line, so
presumably it can decrypt it if sent.  Maybe this only means that the
Answerer can't send cryptex?  But if it did, the Offerer would also decrypt
it, correct?

Section 5.2 Receiving

   When receiving an RTP packet that contains header extensions, the
   "defined by profile" field MUST be checked to ensure the payload is
   formatted according to this specification.  If the field does not
   match one of the values defined above, the implementation MUST
   instead handle it according to the specification that defines that
   value.  The implemntation MAY stop and report an error if it
   considers use of this specification mandatory for the RTP stream.

   If the RTP packet passes this check, it is then decrypted according
   to Decryption Procedure, and passed to the the next layer to process
   the packet and its extensions.  In the event that a zero-length
   extension block was added as indicated above, it can be left as-is
   and will be processed normally.

[BA] In the case referred to above (where the Offerer includes "a=cryptex"
on one
m-line but not another, and the Answerer responds with "a=cryptex" on the
m-line
that offered it, but not on the other m-line, the above text seems to
indicate
to me that the Answerer can receive cryptex on both m-lines (since it
supports
it).

NITs:

Section 1.1

"   Accordingly, these identifiers can be considered at least slightly
   sensitive."

[BA] "at least slightly sensitive" is a bit vague. Instead you might say "a
fingerprinting issue".

Section 4

"In order to determine whether this mechanism defined in this
   specification is supported, "

[BA] s/this/the/

Section 5.2

   value.  The implemntation MAY stop and report an error if it

s/implemntation/implementation/