Re: [Trans] Section 4.2 follow-up

[Eric Rescorla <[e-mail]>]

On Thu, Dec 14, 2017 at 2:26 AM, Eran Messeri <[e-mail]> wrote:

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

What about leaf -> non-CA cert -> trust anchor? That seems to conform to
the requirement that it have a valid signature chain.



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

As I said in my comment, I think it's ultimately a wg decision what to do
here, as long as the MUST is unambiguous (otherwise it doesn't conform to
our basic requirements). So, my purpose here is primarily to ensure
non-ambiguity.

With that said, these aren't the arguments I was offering. Rather, I was
saying that the MUST is guidance to how a log should operate, but it's not
required for interoperability, and potentially not for security (at most
for DoS, it seems?), so I'm not sure it really belongs in this document.

-Ekr


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