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

From: [email-masked]
Date: Wed, 21 May 2014 09:19:41 -0700

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/

---

From: John Mattsson <[email-masked]>
Date: Wed, 28 May 2014 19:29:10 +0000

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:

>_______________________________________________
>Audio/Video Transport Core Maintenance
>[email-masked]
>https://www.ietf.org/mailman/listinfo/avt

---

From: John Mattsson <[email-masked]>
Date: Wed, 28 May 2014 19:50:52 +0000

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

---

From: "Igoe, Kevin M." <[email-masked]>
Date: Fri, 30 May 2014 20:50:47 +0000

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
> 
> "A client implemented according to these values would quickly reveal
> the authentication key to any eavesdropper."
> 
> 
> >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:
> >
> >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.
> >
> >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
> >
> >
> >>        Title           : AES-GCM and AES-CCM Authenticated
> Encryption in
> >>Secure RTP (SRTP)
> >>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.
> >>
> >>Audio/Video Transport Core Maintenance [email-masked]

---

From: John Mattsson <[email-masked]>
Date: Sat, 31 May 2014 08:59:34 +0000

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