IETF conflict review for draft-msahli-ise-ieee1609
conflict-review-msahli-ise-ieee1609-00

The intent of this document is compatible with using TLS extension
points in the intended manner, so I am proposing the "no conflict"
response.  However, the details of how the document is written are
problematic in a few places, in particular there are some
inconsistencies that would merit a DISCUSS if this was an IETF-stream
document.  (I list only the summary here; specifics are in the
section-by-section comments.)

The document is internally consistent about whether the new mechanism is
to be used solely with TLS 1.3 or whether TLS 1.2 usage is also
permitted (multiple sections/occurrences).

Section 4.1 repeats text (including normative keywords) from RFC 8446
with minor variation, but does not state that this is a quote or
repetition of preexisting requirements.

Section 4.2 seems to use mutual support of this document to mandate
client preference for certificate types (which is a change to the TLS
protocol, since TLS does not mandate client preference), but then goes
on to have additional description of server behavior that is
inconsistent with mandatory client-preference.

Figure 3 in Section 6.2 depicts a handshake exchange that violates
invariants of the TLS protocol as specified in RFC 7250.

And now, the section-by-section comments:

Section 1

   ITS certificates.  Volkswagen have committed to deploying V2X next
   year using ITS certificates.  New York, Tampa and Wyoming are

nit(?): "next year" will probably not age well.

Section 1.1

   Certificate Type value, reserved through IANA (see Section 9).  An
   implementation of TLS that is not involved in the Experiment will not
   recognise this new Certificate Type and will not be able to interact
   with an Experimental implementation: TLS sessions will fail to be
   established.

nit: I suggest "and will not participate in the experiment: TLS sessions
will either negotiate the use of existing X.509 certificates or fail to
be established", since nothing in this document prevents an
implementation from supporting both ITS certificates and X.509 ones
(though I do not expect this to occur often in practice).

Section 3

   The TLS extension "client_certificate_type" and
   "server_certificate_type" [RFC7250] are used to negotiate the type of
   the Certificate messages used in TLS to authenticate the server and,
   optionally, the client.  Using separate extension allows for mixed

nit: s/the Certificate/Certificate/

   usage with TLS 1.3.  This document makes no change to the permitted
   certificate types for usage with TLS 1.2 [RFC5246] and earlier
   versions; accordingly, the server MUST NOT send the ITS certificate
   type in either the "client_certificate_type" or
   "server_certificate_type" extension on a TLS 1.2 connection.  For TLS

I think I had suggested this text in a previous review, but I remain
unsure that it conveys the desired intent.  If you expect ITS
certificates to be used with TLS 1.2, it will need to be reworded.  I'm
happy to help with that, but don't know what deployment is expected.

   Certificate message.  For TLS 1.2 [RFC5246], the "extension_data"
   field SHALL follow the [RFC7250].  In case of TLS 1.3, the
   "extension_data" field SHALL contain a list of supported certificate
   types proposed by the client as provided in the figure below:

The "extension_data" field for which extension(s)?

   As per [RFC7250], the server processes the received
   [endpoint]_certificate_type extension(s) and selects one of the
   offered certificate types, returning the negotiated value in its
   ServerHello (TLS 1.2) or EncryptedExtensions (TLS 1.3) message.  Note

Related to the comment above, if we are not defining the use of ITS
certificates for TLS 1.2 we probably don't need to mention the TLS 1.2
behavior here.  (Strictly speaking, it's not wrong, and could remind the
reader of how the extensions we use work in the cases we're not using
them for, but that doesn't directly help the reader understand what we
do use them for.)

Section 4.1

   For maximum compatibility, all implementations SHOULD be prepared to
   handle extraneous certificates and arbitrary orderings from any TLS
   version, with the exception of the end-entity certificate which MUST
   be first.

This "SHOULD" and "MUST" makes me somewhat uncomfortable, as it could be
read as trying to override the procedures specified in RFC 8446.
Luckily, it's not, but I would suggest making it a verbatim quote and
labelling it as such (Section 4.4.2 of RFC 8446):

                                                          For maximum
   compatibility, all implementations SHOULD be prepared to handle
   potentially extraneous certificates and arbitrary orderings from any
   TLS version, with the exception of the end-entity certificate which
   MUST be first.

(Note the "potentially" is not present in the copy in this document.)

Section 4.2

      - If both client and server indicate support for the ITS
      certificate type, the server MUST select the first (most
      preferred) certificate type from the client's list that is
      supported by both peers

This makes me a little uncomfortable, as the core TLS protocol does not
require the server to honor the client's preference at all.  That said,
I can see a reasonable interpretation of this text as only specifying
the behavior when this document is in use (by both parties) and thus not
directly contravening RFC 8446.

(Also, note that the most-preferred certificate type might not be the
ITS type!)

      - The server supports the certificate types specified in this
      document.  In this case, it MAY respond with a certificate of this
      type.  It MAY also include the client_certificate_type extension
      in the Server Hello (for TLS 1.2) or in Encrypted Extension (for
      TLS 1.3).  Then, the server requests a certificate from the client
      ( via the CertificateRequest message )

This seems to be in conflict with the first bullet point -- the first
case has MUST-level requirements on the server's behavior, but these
MAYs seem to allow behavior that contravenes the MUST.

      - The server supports the extension defined in this document, but
      it does not have any certificate type in common with the client.
      Then, the server terminates the session with a fatal alert of type
      "unsupported_certificate".

I still don't see how this is any different from "server does not
support any of the proposed certificate types and terminates the
session" in the second bullet point.  Whether or not the server supports
the extension defined in this document does not have any bearing on the
server's behavior when it doesn't support any of the proposed types.

Section 6.2

Figure 3 needs to include the CertificateRequest message from the
server, since it sends the "client_certificate_type" extension.  (Figure
2 does this already, so I assume this is just an oversight.)

Section 7.2

   received in the handshake expires.  We can consider the TLS
   renegotiation as specified in [RFC5246], but an implementation of
   proposed extension could favor terminating the session on expiry of
   the certificate.

[I commented earlier about some text that says this extension is only
intended to be used with TLS 1.3, which is not really consistent with
discussing TLS 1.2 renegotiation here.]

Section 7.3

   All ITS certificates use public-key cryptographic algorithms with an
   estimated strength of at least 128 bits ,specifically, Elliptic Curve
   Cryptography (ECC) based on curves with keys of length 256 bits or
   longer.  An implementation of the techniques specified in this

[Just to be clear, this is excluding curve2519, x25519 key exchange,
etc.  It's not clear whether that's intended or not.]

Section 7.4

   The assumption in this document is that a party that accepts ITS
   certificates will do it in the context of an access control policy
   that states what PSIDs and SSPs are to be accepted in the handshake,
   and what activities are permitted within the session based on the
   PSIDs and SSPs presented in the handshake.  [ISO21177] provides a
   generalization of this where additional certificates may be presented
   within the context of a TLS session to provide a more complete
   picture of the permissions of the counterparty within the session,

(Side note: This "additional certificates may be presented within the
context of a TLS session" sounds like it could be something that
conflicts with IETF work in developing mechanisms for post-handshake
authentication, but the ISO21177 document is not what's up for conflict
review.)