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

["Paul E. Jones" <[e-mail]>]

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


-------- Original Message --------
From: Roni Even <[e-mail]>
Sent: February 19, 2017 2:38:21 AM EST
To: "Paul E. Jones" <[e-mail]>, RFC Errata System <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "text/[e-mail]" <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]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]; Roni Even;
> [e-mail]
> Cc: [e-mail]; 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]>
> To: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail] Content-
> Type; text/[e-mail]; ; 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]>
> >
> >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