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

From: "Igoe, Kevin M." <[email-masked]>
Date: Tue, 22 Apr 2014 11:44:09 +0000

Apologies to the mailing list.  Apparently when I hit "reply to all"
[email-masked] 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.
> 
> 
> > -----Original Message-----
> > From: avt [mailto:[email-masked]] On Behalf Of John Mattsson
> > Sent: Friday, April 04, 2014 10:42 AM
> > To: [email-masked]
> > 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" <[email-masked]>
> 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 +46 10 71 43 501
> > >SMS/MMS +46 76 11 53 501
> > >[email-masked]
> > >www.ericsson.com <http://www.ericsson.com/>
> > >
> > >
> > >
> > >
> > >
> > >
> > >On 01/04/14 16:24, "Magnus Westerlund"
> > <[email-masked]>
> > >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, [email-masked] 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 [email-masked]
> > >>> https://www.ietf.org/mailman/listinfo/avt
> > >>>
> > >>>
> > >>
> > >>
> > >>--
> > >>
> > >>Magnus Westerlund
> > >>
> > >>-------------------------------------------------------------------
> -
> > >>-
> > -
> > >>Services, Media and Network features, Ericsson Research EAB/TXM
> > >>-------------------------------------------------------------------
> -
> > >>-
> > -
> > >>Ericsson AB                 | Phone  +46 10 7148287
> > >>Färögatan 6                 | Mobile +46 73 0949079
> > >>SE-164 80 Stockholm, Sweden | mailto:
> [email-masked]
> > >>-------------------------------------------------------------------
> -
> > >>-
> > -
> > >>
> > >>_______________________________________________
> > >>Audio/Video Transport Core Maintenance [email-masked]
> > >>https://www.ietf.org/mailman/listinfo/avt
> > >
> >
> > _______________________________________________
> > Audio/Video Transport Core Maintenance [email-masked]
> > https://www.ietf.org/mailman/listinfo/avt

---

From: John Mattsson <[email-masked]>
Date: Fri, 25 Apr 2014 08:05:25 +0000

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

> 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

---

From: "Igoe, Kevin M." <[email-masked]>
Date: Fri, 25 Apr 2014 11:10:18 +0000

Thanks John, I'll address these.  

> From: John Mattsson [mailto:[email-masked]]
> Sent: Friday, April 25, 2014 4:05 AM
> To: Igoe, Kevin M.; [email-masked]
> Subject: Re: [AVTCORE] FW: I-D Action: draft-ietf-avtcore-srtp-aes-gcm-
> 11.txt
> 
> 
> >> reproduce the logic that led to onee of the P MAX figures in the
> >> draft (I believe it was the CCM figure).
> >>
> >> calculated only differed by a few bytes and were vastly larger than
> >> the maximum data size one would see in SRTP.
> “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):
> 
> >> > After checking more carefully I see that some of my previous
> >> > comments were only partly fixed.
> >> >
> >> > 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).
> >> >
> >> > 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.
> >> >
> >> > > - [s13] In the tables, shouldn’t ”Default key lifetime” be
> >> > > ”Maximum key lifetime”
> >> >
> >> > > - [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.
> >> >
> >> > >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
> >> > >
> >> > >
> >> > >-----------------------------------------------------------------
> -
> >> > >--
> >> -
> >> > >
> >> > >As SSRC is used even for SRTCP, maybe better to write
> >> > >“SSRC/ROC/SEQ or SSRC/SRTCP Index”
> >> > >
> >> > >>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.
> >> > >>> https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-aes-
> gc
> >> > >>> m/
> >> > >>>
> >> > >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-srtp-aes-
> gc
> >> > >>> m-
> >> 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.
> >> > >>>
> >> > >>----------------------------------------------------------------
> -
> >> > >>--
> >> -
> >> > >>-
> >> > -
> >> > >>----------------------------------------------------------------
> -
> >> > >>--
> >> -
> >> > >>-
> >> > -
> >> > >>----------------------------------------------------------------
> -
> >> > >>--
> >> -
> >> > >>-
> >> > -
> >> > >>