[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Another DoS attack.
Hi,
I think DoS-resistant protocols should work in the following order:
(1) The responder carries out expensive (but initiator-independent)
computation.
(2) The initiator carries out expensive (and responder-dependent)
computation. This computation must also be session-dependent.
(3) With light computation, the responder checks whether the responder
has really completed (2).
(4) The responder carries out expensive (and initiator-dependent)
computation.
How about verifying the certificate in the step (4)?
(1) can be pre-computed.
If the resultant state is too large,
we can be helped by "stateless connection" (state materials are
encrypted by local secret key and sent back and forth
between the responder and the initiator. This encryption can be
a fast symmetric-key encryption and the key can be used many times.).
Please consult about details with
http://www.ietf.org/internet-drafts/draft-matsuura-sign-mode-01.txt.
Finally, I'd like to point out that
Base Mode (draft-ietf-ipsec-ike-base-mode-01.txt)
is aimed at DoS resistance but
it does not follow the protocol design direction
listed above as (1)-(4).
Signature-verification cost might probably exhaust
the responder's resource, for example.
Tamir Zegman <zegman@checkpoint.com> wrote:
>>I'm posting this message to both mailing lists as this issue concerns
>>them both.
>>
>>An attacker using either aggressive, main or base mode can send a
>>certificate whose RSA public key consists of a long modulus (16384) and
>>a non trivial exponent.
>>The responder will be left to do the exponentiation till hell freezes
>>unless of course his implementation limits the length of public key
>>signatures it is willing to verify.
>>A similar attack can be mounted using DSA.
>>This attack can be extended to other online protocols that use
>>certificates in which the responder is asked to verify a public key
>>signature.
--^^--
Kanta
References: