Subject: Re: [Trans] Mirja Kühlewind's Discuss on draft-ietf-trans-rfc6962-bis-31: (with DISCUSS and COMMENT)

From: Rob Stradling <[email-masked]>
Date: Mon, 14 Oct 2019 14:07:53 +0000

Hi Mirja.  Sorry for the looong delay.

Comments inline, and I've just posted this PR:
https://github.com/google/certificate-transparency-rfcs/pull/316

On 14/03/2019 13:50, Mirja Kühlewind via Datatracker wrote:
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-trans-rfc6962-bis-31: Discuss
> 
> 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:
> ----------------------------------------------------------------------
> 
> There was a presentation at maprg IETF 103 about the question if CT helps
> attackers to find new domains. I think this risk should at least be mentioned
> in the security considerations section.

Addressed by 
https://github.com/robstradling/certificate-transparency-rfcs/commit/3b2ec0a51f8abb4c8c0b985614fefa4291432dd9

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
>   1) I found section 2 a bit hard to follow. Would it maybe be possible to
>   provide more textual explanation of the algorithms instead of just describing
>   the steps of the algorithms? Also I was wondering how much much these
>   algorithms are actually „part“ of the protocol spec…? Are could these be
>   rather seen as example algorithms? Maybe that could be further clarified

We'll consider these comments on section 2 at a later date, along with 
Benjamin Kaduk's comments on section 2.

>   2) Please expand STH on first occurrence (in sec 4.1)

Addressed by 
https://github.com/robstradling/certificate-transparency-rfcs/commit/d2d6b0ac303af2659e5df538391002f1bf454edb

>   3) Sec 4.4: „A log's operator MUST either allocate the OID
>      themselves or request an OID from the Log ID Registry (see
>      Section 10.6.1).“
> Isn't there an obligation to register?

The Log ID Registry is merely a source of OIDs that have short DER 
encodings.  A log operator may either (1) request an OID from the Log ID 
Registry, or (2) allocate an OID themselves (from an OID arc that they 
control, naturally).

The Registry is not intended to be a global directory of all logs.

>   4) sec 4.8: „If an
>     implementation sees an extension that it does not understand, it
>     SHOULD ignore that extension.“
> Maybe it’s just me because I may have missed some context but does „ignore“
> mean here that it should log it or not?

"It" (the precertificate or certificate) must have already been logged, 
because the corresponding SCT (that contains a potentially unrecognized 
extension) couldn't otherwise exist.

>   5) sec 5: „MAY retry the same
>     request without modification at a later date.“
> Would it be possible to provide a recommendation how long the client should
> wait?

The very next sentence in section 5 already specifies a mechanism for 
doing just that:
   'Note that as per
    [RFC7231], in the case of a 503 response the log MAY include a
    "Retry-After:" header in order to request a minimum time for the
    client to wait before retrying the request.'

>   6) sec 5.6: „Logs MAY restrict the number of entries that can be retrieved per
>     "get-entries" request.“
> Should this be added to sec 4.1?

I don't think that's a good idea.  I can imagine that operational issues 
might cause a log operator to want to vary this restriction at any time.

Clients should always be prepared to receive get-entries responses that 
contain fewer entries than they requested.

See also https://trac.ietf.org/trac/trans/ticket/95

>   7) sec 10.3: Couldn’t you use the TLS  SignatureScheme Registry directly
>   (instead of forming an own registry)?

It makes sense to synchronize the signature algorithm values we use with 
the TLS SignatureAlgorithm registry, because our data structures are 
defined according to the conventions laid out in the TLS RFC.

However, I don't think it's a good idea to use the TLS 
SignatureAlgorithm registry directly.  In 6962-bis, we've taken steps to 
make log artifacts smaller (compared to RFC6962); related to that, we've 
removed the option of logs being permitted to use RSA keys/signatures. 
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-16 
permits RSA, and several other signature algorithms that we don't wish 
to permit or recommend (i.e. "anonymous", DSA, GOST, and "Reserved for 
Private Use").

>   8) sec 10.4: i Wonder if an RFC-required policy wouldn’t be more appropriate
>   for the VersionedTransTypes registry?

In 6962-bis section 10.4.1, we ask the appointed Expert to "review the 
public specification to ensure that it is detailed enough to ensure 
implementation interoperability".

AFAICT from RFC8126, "RFC Required" doesn't imply Expert Review, whereas 
"Specification Required" does.  So I think we should leave it as 
"Specification Required".

>   9) sec 10.6.1:I guess  the registration policy is FCFS? RFC 8126 recommend to
>   always (clearly) name the registry.

Thanks.  In our response to Alissa Cooper's DISCUSS/COMMENTs (see 
https://github.com/google/certificate-transparency-rfcs/pull/309), we've 
already clarified that the Log ID Registry is indeed First Come First 
Served.

> And finally one higher level question mainly out of curiosity: was it
> considered to e.g. use json for all data structures? Is there a performance
> reason to not do that or wasn’t that even discussed?

Please don't restart the format wars.  ;-)

We must use ASN.1 for all data structures, because X.509 certificates 
are involved.  But we must use "TLS encoding" for all data structures, 
because TLS is involved.  But we must use JSON for all data structures, 
because JSON is more API-friendly.

It was impossible to please everyone.  We had to choose something, so we 
chose TLS encoding for the data structures, and JSON for the APIs.

