[Trans] Followup on draft-ietf-trans-rfc6962-bis-26.txt

[Eric Rescorla <[e-mail]>]

Responses to author comments and  the changes in the new version.

---------- Forwarded message ----------
From: ekr (Eric Rescorla) <[e-mail]>
Date: Mon, Nov 13, 2017 at 5:34 AM
Subject: [Differential] [Requested Changes] D13:
draft-ietf-trans-rfc6962-bis-26.txt: 2017-08-18 16:09:04.815339
To: [e-mail]


ekr requested changes to this revision.
ekr added a comment.
This revision now requires changes to proceed. View Revision
<https://mozphab-ietf.devsvcdev.mozaws.net/D13>

This looks pretty good, but I have a few notes below on things that I still
think need to be addressed.

*INLINE COMMENTS*
View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-535>
robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:157

Being addressed by https://github.com/google/certificate-transparency-rfcs/
pull/274

LGTM.

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-536>
robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:336

The blank line between "history tree" and "[CrosbyWallach] proposal"? I've
no idea. I only see it here on Phabricator.

It's not in the source .md file. kramdown-rfc2629 doesn't add it. "xml2rfc
--raw" doesn't add it. "xml2rfc --text" does have a page break at this
point though. Could it be a strange artefact of importing the .txt doc into
Phabricator?

Yeah, probably.

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-537>
robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:625

Being addressed by https://github.com/google/certificate-transparency-rfcs/
pull/275

"see Section 5.7 might help here", but this is OK

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-539>
robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:763

Noting that EKR and Ben disagreed on "chose to limit it" versus "chooses to
limit it", I propose "imposes any limit", which sidesteps the question of
precisely when the log operator made the choice and instead simply refers
to the expected current behaviour.

Being addressed by https://github.com/google/certificate-transparency-rfcs/
pull/277

LGTM

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-540>
robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:785

How else could we achieve our goal (i.e., "To avoid being overloaded by
invalid submissions")?

Permitting submitters to submit partial chains would require logs to do
path construction. This would add complexity to log implementations and
would result in the submission process becoming significantly less
deterministic: not all logs would have prior knowledge of all existing
intermediates; fetching missing intermediates can be unreliable (e.g.,
AIA->caIssuers URLs absent, or returning HTTP 404, etc).

The submitter probably possesses the complete chain already; and if they
don't, they might be better placed (than the log) to obtain any missing
intermediates (i.e., the submitter might be the CA or a customer of the
CA). Therefore, it seems reasonable to require the submitter to provide the
complete chain; operational experience with RFC6962 has not found this to
be a problem in practice.

BTW, note that there are tools available to assist submitters with the task
of constructing a chain. e.g., https://crt.sh/gen-add-chain

You might avoid being overloaded by charging people to log stuff with your
log.

I'm not arguing that you shouldn't require submission of complete chains,
I'm saying I don't understand why MUST verify is a conformance requirement.

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-541>
robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:816

Superfluous certificates are not allowed. The "chain" input to the
submit-entry API (section 5.2) is defined as follows:

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

Given the extensive use of cross-certification in the Web PKI, there may be
multiple possible chains for a given certificate that a log would accept.
In this case, the submitter may submit any one of those chains.

>From the TRANS list:
EKR: Hmm... So your theory is that the submitter does path construction
Ben: Yep - and that's borne out by practice.
EKR: OK, well, then it would help if the document were clearer on this
point.

Being addressed by https://github.com/google/certificate-transparency-rfcs/
pull/278 (which clarifies that the submitter does path construction).

OK.

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-542>
robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:837

>From earlier in the document...

"1.2. Data Structures

Data structures are defined and encoded according to the conventions
laid out in Section 4 of [RFC5246]."

However, I suppose we should revise this TLS 1.2 reference to refer to TLS
1.3 instead...

Being addressed by https://github.com/google/certificate-transparency-rfcs/
pull/279

OK.

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-543>
robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:926

That's true, but what's the most logical and sensible lower bound to put in
the document?

This PKIX thread concluded that the smallest well-formed certificate is 66
octets:
https://mailarchive.ietf.org/arch/search/?q=World%27s+smallest+well-formed+
certificate

I could change our definition from...
opaque TBSCertificate<1..2^24-1>;
...to...
opaque TBSCertificate<66..2^24-1>;
...but wouldn't this just cause readers to waste time scratching their
heads and wondering "why 66?" ?

BTW, TLS 1.3 -21 section 4.4.2 says...

case X509:
  opaque cert_data<1..2^24-1>;

So I'm minded to leave our definition as it is.

OK.

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-544>
robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:948

Andrew Ayer wrote:
"That's not a problem, since the name of the CA is included in the Issuer
field of the TBSCertificate, which is part of the Merkle leaf input along
with the CA's public key hash."

OK, so it seems like it's safe, but it also seems like the claim about what
the hash does may not be correct. Or am I confused?

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-545>
robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:970

It's daft, but might a log's parameters ever declare a signature algorithm
of "null" for testing purposes?

BTW, "opaque signature<0..2^16-1>;" appears twice in TLS 1.3 -21.

PR wanted for TLS 1.3 :) Anyway, I am OK with leaving it as is, I suppose

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-548>
robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1163

Ben wrote "The normative requirements are in the various messages below."

OK.

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-550>
robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1432

