Re: [TLS] Verify data in the RI extension?
Stefan Santesson <stefan@aaa-sec.com> Fri, 27 November 2009 15:53 UTC
Return-Path: <stefan@aaa-sec.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 E8B483A685E for <tls@core3.amsl.com>; Fri, 27 Nov 2009 07:53:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.229
X-Spam-Level:
X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HELO_EQ_SE=0.35]
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 2OGGeZIa3UU9 for <tls@core3.amsl.com>; Fri, 27 Nov 2009 07:53:22 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.114]) by core3.amsl.com (Postfix) with ESMTP id D44B83A6858 for <tls@ietf.org>; Fri, 27 Nov 2009 07:53:21 -0800 (PST)
Received: from s19.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 19B8B28A39F for <tls@ietf.org>; Fri, 27 Nov 2009 16:53:11 +0100 (CET)
Received: (qmail 30921 invoked from network); 27 Nov 2009 15:53:05 -0000
Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender <stefan@aaa-sec.com>) by s19.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <ekr@networkresonance.com>; 27 Nov 2009 15:53:05 -0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Fri, 27 Nov 2009 16:53:03 +0100
From: Stefan Santesson <stefan@aaa-sec.com>
To: Eric Rescorla <ekr@networkresonance.com>
Message-ID: <C735B46F.6BEA%stefan@aaa-sec.com>
Thread-Topic: [TLS] Verify data in the RI extension?
Thread-Index: AcpvebOy8kAeBIOUO0aq7ye2h2EeIg==
In-Reply-To: <20091127152236.1F1176C3796@kilo.networkresonance.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] Verify data in the RI extension?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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: Fri, 27 Nov 2009 15:53:23 -0000
Eric, Thanks for the straightforward reply. In-line; On 09-11-27 4:22 PM, "Eric Rescorla" <ekr@networkresonance.com> wrote: > At Fri, 27 Nov 2009 16:00:38 +0100, > Stefan Santesson wrote: >> Many members of this list argue that 2a has better security properties and >> is simpler to deploy (especially for legacy implementations). >> The arguments for 2b seems to be that it is "good enough" and "why should we >> care about old legacy implementations". > > I don't think this characterizes my position particularly well: > > - I don't think that having the data not carried in the message obviously > has better security properties. There may be some version that clearly > does, but I haven't seen it yet. My suspicion is that the "best" versions > of each of these approaches have equivalent security, but as I said > in a previous message, I'm concerned about the specific "implicit" > versions I've seen proposed. > I have a hard time believing that it would be a hard to define a structure for inclusion of past verify_data that would work for implicit inclusion. The real security advantage of implicit is that you know that the opponent actually derived the same value from previous handshake. By sending it in RI you don't know if the opponent just blindly accepted what you sent without checking it. I think that is a significant security advantage for the implicit approach. > [For the record: your argument about reducing information leakage > is, AFAICT, incorrect. The verify_data in the Finished is carried > over the same encrypted channel as the new handshake messages. Any > attacker who can see the second can see the first.] > We can disregard that comment for this discussion. For this I agree with you. > > - I don't agree that it's simpler to deploy versions that don't carry the > verify_data in an extension. It may require fewer lines of code > (though honestly, the number of lines we're talking about here > is so few, it hardly matters), but on the other hand, the lines > of code are in core pieces of TLS, not in peripheral pieces. > > > - I'm not sure where you get the idea that carrying the verify_data > in an extension somehow involves not caring about legacy implementations. > Perhaps you and I have different views of what that would involve. > As I observed earlier, TLS connections that use RI (and not the magic > cipher suite) are fully compliant with all existing TLS RFCs. > That seems pretty legacy-friendly to me. > An RI from the client containing verify_data need to be parsed and values have to be extracted by the server. This means requirement to add extension handling at the server side for all versions of SSLv3 -> TLS 1.2. In the alternative solution no server need to be bothered with parsing extensions. Some people mean that this is much easier to implement for legacy implementations. I just find their arguments convincing. > > In short, I don't think that signaling the previous verify_data in the > extension is merely "good enough". I think it's better. > Fair enough. I'm afraid I still disagree. /Stefan > -Ekr
- Re: [TLS] Verify data in the RI extension? Stefan Santesson
- [TLS] Avoiding first use of RI in ClientHello Eric Rescorla
- Re: [TLS] Avoiding first use of RI in ClientHello Stefan Santesson
- Re: [TLS] Avoiding first use of RI in ClientHello Dr Stephen Henson
- Re: [TLS] Avoiding first use of RI in ClientHello Robert Relyea
- Re: [TLS] Avoiding first use of RI in ClientHello Eric Rescorla
- Re: [TLS] Avoiding first use of RI in ClientHello Yngve N. Pettersen (Developer Opera Software ASA)
- Re: [TLS] Avoiding first use of RI in ClientHello peter.robinson
- Re: [TLS] Avoiding first use of RI in ClientHello Min Huang
- Re: [TLS] Verify data in the RI extension? Yoav Nir
- Re: [TLS] Avoiding first use of RI in ClientHello Pasi.Eronen
- Re: [TLS] Avoiding first use of RI in ClientHello Pasi.Eronen
- [TLS] Verify data in the RI extension? Stefan Santesson
- Re: [TLS] Verify data in the RI extension? Stefan Santesson
- Re: [TLS] Avoiding first use of RI in ClientHello Eric Rescorla
- [TLS] Perhaps there's another way. Was: Verify da… Marsh Ray
- Re: [TLS] Perhaps there's another way. Was: Verif… Dr Stephen Henson
- Re: [TLS] Avoiding first use of RI in ClientHello Stefan Santesson
- [TLS] What would be the point of removing signall… David-Sarah Hopwood
- Re: [TLS] Perhaps there's another way. Was: Verif… Marsh Ray
- Re: [TLS] Perhaps there's another way. Was: Verif… Dr Stephen Henson
- Re: [TLS] What would be the point of removing sig… Stefan Santesson
- Re: [TLS] What would be the point of removing sig… Marsh Ray
- Re: [TLS] What would be the point of removing sig… Bodo Moeller
- Re: [TLS] Perhaps there's another way. Was: Verif… Nelson B Bolyard
- Re: [TLS] What would be the point of removing sig… Nelson B Bolyard
- Re: [TLS] What would be the point of removing sig… Stefan Santesson
- Re: [TLS] Verify data in the RI extension? Pasi.Eronen
- Re: [TLS] Verify data in the RI extension? Simon Josefsson
- Re: [TLS] Verify data in the RI extension? Stefan Santesson
- Re: [TLS] Verify data in the RI extension? Pasi.Eronen
- Re: [TLS] Verify data in the RI extension? Pasi.Eronen
- Re: [TLS] Verify data in the RI extension? Martin Rex
- Re: [TLS] Verify data in the RI extension? Nikos Mavrogiannopoulos
- Re: [TLS] Verify data in the RI extension? Stefan Santesson
- Re: [TLS] Verify data in the RI extension? Eric Rescorla
- Re: [TLS] Verify data in the RI extension? Stefan Santesson
- Re: [TLS] Verify data in the RI extension? Eric Rescorla
- Re: [TLS] Verify data in the RI extension? Martin Rex
- Re: [TLS] Verify data in the RI extension? Eric Rescorla
- Re: [TLS] Verify data in the RI extension? Martin Rex
- Re: [TLS] Verify data in the RI extension? Martin Rex
- Re: [TLS] Verify data in the RI extension? Martin Rex
- Re: [TLS] Verify data in the RI extension? Stefan Santesson
- Re: [TLS] Verify data in the RI extension? Eric Rescorla
- Re: [TLS] Verify data in the RI extension? Eric Rescorla
- Re: [TLS] Verify data in the RI extension? Martin Rex
- Re: [TLS] Verify data in the RI extension? Eric Rescorla
- Re: [TLS] Verify data in the RI extension? Martin Rex
- Re: [TLS] Verify data in the RI extension? Martin Rex
- Re: [TLS] Verify data in the RI extension? Pasi.Eronen
- Re: [TLS] Verify data in the RI extension? Martin Rex
- Re: [TLS] Verify data in the RI extension? Eric Rescorla
- Re: [TLS] Verify data in the RI extension? Martin Rex
- Re: [TLS] Verify data in the RI extension? Pasi.Eronen
- Re: [TLS] Avoiding first use of RI in ClientHello Bodo Moeller
- Re: [TLS] Verify data in the RI extension? Bodo Moeller
- Re: [TLS] Verify data in the RI extension? Michael D'Errico
- Re: [TLS] What would be the point of removing sig… David-Sarah Hopwood
- Re: [TLS] What would be the point of removing sig… David-Sarah Hopwood
- Re: [TLS] What would be the point of removing sig… David-Sarah Hopwood
- Re: [TLS] Verify data in the RI extension? David-Sarah Hopwood
- Re: [TLS] Verify data in the RI extension? Michael D'Errico
- Re: [TLS] Verify data in the RI extension? David-Sarah Hopwood
- Re: [TLS] Verify data in the RI extension? Michael D'Errico
- Re: [TLS] Verify data in the RI extension? David-Sarah Hopwood
- Re: [TLS] Verify data in the RI extension? Bodo Moeller
- Re: [TLS] What would be the point of removing sig… Bodo Moeller
- Re: [TLS] Verify data in the RI extension? Michael D'Errico
- Re: [TLS] Verify data in the RI extension? Michael D'Errico
- Re: [TLS] Verify data in the RI extension? David-Sarah Hopwood
- Re: [TLS] Verify data in the RI extension? Marsh Ray
- Re: [TLS] Verify data in the RI extension? Stefan Santesson
- Re: [TLS] Verify data in the RI extension? Yoav Nir