AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP)
draft-ietf-avtcore-srtp-aes-gcm-17

[Ballot discuss]

I'm ready to goto yes with -16  but am just checking if the
chairs/AD prefer me to keep the discuss while the late
breaking issue of short tags is handled.

Before I move to a yes ballot, I want to chat about two
things...

(1) There are perhaps too many choices being offered
here to be useful. It is very possible so much choice
can harm interop and hence security. Do we *need* the
256 bit key options now? Is CCM really *needed* here?
(Surprised the IEEE or h/w argument applies tbh) And
why so many auth. tag lengths? Who really *needs* all
of those? The DISCUSS point here is to validate that
all of those options really *need* (as opposed to can)
be defined, which may have been done already or may
(and we have seen this) simply be a case of defining
everything in the hope that something gets used. That
can cause potential harm to interop. if different
coders pick up different options. And the "but the USG
will use all of these" is not IMO a sufficiently good
argument for defining all of them - we also have
experience with PKI that adding every option that the
most complex deployments may want is not the recipe for
success (e.g. with enrolment protocols).

(2) Unless discuss point (1) results in there being
only one remaining option, (which I doubt:-), which of
the options specified here are MTI, and if you argue
that that needs to be done elsewhere, then where will
that be done? (We already had a major extended
discussion about SRTP MTI things in general.) I would
suggest that saying something like "128 bit GCM with a
tag length of 16 MUST be implemented by any general
purpose implementation of this specification" or
something similar.

[Ballot discuss]

Before I move to a yes ballot, I want to chat about two
things...

(1) There are perhaps too many choices being offered
here to be useful. It is very possible so much choice
can harm interop and hence security. Do we *need* the
256 bit key options now? Is CCM really *needed* here?
(Surprised the IEEE or h/w argument applies tbh) And
why so many auth. tag lengths? Who really *needs* all
of those? The DISCUSS point here is to validate that
all of those options really *need* (as opposed to can)
be defined, which may have been done already or may
(and we have seen this) simply be a case of defining
everything in the hope that something gets used. That
can cause potential harm to interop. if different
coders pick up different options. And the "but the USG
will use all of these" is not IMO a sufficiently good
argument for defining all of them - we also have
experience with PKI that adding every option that the
most complex deployments may want is not the recipe for
success (e.g. with enrolment protocols).

(2) Unless discuss point (1) results in there being
only one remaining option, (which I doubt:-), which of
the options specified here are MTI, and if you argue
that that needs to be done elsewhere, then where will
that be done? (We already had a major extended
discussion about SRTP MTI things in general.) I would
suggest that saying something like "128 bit GCM with a
tag length of 16 MUST be implemented by any general
purpose implementation of this specification" or
something similar.

[Ballot comment]
As mentioned by KK in his OPS-DIR review.
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.

I feel that this document is well written and ready. I just have one
minor suggestion.

Section 13.2., second sentence, just to be consistent with the rest of
the document, replace ‘Block Chaining Message' with 'Block
Chaining-Message'

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-avtcore-srtp-aes-gcm-14.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA has questions about some of the IANA actions requested in the IANA Considerations
section of this document.

We received the following comments/questions from the IANA's reviewer:

IANA understands that, upon approval of this document, there are five actions that IANA must complete. IANA notes that the fifth action requires Expert Review as defined in RFC 5226.

First, in the SRTP Crypto Suite Registrations subregistry of the Session Description Protocol (SDP) Security Descriptions registry located at:

http://www.iana.org/assignments/sdp-security-descriptions/

The following Crypto Suite Names will be added to the registry; all with a reference of [ RFC-to-be ]:

AEAD_AES_128_GCM
AEAD_AES_256_GCM
AEAD_AES_128_GCM_12
AEAD_AES_256_GCM_12
AEAD_AES_128_CCM
AEAD_AES_256_CCM
AEAD_AES_128_CCM_8
AEAD_AES_256_CCM_8
AEAD_AES_128_CCM_12
AEAD_AES_256_CCM_12

Second, in the DTLS-SRTP Protection Profiles subregistry of the Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP) registry located at:

http://www.iana.org/assignments/srtp-protection/

The following new profiled will be added:

Value: [ TBD-at-registration ]
Profile: AEAD_AES_128_GCM
Reference: [ RFC-to-be ]

Value: [ TBD-at-registration ]
Profile: AEAD_AES_256_GCM
Reference: [ RFC-to-be ]

Value: [ TBD-at-registration ]
Profile: AEAD_AES_128_GCM_12
Reference: [ RFC-to-be ]

Value: [ TBD-at-registration ]
Profile: AEAD_AES_256_GCM_12
Reference: [ RFC-to-be ]

Value: [ TBD-at-registration ]
Profile: AEAD_AES_128_CCM
Reference: [ RFC-to-be ]

Value: [ TBD-at-registration ]
Profile: AEAD_AES_256_CCM
Reference: [ RFC-to-be ]

Value: [ TBD-at-registration ]
Profile: AEAD_AES_128_CCM_8
Reference: [ RFC-to-be ]

Value: [ TBD-at-registration ]
Profile: AEAD_AES_256_CCM_8
Reference: [ RFC-to-be ]

Value: [ TBD-at-registration ]
Profile: AEAD_AES_128_CCM_12
Reference: [ RFC-to-be ]

Value: [ TBD-at-registration ]
Profile: AEAD_AES_256_CCM_12
Reference: [ RFC-to-be ]

Third, in the Encryption algorithm (Value 0) subregistry of the Multimedia Internet KEYing (Mikey) Payload Name Spaces located at:

http://www.iana.org/assignments/mikey-payloads/

two new algorithms are to be registered as follows:

Value: [ TBD-at-registration ]
SRTP encr alg: AES-CCM
Reference: [ RFC-to-be ]

Value: [ TBD-at-registration ]
SRTP encr alg: AES-GCM
Reference: [ RFC-to-be ]

Fourth, in the MIKEY Security Protocol Parameters subregistry also located in the Multimedia Internet KEYing (Mikey) Payload Name Spaces located at:

http://www.iana.org/assignments/mikey-payloads/

one new parameter is to be registered as follows:

SRTP Type: [ TBD-at-registration ]
Meaning: AEAD authentication tag length
Reference: [ RFC-to-be ]

QUESTION: It appears that the authors suggest these values 8, 12, or 16 (in octets).
However those values have been registered.  Do you have any issues to take
the next available value in the registry?

Fifth, in the Authenticated Encryption with Associated Data (AEAD) Parameters registry located at:

http://www.iana.org/assignments/aead-parameters/

two new AEAD algorithm will be registered as follows:

Numeric ID: [ TBD-at-registration ]
Name: AEAD_AES_128_CCM_12
Reference: [ RFC-to-be ]

Numeric ID: [ TBD-at-registration ]
Name: AEAD_AES_256_CCM_12
Reference: [ RFC-to-be ]

As this document requests registrations in Specification Required (see RFC 5226) registries, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

IANA understands that these five actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 

Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP)) to Proposed Standard


The IESG has received a request from the Audio/Video Transport Core
Maintenance WG (avtcore) to consider the following document:
- 'AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-09-11. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

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 file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-aes-gcm/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-aes-gcm/ballot/


No IPR declarations have been submitted directly on this I-D.

Some small issues and some confirmation are needed before progressing this to a short 1 week WG last call on the changes. A revised ID may be needed.