https://github.com/google/certificate-transparency-rfcs/pull/281 puts these
into a table.

LGTM

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-551>
robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1435

Ben wrote "union would probably be a better word."

Also being addressed by https://github.com/google/
certificate-transparency-rfcs/pull/281

LGTM

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-552>
robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1522

Ben wrote "The response includes an STH, which says how big the tree is.
Probably should be the latest one known to that server."

Also, note that section 8.2 (Monitor) expects monitor clients to fetch and
verify the latest STH using get-sth before fetching entries using
get-entries.

OK.

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-555>
robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1599

Being addressed by https://github.com/google/certificate-transparency-rfcs/
pull/282

Thanks

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-556>
robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1627

There's another place in the document where we concatenate TransItems, and
that also uses TransItemList - see section 7.1 (Transparency Information
X.509v3 Extension). Why wouldn't our approach suffice in any other places
you might want to concatenate TransItems?

We've been trying to make SCTs and other TransItems as small as possible,
so that they add as little bloat as possible to certificates, OCSP
responses and TLS handshakes. The theory is: less bloat == less resistance
to adoption.

I wouldn't do this this way, but it's a WG decision.

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-557>
robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1649

Section 6 of the document says (emphasis mine):

"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 corresponds to the
 server certificate**."

So yes, there is no explicit support for CT entries for intermediate certs.
Should there arise a need for this, note that the extension is extensible
(i.e., further VersionedTransType values could be defined by future
documents).

IIRC, TLS1.3 will have per-certificate TLS extensions, so it may be simple
to accommodate CT entries for intermediates for TLS1.3.

Thanks.

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-558>
robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1651

This section defines requirements for CT-using TLS Servers, so it's not the
appropriate section in which to require that clients send an empty
extension. Section 8.1 defines the requirements for TLS Clients; subsection
8.1.1 (Receiving SCTs and inclusion proofs) already says:

'TLS clients that
support the "transparency_info" TLS extension SHOULD include it in
ClientHello messages, with empty "extension_data".'

Requiring "the server to validate that it is in fact empty" is being
addressed by https://github.com/google/certificate-transparency-rfcs/
pull/282

OK.

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-559>
robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1654

I think part of the reason we wrote this "SHOULD" is that we want to
encourage the use of the "transparency_info" TLS extension, because it
offers more agility than embedding TransItems in certs / OCSP responses.
But yes, we want to avoid duplicating the same information, and I agree
that the current text needs some improvement in that regard.

Being addressed by https://github.com/google/certificate-transparency-rfcs/
pull/282

LGTM.

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-677>
robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1722

I'm not yet sufficiently familiar with the TLS 1.3 draft to be able to do
that.

I guess I can live without it.

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-567>
robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1823

Isn't this already covered by "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..." ?
i.e., If a TLS server elects to not use "transparency_info", then it
follows that it "MUST use" at least one of the other two mechanisms (SCTs
embedded in the cert or stapled OCSP response)!

"Trying to reconstruct the reasoning here"
We could be more explicit about the reasoning. Being addressed by
https://github.com/google/certificate-transparency-rfcs/pull/283

LGTM.

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-667>
robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1912

That's covered by the paragraph below:

A TLS client (Section 8.1) can audit by verifying an SCT against any
STH dated after the SCT timestamp + the Maximum Merge Delay by
requesting a Merkle inclusion proof (Section 5.4).

OK.

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-670>
robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:2009

That was the outcome of this thread: https://mailarchive.ietf.org/
arch/search/?q=The+RFC6979+requirement+in+RFC6962-bis+is+bad

OK

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-671>
robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:2150

Fair enough. I propose to switch to First Come First Served then.

Being addressed by https://github.com/google/certificate-transparency-rfcs/
pull/287

LGTM.

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-672>
robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:2163

I think you're referring to the "or that the log has misbehaved, which will
be discovered when the SCT is audited" clause, which I'll therefore propose
to drop.

Being addressed by https://github.com/google/certificate-transparency-rfcs/
pull/288

LGTM

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-674>
robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:2237

The risk is against "Clients that gossip STHs or report back SCTs can be
tracked or traced if..."

Not sure about incentives. Maybe we should change it to a MUST, so that
violating this requirement becomes a clear case of log misbehaviour?

I think "tracked or traced" by who.

As far as a deterministic scheme, that seems like a wg decision, but what
would be the implication for RSA-PSS?

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-675>
robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:2243

I'll propose to rephrase this as "By requiring...TLS clients reduce..."

Being addressed by https://github.com/google/certificate-transparency-rfcs/
pull/282

LGTM.

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-1011>
draft-ietf-trans-rfc6962-bis.txt:2006
the "transparency_info" extension in the ServerHello with the
"extension_data" set to this "TransItemList".

I think this last point needs to be a MUST if you want to ensure the client
gets the data.

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-1004>
draft-ietf-trans-rfc6962-bis.txt:2304
6. Repeat from step 6.

This doesn't seem right, because this is step 6.

*REPOSITORY*
rIETFREVIEW ietf-review

*REVISION DETAIL*
https://mozphab-ietf.devsvcdev.mozaws.net/D13

*EMAIL PREFERENCES*
https://mozphab-ietf.devsvcdev.mozaws.net/settings/panel/emailpreferences/

*To: *ekr-moz, ekr
*Cc: *robstradling