Re: [AVTCORE] Stephen Farrell's Discuss on draft-ietf-avtcore-srtp-aes-gcm-14: (with DISCUSS)

[Magnus Westerlund <[e-mail]>]

Hi Stephen, All,

(Adding the AVTCORE WG): WG there are feedback requested from you below!

I am taking over as shepherd for this document and would like to make
some progress here.

I would like to make some observations around the discuss.
https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-aes-gcm/ballot/#stephen-farrell

First, that Stephen appear to grouping AES-GCM and AES-CCM into one
bucket. From my perspective they are defined as two different ciphers
for SRTP but within a single document. One can implement either of them
without any requirement on implementing the other from this document.

Each of them have MTI requirements on configurations that MUST be
supported if one support that particular cipher. That is defined as
strongest for each key length.

>From the draft:

Section 13.1:

   Any implementation of AES-GCM SRTP MUST support both AEAD_AES_128_GCM
   and AEAD_AES_256_GCM (the versions with 16 octet AEAD authentication
   tags), and it MAY support the four other variants shown in table 1.

Section 13.2:

   Any implementation of AES-CCM SRTP/SRTCP MUST support both
   AEAD_AES_128_CCM and AEAD_AES_256_CCM (the versions with 16 octet
   AEAD authentication tags), and MAY support the other four variants.

I would further also note that to make anything MTI for SRTP independent
on deployment and usage, then a document must Update the MTI definition
in RFC 3711, something that hasn't been done yet. So far it is up to the
umbrella specifications, like WebRTC etc as discussed in SRTP not
mandatory document (RFC 7202) to define what ciphers that MUST be
implemented. And if we are updating RFC 3711 the mandatory to implement
for any SRTP implementation will certainly be a question.


When it comes to the core of your discuss if these 4 (AES-GCM) + 6
(AES-CCM) options must be defined. That is difficult question. One which
is difficult to answer within the context of the WG actually. As David
has raised in the private discussion so far there will be people that
will argue anything other than the longest tags and keys are acceptable,
others will note that using the 16 byte authentication tags do results
in the authentication data being more than the RTP payload (single audio
frame) for a number of the audio formats we have. Me personally I think
I would remove the 12 bytes tag-length from AES-CCM to reduce the number
of options. But two tag-lengths and two key-lengths do not appear
excessive.

WG, the chairs and ADs appreciate feedback on your view here.


Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------