Secure DHCPv6 Using CGAs
draft-ietf-dhc-secure-dhcpv6-07

Sheng is going to work on a new proposal that does the same thing without CGAs, and bring it back through the working group.  If he still sees the need for this work afterward, we may revive it.

[Ballot comment]
- I agree with Sean's discuss based on Steve Kent's thorough
secdir review.

- I didn't get why a client would use this - if the client
generates a CGA then why does it even use DHCP?
Ted explained that prefix delegation is a reason which
seems fair enough, but doesn't seem to be the kind of
thing all DHCP clients might want to do. If address
registration (another offered use) was a reason then the
same privacy issues as arise with SAVI would apply here
and ought be mentioned since CGAs are designed to
provide better privacy and CGA+this seems to give
back whatever privacy advantage you might have
gotten from CGAs.

- My suggestion for how to fix this is to cut it down to
server authentication only (or possibly server and relay
authentication only); get rid of the idea of clients using
this in general; make the leap-of-faith much clearer, and fix
the crypto protocol issues from the secdir review. Such a spec
could be quite useful.

- I made the same point as my discuss above in relation to
another (now-dead?) draft from the same authors. [1]

  [1] https://datatracker.ietf.org/doc/draft-ietf-csi-dhcpv6-cga-ps/ballot/#stephen-farrell

[Ballot discuss]

