Re: [TLS] Re: Russ Housley: Fwd: problems with draft-ietf-tls-openpgp-keys-10.txt
Eric Rescorla <ekr@networkresonance.com> Sun, 02 July 2006 00:50 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwqAE-0002gC-8B; Sat, 01 Jul 2006 20:50:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwqAD-0002g7-2Y for tls@ietf.org; Sat, 01 Jul 2006 20:50:17 -0400
Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwqAA-00037s-Cl for tls@ietf.org; Sat, 01 Jul 2006 20:50:17 -0400
Received: by raman.networkresonance.com (Postfix, from userid 1001) id 55A451E8C1C; Sat, 1 Jul 2006 17:50:13 -0700 (PDT)
To: Kyle Hamilton <aerowolf@gmail.com>
Subject: Re: [TLS] Re: Russ Housley: Fwd: problems with draft-ietf-tls-openpgp-keys-10.txt
References: <20060626203923.59F81222426@laser.networkresonance.com> <200606290020.10111.nmav@gnutls.org> <p06230904c0c9842d3069@128.89.89.106> <200607010918.21080.nmav@gnutls.org> <6b9359640607010436l4728792qdfd988762d804fe2@mail.gmail.com> <86wtaxmk7r.fsf@raman.networkresonance.com> <6b9359640607011717m38702cdbi1d451b83409168ea@mail.gmail.com>
From: Eric Rescorla <ekr@networkresonance.com>
Date: Sat, 01 Jul 2006 17:50:13 -0700
In-Reply-To: <6b9359640607011717m38702cdbi1d451b83409168ea@mail.gmail.com> (Kyle Hamilton's message of "Sat, 1 Jul 2006 17:17:01 -0700")
Message-ID: <86psgoj0e2.fsf@raman.networkresonance.com>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c
Cc: tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: EKR <ekr@networkresonance.com>
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org
"Kyle Hamilton" <aerowolf@gmail.com> writes: > On 7/1/06, Eric Rescorla <ekr@networkresonance.com> wrote: >> "Kyle Hamilton" <aerowolf@gmail.com> writes: >> >> > On 7/1/06, Nikos Mavrogiannopoulos <nmav@gnutls.org> 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 TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls
- [TLS] Re: Russ Housley: Fwd: problems with draft-… Nikos Mavrogiannopoulos
- Re: [TLS] Re: Russ Housley: Fwd: problems with dr… Anyang Ren
- [TLS] Re: Russ Housley: Fwd: problems with draft-… Nikos Mavrogiannopoulos
- Re: [TLS] Re: Russ Housley: Fwd: problems with Martin Rex
- Re: [TLS] Re: Russ Housley: Fwd: problems with dr… Eric Rescorla
- [TLS] Re: Russ Housley: Fwd: problems with draft-… Nikos Mavrogiannopoulos
- Re: [TLS] Re: Russ Housley: Fwd: problems with dr… Kyle Hamilton
- Re: [TLS] Re: Russ Housley: Fwd: problems with dr… Eric Rescorla
- Re: [TLS] Re: Russ Housley: Fwd: problems with dr… Kyle Hamilton
- Re: [TLS] Re: Russ Housley: Fwd: problems with dr… Eric Rescorla
- Re: [TLS] Re: Russ Housley: Fwd: problems with dr… Steven M. Bellovin
- Re: [TLS] Re: Russ Housley: Fwd: problems with Eric Rescorla
- Re: [TLS] Re: Russ Housley: Fwd: problems with dr… Nelson B Bolyard