On Sat, 2005-02-05 at 21:49 +0000, John Levine wrote:
draft-housley-mass-sec-review-00.txt
Most of it's pretty good, but section 4.1 on replay attacks is
just wrong. It misunderstands what signatures do.
The only difference between a replay attack and normal mail forwarding
is intent. The bits are the same. I see a few possible ways that one
might try to deter replay attacks, none of which strike me as being at
all practical.
Replay attacks are only part of the problem a method to revoke
authorization would address. Today the warehouse has more than half the
windows broken. Repairing the broken window is not much different than
shunting a compromised PC. Providing each user with a unique public key
would be wasteful however.
Allowing the signature to include an opaque account identifier, perhaps
derived from the provider's access server or the customer's permanent
LAN address, would be useful to both shunt compromised systems and to
block replay attempts. Where there is no consistent account or where
anonymity is desired, a unique sequential number could be used as an
identifier instead.
Whether the provider themselves or some third-party offered a type of
blackhole-listing of these identifiers, prompt action at repairing the
broken window, so to speak, should reduce the likelihood of other
windows becoming broken. Not having such a mechanism ensures breaking
windows (replay attacks and compromised systems) remain profitable.
A common signature remaining valid for a couple of weeks would not offer
protection from replay abuse, nor would the signature be useful as a
means to exclude compromised systems. 2048 bit keys and millions of
users per domain also causes per-user keys to be complex in terms of
deployment due to the scale of such information over DNS.
A technique based upon the current widespread practice of blackhole
listing would allow rapid revocations to occur, while still allowing a
common signature. The provider would not need to do anything, but they
could publish this information themselves, as the authoritative, least
expensive, and hopefully the fastest method to distribute this
information.
The information could take the form:
<opaque-identifier>._rl.<signature-domain>
or
<opaque-identifier>._rl.<signature-domain>.<third-party-domain>
A convention of _null as an identifier when an identifier is not
included within the signature would allow third-party reputations to be
used consistently with or without such an identifier. Most domains
should not require an identifier. Larger domains, where per-user keys
are a greater difficulty, a blackhole-listing mechanism should actually
be less complex to implement than any other scheme. When the response
is prompt, there should be but a few accounts that even need listing.
This mechanism, used together with signatures, should save time and
revenue. For large domains, not doing so would be a missed opportunity.
-Doug