I don't get why a client would use this - if the client
generates a CGA then why does it even use DHCP? (If that's
mentioned already in one of the other discusses I'm happy to
make this a comment - will check when I've time.)

[Ballot comment]

- I agree with Sean's discuss based on Steve Kent's thorough
secdir review.

- My suggestion for how to fix this is to cut it down to
server authentication only (or possibly server and relay
authentication only); get rid of the idea of clients using
this; make the leap-of-faith much clearer, and fix the crypto
protocol issues from the secdir review. Such a spec could be
quite useful.

- I made the same point as my discuss above in relation to
another (now-dead?) draft from the same authors. [1]

  [1] https://datatracker.ietf.org/doc/draft-ietf-csi-dhcpv6-cga-ps/ballot/#stephen-farrell

[Ballot comment]
A COMMENT from the OPS directorate review, take or leave it, but I wanted to share it.

Readability of the document could be improved by adding an acronym section and by adding diagrams to the introduction section showing the various network configurations, with and without the relay element.

[Ballot discuss]
From the secdir review:

The document does not provide a thorough system-level description of how the security mechanisms are to be used, and how clients, servers, and relay agents might need to be configured accordingly. For example, if the primary focus is thwarting fake DHCPv6 server attacks, then a client might not need to signature a query directed to a server. On the other hand, if the goal is to enable servers to selectively provide service to clients, e.g., based on cached CGA values, then a client would need to sign a query. The document needs to provide additional background in this regard, to enable readers (and implementers) to understand what features need to be present in system components making use of these security mechanisms. A description of local configuration variables that can be used to achieve the desired system-level behavior is needed.

Section 4 describes the proposed mechanism. The section states the assumptions that underlie use of CGAs in this context, but it does so in a confusing manner. The use of CGAs provides intrinsic authentication of the sender of a signed message, in terms of the IPv6 address of the sender. For DHCPv6 clients, this may be all that is required, but the text does not make that argument. For DHCPv6 servers, clients (and relay agents) simple address authentication does not suffice; a client (or a relay agent) needs to know that the sender of a message is authorized to act as a server (or relay agent). The text is not at all clear on this point, i.e., it fails to state for which entities it is necessary to pre-configure CGA parameters, to enable meaningful authentication (and authorization).

The text here states an exception to the need for pre-configuration saying  that an entity could have “ … recorded [the parameters] from previous communications.” This leap of faith (LoF) key management approach is discussed again only in Section 7. The discussion there is superficial. More text is needed to explain when LoF may be viewed as appropriate, and to address issues such as how a client that acquired a server’s CGA would transition to a new server CGA, securely.

Section 4 ends by noting that the “authentication options” (presumably the signature option) can be used to counter replay attacks. This is not quite accurate, i.e., it is the integrity aspect of the signature that provides a basis for anti-replay mechanisms, vs. the authentication  aspect. More worrisome is that fact that there is no later mention of anti-reply in the document. The authors need to add text discussing anti-replay in this context.

Section 4.2 discusses algorithm agility, but does so only for hash algorithms. This section needs to be expanded to discuss signature algorithm agility as well. Also, the text here states that “mainly unilateral notification” is the means by which an algorithm change is made known to a peer communicant, but that not all senders in a network need to transition to a new algorithm at the same time. This section needs to describe how an orderly transition to a new algorithm can be effected in a network. For example, one might add an option that a sender could include in a message, indicating a preferred list of algorithms (signature and has) that it supports. This would enable a server to know whether clients are prepared to transition to a new algorithm.

Section 5.2 defines a signature option. There is a timestamp here, which is present to help “reduce the danger of replay attacks.” However, the processing rules for a receiver (Section 6.2) make no mention of this timestamp. This mismatch needs to be fixed. The description of what data is protected by the signature is a bit complex to follow. A diagram is needed. A padding field is defined, but there is no mention of what padding bits are to be used.

Section 5.3 defines a signature option for relayed replies. It is used to enable encapsulation of a reply that passes through one or more relay agents, so that there are separate signatures for each agent and for the target client. The description here is not clear to me, especially if there is more than one relay agent.

Sections 6.1 and 6.2 provides processing rules for senders and receivers, respectively. This is a very good structure, but, as noted above, some details are missing, e.g., there is no mention of timestamp use. (If timestamp processing rules are defined elsewhere, e.g., 3515, then this text should include the relevant cite). The description of when the CGA, Signature and DUID options MUST and MUST NOT be used is sufficiently complex that a table needs be included. There is a reference to an Authentication Option near the bottom of page 11, but none is defined in this document.

The opening discussion for Section  6.2 is confusing when it discusses how a Secure DHCPv6 “enabled” receiver might, or might not, discard messages that omit the CGA and Signature options. The authors may need to distinguish between a receiver that is Secure DHCPv6 “capable” vs. “enabled” to clarify what they mean. Maybe the purported source address of the sender plays a roll here as well. Discarding a packet for which the required options are absent is a SHOULD, here. But, near the bottom of page 12, there is text that says a packet that does not pass all of the checks MUST be discarded. These two statement need to be reconciled. There is no discussion of how a receiver verifies that a message is from an authorized server or relay agent, e.g., by reference to pre-configured CGA data.  There is no discussion of when a receiver should cache CGA data for future use, despite an allusion to this possibility in Section 4. These topics must be addressed if the processing rules are to be considered complete. The “minbits” description is  bit confusing, as its name specifies a minimum key size, but the description discusses both min and max key sizes. Also, this variable needs to be augmented with an algorithm ID, so that it is clear to which algorithm the key size applies.

The security considerations section states that “… clients should be pre-configured with the DHCPv6 server CGA.” This seems important enough to be “SHOULD” vs. “should.” Similar language is used to describe the need to pre-configure CGAs for relays and servers, and it too needs to be stated more firmly. In both cases the text states that how secure pre-configuration of CGAs is achieved is out of scope. Later in this section the authors suggest that a leaf of faith (LoF) approach to acquisition of these CGAs by clients may be a reasonable alternative to secure distribution of server CGA values. This suggestion ignores the issue of how a key change for a server will be accommodated, or how the addition of a new server would work. Absent a discussion of these issues, the LoF suggestion seems questionable.

This section contains a brief discussion of collision attacks against hash functions, and why the current levels of attacks are not a serious concern in this context. Hash functions, per se, do not have a “non-repudiation feature” so I think the text here should be improved. Discussion of the hash function security in the SeND context seems relevant. As noted earlier, the test in 4.2 that talks about why hash functions are adequately secure for this context should move here, and the redundancies should be removed.

[Ballot comment]
Also from the secdir review:

Section 3 provides a very brief discussion of the vulnerabilities associated with unsecured DHCPv6, and then reviews the security mechanisms offered in RFC 3315. It notes that the symmetric key management approach offered in 3315 is difficult to manage, a conclusion with which I concur. However, the authors overstate the simplicity of their proposed approach, deferring to the Security Considerations section a discussion of public key management.

Section 3 notes that 3315 suggests use of IPsec to secure communications between servers and relay agents (or between relay agents), but dismisses that approach due to complexity. I am less sympathetic to this statement. IPsec is already implemented in all major operating systems, so an argument about its complexity, relevant to a set of proposed new mechanisms, is not especially relevant. Perhaps the authors intend to argue that management of IPsec for this application is more complex than their proposed solution. If so, I suggest that the text in bullet “c” of Section 3 be revised.

Much of the text in 4.2 should be moved to the Security Considerations section, as it is motivational material not describing the working of the protocol.

Section 6.3 describes special processing performed by relay agents, above what is described for them as senders and receivers, in the preceding two sections. Because relay agent processing has already been discussed in 6.1 and 6.2, the additional text here seems confusing to me. The closing paragraph is especially confusing to me, but maybe DHCPv6 experts will find it understandable.

[Ballot comment]
Question:
5.2 and 5.3: Is it normal practice to have a separate "Padding" field displayed in the data structure and defined instead of just defining Signature as "padded with zero to an octet" or something like that? It's just an odd way to say it.

And a couple of nits:
6.1, paragraph 2: The node MUST have -> The node needs to have
6.2, paragraph 6 & 7: MAY record -> can record
8, paragraph 1 and 2: MUST be assigned -> have been assigned
(or the last could be "will be assigned" and IANA and the RFC Editor can update the text when they're done)

[Ballot discuss]

  The Gen-ART Review by Francis Dupont on 20-Feb-2013 raised a major
  issue, and I have not seen any response from the authors.
  >
  > Major issues: the proposal fails to provide the expected security,
  > in particular it does nothing real against replay and the basic
  > function (anti-spoofing) relies on pre-configuration.

[Ballot discuss]
I think the proposed approach is a good one and support seeing it published.  I do have some issues that I would like to get ironed out...

1) The discussion on the server-relay-client seems incomplete.  For example, do I need to include a Signature-Option *per relay* if I have a chain of relay agents?  Are the processing rules affected by such chaining?

2) It is unclear how feasible the following assumption is : "the receiver has already been have the CGAs of the sender, which may be pre-configured or recorded from previous communications".  In an enterprise environment, I can see this assumption being valid, but not for a Wi-Fi hotspot scenario (where this type of solution would improve things dramatically).  It would be good to clearly state what assumptions have been made in this solution.

