Subject: [Trans] overview of remaining(?) DISCUSS items for draft-ietf-trans-rfc6962-bis-33

From: Paul Wouters <[email-masked]>
Date: Wed, 18 Sep 2019 15:07:05 -0400 (EDT)

On Wed, 18 Sep 2019, Rob Stradling wrote:

> No comments received after a week, so I'm going to merge PR 312 now and
> publish -33.

Looking at the DISCUSS items, I see some minor items that seems to
require some small edits. Can the authors answers these DISCUSS
questions cited below and let us know if they will do another revision
or whether they consider all DISCUSS items below resolved?

Paul

Alissa Cooper:

 	= Section 10.3 =

 	This section needs to state what the registry policy is for the code
 	points not already registered (presumably Expert Review given 10.3.1,
 	but it needs to be explicit).

 	= Section 10.6.1 =

 	FCFS registries by definition can require additional information to be
 	provided in order to get something registered. For avoidance of
 	confusion I think the assignment policy should be listed as First Come
 	First Served and the requirement that parameters be included in the
 	application can use a normative MUST in the last paragraph if there is
 	concern that the parameters won't be supplied.

 	However, I also wonder what will be done with the parameters that are
 	supplied. Is IANA expected to just maintain them privately, or to
 	publish them?

 	What is expected to appear in the 'Log' column in the registry?

And let me add my own question regarding 10.6.1. Should we expect these
registry entries can change over time? If so, is it definied anywhere what
consumers are supposed to do or how they are supposed to find out, that a
log base url has changed? Shouldn't such a change be done using a new OID?

Benjamin Kaduk:

 	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

Mirja Kühlewind:

 	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.

To answer Mirja, the work to discuss these were going to appear in the
threat model draft. Unfortunately, this document got stuck due to
unworkable differences between the author and the WG. While I don't
object to adding a sentence covering your DISCUSS, I do not believe the
WG should try to cherry-pick content of the threat document at this
stage. So I think we should limit the Security Considerations to the
specific bis document specification, and not include issues that cover
the whole the CT ecosystem.

Alexey Melnikov:

 	I think you need to register [log client message type URN] in <https://www.iana.org/assignments/params/params.xhtml#params-1>

 	Also, can you clarify whether error need an IANA registry?

---

From: Rob Stradling <[email-masked]>
Date: Thu, 19 Sep 2019 13:53:02 +0000

> or whether they consider all DISCUSS items below resolved?

Hi Paul.

>      but it needs to be explicit).

This was addressed by PR 309, in this commit:
https://github.com/robstradling/certificate-transparency-rfcs/commit/7cd3471548c903fd891a99227bf081ca51939470

>      What is expected to appear in the 'Log' column in the registry?

This was addressed by PR 309, in this commit:
https://github.com/robstradling/certificate-transparency-rfcs/commit/704a71a18457b4558ce26fe4be519d6ea06a729a

> log base url has changed? Shouldn't such a change be done using a new OID?

Since the OID (the Log ID) appears in each of the signed log artifacts 
(SCTs, STHs), I think trying to change the OID of an existing log would 
be pretty disastrous.

However, I agree that there could be legitimate reasons for wanting to 
change a log's base URL.  For example, in the currently deployed CT v1 
ecosystem, it would be really nice if Sectigo could update the base URLs 
of our Mammoth and Sabre logs.  ({mammoth,sabre}.ct.comodo.com made 
sense when we set up these logs, but then Sectigo (formerly Comodo CA) 
was carved out of Comodo).

Having said that though, I think the best approach would be to add a 
sentence to the document that says that log base URLs MUST NOT change. 
Nice and simple.

>      I think you need to register [log client message type URN] in 
> <https://www.iana.org/assignments/params/params.xhtml#params-1>
> 

We have not yet made any attempt to respond to the DISCUSS/COMMENT items 
from Benjamin Kaduk, Mirja Kühlewind, and Alexey Melnikov.

Now that the lengthy debate about BCP190 is over, I do intend to look at 
these remaining items soon.  I will be looking for help to address 
Benjamin's COMMENTs on section 2; I am not a cryptographer, and I want 
to ensure that these comments are satisfactorily addressed.

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

