Re: [TLS] Cached Info extension - Draft 01
Martin Rex <Martin.Rex@sap.com> Thu, 02 July 2009 16:33 UTC
Return-Path: <Martin.Rex@sap.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FC923A6B15 for <tls@core3.amsl.com>; Thu, 2 Jul 2009 09:33:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.094
X-Spam-Level:
X-Spam-Status: No, score=-6.094 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lJ5uTYVokea for <tls@core3.amsl.com>; Thu, 2 Jul 2009 09:33:31 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 5A5803A6B11 for <tls@ietf.org>; Thu, 2 Jul 2009 09:33:31 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id n62GXoBc005404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jul 2009 18:33:50 +0200 (MEST)
From: Martin Rex <Martin.Rex@sap.com>
Message-Id: <200907021633.n62GXnGV009098@fs4113.wdf.sap.corp>
To: stefan@aaa-sec.com
Date: Thu, 02 Jul 2009 18:33:49 +0200
In-Reply-To: <C6721D2F.2ECF%stefan@aaa-sec.com> from "Stefan Santesson" at Jul 2, 9 08:15:43 am
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
Cc: simon@josefsson.org, tls@ietf.org
Subject: Re: [TLS] Cached Info extension - Draft 01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: martin.rex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Jul 2009 16:33:32 -0000
Stefan Santesson wrote: > > On 09-07-02 1:00 AM, "Martin Rex" <Martin.Rex@sap.com> wrote: > > > > If the real data is no longer part of the SSL handshake, but instead > > either a weak hash or even a static "cache handle", then there is > > a change in the cryptographic properties of the SSL handshake using > > cached handshake data and the full handshake with the real data. > > I don't believe this conclusion is correct. I think you might be misreading my conclusion. I think that we're cryptographically safe in modyfying the handshake by making a strong (agile) hash value over the original data part of the handshake instead. This is even safe for handling errors. If we drop the cryptographic binding of the original data in the handshake, we might create problems that we haven't thought of so far, and the architecure becomes brittle to handling errors. Without the cryptographic binding, cache poisoning will become feasible. The (server) endpoint identification that many/most clients currently perform is so ridiculously weak that I'm worried about cache poisoning. And how about caching of handshake data from incomplete TLS-handshakes that are incomplete, common and non-malicious? (like when a server requests a client cert, the client doesn't send one, and the server terminates the handshake with a fatal alert? Without the cryptographic binding of the original data to the cache-using handshake, we should probably need to explicitly prohibit caching there. For the TLS extension client certificate URL the previously optional hash over the client cert was made mandatory. I think that it is a sensible action to play safe and to try to maintain the cryptographic binding to the full SSL handshake by including a strong agile hash value over the original handshake data when the original data is omitted or replaced by a weak reference. -Martin
- [TLS] Cached Info extension - Draft 01 Stefan Santesson
- Re: [TLS] Cached Info extension - Draft 01 Stefan Santesson
- Re: [TLS] Cached Info extension - Draft 01 Simon Josefsson
- Re: [TLS] Cached Info extension - Draft 01 Martin Rex
- Re: [TLS] Cached Info extension - Draft 01 Stefan Santesson
- Re: [TLS] Cached Info extension - Draft 01 Florian Weimer
- Re: [TLS] Cached Info extension - Draft 01 Martin Rex
- Re: [TLS] Cached Info extension - Draft 01 Stefan Santesson
- Re: [TLS] Cached Info extension - Draft 01 Martin Rex
- Re: [TLS] Cached Info extension - Draft 01 Stefan Santesson
- Re: [TLS] Cached Info extension - Draft 01 Martin Rex