[Ballot discuss]
This is a fine idea, and I support it -- certainly no objection to the document in general.  I have two things I'd like to discuss first:

-- Section 5.2 --
In the definition of Key Hash, you say it's from the "hash value of the public key used for constructing the signature."  I presume you mean the "hash value of the public key from the public/private key pair that was used for constructing the signature," because the signature is made with the private key, not the public one.

-- Section 6.2 --
I don't understand the purpose of the Key Hash field.  It appears to be for some pre-verification that the key you need to use to verify the signature is the one you have and intend to use.  But it doesn't appear to help you select the right one -- you either have the right one or you don't.  Why is this useful; why doesn't the receiver just verify the signature with the public key it has?  What's the point of checking the hash first?

[Ballot comment]
A few non-blocking comments that I think will improve things:

-- Section 4.2 --
I find the first two paragraphs and their lead-in to the third to be convoluted and confusing.  I also think the first two paragraphs are unnecessary, so maybe the best answer is to do something like this:

OLD
  Hash functions are the fundamental security mechanism, including CGAs
  in this document. "...they have two security properties: to be one
  way and collision free." "The recent attacks have demonstrated that
  one of those security properties is not true." [RFC4270] It is
  theoretically possible to perform collision attacks against the
  "collision-free" property.

  Following the approach recommended by [RFC4270] and [NewHash], recent
  analysis shows none of these attacks are currently possible,
  according to [RFC6273]. "The broken security property will not affect
  the overall security of many specific Internet protocols, the
  conservative security approach is to change hash algorithms."
  [RFC4270]

  However, these attacks indicate the possibility of future real-world
  attacks. Therefore, we have to take into account that attacks will
  improved in the future, and provide a support for multiple hash
  algorithms. Our mechanism, in this document, supports not only hash
  algorithm agility but also signature algorithm agility.

NEW
  Cryptographic hash functions and signature algorithms that are
  accepted as secure today are likely to show weaknesses in the future,
  as computer systems get faster and attacks become more sophisticated.
  It is, therefore, important to provide algorithm agility: the ability
  to easily replace these algorithms when necessary.  Our mechanism, in
  this document, supports both hash algorithm agility and signature
  algorithm agility.

