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

[John Mattsson <[e-mail]>]

On 22/04/14 13:44, "Igoe, Kevin M." <[e-mail]> wrote:

>Apologies to the mailing list.  Apparently when I hit "reply to all"
>[e-mail] wasn't included on the "To" list.  Live and learn!
>
>> -----Original Message-----
>> From: Igoe, Kevin M.
>> Sent: Wednesday, April 16, 2014 12:53 PM
>> To: 'John Mattsson'
>> Subject: RE: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-aes-gcm-
>> 11.txt
>> 
>> John:
>> 
>>   Have you ever heard of the Journal of Irreproducible Results?
>> When David and I reviewed the P MAX figures, neither of us could
>> reproduce the logic that led to onee of the P MAX figures in the draft
>> (I believe it was the CCM figure).
>> 
>> Rather than risk publishing an erroneous figure, we decided to avoid
>> the issue by removing all references to P MAX. The two figures we had
>> calculated only differed by a few bytes and were vastly larger than the
>> maximum data size one would see in SRTP.
>> Apparently we missed at least one reference.  Let me know where you
>> found it and I will remove it.
>> 
>> Mea culpa.

Hi,

Your draft does not mention the term “P_MAX” but it does talk about
“Plaintext_len”, “C_MAX", and “block counter”, they are related. Further
down in my post I referred to all places that I found that seem to violate
the P_MAX value in RFC5116 (there might be more):

> - [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


The exact formulation in your draft are:

"Plaintext_len <= (2**28)-16”


“C_MAX      maximum ciphertext length per invocation
 GCM: MUST be <= 2^36-16 octets.
 CCM: MUST be <= 2^28 octets.
”

“The block counter is incremented
        after each block key has been produced, but it MUST NOT be
allowed to exceed 2^32-1 for GCM and 2^24-1 for CCM."

Hope this helps.

John


>> 
>> 
>> > -----Original Message-----
>> > From: avt [mailto:[e-mail]] On Behalf Of John Mattsson
>> > Sent: Friday, April 04, 2014 10:42 AM
>> > To: [e-mail]
>> > Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-aes-gcm-
>> > 11.txt
>> >
>> > 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-
>> 1
>> > >>> 1
>> > >>>
>> > >>>
>> > >>> 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
>> > >
>> >
>> > _______________________________________________
>> > Audio/Video Transport Core Maintenance [e-mail]
>> > https://www.ietf.org/mailman/listinfo/avt
>_______________________________________________
>Audio/Video Transport Core Maintenance
>[e-mail]
>https://www.ietf.org/mailman/listinfo/avt