Re: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-aes-gcm-11.txt

[John Mattsson <[e-mail]>]

After checking more carefully I see that some of my previous comments were
only partly fixed.

The P_MAX misalignment (or?) with RFC5116 needs to be addressed in some
way.

Cheers John


Previous comments not addressed or only partly fixed
---------------------

- [RFC5116] states that P_MAX is 2^24 - 1 octets for CCM.

While your draft states
Section 6: P_MAX = 2^28 – 16
Section 11: C_MAX = 2^28
Section 14: Maximum block counter = 2^24-1

After reading the NIST specification for CCM I see that P_MAX is not only
bound by the length of the block counter but also the variable q, which in
RFC5116 is set to 3 => P_MAX < 2^24 - 1 octets. The values in RFC5116
therefore seem correct to me and must not be exceeded (unless you increase
q).

The values in your draft should therefore probably be (assuming you want
block length alignment):

P_MAX (and keystream) = 2^24-16 octets
C_MAX = 2^24 octets
Maximum block counter = 2^20-1

As you have not fixed this, can you please comment how the values are in
line with RFC5116? Unless they are, this needs to be addressed in some way.

> - The values for the maximum number on invocations (2^48 and 2^31)
> for GCM_8 do not seem to agree with the constraints in Appendix C
> of 800-38D. This seems to be missing in RFC5285 as well.

You have only updated parts of the document. Section 11 and Section 13.1,
still has (2^48 and 2^31) for GCM_8 and GCM in general. Maybe add a
specific value for GCM_8 in section 11.

> - The values for the maximum Ciphertext length for GCM_8 do not
> seem to agree with the constraints in Appendix C of 800-38D: "For
> any implementation that supports 32-bit or 64-bit tags, one of the
> rows in Table 1 or Table 2, respectively, shall be enforced." This
> seems to be missing in RFC5285 as well.

To be more specific, I mean the general GCM value 2^36-16 given in Section
11. Maybe add a specific value for GCM_8.

> - [s9.2, s10.2, s10.3] The SRT(C)P MKI and the SRT(C)P
> authentication tag both have variable lengths (i.e. not 32 bit).

10.2 still states: “The 32-bit optional SRTCP MKI index and 32-bit SRTCP
authentication tag”

> - [Figure 2,4,5] I suggest writing "SRTP authentication tag" and
> "SRTCP authentication tag" instead of just "authentication tag".

Figure 6 still has “authentication tag” instead of “SRTCP authentication
tag”

> - [s13] In the tables, shouldn’t ”Default key lifetime” be ”Maximum
> key lifetime”

You made this change in 13.2 but not in 13.1	

> - [s15.3] If there is a default key length, there should also be a
> default "AEAD authentication tag length"

You have instead added “Default Auth Tag Length” = 16, which I think is
wrong. The default “Authentication tag length” when using AEAD should be 0.

> - [s17] If you would like to thank my Ericsson colleagues, their
> names are "Westerlund" and "Ohlsson"






On 04/04/14 11:37, "John Mattsson" <[e-mail]> wrote:

>Hi,
>
>In general I think this updated version looks good!
>
>I’ll have at least one remaining issue (relating to RFC5116) that I
>commented on before and did not get any reply on, but I’ll make a separate
>post about that when I have looked through my previous comments.
>
>Cheers John
>
>
>Here are some comments on the new text:
>---------------------------------------------------------------------
>
>- [s3] “AES-GCM and AES-CCM to work with SDES, DTLS and MIKEY”
>
>-> “AES-GCM and AES-CCM to work with SDES, DTLS-SRTP and MIKEY”
>
>- [s9.2] “Payload Type PT (8 bits)”
>-> “Payload Type PT (7 bits)”
>
>- [s10.4] “SRTCP cycles back to the starting value”
>-> “SRTCP index cycles back to the starting value”
>
>- “SRTCP MKI”, is for some reason called “SRTCP MKI index”?
>
>- “optional” and “OPTIONAL” is both used in the figures:
>
>“SRTP MKI (OPTIONAL)”
>“SRTCP MKI (optional)”
>“contributing source (CSRC) identifiers (optional)”
>“RTP extension (OPTIONAL)”
>
>- [s14.1] “IV uniqueness is ensured by the inclusion of	SSRC/ROC/SEQ or
>SRTCP Index in the IV”
>
>As SSRC is used even for SRTCP, maybe better to write “SSRC/ROC/SEQ or
>SSRC/SRTCP Index”
>
>- [s14.1] “the first block of key produced”
>->“the first block of keystream produced”
>
>- [Table 15] For 16 byte tags, the values for CCM and GCM are swapped.
>
>
>
>-------------------------------------------------------------
>
>JOHN MATTSSON
>MSc Engineering Physics, MSc Business Administration and Economics
>Ericsson IETF Security Coordinator
>Senior Researcher, Security
>
>Ericsson AB
>Security Research
>Färögatan 6
>SE-164 80 Stockholm, Sweden
>Phone [phone]
>SMS/MMS [phone]
>[e-mail]
>www.ericsson.com <http://www.ericsson.com/>
>
>
>
>
>
>
>On 01/04/14 16:24, "Magnus Westerlund" <[e-mail]>
>wrote:
>
>>WG,
>>
>>As result of the AD review and some comments within the WG, a number of
>>changes has been done to this document. I will let the authors comment
>>on what changes has been done.
>>
>>Anyway, before progressing to IETF last call, I like to have the WG have
>>one week until the 8th of April to review the changes to this document.
>>So please any comments on these changes as soon as possible.
>>
>>Cheers
>>
>>Magnus
>>
>>On 2014-04-01 15:54, [e-mail] wrote:
>>> 
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>directories.
>>>  This draft is a work item of the Audio/Video Transport Core
>>>Maintenance Working Group of the IETF.
>>> 
>>>         Title           : AES-GCM and AES-CCM Authenticated Encryption
>>>in Secure RTP (SRTP)
>>>         Authors         : David A. McGrew
>>>                           Kevin M. Igoe
>>> 	Filename        : draft-ietf-avtcore-srtp-aes-gcm-11.txt
>>> 	Pages           : 36
>>> 	Date            : 2014-04-01
>>> 
>>> Abstract:
>>>    This document defines how AES-GCM and AES-CCM Authenticated
>>>    Encryption with Associated Data algorithms can be used to provide
>>>    confidentiality and data authentication in the SRTP protocol.
>>> 
>>> 
>>> 
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-aes-gcm/
>>> 
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-ietf-avtcore-srtp-aes-gcm-11
>>> 
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-srtp-aes-gcm-11
>>> 
>>> 
>>> Please note that it may take a couple of minutes from the time of
>>>submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>> 
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>> 
>>> _______________________________________________
>>> Audio/Video Transport Core Maintenance
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/avt
>>> 
>>> 
>>
>>
>>-- 
>>
>>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]
>>----------------------------------------------------------------------
>>
>>_______________________________________________
>>Audio/Video Transport Core Maintenance
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/avt
>