Subject: Re: [Sidrops] AD Review of: draft-ietf-sidrops-6486bis

From: Tim Bruijnzeels <[email-masked]>
Date: Wed, 1 Dec 2021 09:42:45 +0100

Hi,

> On 30 Nov 2021, at 20:30, Rob Austein <[email-masked]> wrote:
> 
> One thing that may not be immediately obvious to Warren: there's a big
> difference between NotBefore in certificates and ThisUpdate in CRLs
> and manifests.  Backdating NotBefore by some small amount makes sense
> given the possibility that clock skew might cause a certificate to be
> interpreted as invalid at the time it's issued, which could be bad.
> ThisUpdate is more of a tick mark recording the passage of time in the
> evolving history of a manifest or CRL: nothing terrible should happen
> in the case of clock skew, so as Steve suggests it's probably best to
> tell the truth about the time of publication.
> 
> Manifests have this extra twist in that the manifest CMS contains an
> embedded EE certificate which has a NotBefore, so one gets to invoke
> both of these rules at once while generating the same object, yay.

So, section 6.3 says:
"If the current time is earlier than thisUpdate, the CA has made an error"

It is also RECOMMENDED earlier that the EE certificate notBefore matches
thisUpdate.

As a CA I have every intention not to be sloppy and manage my own NTP,
but I feel vulnerable to RPs with sloppy NTP. I do not see what the
big deal is with back-dating five minutes. The object did not exist five
minutes ago, but if an RP lives 2 minutes in the past - why should they
reject me? What if my parent issued a covering ROA and I try to publish
a more specific, and it is rejected for this reason?

NOTE: For manifest and other RPKI Signed Objects there is also the option
of using the Signing-Time Attribute (section 2.1.6.4.3 of RFC 6488). In
my mind this is where the CA tells the truth about the time of signing.

Also note that there are different components involved in the chain.
When a CA signs a new manifest and uses *now* for notBefore, then there
will still be some delay before it is actually published by its
Publication Server (seconds to minutes). And then there is a further
delay before an individual RP picks it up. So, assuming that the CA and
RP NTP are in sync, the latter will always find things after the fact.

Speaking for my own implementation publication happens within seconds
after signing and that is when the first RPs will pick it up. For others
it may take minutes between signing and publications and therefore they
may be less afraid of RPs living in the very recent past.

Tim

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

---

From: Ties de Kock <[email-masked]>
Date: Wed, 1 Dec 2021 18:25:18 +0100

Hi all,

> On 30 Nov 2021, at 23:16, Job Snijders <job=[email-masked]> wrote:
> 
> Hi all.
> 
> Thank you Warren for your review, thanks Stephen Kent for responding.
> 
> On Tue, 30 Nov 2021 at 19:44, Stephen Kent <stephen.kent=[email-masked] <mailto:[email-masked]>> wrote:
> 
> > 2: S 4.2.2. Names in FileAndHash objects
> > "As an example, ’vixxBTS_TVXQ-2pmGOT7.cer’ is a valid filename."
> > I'm not sure where to make this comment (here or in the validation 
> > section), but I'm *assuming* that the case is "important" -- 
> > vixxBTS.cer != VIXXBTS.CER? There are some operating systems which are 
> > case insensitive for filenames (e.g: Mac OS can format a device as 
> > "Mac OS Extended (Journaled)" or "Mac OS Extended (Case-sensitive, 
> > Journaled)". I'm suspecting that this might be a corner case, and / or 
> > not really an issue for this document, but it seems like it may be 
> > worth having a reminder / note.
> 
> This text first appeared in version 3 of 6496bis, published in November 
> 2020, over a year ago. The text was proposed by Job Snijders. The topic 
> of case sensitivity, as well as some other aspects of the proposed text, 
> were discussed on the list from 11/19-11/24/20, by several WG 
> participants. I'm happy to add further clarification re case 
> sensitivity, if the WG agrees on what that clarification should be.
> 
> 
> I would like to suggest to leave this part of the document as-is.
> 
> I don’t recall there ever having been any ambiguity in the minds of either RP developers, or CA operators, on the topic of case sensitivity.
> 
> A contextual aspect is that each file (listed by name), also is addressable by its SHA256 hash, also listed on the manifest.

There also was some off-list discussion about edge-cases (such as RPs truncating
file names where the IA5String contains a null-byte). In the end the signature
on such a manifest shows the CAs intent.

It is extremely hard to get rules about file names right (length, null bytes,
name collisions) and I don't think these rules should be a major section here.
Perhaps there is another document we can refer to?

