Re: [TLS] Re: Russ Housley: Fwd: problems with draft-ietf-tls-openpgp-keys-10.txt

[Eric Rescorla <[e-mail]>]

"Kyle Hamilton" <[e-mail]> writes:

> On 7/1/06, Eric Rescorla <[e-mail]> wrote:
>> "Kyle Hamilton" <[e-mail]> writes:
>>
>> > On 7/1/06, Nikos Mavrogiannopoulos <[e-mail]> wrote:
>> >>
>> >> Maybe the wording wasn't clear. Would an update to the security
>> >> considerations text like the one below be more clear to you?
>> >>
>> >>          Security considerations about the use of the web of trust or
>> >>          the key verification procedure are outside the scope of this
>> >>          document and are considered issues to be handled by the
>> >>          application layer protocols.
>> >
>> > Security considerations that have anything to do with identity key
>> > verification and entity mapping (pre-shared keys, PKIX, web-of-trust),
>> > and the corresponding authorization to use the application being
>> > protected, are outside the scope of this document.  These are
>> > considered issues to be handled by the application layer protocols, or
>> > at the very least by the TLS implementation in accordance with
>> > key-interpretation protocols that are separately described.
>>
>> I don't think any of the below material is really relevant
>> here. It's just boilerplate that applies to any crypto
>> protocol
>>
>> [...snip...]
>>
>> This is duplicative of RFC 1984.
>
> Then reference RFC 1984 in the Security Considerations section.  I
> don't particularly care where they're written, but these are
> considerations which need to be taken into account by every TLS
> implementor and administrator -- and just because you already know
> about it does not mean that everyone else does.  If someone decides to
> read up on how the TLS protocol works by reading the document (even if
> they're not implementing the protocol per se but even using it) it
> would be a good idea to put it in.

No.

RFC 4346 already has a reference to RFC 4096 (the current randomness
requirements RFC). Implementors of this document would clearly
need to read RFC 4346 and the security considerations section 
of that document is included by reference. The security considerations
section of this document only needs to cover issues which are different
from those in 4346.


>> > Certain algorithms have "weak keys", and implementations of those
>> > algorithms should check generated keys against them and reject them as
>> > candidates for usage.
>>
>> In particular, this advice does not match with current TLS practice,
>> which is NOT to check for weak keys.
>
> It is a security consideration, and I present it for consideration as
> such.  Let's consider the (admittedly unlikely, but also admittedly
> possible) case of DES with an all-zero key, or 3DES with an all-zero
> key.  Surprise!  Identity operation!  Would you want /your/ medical or
> financial data protected over a network that had implementations that
> could possibly not encrypt it at all?

Yes, I'm quite familiar with the issue. And yes, I'm quite comfortable
with the current situation.


> Regardless of whether it meshes with current TLS practice, these are
> issues that need to be pointed out. I think it's absolutely barbaric
> that TLS is a security protocol, yet legitimate security concerns are
> being whitewashed because it doesn't mesh with "current practice".

The concerns aren't being "whitewashed". 

The debate over whether one should do weak key detection in protocols
has a very long history which I don't intend to reprise here other
than to note that the discussion usually focuses on the extremely
low probability of a random key being weak balanced against the
complexity of weak key checks. See this message on IPsec if you're
interested in the flavor of the debate:
http://www.sandelman.ca/ipsec/2000/01/msg00113.html

TLS embodies a deliberate design choice not to check for weak
keys. You may not happen to agree with that, but it's not something
that's likely to change and certainly not appropriate to change it in
the security considerations of a new TLS ciphersuite advancing outside
the standards track. I'd certainly be happy to include some text
explaining the weak key issue and TLS's choice not to check for
them in 4346bis, however.


>> > The RSA asymmetric encryption system is known to be vulnerable to
>> > advances in factoring large numbers.  In particular, the General
>> > Number Field Seive is being advanced slowly but inexorably.  It is
>> > recommended that implementations move away from RSA for identity keys.
>>
>> I don't agree with this recommendation.
>
        
[comments about GNFS deleted]

> The largest number ever factored by the special number sieve was 274
> digits long.  This is larger than 768-bit RSA, and suggests that
> 1024-bit RSA composites that are of the special form could be
> factorable at this point or in the fairly near future.
>
> This is why I recommend exploring options other than RSA for identity
> keys.  Why do you disagree with this recommendation?

You didn't recommend "exploring" it. You recommended that
implementations move away from it, which isn't the same thing 
at all.

Yes, 768 bit keys are almost certainly not safe for long-term use, but
that doesn't mean that RSA isn't safe, just that you need longer key
sizes (the Lenstra recommendation [0] is 1568 bits for security
through 2020). I'd have no problem with a recommendation that people
study the Lenstra recommendations (or other well-sourced
recommendations and choose key lengths appropriately, but a blanket
statment that they should move away from RSA is not appropriate.

That said, I consider the focus on key length to be generally
misguided, as it's far from the easiest way to recover the private
key. Remotely compromising the server in question and recovering the
private key directly is generally easier, and given the amounts of
money involved in mounting a credible attack on even a modest-length
key (e.g., 1024 bits), it would generally be far more cost effective
to simply mount a social engineering or physical attack on the server
in question. Yes, it's important to have a strong key, but for nearly
all commercial uses it's not plausible that an NSA-scale attacker is
going to spend 2 years trying to factor your RSA modulus.
 
-Ekr

[0] http://www.keylength.com/

_______________________________________________
TLS mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tls