Re: [Sidrops] mft/ee validity time window alignment issue - Re: I-D Action: draft-ietf-sidrops-6486bis-05.txt

Hi Job,

> On 9 Jul 2021, at 12:59, Job Snijders <job=40fastly.com@dmarc.ietf.org> wrote:
> 
> Hi,
> 
> On Fri, Jul 09, 2021 at 12:39:48PM +0200, Tim Bruijnzeels wrote:
>>> On 8 Jul 2021, at 20:09, Job Snijders <job=40fastly.com@dmarc.ietf.org> wrote:
>>> I think the latest changes looked great on paper (and indeed simplify
>>> the text significantly), but are not operationally feasible.
>>> 
>>> Quoting from draft-ietf-sidrops-6486bis-05 section 4.2.1 "Manifest":
>>>> Because a "one-time-use" EE certificate is employed to verify a
>>>> manifest, the EE certificate MUST have a validity period that
>>>> coincides with the interval from thisUpdate to nextUpdate in the
>>>> manifest, to prevent needless growth of the CA's CRL.
>>> 
>>> It appears there are quite some CAs out there where 'nextUpdate' and
>>> 'notAfter' are not equivalent, I estimate it would reduce the global VRP
>>> count from ~ 263,175 down to ~ 209,931.
>> 
>> Indeed, I mentioned that Krill is doing it wrong (or well following
>> earlier discussions but let's not dwell).
>> 
>> The fix is in the 0.9.1-dev branch but will take time to be deployed.
>> There may also be other CA implementations which are affected by this.
>> Though generally speaking hosted CA services could re-issue all their
>> objects without the need for users of the service to upgrade.
> 
> Other CA implementations also appear impacted. What I meant with 'not
> operationally feasible' is that we'd have to wait for all CAs to be
> upgraded, then to upgrade all RPs to add the '-05 check', and all this
> work would take place merely to decrease CRL traffic.
> 
> If we are looking to decrease traffic, I'd first remove XML from RRDP as
> that appears a 50% bloat compared to using DER as container :-)
> 
> Given the sheer amount of upgrade work, and the particular order 'first
> CA' -> 'then RP', I just don't see the current text as feasible.
> 
>>> I suspect the best we can do is demand that the EE certificate validity
>>> window fully encompasses the Manifest validity window described in the
>>> eContent, and merely recommend to align the two...
>> 
>> It may be appropriate to differentiate between what a CA MUST or
>> SHOULD do and what an RP MUST reject.
>> 
>> What I am after is that I think:
>> - a CA SHOULD (not MUST) have a validity period that coincides with the interval from thisUpdate to nextUpdate
>> - an RP MUST reject a manifest if:
>>    - thisUpdate is after now
>>    - nextUpdate is before now
>>    - EE not-before is after now
>>    - EE not-after is before now
> 
> You'll also want to check if nextUpdate is not before thisUpdate!
> 
> The below link shows how rpki-client validates thisUpdate and
> nextUpdate:
> 
> https://github.com/openbsd/src/blob/01ae73c5eb2d059ceb1d1734f72282cefb78d440/usr.sbin/rpki-client/mft.c#L82-L120
> 
>> One other note. NTP not being as perfect as we would like, I would
>> advise backdating the 'thisUpdate' and not before a tiny bit, say 5
>> minutes. 
> 
> Can you elaborate on your concern related to NTP and the need for
> backdating?

I would suspect that Tim’s concern is that a certificate is effectively published
and read by an RP before its validity period starts according to the local clock
of the RP.

I have encountered this when using a VM where the clock had drifted.

I would expect that there is a fair amount of clock drift between RPs and issuing
at the ‘current’ time gives a risk of objects being rejected by (a few) RPs.
> 
> I suspect that in this context it might not be needed to document such a
> recommendation given that the WG appears to have agreed that polling
> more frequently than once every ten minutes shouldn't happen, and the
> publication server usually has some delays here and there in the
> pipeline anyway (such as copying newly issued objects into a spool
> directory).
> 
> Promoting the concept of backdating will probably bite us when we get a
> proper Certificate Transparency project on the road. I expect that the
> log operators and the certificate issuers will have their clocks synced
> well within 5 minutes of slack.

As far as I know backdating a tiny bit is common for web CAs (where CT
is common).

I could not quickly find a statement on “notBefore < now” in
the CAB forum guidelines, but backdating is on the list of problematic
practices of Mozilla [0] except for technical compatibility reasons - which this
five minute window is in my opinion.

When CT is used. I would encourage CT logs to only issue a SCT for a
pre-certificate that has a “reasonable” validity period - I could see, and
would encourage, both limitations on notBefore and validity period being
enforced there.

Kind regards,
Ties

[0]: https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Backdating_the_notBefore_Date
> 
> Kind regards,
> 
> Job
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops