Re: [AVTCORE] Zaheduzzaman Sarker's Yes on draft-ietf-avtcore-cryptex-06: (with COMMENT)

[Bernard Aboba <[e-mail]>]

"The write up should be updated, was the WG not aware of these IPRs?"

[BA] The IPRs were submitted after IESG publication was requested.  When we
were made aware of the declarations, we brought them to the WG's attention
on April 7, 2022:
https://mailarchive.ietf.org/arch/msg/avt/erUF7hbJPzfQ8Zz9b0J9Q8rOV7U/

We also brought up the IPRs in the Virtual Interim on May 19, 2022:
AVTCORE_Interim_5_19_2022 - Google Slides
<https://docs.google.com/presentation/d/1ot8QMaR6lRSz4ULcJlXkqQHkyKlzsV382447s962QeA/edit#slide=id.g11bb3f554e8_0_9>

No objections were raised to proceeding with publication, either on the
list or at the meeting .

On Wed, Jun 15, 2022 at 2:38 PM Zaheduzzaman Sarker via Datatracker <
[e-mail]> wrote:

> Zaheduzzaman Sarker has entered the following ballot position for
> draft-ietf-avtcore-cryptex-06: Yes
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-avtcore-cryptex/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thanks for working on this important specification. I just wish if we could
> provide more stronger specification and don't allow the mix of cryptex with
> other not so secure exiting solutions.
>
> I have some comments/suggestions/questions -
>
> - the shepherd's write-up says there is not IPR declarations but
>
> https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-avtcore-cryptex
> return two hits on IPR declarations. The write up should be updated, was
> the WG
> not aware of these IPRs?
>
> - section 1.1 : it says -
>
>         "Accordingly, these identifiers can be considered a fingerprinting
>         issue."
>
>      is there any analysis of this claim that can be referred to?"
>
> - section 1.3 : it says -
>
>         "While we considered possible solutions that would have encrypted
> more
>         of the RTP header (e.g., the number of CSRCs), we felt the
> inability to
>         parse the resultant packets with current tools, as well as
> additional
>         complexity incurred, outweighed the slight improvement in
>         confidentiality"
>
>      if I have understood it correctly, I would suggest to rewrite this to
>      something like -
>
>         While considering the possible solutions that would have encrypted
> more
>         of the RTP header (e.g., the number of CSRCs), lack of support on
>         current tools was inevitable and the additional complexity
> outweighed
>         the slight improvement in confidentiality by fixing previous
> solutions.
>         Hence, new approach was needed to solve the described problem in
>         section 1.1.
>
>
>
>