Kind regards
Ties

> Kind regards,
> Job

---

From: Stephen Kent <[email-masked]>
Date: Fri, 3 Dec 2021 14:23:29 -0500

Tim,
> ...
If an RP is sloppy re their time maintenance, they will have to retry 
the fetch, and eventually the problem will be resolved. We have no way 
to ensure that all RPs process newly posted info in a timely fashion, so 
this is just another factor that influences the speed with which PP data 
is acquired, validated, and used internally by RPs.
> may be less afraid of RPs living in the very recent past.

As you observed, different CAs may have different timing concerns. 
Still, if we don't direct RPs to pay attention to this field, it 
undermines confidence in the system. Experience from a number of PKI 
contexts shows that if RPs fail to enforce constraints on cert 
processing, bad behavior by CAs will go unnoticed and uncorrected for 
some time.

Steve

---

From: Warren Kumari <[email-masked]>
Date: Wed, 8 Dec 2021 17:57:39 -0500

Hi all,

I'm in the process of digging out from my mail backlog, getting all of my
ducks in a row before the new year starts, etc.

Just a reminder to post a new version when you have a chance, and then
SHOUT LOUDLY so I don't accidentally miss it!

Thanks,
W

-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra

---

From: Stephen Kent <[email-masked]>
Date: Thu, 9 Dec 2021 10:24:54 -0500

Warren,

I will have a new version generated and posted by next week.

To address the two outstanding issues I have made the following changes:

No one has provided a cite for a filename guideline, So, I have inserted 
the following text in 4.2.2:

The example above contains a mix of uppercase and lowercase characters 
in the filename. Some filesystems are case agnostic, while others are 
case sensitive. It is RECOMMENDED that CA employ only lowercase 
characters in filenames, but RPs MUST be able to process filenames that 
contain uppercase characters.

In section 6.3 I have revised the text to take into account Tim's 
observations:

If the current time isearlier than thisUpdate, the CA may have made an 
error or the RP’s local notion of time may be in error; the RP MAY 
choose to treat this as a failed fetch and proceed to Section 6.6.

Steve

---

From: Job Snijders <[email-masked]>
Date: Thu, 9 Dec 2021 16:49:42 +0100

Dear Stephen, Warren, group,

On Thu, Dec 09, 2021 at 10:24:54AM -0500, Stephen Kent wrote:
> No one has provided a cite for a filename guideline, So, I have inserted the
> following text in 4.2.2:
> 
> > The example above contains a mix of uppercase and lowercase characters in
> > the filename. Some filesystems are case agnostic, while others are case
> > sensitive. It is RECOMMENDED that CA employ only lowercase characters in
> > filenames, but RPs MUST be able to process filenames that contain uppercase
> > characters.

I am not sure the above paragraph aligns well with current operations.
Virtually all RIRs and CAs use a mixture of upper-case and lower-case in
their filenames. I believe virtually all RPs expect to run on
case-sensitive, case-preserving filesystems. The newly suggested
recommendation is somewhat at odds with what's currently deployed in the
wild, and I see no need to introduce friction or change in this regard.

POSIX.1 considers case-insensitive filesystems to be 'non-conforming'
filesystems. https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap02.html#tag_02_01_01
However, a POSIX reference is not ideal as draft-ietf-sidrops-6486bis
specifies the use of a subset of the POSIX portable file name character
set.

If I may suggest some text:

    """
    The example above contains a mix of uppercase and lowercase
    characters in the filename. CAs and RPs MUST be able to perform
    filesystem operations in a case-sensitive, case-preserving manner. 
    """

Kind regards,

Job

[1]: https://jakewharton.com/case-insensitive-filesystems-considered-harmful-to-me/

---

From: Stephen Kent <[email-masked]>
Date: Thu, 9 Dec 2021 11:58:31 -0500

Job,

I'm happy to adopt your text - it would have been nice to receive this 
input sooner.

---

From: Job Snijders <[email-masked]>
Date: Thu, 9 Dec 2021 18:03:05 +0100

> I'm happy to adopt your text - it would have been nice to receive this

My apologies; however it was your newly suggested draft text that
prompted me to immediately write a counter-proposal. Assuming a linear
sequence of events, I don't see how I could've delivered earlier :-)

All the best, and thank you for your good patience shepherding this -bis
document.

Kind regards,

Job

---

From: Job Snijders <[email-masked]>
Date: Thu, 9 Dec 2021 18:29:35 +0100

Hi all,

