[Monotone-devel] hypothetical - future-dated certs (Re: Monotone Security)

[Daniel Carosone]

This is a little bit of a diversion into the abstract and
hypothetical, and may serve no practical purpose whatsoever - so I've
changed the subject accordingly.  Don't feel obliged to follow me down
this rabbit-hole. 

On Fri, Oct 17, 2008 at 08:30:17PM +0200, Markus Wanner wrote:
> Zack Weinberg wrote:
> > Yes.  Distributed systems research has concluded that there ain't no
> > such thing as a trustable global clock.  (I don't have cites - this is
> > my paraphrase of something Nathaniel said some years ago.)
> 
> While that's certainly true, I also agree with Daniel that there's
> something wrong with revisions A -> B having timestamps in reverse ordering.

I'm not so sure..  I'd happily go for 'strange' or some other word,
rather than 'wrong'.   At the very least, I'd like to try and work
through all the cases we can think of where this might arise, and just
confirm whether a sensible or legitimate interpretation could have
been intended.  If we fail to come up with any, fine.  If we do,
perhaps we'll have a new and interesting use case to consider
supporting properly..

> IMO monotone should at least warn about such obviously ill-certified
> revisions, better yet protect against such wrong information. 

No issue with intelligent situational reporting to help discovery of
something unusual, like clock skew.

The question remains, however: when something like this is detected,
what should either the user or the software do to resolve the issue?
Let's say I decide to add another date cert with a more reasonable
value; this doesn't and can't get rid of the old one, so nothing is
really solved.  

In particular, my concern is that despite agreeing and acknowleding
that there can't be a global clock, warnings or errors like this help
to encourage in the users' minds that there is a global clock anyway.
I worry that this will just lead to confusion, rather than encouraging
users to fully embrace the realities of the distributed/disconnected
world.  

> That's one reason for my work on nvm.dates: being able to compare
> the dates, so we can do these checks.

Again, fully support this, just not sure how it should be used.
Giving room to experiment and discover how it should be used is a good
end in itself.

> So with refusing to commit revisions with a date *before* its ancestor,
> monotone would help detecting clock skews. And by warning and (possibly
> automatically) distrusting certs from the future, monotone could prevent
> situations where you cannot commit because someone else has signed a
> revision with an erroneous date. Keep in mind that you can always decide
> to *not* trust a cert with an invalid date.

Understood.  Despite the fact that there seems to be a contradiction
between these two points, I can see a workable and useful result.

However, I don't think it makes much sense in the current cert model,
where date certs are detached from others.  Dates just aren't that
important. 

It seems to me to be a much more relevant thing to consider as part of
cert format rewrites, when we add a signing-date to certs, and that it
should be applied to the signing-date rather than the basic date.  At
that point, signing a cert with a future date *could* be used to delay
the validity of a cert until some future date.  However, if something
like that does turn out to be legitimately useful, my opinion is that
it should be via explicit valid-from and valid-until (optional) cert
fields, rather than by trying to overload the signing date.

I could think of some uses for this, perhaps in the area of automated
distributed testing, but it's a stretch and I'm not sure that explicit
cert dependencies (this cert replaces that cert) would still not be a
better way than a clock.

--
Dan.

pgplDadty3CtF.pgp
Description: PGP signature