Re: [tcpm] question about TCP-AO and rekeying

[Eric Rescorla <[e-mail]>]

At Wed, 17 Jun 2009 22:19:30 -0700,
Joe Touch wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Eric Rescorla wrote:
> > At Wed, 17 Jun 2009 21:52:16 -0700,
> > Joe Touch wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >>
> >>
> >>>>> If so, the entry fails. If that's what
> >>>>> you mean by "prohibit overlaps", yes, I think we should
> >>>>> prohibit overlaps. 
> >>>>>
> >>>>> If what you mean is that two MKTs with different key-ids can't overlap
> >>>>> the same socket pair space, I don't see a problem with that.
> >>>> That is a problem for outgoing SYNs. For those, either the connection
> >>>> has to know a-priori which ID to use, or we need to make sure MKTs can't
> >>>> overlap at all (ignoring keyIDs).
> >>> I'm sorry, but I don't see why. 
> >> So let's consider outgoing SYNs.
> >>
> >> Consider a system with two MKTs:
> >>
> >> 	MKT alpha	from ANY:ANY to JOE:80	KEYID=4
> >>
> >> 	MKT beta	from ANY:ANY to ANY:ANY	KEYID=5
> >>
> >>
> >> So my web client wants to connect to JOE:80. The web client has not been
> >> modified to indicate a desired KEYID; I doubt many apps will be so
> >> modified. So I'll need to ensure that the socket pair of the SYN matches
> >> only one MKT.
> >>
> >> That means I can't have default keys, like beta.
> > 
> > Why on earth would you want to do this? The misquote Dr. Strangelove,
> > "the whole point of a cryptographic key is lost unless you keep it
> > a secret. Why would you tell the world?"
> > 
> > Since almost every other machine on the Internet isn't going to 
> > have key beta, you're going to get packets that aren't protected
> > with AO, in which case you'll have to discard them. Configuring
> > your system this way is mostly useful for breaking TCP
> 
> It's a bit overgeneralized above, but clamp it down a bit more and it
> might still make sense, e.g.:
> 
> 	alpha		from ME:ANY to JOE:BGP KEYID=6
> 	beta		from ME:ANY to JOE:ANY KEYID=7
> 
> I.e., I may want to lock BGP with a different key than other connections
> between the two, but OK to use a single key for the rest.

Why would you want to do this?

The configuration you propose would still leave you vulnerable to
packet injection by someone who knew key alpha. 

Going up a level, I'm skeptical of this entire line of argument.
The existing rationale for this technology (BGP DoS prevention)
doesn't really justify engineering for extensively complicated
key use policies.

-Ekr