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

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 18 Oct 2021 14:05:40 +0200

Hi Bernad,

Thanks for the feedback, sorry for the delay in answering them. See my
comments below:

El lun, 9 ago 2021 a las 21:45, Bernard Aboba (<[email-masked]>)
escribió:

> 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 that preferring cryptex on sending should be a local policy on the
sender side and the presence of the cryptex attribute on the SDP only
indicates the ability to receive cryptex.

> 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.
>

I agree that media-level negotiation only makes sense if for non bundle.
Moreover, as the "mid" value is sent in a header extension, if doing
ssrc-less negotiation, it wouldn't be possible for a receiver to support
cryptex on one m-line but do not support it on another.

I would propose to add a note about bundle and mandate that, if present,
the cryptex attribute must be present for all the m-lines from the same
bundle group.

>
> 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?
>

Let's assume that audio and video are not bundled and that the offerer (A)
adds the cryptex attribute for audio, but not for video.
The answer from B, then sets the attribute in the other way, for video but
not for audio.

Then A could send crytex on video to B, and B could send cryptex to A on
audio.

>
> 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).
>

Yes

> 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/
>

Will address this in the next draft.

Best regards
Sergio

---

From: Justin Uberti <[email-masked]>
Date: Sun, 24 Oct 2021 22:13:00 -0700

Thanks Bernard for these comments. Sergio, I agree with your responses.

On Mon, Oct 18, 2021 at 5:06 AM Sergio Garcia Murillo <
[email-masked]> wrote:

>> [BA] In the case referred to above (where the Offerer includes
>> "a=cryptex" on one
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>