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

From: "Igoe, Kevin M." <[email-masked]>
Date: Mon, 2 Jun 2014 18:27:27 +0000

John:

  I've been checking with my co-author and customers on dropping 
support for an 8-octet authentication tag entirely and have found
no objections.  Hence I propose dropping support for 8-octet tags.
This avoids the problem at hand, plus it has the additional virtue 
of being the rational thing to do.

> -----Original Message-----
> From: John Mattsson [mailto:[email-masked]]
> Sent: Saturday, May 31, 2014 5:00 AM
> To: Igoe, Kevin M.; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-aes-gcm-
> 12.txt
> 
> The important principle here is that the maximum values from SP800-38D,
> RFC5116, RFC5282, and RFC6655 shall not be exceeded.
> 
> For GCM_8 the document needs to somehow be made compatible with Table 2
> from Appendix C in SP800-38D. Appendix C gives some flexibility by
> stating, “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”
> 
> ---------------------------------------------------------
> Table 2: Constraints with 64-bit Tags
> 
> Maximum Combined Length        Maximum Invocations of the
> of the Ciphertext and AAD      Authenticated Decryption
> In a Single Packet (bytes)     Function
> 
> 2^15                           2^32
> 2^17                           2^29
> 2^19                           2^26
> 2^21                           2^23
> 2^23                           2^20
> 2^25                           2^17
> ---------------------------------------------------------
> 
> This can be done in several ways, by just referring to the table and
> let the developer choose. Or by picking one of the rows and enforce
> that.
> 
> Currently the only mention of Appendix C is in the DTLS-SRTP section
> (15.2) where it is stated, “Note that GCM with an 8 octet
> auth_tag_length has a smaller than anticipated maximum lifetime due to
> the constraints imposed by NIST SP 800-38D appendix C”. But then
> stating, "maximum
> lifetime: at most 2^17” indicating that you have chosen the last row.
> 
> The generic part of the document describing GCM_8 must also follow the
> requirements in Appendix C. And then not only the lifetime aspect, but
> also the packet size aspect.
> 
> Would be good with opinions from the list whether the document should
> to let the developer chose a row in table 2, or if the document should
> enforce a single row, and in that case which. There is a tradeoff
> between packet length and how often rekeying needs to be done.
> 
> John
> 
> 
> 
> 
> 
> 
> 
> On 30/05/14 22:50, "Igoe, Kevin M." <[email-masked]> wrote:
> 
> >John et al:
> >
> >One of the annoying things about a short tag size is that frequent
> >changes of key does not affect the likelihood of blindly hitting a
> >valid authentication tag.  Frequent changes just reduce the amount of
> >traffic whose authenticity is compromised.  Changing P_MAX is
> >equivalent to increasing the frequency of key changes.  This reduces
> >the damage done by a successful spoof, but does not change the
> >likelihood of success.
> >
> >I am hoping table 15 will convince users use a authentication tag of
> at
> >least 12 octets.
> >
> >Frankly, I'd like to ban anything below 12 octets, but we already have
> >customers who are unwilling to use a tag size of that size. (Voice
> only
> >applications within a small community, willing to rely upon voice
> >recognition to supplement the authentication tag.)
> >
> >
> >> -----Original Message-----
> >> From: avt [mailto:[email-masked]] On Behalf Of John Mattsson
> >> Sent: Wednesday, May 28, 2014 3:51 PM
> >> To: John Mattsson; [email-masked]; [email-masked]
> >> Cc: [email-masked]
> >> Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-aes-gcm-
> >> 12.txt
> >>
> >> Before anybody corrects me:
> >>
> >> "A client implemented according to these values would quickly reveal
> >> the authentication key to any eavesdropper."
> >>
> >>
> >> This is wrong, I mixed the keysteam reuse case with the short-tag
> case.
> >> The correct statement should be.
> >>
> >> "A client implemented according to these values would be weak to an
> >> attacker actively forging messages”
> >>
> >> John
> >>
> >>
> >>
> >>
> >> On 28/05/14 21:29, "John Mattsson" <[email-masked]>
> wrote:
> >>
> >> >Hi,
> >> >
> >> >Except for fixing the important CCM violation of the P_MAX value
> >> >from
> >> >RFC5116 and 800-38D, the update does not seem to address any of the
> >> >issues I pointed out in my posts on Fri, 4 Apr 2014.
> >> >
> >> >
> >> >Two Examples:
> >> >
> >> >1. Section 13.1 still states that for AEAD_AES_128_GCM_8:
> >> >
> >> >"Default key lifetime (SRTP)    | 2^48 packets”
> >> >
> >> >
> >> >When is should say:
> >> >
> >> >“Maximum key lifetime (SRTP)    | 2^17 packets”
> >> >
> >> >
> >> >
> >> >2. GCM_8 needs its own P_MAX value as the general GCM P_MAX value
> >> given
> >> >in Section 11 violates the numbers given in SP-800-38D Appendix C.
> >> >
> >> >
> >> >Given the recent GCM_8 criticism and debate on the list, I would
> say
> >> >that this needs to be fixed before advancing the draft. A client
> >> >implemented according to these values would quickly reveal the
> >> >authentication key to any eavesdropper.
> >> >
> >> >Maybe I expressed myself sloppy when I wrote that “the current
> >> >version clearly expresses the constraints that apply to GCM.” What
> I
> >> >really meant was "the current version with my previously pointed
> out
> >> >inaccuracies fixed".
> >> >
> >> >
> >> >BR
> >> >John
> >> >
> >> >
> >> >On 21/05/14 18:19, "[email-masked]"
> >> ><[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-12.txt
> >> >>	Pages           : 33
> >> >>	Date            : 2014-05-21
> >> >>
> >> >>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-12
> >> >>
> >> >>A diff from the previous version is available at:
> >> >>http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-srtp-aes-gcm-
> 12
> >> >>
> >> >>
> >> >>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
> >> >
> >> >_______________________________________________
> >> >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: Sat, 21 Jun 2014 17:48:51 +0000

I’m ok with that approach.

It definativly simplifies things for GCM. But in general I see very little
problems with 64-bit tags when it comes to SRTP.

/John

---

From: "Igoe, Kevin M." <[email-masked]>
Date: Mon, 23 Jun 2014 12:06:18 +0000

The I-D I'm about to post (needs another pas thru spell checker)
allows 64, 96 and 128 for CCM but only 96 and 128 for GCM.

> Sent: Saturday, June 21, 2014 1:49 PM
> It definativly simplifies things for GCM. But in general I see very
> little problems with 64-bit tags when it comes to SRTP.
> 
> /John
> 
> 
> 
> >support for an 8-octet authentication tag entirely and have found no
> >objections.  Hence I propose dropping support for 8-octet tags.
> >This avoids the problem at hand, plus it has the additional virtue of
> >being the rational thing to do.
> >
> >> The important principle here is that the maximum values from
> >> SP800-38D, RFC5116, RFC5282, and RFC6655 shall not be exceeded.
> >>
> >> For GCM_8 the document needs to somehow be made compatible with
> Table
> >> 2 from Appendix C in SP800-38D. Appendix C gives some flexibility by
> >> auth_tag_length has a smaller than anticipated maximum lifetime due
> >> to the constraints imposed by NIST SP 800-38D appendix C”. But then
> >> stating, "maximum
> >> The generic part of the document describing GCM_8 must also follow
> >> the requirements in Appendix C. And then not only the lifetime
> >> aspect, but also the packet size aspect.
> >>
> >> to let the developer chose a row in table 2, or if the document
> >> should enforce a single row, and in that case which. There is a
> >> tradeoff between packet length and how often rekeying needs to be
> done.
> >>
> >> John
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> >valid authentication tag.  Frequent changes just reduce the amount
> >> >of traffic whose authenticity is compromised.  Changing P_MAX is
> >> >Frankly, I'd like to ban anything below 12 octets, but we already
> >> >have customers who are unwilling to use a tag size of that size.
> >> >(Voice
> >> only
> >> >> Subject: Re: [AVTCORE] I-D Action:
> >> >> draft-ietf-avtcore-srtp-aes-gcm- 12.txt
> >> >>
> >> >> "A client implemented according to these values would quickly
> >> >> reveal the authentication key to any eavesdropper."
> >> >>
> >> >>
> >> >> "A client implemented according to these values would be weak to
> >> >> an attacker actively forging messages”
> >> >>
> >> >> John
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> >RFC5116 and 800-38D, the update does not seem to address any of
> >> >> >the issues I pointed out in my posts on Fri, 4 Apr 2014.
> >> >> >
> >> >> >
> >> >> >Two Examples:
> >> >> >
> >> >> >>A New Internet-Draft is available from the on-line
> >> >> >>Internet-Drafts directories.
> >> >> >>https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-aes-
> gcm
> >> >> >>/
> >> >> >>
> >> >> >>http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-srtp-aes-
> gcm
> >> >> >>-
> >> 12
> >> >> >>
> >> >> >>
> >> >> >>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.
> >> >> >>