[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-pkix
Subject:    Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
From:       Stephen Kent <kent () bbn ! com>
Date:       2009-08-19 16:15:19
Message-ID: p0624080ac6b1d53f0269 () [128 ! 89 ! 89 ! 40]
[Download RAW message or body]


A
>...
>
>On a new topic: Another concern I have is that there's a DoS attack 
>when the attacker sends a really big bogus signture and the client 
>has to spend time figuring this out.  We had a long discussion about 
>this on the SMIME list.  We added a security consideration in 
>draft-ietf-smime-3851bis as follows:
>
>  Receiving agents that validate signatures and sending agents that
>  encrypt messages, need to be cautious of cryptographic processing
>  usage when validating signatures and encrypting messages using keys
>  larger than those mandated in this specification.  An attacker could
>  send certificates with keys which would result in excessive
>  cryptographic processing, for example keys larger than those mandated
>  in this specification, which could swamp the processing element.
>  Agents which use such keys without first validating the certificate
>  to a trust anchor are advised to have some sort of cryptographic
>  resource management system to prevent such attacks.

I agree that analogous text would be appropriate here.

>>...
>
>There are 2 tables in RFC 5480.  The 1st lists the possibilities for 
>ECDSA but the 2nd (on page 10) provides some RECOMMENDED key sizes, 
>hashes, and curves for a given # of bits of security.  What I was 
>saying is that if we use that table, then we could infer everything. 
>But, the group will need to agree to that.

I like referring to such tables as a way to keep things simple, and 
increase the likelihood of interoperability.

Steve

[prev in list] [next in list] [prev in thread] [next in thread]