Writeup for draft-ietf-avtcore-srtp-aes-gcm-10
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the proper
type of RFC? Is this type of RFC indicated in the title page header?
This document is request to be published as a Proposed Standard.
(2) The IESG approval announcement includes a Document Announcement Write-Up.
Please provide such a Document Announcement Write-Up. Recent examples can be
found in the "Action" announcements for approved documents. The approval
announcement contains the following sections:
Technical Summary:
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. Identifiers
for using these with DTLS-SRTP, MIKEY and Security Descriptions are also
being registered in the appropriate IANA registries.
Working Group Summary:
There has been no controveries around this document. It has rather lacked in
contribution due to difficult intersection between RTP and Security.
Document Quality:
This has gotten close to minimal level of reviews from the WG. Jonathan Lennox
reviewed it and was especially helpfull dealing with Header Extensions. Can
also thank Woo-Hwan Kim for his reviews. The changes after WG last call, has
been verified by the WG consensus call on the changes. In this call one
additional reviewer (Michael A Peck) confirmed suitability to publish.
Mocana's Keytone already implements AES-GCM-256 in SRTP, thou an earlier draft
version. NSA plans to include cipher suits from this document into secure
communication profiles for US governmental use. Because of that it is believed
that several implementations are under way.
Personnel:
Magnus Westerlund is the document shepherd.
Responsible AD is Richard Barnes
(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the IESG.
The document shepherd reviewed the document in WG last call. The changes has
since been reviewed. As part of the writeup the draft has been gone through
using the ID checklist, the ID-nits and the questions in the template. A number
of issues was found which was corrected prior to submitting the publication
request.
(4) Does the document Shepherd have any concerns about the depth or breadth of
the reviews that have been performed?
Yes, the review of this document has been minimal although some core RTP
persons and some security focues persons have taken a look, the document could
benefit from more review.
(5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place.
More security review is desirable. This was requested on the SAAG mailing list,
but uncertain if that has resulting in any reviews.
(6) Describe any specific concerns or issues that the Document Shepherd has
with this document that the Responsible Area Director and/or the IESG should be
aware of? For example, perhaps he or she is uncomfortable with certain parts of
the document, or has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated that it still
wishes to advance the document, detail those concerns here.
No concerns beyond the limited amount of reviews.
(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed. If not, explain why?
Kevin M. Igoe and David McGrew has confirmed that they are in conformance.
(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.
No
(9) How solid is the WG consensus behind this document? Does it represent the
strong concurrence of a few individuals, with others being silent, or does the
WG as a whole understand and agree with it?
Strong concurrence of a few individuals.
(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
If so, please summarise the areas of conflict in separate email messages to the
Responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)
No.
(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
Boilerplate checks are not enough; this check needs to be thorough.
No, nits have been found for this version (10).
(12) Describe how the document meets any required formal review criteria, such
as the MIB Doctor, media type, and URI type reviews.
No formal review required.
(13) Have all references within this document been identified as either
normative or informative?
Yes.
(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative references
exist, what is the plan for their completion?
No, all published documents.
(15) Are there downward normative references references (see RFC 3967)? If so,
list these downward references to support the Area Director in the Last Call
procedure.
YES: Normative reference to an Informational RFC: RFC 3610
This RFC is not part of the downref registry.
(16) Will publication of this document change the status of any existing RFCs?
Are those RFCs listed on the title page header, listed in the abstract, and
discussed in the introduction? If the RFCs are not listed in the Abstract and
Introduction, explain why, and point to the part of the document where the
relationship of this document to the other RFCs is discussed. If this
information is not in the document, explain why the WG considers it unnecessary.
No, changes to other documents.
(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes are
associated with the appropriate reservations in IANA registries. Confirm that
any referenced IANA registries have been clearly identified. Confirm that newly
created IANA registries include a detailed specification of the initial
contents for the registry, that allocations procedures for future registrations
are defined, and a reasonable name for the new registry has been suggested (see
RFC 5226).
The shepherd knows as RFC 3711 points out that SRTP cipher suits registrations
are with the keymanagement systems that needs to use this cipher suites and its
possible configurations. The IETF defined keymanagement systems for SRTP are
Security Descriptions, DTLS-SRTP and MIKEY. They all are included.
Security Descriptions: Needed correction to point to the right registry and
missed a requirement. All this is now fixed.
DTLS-SRTP: Fulfills the requirements stated in RFC 5764 and provides the values
defined to be relevant for the crypto algorithm itself.
MIKEY: The registries to which to add was checked. From the shepherds
understanding this is the right way of adding the needed parameters to Mikey.
(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful in
selecting the IANA Experts for these new registries.
No new registries.
(19) Describe reviews and automated checks performed by the Document Shepherd
to validate sections of the document written in a formal language, such as XML
code, BNF rules, MIB definitions, etc.
No formal language