Re: [AVTCORE] [Technical Errata Reported] RFC7714 (4938)

["Mo Zanaty (mzanaty)" <[e-mail]>]

The root cause of the ambiguity on whether to zero-pad the salt on the left or right stems from the different salt sizes specified in RFC 7714 GCM (96 bits) versus RFC 3711/6188 AES 128/192/256 CM (112 bits).

That discrepancy, in turn, is due to the block counter size expansion from 16 bits to 32 bits in GCM, which expands the max packet size from 1 MB (64K*16B) to 64 GB (4G*16B). Was this intentional to accommodate IPv6 jumbograms? Or an unintended carryover from non-network GCM uses like file encryption?

Are there any security considerations of not salting the 16 bits before the 16-bit block counter in the PRF IV?

For clarity, here is the IV layout of CM vs GCM vs PRF (used by both CM and GCM).


RFC 3711/6188 CM IV:

 0  1  2  3  4  5  6  7  8  9  10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|00|00|00|00|   SSRC    |   packet index  | b_c |---+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+   |
                                                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+   v
|                  salt (k_s)             |00|00|->(+)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

RFC 3711 PRF IV:

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|00|00|00|00|00|00|00|LB|    index/rate   | b_c |---+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+   |
                                                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+   v
|                  salt (k_s)             |00|00|->(+)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

RFC 7714 GCM IV:

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|00|00|   SSRC    |   packet index  |    b_c    |---+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+   |
                                                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+   v
|                  salt (k_s)       |00|00|00|00|->(+)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+


Mo


From: avt <[e-mail]<mailto:[e-mail]>> on behalf of Paul Jones <[e-mail]<mailto:[e-mail]>>
Date: Sunday, February 19, 2017 at 10:18 AM
To: Roni Even <[e-mail]<mailto:[e-mail]>>, RFC Errata System <[e-mail]<mailto:[e-mail]>>, "David McGrew (mcgrew)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, 'Magnus Westerlund' <[e-mail]<mailto:[e-mail]>>
Cc: "text/[e-mail]<mailto:text/[e-mail]>" <text/[e-mail]<mailto:text/[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [AVTCORE] [Technical Errata Reported] RFC7714 (4938)

Roni,

Sure, we could do that. However, I do wonder how useful that would be. In the outside chance one encounters such an implementation, what would they do about it?

Paul

________________________________
From: Roni Even <[e-mail]<mailto:[e-mail]>>
Sent: February 19, 2017 2:38:21 AM EST
To: "Paul E. Jones" <[e-mail]<mailto:[e-mail]>>, RFC Errata System <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "text/[e-mail]<mailto:text/[e-mail]>" <text/[e-mail]<mailto:text/[e-mail]>>
Subject: RE: [Technical Errata Reported] RFC7714 (4938)


Paul,
I saw the email with what looks like this direction but maybe the new text should mention as a note that since this was not specified before there may be few implementations that added padding on the other side.
Roni Even
As individual

 -----Original Message-----
 From: Paul E. Jones [mailto:[e-mail]]
 Sent: יום ה 16 פברואר 2017 23:45
 To: RFC Errata System; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;
 [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Roni Even;
 [e-mail]<mailto:[e-mail]>
 Cc: [e-mail]<mailto:[e-mail]>; text/[e-mail]<mailto:text/[e-mail]>
 Subject: Re: [Technical Errata Reported] RFC7714 (4938)

 Since this issue needs closure in order to ensure that we have interoperable
 solutions, it would be good to have confirmation / agreement on the
 proposed change.

 Paul

 ------ Original Message ------
 From: "RFC Errata System" <[e-mail]<mailto:[e-mail]>>
 To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;
 [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;
 [e-mail]<mailto:[e-mail]>
 Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]> Content-
 Type; text/[e-mail]<mailto:text/[e-mail]>; ; charset=[e-mail]<mailto:charset=[e-mail]>
 Sent: 2/16/2017 3:23:30 PM
 Subject: [Technical Errata Reported] RFC7714 (4938)

The following errata report has been submitted for RFC7714, "AES-GCM
Authenticated Encryption in the Secure Real-time Transport Protocol
(SRTP)".

________________________________

You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7714&eid=4938

________________________________

Type: Technical
Reported by: Paul E. Jones <[e-mail]<mailto:[e-mail]>>

Section: 11

Original Text
-------------
A Key Derivation Function (KDF) is used to derive all of the required
encryption and authentication keys from a secret value shared by the
endpoints.  The AEAD_AES_128_GCM algorithm MUST use the (128-bit)
AES_CM PRF KDF described in [RFC3711].  AEAD_AES_256_GCM MUST use
 the
AES_256_CM_PRF KDF described in [RFC6188].

Corrected Text
--------------
A Key Derivation Function (KDF) is used to derive all of the required
encryption and authentication keys from a secret value shared by the
endpoints.  The AEAD_AES_128_GCM algorithm MUST use the (128-bit)
AES_CM PRF KDF described in [RFC3711].  AEAD_AES_256_GCM MUST use
 the
AES_256_CM_PRF KDF described in [RFC6188].  Since the KDF functions in
those RFCs assume as input a 112-bit master salt, the 96-bit master
salt specified in this document must be multiplied by 2^16 to form the
112-bit salt used as the master salt in those key derivation functions.

Notes
-----
The salt specified in RFC 7714 is 96 bits in length, but intended for
use in KDF functions defined in RFC 3711.  This led to different
interpretations when implementing this RFC.  A more complete
description was presented on the avtcore mailing list
(https://mailarchive.ietf.org/arch/msg/avt/IRfLuNKglD3qhqwSz3v3t0CG6fA
 )
and, after some dialog, there seemed to be agreement to adopt the
approach most widely implemented
(https://mailarchive.ietf.org/arch/msg/avt/-
 C1cIWQXpyzS2KfBjGR6B2kK92w).
  This suggested text is intended to reflect that agreement.  In
effect,
16 zero bits are padded to the right of the salt value  defined in RFC
7714 (creating a 112 bit salt value) before it is used as described in
the KDF functions defined in RFC 3711 that require a 112 bit salt
value.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or rejected.
When a decision is reached, the verifying party can log in to change
the status and edit the report, if necessary.

________________________________

RFC7714 (draft-ietf-avtcore-srtp-aes-gcm-17)
________________________________

Title               : AES-GCM Authenticated Encryption in the Secure
Real-time Transport Protocol (SRTP)
Publication Date    : December 2015
Author(s)           : D. McGrew, K. Igoe
Category            : PROPOSED STANDARD
Source              : Audio/Video Transport Core Maintenance
Area                : Applications and Real-Time
Stream              : IETF
Verifying Party     : IESG