Subject: [Trans] Section 4.2 follow-up

From: Eran Messeri <[email-masked]>
Date: Tue, 21 Nov 2017 19:20:09 +0000

[shortening subject]

Two MUSTs are being discussed:
(1) "the log MUST NOT accept any submission until it has verified ..."
(2) "The log MUST NOT use other sources of intermediate CA certificates"

These MUSTs are to do with security (as Andrew Ayer pointed out
<https://github.com/google/certificate-transparency-rfcs/pull/289#issuecomment-344668837>)
as well as protocol correctness and determinism of the logs, not in order
to restrict what logs should accept.

A consensus has already been established in the group that logs need to be
allowed to accept certificates that are not fully compliant with RFC5280
validation rules (hence the SHOULD in the second paragraph of said section
and MAY on the third paragraph).

Another consensus was established that logs should be allowed to drop valid
submissions under load (to protect against DoS attacks) - which again is
allowed by the SHOULD on the 2nd paragraph.

The MUSTs that have remained, have remained there to guarantee that a
submission has made it into the log if, and only if, it has been validated
according to the log's implementation (which, again, may deviate from
RFC5280). These MUSTs are in place to guide the implementation, even if
there's no technical way to validate, from an external POV, that a log
adhered to them at all times.

To present from a different angle, if the MUSTs are changed to SHOULDs then
(according to my understanding of RFC2119) logs will be able to claim that
any accepted submission was not validated because the it wasn't checked.
That would make monitoring difficult and submission non-deterministic
(because a log would then be allowed to use other sources of intermediate
CA certificates to complete a partially-submitted chain).

RFC2119 says about SHOULD that "there may exist valid reasons in particular
circumstances to ignore a particular item [...]" but I do not see a valid
reason to ignore validation for some entries or allow acceptance of partial
chains, where the 6962-bis goes to great length to ensure the submitted,
valid chain is always presented to monitors.

>From what I can tell, the arguments in the GitHub PR mentioned below either
fall into the "non-RFC5280-compliant submission" (which is already covered)
or involve the implications of a particular log not being 6962-bis
compliant, which fall into the Client Behaviour category (implications of
the protocol on clients and servers' behaviour, not the protocol
specification itself).

This part of section 4.2. has been discussed on the list a year ago (
https://www.ietf.org/mail-archive/web/trans/current/msg02484.html) and
earlier (https://trac.ietf.org/trac/trans/ticket/73,
https://trac.ietf.org/trac/trans/ticket/21).

On Mon, Nov 20, 2017 at 7:22 PM, Al Cutter <[email-masked]> wrote:

> Hi all,
>
> I was trying to help (honest!) Rob Stradling with the outstanding AD
> comments from ekr on -bis27, and so we took an easy starter for 10:
>     [ekr] *"Why is this a 2119 MUST? It seems wise, but not necessarily a
> conformance requirement"*
> in regards to Section 4.2:
>
>> "To avoid being overloaded by invalid submissions, the log MUST NOT
>> accept any submission until it has verified that the certificate or
>> precertificate was submitted with a valid signature chain to an accepted
>> trust anchor.
>
>
> FWIW I agree with ekr on this (it's a policy statement, and, I believe, a
> potentially dangerous one to encode as an RFC MUST) and managed to persuade
> Rob of the same (at least that's what he said at the time), so he kindly
> put together a PR to change that MUST NOT to a SHOULD NOT:
> https://github.com/google/certificate-transparency-rfcs/pull/289
>
> Apparently not everyone sees it quite so clearly, and there's been a bit
> of a discussion on the PR, so in the interests of Transparency I wanted to
> call it out here too in case there's anybody who was not already aware of
> the PR and wants to get involved, again, on this well worn and comfy topic.
>
> Cheers,
> Al.
>
>
>
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>
>

---

From: Al Cutter <[email-masked]>
Date: Tue, 21 Nov 2017 19:33:59 +0000

> (1) "the log MUST NOT accept any submission until it has verified ..."

Actually it's just this one, I think the one below was included possibly by
mistake (I mentioned to that to Rob when I spotted it on the PR).

> Another consensus was established that logs should be allowed to drop
> valid submissions under load (to protect against DoS attacks) - which again
> is allowed by the SHOULD on the 2nd paragraph.
>
> To present from a different angle, if the MUSTs are changed to SHOULDs
> then (according to my understanding of RFC2119) logs will be able to claim
> that any accepted submission was not validated because the it wasn't
> checked. That would make monitoring difficult and submission
> non-deterministic (because a log would then be allowed to use other sources
> of intermediate CA certificates to complete a partially-submitted chain).
>
> RFC2119 says about SHOULD that "there may exist valid reasons in
> particular circumstances to ignore a particular item [...]" but I do not
> see a valid reason to ignore validation for some entries or allow
> acceptance of partial chains, where the 6962-bis goes to great length to
> ensure the submitted, valid chain is always presented to monitors.
>
> From what I can tell, the arguments in the GitHub PR mentioned
> below either fall into the "non-RFC5280-compliant submission" (which is
> already covered) or involve the implications of a particular log not being
> 6962-bis compliant, which fall into the Client Behaviour category
> (implications of the protocol on clients and servers' behaviour, not the
> protocol specification itself).
>
>>     [ekr] *"Why is this a 2119 MUST? It seems wise, but not necessarily
>> a conformance requirement"*

---

From: Rob Stradling <[email-masked]>
Date: Wed, 22 Nov 2017 11:55:01 +0000

On 21/11/17 19:33, Al Cutter wrote:
> 
> 
> On Tue, Nov 21, 2017 at 7:20 PM, Eran Messeri <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     [shortening subject]
> 
> Actually it's just this one, I think the one below was included possibly 
> by mistake (I mentioned to that to Rob when I spotted it on the PR).

Yeah, I misunderstood which MUSTs (in section 4.2) EKR (and Al) thought 
should be SHOULDs.

I've updated the PR.  This discussion is now only about whether or not 
that first "MUST NOT" should be changed to "SHOULD NOT".

 From the discussion on the PR, it seems that:
   - Eran and Andrew strongly prefer "MUST NOT".
   - EKR wrote "this is a WG decision" and so I presume he'll accept 
either "MUST NOT" or "SHOULD NOT".
   - Al is the sole proponent of changing it to "SHOULD NOT".

Al, can you live with "MUST NOT"?

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 22 Nov 2017 08:58:11 -0800

On Wed, Nov 22, 2017 at 3:55 AM, Rob Stradling <[email-masked]>
wrote:

>> On Tue, Nov 21, 2017 at 7:20 PM, Eran Messeri <[email-masked] <mailto:
>> [email-masked]>> wrote:
>>
>>     [shortening subject]
>>
>   - EKR wrote "this is a WG decision" and so I presume he'll accept either
> "MUST NOT" or "SHOULD NOT".
>

I'll accept MUST NOT as long as the MUST NOT is unambiguous. I thought it
was but the discussion in the PR suggests that it's not because we don't
know what the lax validation exception covers. As long as you have clarity
on that point then SHOULD NOT/MUST NOT is totally up to the WG.

-Ekr