Subject: [Sidrops] Validation violations

From: Randy Bush <[email-masked]>
Date: Sun, 08 Mar 2020 16:31:23 -0700

http://valid.rg.net:8080/trust-anchors is not ideal

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 8 Mar 2020 23:38:07 +0000

> http://valid.rg.net:8080/trust-anchors is not ideal

a commitment to long-term stability?

Overwhelming weariness because changing root certs is such a drag?

Something else?

Nick

---

From: David Conrad <[email-masked]>
Date: Sun, 8 Mar 2020 16:46:05 -0700

One might make a comparison to the expiration of the DNSSEC root trust anchor…

Regards,
-drc

> On Mar 8, 2020, at 4:38 PM, Nick Hilliard <[email-masked]> wrote:
> 
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops

---

From: Randy Bush <[email-masked]>
Date: Sun, 08 Mar 2020 17:21:41 -0700

> http://valid.rg.net:8080/trust-anchors is not ideal

yes, alex; that's an old version.  :)

i just give the grad stuents a vm; not control it.

randy

---

From: Matthias Waehlisch <[email-masked]>
Date: Mon, 9 Mar 2020 01:52:38 +0100

I can update tomorrow (even though i'm not sure whether this is only a 
sw update problem). we run the old version because my impression was 
that Validator 3.x was less stable than previous versions. anyhow, think 
about the other deployments ... fixing one version doesn't help to 
improve the ecosystem.

Cheers
  matthias

-- 
Matthias Waehlisch
.  Freie Universitaet Berlin, Computer Science
.. http://www.cs.fu-berlin.de/~waehl

---

From: George Michaelson <[email-masked]>
Date: Mon, 9 Mar 2020 10:59:00 +1000

Upgrading to 3.1 is sensible. its a better codebase.

But, not all of the problems go away simply by updating: Some of this
is down to what I call 'incoherent' state in the publish cycle. Being
able to fetch a manifest and CRL which don't align in time with the
repository state is not good.

-G

On Mon, Mar 9, 2020 at 10:56 AM Matthias Waehlisch
<[email-masked]> wrote:
> ..  Freie Universitaet Berlin, Computer Science
> ... http://www.cs.fu-berlin.de/~waehl
>

---

From: Nathalie Trenaman <[email-masked]>
Date: Mon, 9 Mar 2020 09:46:28 +0100

+1 for upgrading to 3.1. As for the problematic repos in the RIPE region, we do try to chase them to fix things. Not sure if we should though. 

Nathalie

> Op 9 mrt. 2020, om 01:59 heeft George Michaelson <[email-masked]> het volgende geschreven:
>

---

From: Tim Bruijnzeels <[email-masked]>
Date: Mon, 9 Mar 2020 10:40:52 +0100

Hi,

So, Nathalie, I think you are now referring to the issues listed on this page under the TAs, which are actually issues with CAs in the tree of a TA.

To the casual reader they look like they are the responsibility of that TA, and I guess I am partly to blame for that, going back to working I did on this page at RIPE NCC.

But, this raises questions that I would like to ask sidrops: Do people think that parent CAs should actively monitor delegated CAs? In case they produce errors and don't fix them.. should any action be desired? Ultimately the parent can reach out only so much, and then come to a point where they can only revoke a child - which is rather drastic. I think a lot of this comes down to agreements between the parent and the child as well. I am not sure that we force this as a technical community.

So, while these things stick out, we may have to accept that unreachable repositories, and unmaintained (stale as well as expired) publications by CAs, are a reality in delegated RPKI.

Personally I think that parent CAs, especially the RIRs should seek to provide publication services to others, so that the number of repositories and repositories with issues can be managed.

But with more delegated CAs popping up I found that there are other things that should be considered, like:
- maybe we should extend the publication protocol to be able to enforce limits (size and number of objects, possibly even only allow syntactically correct RPKI objects)
- maybe parents should monitor for children who make millions of ROAs, or delegations, or which try to create validation loops. (e.g. in their own repository)

I think that in spirit the parent CAs keep an eye on these things, and they can revoke reactively. I am not even sure that we can dictate good parenting practice in this forum. But, I do think it's a discussion that we need to have.

Tim

> On 9 Mar 2020, at 09:46, Nathalie Trenaman <[email-masked]> wrote:
>

---

From: Randy Bush <[email-masked]>
Date: Mon, 09 Mar 2020 04:22:02 -0700

[ cc:s trimmed as everyone is on the ml ]

