Re: [Rescert] Another attempt to round off the IR-ISP protocol

["Steven M. Bellovin" <smb@cs.columbia.edu>]

On Tue, 05 Jun 2007 17:10:05 +1000
Geoff Huston <gih@apnic.net> wrote:

> Rob Austein wrote:
> > So, at this point I think we have two real issues, and some trivial
> > stuff.  I'm going to ignore the trivial stuff for now.
> > > 1) On the replay protection thing: Randy and I have been talking
> > > to
> >    Steve Bellovin, and while we haven't quite converged yet it looks
> >    like the simplest answer is to follow RobK's earlier suggestion:
> >    just make the msg_ref a monotonically increasing integer, no CMS
> >    timestamp required, no reset mechanism required, done, full stop.
> >    The likely implementation would be to generate the msg_ref value
> >    from a clock on the sender side, eg, nanoseconds since epoch, but
> >    it really doesn't matter so long as it's monotonically
> > increasing. The CMS timestamp doesn't isn't fine enough for this,
> > and combining CMS timestamp with an additional value has timing
> > screws, so let's just keep this simple and go with the counter.
> > >    Steve Bellovin doesn't quite believe this yet but I think that
> >    Randy and I can convince him.  We'll keep you posted.
> > We've talked about this approach as well, and there are a few nits
> > that continue to be bothersome when thinking about this:
> 
> 1. How old (in terms of CMS signing time) a message are you as a
> server prepared to accept? Should be be a limit, or are we happy
> processing messages that purportedly were signed years ago?

I think that that's a separate issue.  I agree that some limit is
needed.
> 
> 
> 2. What happens as a client when you are using a simple incremented
> counter for msg_ref and you reboot? How do you resume msg_ref?

That's the reason not to use msg_ref.
> 
> 3. If the answer to q2 is the clock (as per your note above) what
> happens as a client if NTP sets your clock backwards in time? Or just
> freezes the clock?
> 
We're already assuming time that's correct +/- 60 seconds; there's no
difference in my proposed scheme.

The whole point of something that's purely clock-driven is to avoid the
need for non-volatile client state.  We're talking about secured
objects, rather than secured transmission, which means that things like
nonces are very much harder to use.  (Exception: we probably could use
hash chains, though I haven't worked this out in detail.  Apart from
complexity, see your local IPR lawyer.)

The point where I currently disagree with Rob and Randy is on the
granularity of the timer.  Whatever granularity is chosen bounds the
maximum signing rate.  Thus, if you use a 1-second clock, you can't
sign more than 1 object/sec.  (Well, you can cheat and "borrow" from
future seconds, up to the actual clock skew, but that does cut your
margin.)  If we go with a nanosecond timer, we're limited to 10^9
objects/sec, ever.  I'm not convinced we can predict the future well
enough to know that that's reasonable, so I've suggested that the spec
support fractional seconds -- we can always extend the number of
significant digits to the right of the radix point without a protocol
change.

That said, I think that a fixed-granularity timer is fine if someone
will do the quantitative analysis to show what the bound should be.  I
don't know the subject area quite well enough to do that, I suspect.
(Aside: back in 1979, I predicted that Netnews would grow to 50-100
computers and 1-2 messages/day.  We designed A-news accordingly.  Ever
since then, I've been been leary of making traffic forecasts.  As either
Yogi Berra or Niels Bohr said -- see Wikipedia -- "It is very difficult
to make an accurate prediction, especially about the future.")

		--Steve Bellovin, http://www.cs.columbia.edu/~smb