END

-- Section 5.2 --
In the definitions of HA-id, SA-id, and HA-id-KH, you give registry names from which these values come:
"The value is from the Hash Algorithm for Secure DHCPv6 registry in IANA."
"The value is from the Signature Algorithm for Secure DHCPv6 registry in IANA."

It would probably be useful to say that those registries are newly created in this document.  I think it's sufficient to do that with a forward reference in each case:
"The value is from the Hash Algorithm for Secure DHCPv6 registry in IANA (see Section 8)."

-- Throughout --
Please make sure your capitalization for "Relay-Reply" and "Relay-Forward" is consistent (I see "Relay-reply" and "relay-reply" as well, for example).  The RFC Editor will raise this, and it's better to fix it now rather than wait.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-dhc-secure-dhcpv6-07.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We have a question about one action requested in this document and
expect a reply from the authors.

We understand that, upon approval of this document, there are five actions that need to be completed.

First, the document "defines two new DHCPv6 [RFC3315] options, which MUST be assigned Option Type values within the option numbering space for DHCPv6 messages:" However, in reading the document it appears that there are three options being requested:

CGA Parameter Option
Signature Option
Signature Option for Relay-Reply Message

QUESTION -> are the authors requesting that two of those three options be registered, or all three? 

If all three are to be registered, we understand that these will be done in the DHCP Options Codes subregistry of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) registry located at:

www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml

as follows:

Value: [ TBD AT TIME OF REGISTRATION ]
Description: OPTION_CGA_PARAMETER
Reference: [ RFC-TO-BE ]

Value: [ TBD AT TIME OF REGISTRATION ]
Description: OPTION_SIGNATURE
Reference: [ RFC-TO-BE ]

Value: [ TBD AT TIME OF REGISTRATION ]
Description: OPTION_SIGNATURE_RRM
Reference: [ RFC-TO-BE ]

The DHCP Options Codes subregistry is currently maintained through Expert Review.

NOTE: We will initiate Expert Review for this action when we receive
a response from the authors to the question above.

Second, in the DUIDs subregistry of the DHCP Options Codes subregistry of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) registry located at:

www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml

a new DUID will be registered as follows:

Type: [ TBD AT TIME OF REGISTRATION ]
Name: DUID-SA
Reference: [ RFC-to-be ]

Third, a new registry, called the "Hash Algorithm for Secure DHCPv6" registry, will be created. The registry will be maintained through Standards Action as defined in RFC 5226. Each registration will consist of a name, value and reference. There are initial values for this registry as follows:

Name Value Reference
------------- ----------- ------------------
Reserved 0x0000 [ RFC-to-be ]
SHA-1 0x0001 [ RFC-to-be ]
SHA-256 0x0002 [ RFC-to-be ]

Fourth, a new registry, called the "Signature Algorithm for Secure DHCPv6" registry, will be created. The registry will be maintained through Standards Action as defined in RFC 5226. Each registration will consist of a name, value and reference. There are initial values for this registry as follows:

Name Value Reference
----------------- ----------- ---------------
Reserved 0x0000 [ RFC-to-be ]
RSASSA-PKCS1-v1_5 0x0001 [ RFC-to-be ]

Fifth, in the CGA Extension Type Tag registry in the Cryptographically Generated Addresses (CGA) Message Type Name Space located at:

http://www.iana.org/assignments/cga-message-types/cga-message-types.xml

a new CGA Type Tag will be registered as follows:

CGA Type Tag: 0x81be a1eb 0021 ce7e caa9 4090 0665 d2e0 02c2
Reference: [ RFC-to-be ]

We understand 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.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Secure DHCPv6 Using CGAs) to Proposed Standard


The IESG has received a request from the Dynamic Host Configuration WG
(dhc) to consider the following document:
- 'Secure DHCPv6 Using CGAs'
  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 2013-02-25. 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


  The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables
  DHCPv6 servers to pass configuration parameters. It offers
  configuration flexibility. If not secured, DHCPv6 is vulnerable to
  various attacks, particularly spoofing attacks. This document
  analyzes the security issues of DHCPv6 and specifies a Secure DHCPv6
  mechanism based on using CGAs.






The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dhc-secure-dhcpv6/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dhc-secure-dhcpv6/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1343/

