[Trans] Benjamin Kaduk's Discuss on draft-ietf-trans-rfc6962-bis-31: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-trans-rfc6962-bis-31: Discuss

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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

First off, thanks for this well-written document!  I intend to ballot Yes,
but there are a few issues that need to be resolved first.

Sections 4.11 and 4.12 have arrays of NodeHash to carry consistency and
inclusion proofs, respectively, with minimum array size of 1.  However,
Sections 2.1.4.1 and 2.1.3.1 (respectively) seem to admit the
possibility of zero-length proofs in degenerate cases, which the
aforementioned protocol description language forbids the conveyance of.
(Section 5.3 explicitly requires the use of an empty consistency proof.)
Do those minimum array sizes need to be (implicit) zero?
(If they do not, it seems that a minimum size of 32 would have the same
effect as that of one, since a NodeHash has minimum size 32.)

I support Alexey's Discuss regarding the registration of a
"urn:ietf:params:trans:error" URN namespace.

In Section 6:

   o  An Online Certificate Status Protocol (OCSP) [RFC6960] response
      extension (see Section 7.1.1), where the OCSP response is provided
      in the "CertificateStatus" message, provided that the TLS client
      included the "status_request" extension in the (extended)
      "ClientHello" (Section 8 of [RFC6066]).  [...]

This is not quite a TLS 1.3-compliant formulation -- TLS 1.3 does not
use the "CertificateStatus message", but rather uses the encoding of
that structure in a status_request extension in the CertificateEntry.

I also think we need greater clarity on the (non-)usage of CT for TLS
client certificates; see COMMENT

I also support Alissa's Discuss.


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

Since the 64-bit timestamp format (milliseconds since epoch) is used in
multiple places, there is perhaps room for consolidation into a single
definition.

Section 1

Do we need to provide a definition or reference for "public
certification authority"?

   It is necessary to treat each log as a trusted third party, because
   the log auditing mechanisms described in this document can be
   circumvented by a misbehaving log that shows different, inconsistent
   views of itself to different clients.  Whilst it is anticipated that
   additional mechanisms could be developed to address these
   shortcomings and thereby avoid the need to blindly trust logs, such
   mechanisms are outside the scope of this document.

Doesn't Section 11.3 discuss/link to some (partial) mechanisms to detect
misbehaving logs?  It's not clear that "anticipated" is quite the right
terminology to use here, then...

Section 2.1.1

   We have established a registry of acceptable hash algorithms (see
   Section 10.2).  [...]

It's not clear that we need to use the first person here.

Section 2.1.2

   When a client has a complete list of n input "entries" from "0" up to
   "tree_size - 1" and wishes to verify this list against a tree head
   "root_hash" returned by the log for the same "tree_size", the
   following algorithm may be used:

This seems to imply that n equals "tree_size"; do we want to normalize
to one name or the other?

   3.  If there is more than one element in the "stack", repeat the same
       merge procedure (Step 2.3 above) until only a single element
       remains.

nit: we just want the sub-sub-bullets of 2.3, and not the "repeat
merge_count times" part, since "merge_count" is not defined in this
scope?

Section 2.1.3.2

IMPORTANT: We need to define/specify what "leaf_index" is.

Section 2.1.4.1

   SUBPROOF(m, D[m], true) = {}

I don't remember seeing the "D[m]" notation defined; is this a typo for
something else?

   If m <= k, the right subtree entries D[k:n] only exist in the current
   tree.  We prove that the left subtree entries D[0:k] are consistent
   and add a commitment to D[k:n]:

   SUBPROOF(m, D_n, b) = SUBPROOF(m, D[0:k], b) : MTH(D[k:n])

This 'b' is always 'false', right?

Section 2.2

   Various data structures Section 1.2 are signed.  A log MUST use one
   of the signature algorithms defined in Section 10.3.

A literal reading of this forbids any algorithms registered in the
future but not listed in this document; we probably want to say "listed
in the registry defined in".

Section 3.2

   o  "SignedData.digestAlgorithms" MUST only include the
      "SignerInfo.digestAlgorithm" OID value (see below).

nit: this could be misread as saying that there is a single
distinguished OID that has symbolic name "SingerInfo.digestAlgorithm";
we just want this one to match the one in the SignerInfo in the
SignedData.signerInfos, so maybe something about "same as" would avoid
the ambiguity.

Section 4.1

   Maximum Chain Length:  The longest chain submission the log is
      willing to accept, if the log imposes any limit.

Is the absence of a limit indicated by the absence of the parameter or a
distinguished sentinel value?

   Final STH:  If a log has been closed down (i.e., no longer accepts
      new entries), existing entries may still be valid.  In this case,
      the client should know the final valid STH in the log to ensure no
      new entries can be added without detection.  The final STH should
      be provided in the form of a TransItem of type
      "signed_tree_head_v2".

Is this a lowercase "should" or a "SHOULD" or a "MUST"?  (How else would
it be provided?)

Do we need to say that the Final STH is not provided for a log that is
still accepting submissions?

Section 4.4

   Note that the ASN.1 length and the opaque vector length are identical
   in size (1 byte) and value, so the DER encoding of the OID can be
   reproduced simply by prepending an OBJECT IDENTIFIER tag (0x06) to
   the opaque vector length and contents.

nit: maybe "full DER encoding (including tag and length)" to contrast
with the previous paragraph?

   OIDs used to identify logs are limited such that the DER encoding of
   their value is less than or equal to 127 octets.

This seems to be a new requirement to this spec, in which case RFC 2119
language would be appropriate?

Section 4.7

   "sct_extensions" matches the SCT extensions of the corresponding SCT.

