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

The following approval message was sent
From: The IESG
To: Adrian Farrel ,
    draft-msahli-ise-ieee1609@ietf.org,
    rfc-ise@rfc-editor.org
Cc: IETF-Announce ,
    iana@iana.org,
    The IESG
Subject: Results of IETF-conflict review for draft-msahli-ise-ieee1609-06

The IESG has completed a review of draft-msahli-ise-ieee1609-06 consistent
with RFC5742.

The IESG has no problem with the publication of 'TLS Authentication using ITS
certificate'  as an Experimental RFC.

The IESG has concluded that this work is related to IETF work done in WG TLS,
but this relationship does not prevent publishing.

The IESG would also like the Independent Submissions Editor to review the
comments in the datatracker related to this document and determine whether or
not they merit incorporation into the document. Comments may exist in both
the ballot and the history log.

The IESG review is documented at:
https://datatracker.ietf.org/doc/conflict-review-msahli-ise-ieee1609/

A URL of the reviewed Internet Draft is:
https://datatracker.ietf.org/doc/draft-msahli-ise-ieee1609/

The process for such documents is described at
https://www.rfc-editor.org/indsubs.html

Thank you,

The IESG Secretary

[Ballot comment]
doc{draft-msahli-ise-ieee1609-06}
ballot{No Objection}

[nits]

S1

* The sentence "In this document, we call this certificates: ITS certificates."
  is redundant with the last sentence of this paragraph, which nicely explains
  the definition of ITS.

[Ballot comment]
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.)

From the ISE: "We previously kicked off a request for a conflict review of this draft, but I withdrew the request after discussion with Ben Kaduk. I'd like to kick the request off again."