On Thu, Dec 09, 2021 at 10:24:54AM -0500, Stephen Kent wrote:
> > If the current time is earlier than thisUpdate, the CA may have made
> > an error or the RP’s local notion of time may be in error; the RP
> > MAY choose to treat this as a failed fetch and proceed to Section
> > 6.6.

I do not feel comfortable with this use of 'MAY', such a directive may
encourage RPs to act fast & loose with the interpretation of signed time
values, potentially violating "CA Intent".

The use of freely and pubicly available NTP sources on the Internet
EASILY brings RPs within a -/+ range of 1 (one) second (but likely
accurate in the order of tens of miliseconds). The Internet's routing
and forwarding system is able to deliver with jitter globally measured
in the low microseconds. Time signal is also beamed through the ether
for free: GPS, Galileo, GLONASS, or long wave: MSF, DCF77, WWVB.

I would leave the text as-is, or suggest to change the MAY to MUST:

    """
    If the current time isearlier than thisUpdate, the CA may have made an
    error or the RP’s local notion of time may be in error; the RP MUST
    choose to treat this as a failed fetch and proceed to Section 6.6.
    """

Timing matters not just for the Manifest's eContent thisUpdate value,
but likewise the Manifest's EE cert, and the CRL's thisUpdate, and the
parent's validity window. Let's please not open Pandora's box and do
away with the concept of globally agreed upon time.

CAs should not attempt to compensate for *potentially* broken RPs, as
that puts a burden on everyone; it is safer to let broken RPs be broken.
Hopefully the RP administrator at some point in time takes an interest
to fix the RPs notion of time.

In rare cases where an RP is out-of-sync within a margin of a few
minutes, things will probably work 'as expected' after the next
validation run. So at worst a 10-50 minute delay takes place (because
the RPs clock is broken). However, in my experience RPs that have broken
time, are likely to be living in the early 70s... such RPs should not
produce VRPs.

Kind regards,

Job

---

From: Tim Bruijnzeels <[email-masked]>
Date: Fri, 10 Dec 2021 11:17:33 +0100

Hi Job, Steve, all..

> On 9 Dec 2021, at 18:29, Job Snijders <job=[email-masked]> wrote:
> 
> Hi all,
> 

First of all.. my apologies if my concerns were confusing. I did indeed
raise them in response to a question Warren raised about section 6.3. But,
I agree with Job on the above - as far as I can see.

I think it would not be desirable to have a MAY as it will lead to differences
between RP implementations, discussions and grief. And I lean towards
making the RPs be strict.

What I was driving at (or meant to anyway) is that I would like it to
be understood and condoned that the CA can use backdating in this case,
of course within measure (which would be section 4.2.1). See below.

> to fix the RPs notion of time.

Well, as you said, even if NTP works optimally on both ends there can
be a second variance (perhaps two if you count both ways). So, I think
that at least a couple of seconds backdating should be acceptable based
on that alone.

I understand that it's unlikely that an RP will see a new manifest this
fast, but it's not impossible if your CA and Publication Server are
fast.

> time, are likely to be living in the early 70s... such RPs should not

Perhaps.. but then again.. if I publish new ROAs to allow new announcements
or fix existing announcements that were invalid due to an earlier error,
then I may not want to have to wait until other parties beyond my control
accept my fix. Even if they are running on under-resourced VMs and run a
few minutes behind (they shouldn't, but it happens).

More importantly though, I think that in this particular *context* the
backdating would be harmless. I worry about replays in the future, but
I do not worry about replays in the past - because this object did not
exist then. I am also not trying to publish anything that should be
considered invalid until some point in the future.

So, if I backdate by a few minutes then this is actually intentional.
I am saying that I don't mind if you live a bit in my past - this manifest
should be valid because I know I just made it. I want it to be valid
until it's either expired (protect against future replays) or (better)
replaced by a new manifest and revoked on that new manifest's CRL.

So, in my view being strict here on backdating does not improve the
security - while it can lead to ROA fixes for invalid announcements
taking longer to propagate. In other words there is little (or no?)
gain, but there is pain.

If I am wrong about the security risk of backdating in this context
then please point out how. I would be happy to learn.

Kind regards,
Tim

---

From: Stephen Kent <[email-masked]>
Date: Tue, 14 Dec 2021 16:44:11 -0500

Tim,

> I agree with Job on the above - as far as I can see.

Yes, your concerns, as stated we VERY confusing, which the only reason I 
changed the text in question.

I will change the 'MAY" back to "MUST" and publish the revised document.

Steve