Is this supposed to imply the ordering and non-duplication requirements?
(If it does not, then recreating the log entry from the SCT for
signature validation could prove difficult.)

Sections 4.9, 4.10

Do we really want to allow for zero-length signatures in the structure
definition?

Section 4.11

   "consistency_path" is a vector of Merkle Tree nodes proving the
   consistency of two STHs.

A backreference to Section 2.1.4 might be helpful.

Section 4.12

   "inclusion_path" is a vector of Merkle Tree nodes proving the
   inclusion of the chosen certificate or precertificate.

A backreference to Section 2.1.3 might be helpful.

Section 5

Sometimes documents using base64 note explicitly that the padding
characters are (or aren't) included; 4648 is fairly clear that the
default is to include the padding characters, so there isn't necessarily
any change needed here.

Section 5.1

      chain:  An array of zero or more base64 encoded CA certificates.
         The first element is the certifier of the "submission"; the
         second certifies the first; etc.  The last element of "chain"
         (or, if "chain" is an empty array, the "submission") is
         certified by an accepted trust anchor.

I'm reading this to be a JSON array of strings; is that correct, and do
we want to be more explicit about it ("no" may well be fine)?

   If "submission" is an accepted trust anchor whose certifier is
   neither an accepted trust anchor nor the first element of "chain",
   then the log MUST return the "unknown anchor" error.  A log cannot
   generate an SCT for a submission if it does not have access to the
   issuer's public key.

Is this a descriptive "cannot" or a normative "MUST NOT"?

   If the returned "sct" is intended to be provided to TLS clients, then
   "sth" and "inclusion" (if returned) SHOULD also be provided to TLS
   clients (e.g., if "type" was 2 (for "precert_sct_v2") then all three
   "TransItem"s could be embedded in the certificate).

nit: the grammar is a bit weird around the second "then", maybe ", so
that" is easier to read?

Section 5.4

IMPORTANT: The input to get-proof-by-hash has a "tree_size" but the
processing discussion refers to a single "requested STH".  It does not
seem like the one uniquely determines the other, since there could be
multiple valid STHs for a given tree size (e.g., if there are no
submissions for more than the MMD).  Is the intent to supply an STH as
input, or is there otherwise need for further clarity here?

      inclusion:  A base64 encoded "TransItem" of type
         "inclusion_proof_v2" whose "inclusion_path" array of Merkle
         Tree nodes proves the inclusion of the chosen certificate in
         the selected STH.

We don't seem to define "chosen certificate"; do we just want to refer
to the (input) leaf hash?

Section 5.5

[similar note about tree_size/STH mapping]

Similarly, we talk about "index of requested hash", which is at least
unambiguous (IIUC), but we don't give a description of how the server
could/should determine.

[same comment about "chosen certificate"]

Section 5.6

         submitted_entry:  JSON object representing the inputs that were
            submitted to "submit-entry", with the addition of the trust

What does "representing" mean?  (In particular, does it use the same
JSON structure?)

Section 5.7

There is not a note here about how no signature is required on the
results, and in fact this data does seem to only be authenticated by the
surrounding TLS connection.  Perhaps it's worth making a note of that.

Section 6

   CT-using TLS servers MUST use at least one of the three mechanisms
   listed below to present one or more SCTs from one or more logs to
   each TLS client during full TLS handshakes, where each SCT

This MUST may need some caveats, given that the server can't use TLS
extensions not offered first by the client.  So maybe it has to be
"each CT-using TLS client".

Section 6.1

   o  One or more logs may not have become acceptable to all CT-using
      TLS clients.

nit: are we concerned about (new?) logs potentially becoming acceptable
to clients, or logs acceptable to clients becoming no longer accepted
(or both)?

Section 6.3

   In each "TransItemList" that is sent to a client during a TLS

nit: I don't know that "to a client" is needed; the server can just as
well use CT for client certificates, right?

   o  The TLS server MUST construct a "TransItemList" of relevant
      "TransItem"s (see Section 6.3), which SHOULD omit any "TransItem"s
      that are already embedded in the server certificate or the stapled
      OCSP response (see Section 7.1).  If the constructed
      "TransItemList" is not empty, then the TLS server MUST include the
      "transparency_info" extension with the "extension_data" set to
      this "TransItemList".

Am I allowed to send an empty "transparency_info" extension if the
TransItemList is empty?

   TLS servers MUST only include this extension in the following
   messages:

   o  the ServerHello message (for TLS 1.2 or earlier).

   o  the Certificate or CertificateRequest message (for TLS 1.3).

Servers sending it in CR implies that clients can send it in Certificate
(heh, the normal "CT" abbreviation is not really usable in this
context), but we don't explicitly say that.

Section 10.3

I'm confused by this registry.  Is the SignatureScheme value required to
come from/match the TLS SignatureScheme registry?  Is anything going to
key off that value or otherwise use the value in a protocol data
structure?  (Why are there two entries for 0x0403?)

Section 10.5

   All OIDs in the range from 1.3.101.8192 to 1.3.101.16383 have been
   reserved.  This is a limited resource of 8,192 OIDs, each of which
   has an encoded length of 4 octets.

The table says "Unassigned"; which is it?

Section 11.1

This seems to be making some unstated assumptions, including perhaps
that someone has actually submitted the misissued certificate in
question to a log (in order to support the claim that the maximum time
it can be used without audit is twice the MMD).

Section 11.3

We may want to note the potential privacy concerns relating to gossip
and similar mechanisms, at least in passing.  I do see Section 11.4,
though there's not a terribly tight linkage in the text, and 11.4 may
not have comprehensive coverage of all privacy considerations.

Section 13.2

I think that RFCs 6234 and 6979 may need to be normative, since they're
needed for the signature/hash algorithms that are specified for use.