[AVTCORE] Roman Danyliw's Discuss on draft-ietf-avtcore-cryptex-06: (with DISCUSS and COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-avtcore-cryptex-06: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I’m having trouble understanding the relationship between this work and SRTP
without making assumptions.  Section 1.3 notes that there is a design goal to
build on top of SRTP and to have simple SRTP interactions.  Section 3 also says
the design goal is to “reuse the existing SRTP framework.”  Finally, Section
6.2 and 6.3 says ”[t]he encryption (or decryption) procedure is identical to
that of [RFC3711] except for the Encrypted Portion of the SRTP packet.”

I believe the correct read is that “do everything from SRTP unless noted as
different here”.  However, saying “encryption and description procedures" per
Sections 6.2/6.3 doesn’t capture that for me.  This leaves open questions about
key management, establish and maintaining state for cryptographic contexts, MTI
algorithms, etc.

The text would benefit from being explicit on what behavior “a=cryptex”
behavior reuses from SRTP.  I don’t believe that changes any of the expected
core mechanics.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to Rifaat Shekh-Yusef for the SECDIR review.

** Section 6.2.  What does the notation “_4*CC_ bytes of the ciphertext …” mean?

** Section 6.2.

Implementations can rearrange a packet so that the AAD and plaintext
   are contiguous by swapping the order of the extension header and the
   CSRC identifiers, resulting in an intermediate representation of the
   form shown in Figure 2.

Where would this intermediate representation be used?  To double check, this
would not be put on the wire?

** Section 8.  On MTI/optional/default transforms, does this document want to
change anything from what was said in RFC3711?

-- Should something be said about AES-GCM per RFC7714, especially since it was
listed as an example.

-- Assuming this document inherits the MTI transforms for SRTP, please
explicitly call out the dangers using NULL transform.

** Section 8.  Does any subset of the Security Considerations of RFC3711 apply
here?

** A.1.  Cite AES-CTR per RFC3711.

** A.2.  Cite AES-GCM per RFC7714.

Nits
** Section 5.1.  Typo.  There is a markdown typo of “{RFC8285}}” (i.e., single
open brace) which is preventing the rendering this reference correctly in the
first sentence.

** Section 5.2. Typo. s/the the/the/