(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?

Proposed Standard.  This documents an extension to the DHCPv6
protocol, so it only really makes sense as a PS.  The intended type is
indicated in the header.

(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 specifies a new security mechanism for DHCPv6 based
Cryptographically Generated Addresses (CGAs).

Working Group Summary:

This document was first presented to the DHC working group in August
of 2010.  There was significant interest in the document at that time,
and it was reviewed by several key DHC participants, myself included.

At the time my feeling about the document was that it lacked clarity
and might not be implementable; I also didn't feel comfortable that
the document had been vetted by anybody with expertise in security
other than the authors.  At my urging, the authors sought review from
Stephen Kent and the security directorate, and updated the document to
address their comments.

I still wasn't happy with the document, and other work intervened, so
it languished for a while, finally passing last call with fairly
limited support but no opposition in July of 2012.

Because I still wasn't happy with the document (I felt it lacked
clarity) I worked with Sheng at the summer IETF to address the
problems I saw in it, and we managed to do a pretty good rewrite to
address my concerns.

The document at this point is pretty solid, although I think it will
benefit from IESG review.  I wish we'd gotten broader participation
during the working group last call, but it's a difficult document, and
getting the review we did was hard enough--several people who reviewed
it in 2011 didn't remember in 2012 that they'd reviewed it.  I think
the work is important, so I'd rather advance it with the support we
had than drop it and lose the work.

Document Quality:

I'm not aware of any existing implementations.  The people who
reviewed the document are mentioned in the acknowledgements section.

Personnel:

Ted Lemon is the document shepherd.  Ralph Droms is the responsible AD.

(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.

I've read this document several times, most recently just now, and in
July.  The document has some english language issues that I expect the
RFC editor can correct.  I'm pretty happy with it, but am looking
forward to the IESG kicking the tires.

(4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed?

The document has had a great deal of review, and indeed I made a
particular point of trying to really satisfy myself that the review
had been sufficient before writing this shepherd document.

(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.

This document has been reviewed by several secdir participants.
Further review is welcomed.  The document has been edited for clarity
since that review occurred, so it may be that the same reviewers would
notice things they missed last time.

(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.

I've addressed this above--I'm pretty happy with the document.  I
realize that the document will probably attract some comment from the
IESG, and am looking forward to working with IESG members and the
authors to address whatever comment comes up (assuming that it's not
along the lines of "this is a bad idea, don't do it," of course, in
which case there's not much to be done).

(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?

Sheng and Sean have both confirmed that they have submitted all IPR
they are aware of.

(8) Has an IPR disclosure been filed that references this document? If
    so, summarize any WG discussion and conclusion regarding the IPR
    disclosures.

One of the authors, Sheng Jiang, was relatively new to the IETF when
he wrote this document, and as a consequence he filed a patent for his
employer, Huawei.  The IPR declaration says that they will make it
available to anyone who wants to implement the standard without
charge, as long as the implementor doesn't assert patents against
them.  They have also said they will license it under FRAND terms,
which doesn't entirely make sense to me.  It might be worthwhile to
try to get some clarification on this from Huawei, but it seems that
their intent is as good as can be expected given that there's IPR at
all.  Sheng was pretty apologetic about the whole thing--I think he
was used to the way other standards bodies operate.

(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?

This document has been around long enough that most of the usual
suspects have reviewed it and expressed support for it at one time or
another, but it was hard to get responses during the working group
last call on the mailing list--many of the people mentioned in the
acknowledgments did not respond by email, although they did raise
their hands in the meeting.

So I think we have pretty decent support for the document in the
working group, but it's not as fulsome as I might have wished.

(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.)

There hasn't been any serious objection to this document of which I am
aware.

(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.

The document passes idnits with no warnings.

(12) Describe how the document meets any required formal review
    criteria, such as the MIB Doctor, media type, and URI type
    reviews.

The document contains nothing like this.

(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 the normative references are to RFCs.

(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.

No.

(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.

(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).

All the necessary information is in the IANA considerations document.
The bit about the new DHCPv6 option codes could have been expressed
better, but I think it's clear enough that the IANA will be able to
implement it.

(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.

This document adds a registry for hash algorithms and a registry for
signature algorithms, both of which can be added to only by Standards
Action.

(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.

There are no such parts to the document.