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

["Igoe, Kevin M." <[e-mail]>]

Thanks John, I'll address these.  

> -----Original Message-----
> From: John Mattsson [mailto:[e-mail]]
> Sent: Friday, April 25, 2014 4:05 AM
> To: Igoe, Kevin M.; [e-mail]
> Subject: Re: [AVTCORE] FW: I-D Action: draft-ietf-avtcore-srtp-aes-gcm-
> 11.txt
> 
> 
> 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-
> gc
> >> > >>> m/
> >> > >>>
> >> > >>> 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-
> 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.
> >> > >>>
> >> > >>> 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