[IPsec] Orie Steele's No Objection on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

[Orie Steele via Datatracker <[e-mail]>]

Orie Steele has entered the following ballot position for
draft-ietf-ipsecme-ikev2-auth-announce-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-auth-announce/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# Orie Steele, ART AD, comments for draft-ietf-ipsecme-ikev2-auth-announce-09
CC @OR13

https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-ipsecme-ikev2-auth-announce-09.txt&submitcheck=True

## Comments

Thanks to Marc Blanchet for the ARTART review, and to Valery for addressing his feedback.

```
175	   then the responder MAY choose not to send actual list of the
176	   supported authentication methods in the IKE_SA_INIT exchange and
177	   instead ask the initiator to start the IKE_INTERMEDIATE exchange for
178	   the list to be sent in.
```

Why not "SHOULD not send..."?

```
189	   the SUPPORTED_AUTH_METHODS notification.  Otherwise, the initiator
190	   MAY start the IKE_INTERMEDIATE exchange just for this sole purpose by
191	   sending an empty IKE_INTERMEDIATE request.  The initiator MAY also
192	   indicate its identity (and possibly the perceived responder's
193	   identity too) by including the IDi payload (possibly along with the
194	   IDr payload) into the IKE_INTERMEDIATE request.  This information
195	   could help the responder to send back only those authentication
196	   methods, that are configured to be used for authentication of this
197	   particular initiator.  If these payloads are sent, they MUST be
198	   identical to the IDi/IDr payloads sent later in the IKE_AUTH request.
```

Why not SHOULD instead of MAY?

```
226	   HDR, SAi1, KEi, Ni -->
227	                                      <-- HDR, SAr1, KEr, Nr, [CERTREQ,]
228	                                          [N(SUPPORTED_AUTH_METHODS)()]

230	   HDR, SK {..., [IDi, [IDr,]]}  -->
231	                                      <-- HDR, SK {..., [CERTREQ,]
232	                                      [N(SUPPORTED_AUTH_METHODS)(...)] }
```

Is the "()" vs "(...)" significant, or meant to indicate the empty IKE_INTERMEDIATE ?
What does "(...)" expand to?

```
347	   Signature" (1), "DSS Digital Signature" (3), "ECDSA with SHA-256 on
348	   the P-256 curve" (9), "ECDSA with SHA-384 on the P-384 curve" (10)
349	   and "ECDSA with SHA-512 on the P-512 curve" (11).  Note however, that
350	   these authentication methods are currently superseded by the "Digital
351	   Signature" (14) authentication method, which has a different
```

I think you mean P-521 curve, also known as secp521r1.


## Nits

```
531	   This appendix shows some examples of announcing authentication
532	   methods.  This appendix is purely informative; if it disagrees with
533	   the body of this document, the other text is considered correct.
```

You will see errata filed either way...
I recommend omitting the second sentence.