---

From: Paul Wouters <[email-masked]>
Date: Thu, 19 Sep 2019 12:19:53 -0400 (EDT)

> https://github.com/robstradling/certificate-transparency-rfcs/commit/7cd3471548c903fd891a99227bf081ca51939470

Alissa, is the resolution okay with you? I thought you might also wanted
text in the paragraph itself, and not just in the table, but perhaps
this is all you wnated?

> https://github.com/robstradling/certificate-transparency-rfcs/commit/704a71a18457b4558ce26fe4be519d6ea06a729a

Okay that seems clear to me now. Hopefully to Alissa as well. Alissa,
can you clear your DISCUSS if all your concerns are addressed?

> sentence to the document that says that log base URLs MUST NOT change.

So this seems to contradict itself. You give a good reason why a base
url might change, then suggest to say MUST NOT. And you cannot add a
new entry with updated base url using the same OID I guess? So one would
have to replay the existing log into a new one. If that becomes a common
practise, how is this distinguishable from a log reply that removes an
entry and urges everyone to (automatically or not) update to the new
base url ?

> to ensure that these comments are satisfactorily addressed.

Okay. Hopefully this can be done very soon so we can re-issue a WGLC and
then have this done before IETF 106.

Paul

---

From: Rob Stradling <[email-masked]>
Date: Mon, 23 Sep 2019 12:53:26 +0000

> On Thu, 19 Sep 2019, Rob Stradling wrote:
<snip>
> entry and urges everyone to (automatically or not) update to the new

Hi Paul.  This was my thought process...

A mechanism for a log to change its base url might be "nice to have", 
but it would add complexity.  Adding complexity should be avoided unless 
it's "really necessary".  "nice to have" is not "really necessary", and 
besides, there is already a mechanism for achieving the same goal: 
retire the current log and spin up a new log.

The ecosystem needs to be agile enough to support regular log retirement 
and regular spinning up of new logs, so let's not (over)engineer an 
alternative mechanism that assumes the ecosystem lacks that agility.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 23 Sep 2019 17:35:52 -0400 (EDT)

> alternative mechanism that assumes the ecosystem lacks that agility.

While I agree with you, I am just a WG chair. So we need to hear a few
more opinions of people and then if there is a consensus, we can go ahead
and make this change.

Paul

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 24 Sep 2019 04:05:39 +0200

> more opinions of people and then if there is a consensus, we can go ahead

Sorry about that, Paul. I’m so used to the CA/Browser Forum and related,
where it’s more pressing to chime in on the bad ideas early, rather than
the good ideas like this one.

To be clear: I agree with Rob that the flexibility to make that change
seems better addressed through agility of the client. I realize this is
somewhat divergent from how 6962 was initially promoted (“just a few logs
and never need to change them”), but the operational experience there has
emphasized the importance of client agility.

Similar to the Base URL discussion by Andrew Ayer, the less flexibility we
attempt to accommodate log operators with, the greater predictability and
verifiability we offer clients. Thus, avoiding “nice to haves” that
introduce unpredictable flexibility is... nice to have. So that’s why Rob’s
response sounds right to me, and the best answer is rely on client agility
for exceptional situations.

---

From: Rob Stradling <[email-masked]>
Date: Tue, 24 Sep 2019 08:56:29 +0000

On 24/09/2019 03:05, Ryan Sleevi wrote:
> On Mon, Sep 23, 2019 at 11:36 PM Paul Wouters wrote:
>      >
>     more opinions of people and then if there is a consensus, we can go
>     ahead and make this change.

Paul, I'm not sure what you mean by "this change".

If there's consensus to not add a mechanism (that would allow logs to 
modify their base URLs) to 6962-bis, then...6962-bis already doesn't 
have such a mechanism.

Are you perhaps suggesting that "this change" would be to add a sentence 
to the end of section 10.6.1 along these lines:
"IANA is asked to reject all requests to modify or remove entries from 
the Log ID Registry"
?