As I mentioned earlier, one goal of 6962-bis is to make log artifacts 
smaller.  TLS encoding is more suited to this than JSON.

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 14 Oct 2019 17:32:13 +0200

Hi Rob,

Thanks for your replies and edits. I will clear my discuss as soon as the new version is submitted.

Please see some minor comments below!

Thanks!
Mirja

> On 14. Oct 2019, at 16:07, Rob Stradling <[email-masked]> wrote:
> 

Could be good to clarify in the text.

> extension) couldn't otherwise exist.

Could be good to clarify in the text.

>    client to wait before retrying the request.’

I meant, would it make sense to actually provide a default value or something for this waiting time?

> "Specification Required”.

RFC Required implies that the document got some reviews based on the respective process.

However, I guess I actually wanted to propose IETF Review (and used the wrong term). That would imply that it had to go through the IETF process with respective review (and therefore usually it is expected that no expert review is needed in addition). Anyway this was mainly a comment to double-check this decision. 

> Please don't restart the format wars.  ;-)

Didn’t know that… 

> smaller.  TLS encoding is more suited to this than JSON.

Okay thanks for the background info. As long as this was discussed that's fine!

---

From: Rob Stradling <[email-masked]>
Date: Wed, 16 Oct 2019 13:36:58 +0000

> Thanks for your replies and edits. I will clear my discuss as soon as the new version is submitted.

Thanks Mirja.

> Please see some minor comments below!

Replies inline.

> Could be good to clarify in the text.

Addressed by 
https://github.com/robstradling/certificate-transparency-rfcs/commit/18be3bdc0eb3a8f5b95040081ccfaddcd2924fcb

> Could be good to clarify in the text.

I think other sections of the document already make it clear that a 
certificate or precertificate must be submitted to (and accepted by) a 
log before an SCT will be produced.

Section 3 says:
   "If a log accepts a submission, it will return a Signed Certificate
    Timestamp (SCT)"

Section 4 says:
   "When it receives and accepts a valid submission, the log MUST return
    an SCT that corresponds to the submitted certificate or
    precertificate."

I think reiterating this point again would be both unnecessary and out 
of scope for section 4.8, the purpose of which is to define the 
structure of an SCT.

> I meant, would it make sense to actually provide a default value or something for this waiting time?

We could, but it would be fairly arbitrary.  So why bother?

Some transient failures may be very short-lived, but others may last for 
hours.  Only the log operator can possibly know how long a client should 
wait before retrying a request would be expected to succeed.

> However, I guess I actually wanted to propose IETF Review (and used the wrong term). That would imply that it had to go through the IETF process with respective review (and therefore usually it is…

I personally don't have a preference, but I'll start another list thread 
to discuss this proposal.

---

From: Rob Stradling <[email-masked]>
Date: Wed, 16 Oct 2019 13:56:15 +0000

Mirja has proposed that we change the assignment policy from 
"Specification Required" (see 
https://tools.ietf.org/html/rfc8126#section-4.6) to "IETF Review" (see 
https://tools.ietf.org/html/rfc8126#section-4.8).

https://tools.ietf.org/html/rfc8126#section-4.11 says:
   "When reviewing a document that asks IANA to create a new registry or
    change a registration policy to any policy more stringent than Expert
    Review or Specification Required, the IESG should ask for
    justification to ensure that more relaxed policies have been
    considered and that the more strict policy is the right one."

Can anybody provide justification for adopting Mirja's proposal?

> On 14/10/2019 16:32, Mirja Kuehlewind wrote:
<snip>
> to discuss this proposal.
<snip>

---

From: Rob Stradling <[email-masked]>
Date: Wed, 16 Oct 2019 13:56:52 +0000

<snip>
<snip>

---

From: Melinda Shore <[email-masked]>
Date: Wed, 16 Oct 2019 11:25:47 -0700

> Can anybody provide justification for adopting Mirja's proposal?

No hats: I don't see it as likely to improve the review, myself.

Melinda

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 23 Oct 2019 11:52:21 +0200

Hi Rob,

Just one more comment regarding the default for the waiting time: I understand that it is arbitrary but I guess someone implementing CT in the first place has to make the same arbitrary choice and just select some value. Of course this value should be configurable but recommending some default or at least a range or order of value could reduce surprises. However, this is a just a recommendation from me and it’s your call!

Mirja

> On 16. Oct 2019, at 15:36, Rob Stradling <[email-masked]> wrote:
>

---

From: Rob Stradling <[email-masked]>
Date: Wed, 23 Oct 2019 10:15:29 +0000

> Just one more comment regarding the default for the waiting time: I understand that it is arbitrary but I guess someone implementing CT in the first place has to make the same arbitrary choice and…

Would anyone else like to comment on whether they agree or disagree with 
this recommendation?

If you agree, then please propose a default waiting time (for situations 
where the log server does not send an explicit "Retry-After" header).

Thanks.

Email: [email-masked]
Bradford, UK
Office: +441274024707
Sectigo Limited

This message and any files associated with it may contain legally 
privileged, confidential, or proprietary information. If you are not the 
intended recipient, you are not permitted to use, copy, or forward it, 
in whole or in part without the express consent of the sender. Please 
notify the sender by reply email, disregard the foregoing messages, and 
delete it immediately.