Re: [Trans] Section 4.2 follow-up

[Eran Messeri <[e-mail]>]

To follow up on some of the points raised in the issue:

Examples of chains that are allowed under the current text:
* RFC5280-compliant leaf -> intermediate -> trust anchor.
* RFC5280-compliant leaf -> intermediate -> TA, where the leaf or one of
the intermediate are revoked or not temporally valid (I don't know of any
logs that do revocation checking currently).
* Non RFC5280-compliant leaf (for example, BER-encoded instead of DER
encoded) -> intermediate -> TA.
* leaf -> intermediate1 -> intermediate2 without the trust anchor (however
when the log stores and serves the chain it must serve the trust anchor
used to accept the submission).

Examples of chains that are not allowed:
(1) Incomplete chain: leaf -> intermediate1 , missing intermediate2 ->
trust anchor.
(2) leaf -> intermediate -> trust anchor _not trusted by the log_.
(3) leaf -> intermediate -> trust anchor, where the signatures either by
the intermediate or the TA do not validate.

In PR289 <https://github.com/google/certificate-transparency-rfcs/pull/289>,
the suggestion was to change the MUST restricting chains (2), (3) from
being admitted at all, to a SHOULD, so such chains may be admitted under
some circumstances (that is, AFAIUI, the meaning of SHOULD in RFC2119).

The arguments were:
* Chrome CT policy requires CT logs to be RFC compliant.
* A bug in a CT log implementation could lead to accepting a submission
that doesn't chain to a trust anchor accepted by the root.
* Such a bug would make the CT log non RFC-compliant, and so subject to
removal from the set of logs trusted by Chrome.

I do not think this is a strong argument in favour of these changes because:
* The Chrome CT policy can be changed to accommodate some deviations from
the standard (Chrome's policy is dynamic and may change at any time).
* There have been cases where a log incorrectly accepted chains that do not
terminate in an accepted TA (Rob Stradling has found at least one). In
those cases the log was not disqualified from Chrome.
* Most importantly, it further burdens monitors and log clients - which
will have to investigate, and be able to cope with, corrupted chains. There
are already quite a few certificates in 6962 logs that require particularly
lax parsers and some CT log clients already resort to their own fork of DER
parsers / X.509 decoders. I think perpetuating this situation in unhealthy
in the long term.
* These MUST statements are there to guide implementation - to make it
clear that no 6962-bis implementation should admit submissions unless it
can check their validity.

While I can appreciate that the narrow view of a log operator would favour
as few restrictions on the log as possible, relaxing the requirement that
each chain is signed correctly and terminates at an accepted TA does not
make sense for the overall protocol. The CT protocol is already biased
towards ease of log implementation and I don't see a reason to tip the
balance further towards log implementation (given it has already been
demonstrated in the workgroup that finding feasible, privacy-preserving
methods to audit logs or get stronger security guarantees from them is
hard).

Eran


On Wed, Nov 22, 2017 at 4:58 PM, Eric Rescorla <[e-mail]> wrote:

>
>
> On Wed, Nov 22, 2017 at 3:55 AM, Rob Stradling <[e-mail]>
> wrote:
>
>> On 21/11/17 19:33, Al Cutter wrote:
>>
>>>
>>>
>>> On Tue, Nov 21, 2017 at 7:20 PM, Eran Messeri <[e-mail] <mailto:
>>> [e-mail]>> wrote:
>>>
>>>     [shortening subject]
>>>
>>>     Two MUSTs are being discussed:
>>>     (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).
>>>
>>
>> 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".
>>
>
> 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
>
>
>
>
>
>>   - 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
>>
>>
>> _______________________________________________
>> Trans mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/trans
>>
>
>