> somewhat divergent from how 6962 was initially promoted (“just a few 
> logs and never need to change them”), but the operational experience 
> there has emphasized the importance of client agility.
> 
> Similar to the Base URL discussion by Andrew Ayer, the less flexibility 
> we attempt to accommodate log operators with, the greater predictability 
> and verifiability we offer clients. Thus, avoiding “nice to haves” that 
> introduce unpredictable flexibility is... nice to have. So that’s why 
> Rob’s response sounds right to me, and the best answer is rely on client 
> agility for exceptional situations.

Ryan, thanks for chiming in here.

---

From: Andrew Ayer <[email-masked]>
Date: Tue, 24 Sep 2019 07:55:19 -0400

On Mon, 23 Sep 2019 17:35:52 -0400 (EDT)
Paul Wouters <[email-masked]> wrote:

> >> So this seems to contradict itself. You give a good reason why a
> >> base url might change, then suggest to say MUST NOT. And you
> >> cannot add a new entry with updated base url using the same OID I
> >> guess? So one would have to replay the existing log into a new
> >> one. If that becomes a common practise, how is this
> >> distinguishable from a log reply that removes an entry and urges
> >> everyone to (automatically or not) update to the new base url ?
> >
> > A mechanism for a log to change its base url might be "nice to
> > have", but it would add complexity.  Adding complexity should be
> > avoided unless it's "really necessary".  "nice to have" is not
> > "really necessary", and besides, there is already a mechanism for
> > achieving the same goal: retire the current log and spin up a new
> > log.
> >
> > The ecosystem needs to be agile enough to support regular log
> > retirement and regular spinning up of new logs, so let's not
> > (over)engineer an alternative mechanism that assumes the ecosystem
> > lacks that agility.
> 

I'm also not sure what "this change" would be, but I agree with the
other comments here that CT shouldn't provide a mechanism for logs to
change URL.

Regards,
Andrew

---

From: Paul Wouters <[email-masked]>
Date: Tue, 24 Sep 2019 13:38:05 -0400 (EDT)

> other comments here that CT shouldn't provide a mechanism for logs to

I meant the clarification text of Base URL change (verus a potential
other consensus of text that would allow updating the base url)

I'm not sure what the policy is for declaring a registry append only.
Maybe leave a comment in for IANA whether or not that needs text? Or
alternatively, in the text for the Expert Review, mention the
registry is strictly append-only ?

Paul

---

From: Rob Stradling <[email-masked]>
Date: Wed, 25 Sep 2019 11:16:06 +0000

On 24/09/2019 18:38, Paul Wouters wrote:
> Maybe leave a comment in for IANA whether or not that needs text?

In -33, section 10.6.1 says:
   "Each application for the allocation of a Log ID MUST be accompanied
    by:
      - the Log's Base URL (see Section 4.1).
      - a Contact (including contact information), from whom further
        information can be obtained.
      - an Owner (including contact information), who is authorized to
        change this Log ID allocation."

I think we should fold "Owner" and "Contact" into just one field named 
"Log Operator", and clarify that the only part of a Log ID Registry 
entry that can be updated is the log operator's contact information.

Also, given that log operators are permitted to allocate Log IDs from 
other OID arcs (see section 4.4), ISTM that we also need to update 
section 4.1 to say that a log's Base URL is immutable.

Furthermore, ISTM that it would help to be explicit about the 
immutability of each and every log parameter.

Here's a PR that attempts to resolve all of the above:
https://github.com/google/certificate-transparency-rfcs/pull/314

> Or alternatively, in the text for the Expert Review, mention the

There is no Expert Review text relating to the Log ID Registry.

---

From: Eran Messeri <[email-masked]>
Date: Wed, 25 Sep 2019 17:11:58 +0100

> https://github.com/google/certificate-transparency-rfcs/pull/314

I agree with Rob and Ryan's stance - as demonstrated with 6962 deployment,
client agility would address the issue of logs wanting to change their URLs
(and I do not recall an occasion where having the ability to change just
the log URL would have been helpful).

> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 27 Sep 2019 13:44:48 -0400

I cleared my DISCUSS. Thanks!
Alissa

> On Sep 19, 2019, at 12:19 PM, Paul Wouters <[email-masked]> wrote:
>