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

[Stephen Farrell <[e-mail]>]

Hi Magnus,

I had hoped the WG would chime in but apparently they do not
care much about this topic.

I'd take that as indicating that it is ok to remove some of
the options since nobody is yelling that they are all needed.

After all - is there really a need to define 10 ways of using
one algorithm (AES) to do pretty much exactly the same thing?

I think 10 options is just damaging to interop even if done for
the best of motives.

S.

On 29/01/15 11:02, Magnus Westerlund wrote:
> 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]
> ----------------------------------------------------------------------
>