tim,

> Do people think that parent CAs should actively monitor delegated CAs?

should i test dns delegations for lameness, bad keying, ...?  you
betcha.

> come to a point where they can only revoke a child

different question.  what to do with various forms of breakage.  but if
a child is causing a public problem, yes, dire measures may be needed.

> So, while these things stick out, we may have to accept that
> unreachable repositories, and unmaintained (stale as well as expired)
> publications by CAs, are a reality in delegated RPKI.

i am not so comfortable with this.

> Personally I think that parent CAs, especially the RIRs should seek to
> provide publication services to others, so that the number of
> repositories and repositories with issues can be managed.

when designing this stuff, we assumed that the number of CAs would be
anaologous to the number of IRR instances, O(100),  if that asumption
does not hold, then we will have a management and correctness problem.

> - maybe we should extend the publication protocol to be able to
>   enforce limits (size and number of objects, possibly even only allow
>   syntactically correct RPKI objects)

uh, yes.  i think that was assumed.  if it is not stated in the rfc,
save it for the bis.

> - maybe parents should monitor for children who make millions of ROAs,
>   or delegations, or which try to create validation loops. (e.g. in
>   their own repository)

i.e. we need to prepare to deal with malicious CAs.

> I think that in spirit the parent CAs keep an eye on these things, and
> they can revoke reactively. I am not even sure that we can dictate
> good parenting practice in this forum. But, I do think it's a
> discussion that we need to have.

yep

randy

---

From: George Michaelson <[email-masked]>
Date: Tue, 10 Mar 2020 08:28:08 +1000

We reach out to child CA's regularly. The responsiveness is a function
of leave and other factors getting in the way of remediation. Asking
them whats up and asking for a re-publication feels like the best we
can do because telling them to do things or else is simply not in our
role. Cryptographic/Validation invalidity makes things invalid that
are harmful. The rest is confusing.

I don't think all problems stem from operator confusion: I believe a
lot of the MFT/CRL mismatch is coming from engines which do in-place
publication and so create downloadable states which are not in the
collection list or the repudation list. I think doing work in a side
directory and a single (semi atomic) mv is probably better from a
coherence point of view, but even between RRDP and rsync there are
disagreements about state and they are not publishing the same
physical on-disk filestate, even if they are assertions about the same
signing events. (I say this observing how things exist in the tree
when I run code) -If the code bases actually do the clone-dir mv trick
then I guess it must be something else.

The "time of day went backward" thing I think is lack of clock sync
between operational nodes. Do we need to work on some granularity like
5min or do we obligate NTP time sync? I obviously believe in the
latter but even NTP consists of de-cohered islands of time. There
might be some time dither we need to live with. A minute?

There is a persisting overclaim on the edge of the tree rooted in
APNIC, under a sub-CA. I am talking to them about this, why it
persists. It should not persist. That it does worries me, because no
CA code I know of will sign over a child certificate which has
overclaim in the 3779 so it must be persisting state in a child which
hasn't re-synced in up-down, to operate with an overclaim (or, long
lived product which is not being repudiated)

I run two validator instances locally, same codebase, and they do not
agree much of the time about the intermittent states of invalidity. It
might only be single digit variances, but none the less, two fetches
within 1-2 minutes of each other do not always get the same state,
which them persists for up to 3600 seconds.

---

From: Claudio Jeker <[email-masked]>
Date: Tue, 10 Mar 2020 08:30:18 +0100

> might be some time dither we need to live with. A minute?

Please do not add specifc workarounds to RPKI X509 checking that is not
part of X509 itself. When writing a validator we depend on using the X509
validators that are well tested and used for SSL/TLS. Not being able to
use the default validation function is a source of major bugs since X509
validitation is complex and fragile. The publisher of RPKI
resources can solve this issue by issuing certs, crls, etc with
timespans that include a bit of extra time.
So just reduce the 'Not Before' time by Xmin and increase the 'Not After'
time by Xmin.

-- 
:wq Claudio

---

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 10 Mar 2020 09:02:24 +0100

Hi

> On 10 Mar 2020, at 08:30, Claudio Jeker <[email-masked]> wrote:
> 

I am not sure that George suggested that the workaround should be in the validation code. For what it's worth
Krill uses 5 minutes before now when issuing things just to be safe. We expect that people use NTP. It's not as not as perfect as we would hope, and five minutes should be ample to accommodate for it.

I am not sure what other CA implementers do, but I would expect that at least some of them already do this as well.

Tim