Re: [TLS] Re: Russ Housley: Fwd: problems with

Eric Rescorla <ekr@networkresonance.com> Mon, 03 July 2006 14:33 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxPUQ-000583-Uz; Mon, 03 Jul 2006 10:33:30 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxPUO-00054z-K0 for tls@ietf.org; Mon, 03 Jul 2006 10:33:28 -0400
Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxPUN-0000Te-A0 for tls@ietf.org; Mon, 03 Jul 2006 10:33:28 -0400
Received: by raman.networkresonance.com (Postfix, from userid 1001) id ABCA81E8C1C; Mon, 3 Jul 2006 07:33:26 -0700 (PDT)
To: martin.rex@sap.com
Subject: Re: [TLS] Re: Russ Housley: Fwd: problems with
References: <200607031420.QAA06616@uw1048.wdf.sap.corp>
From: Eric Rescorla <ekr@networkresonance.com>
Date: Mon, 03 Jul 2006 07:33:26 -0700
In-Reply-To: <200607031420.QAA06616@uw1048.wdf.sap.corp> (Martin Rex's message of "Mon, 3 Jul 2006 16:20:21 +0200 (MET DST)")
Message-ID: <86hd1ybvwp.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: 0bc60ec82efc80c84b8d02f4b0e4de22
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

Martin Rex <martin.rex@sap.com>; writes:

> Eric Rescorla wrote:
>> 
>> >> 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.
>
> Although the existing SSL/TLS specs do not define how to synchronously
> skip/drop weak keys during key generation upfront and synchronously,
> wouldn't it be possible for either side (when the particular implementations
> feels such a need) to detect a weak key and force the peer directly
> through a renegotiate -- even old peers?

Sure. Except that the other side can refuse to renegotiate and
that there are deadlock conditions if you try to renegotiate
at the wrong time....

-Ekr

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls