[TLS] Verify data in the RI extension?
Stefan Santesson <stefan@aaa-sec.com> Thu, 26 November 2009 08:28 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 39AF83A6A1C for <tls@core3.amsl.com>; Thu, 26 Nov 2009 00:28:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.614
X-Spam-Level:
X-Spam-Status: No, score=-2.614 tagged_above=-999 required=5 tests=[AWL=0.635, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1]
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 1BZ5uBCsE6TU for <tls@core3.amsl.com>; Thu, 26 Nov 2009 00:28:46 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by core3.amsl.com (Postfix) with ESMTP id 4C0163A688D for <tls@ietf.org>; Thu, 26 Nov 2009 00:28:46 -0800 (PST)
Received: from s60.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 505332912E7 for <tls@ietf.org>; Thu, 26 Nov 2009 09:28:42 +0100 (CET)
Received: (qmail 91592 invoked from network); 26 Nov 2009 08:28:39 -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 s60.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <ekr@networkresonance.com>; 26 Nov 2009 08:28:39 -0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Thu, 26 Nov 2009 09:28:36 +0100
From: Stefan Santesson <stefan@aaa-sec.com>
To: Eric Rescorla <ekr@networkresonance.com>, tls@ietf.org
Message-ID: <C733FAC4.6B2F%stefan@aaa-sec.com>
Thread-Topic: Verify data in the RI extension?
Thread-Index: AcpucnKDBfZJfFA4bkCu+kOI5DD7Ag==
In-Reply-To: <20091125223502.4265B6C3285@kilo.networkresonance.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: [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: Thu, 26 Nov 2009 08:28:47 -0000
Eric and all, On 09-11-25 11:35 PM, "Eric Rescorla" <ekr@networkresonance.com> wrote: > What about not putting the verify data in the extension? > I think that issue is separable from the question of how we signal > support, so would like to deal with it separately. I would like to elaborate my support for an RI with absent verify data. The major argument I have seen for including verify data in the RI extension is that it would allow us to preserve the current Finished calculation. This will allow us to use more of the current implementation code and provide a more clean design. I think these to a major extent are valid arguments, but I find the opposing arguments even more convincing. These are: 1) Empty RI It's good security design If you want to make sure two parties agree on a value that they have derived from a previous state, in order to bind to the previous state, then why would you exchange that value before doing the check? On the contrary, I find it to be good security design not to exchange that value as it: 1) Reduce information leakage to an attacker 2) Increase the security assumptions that can be made based on a proof of matching values (good Finished messages). Even if there are no attack today to exploit the information leakage and exchanging the values allows secure design, I still find it valuable to apply the best possible security design to reduce the chance of future problems. 2) Better migration path towards future If we would design TLS 1.3, then would we send this data in the handshake, or would we not? I suspect we would not, due to argument 1) Exchanging this value serves no purpose other than saving a few lines of code changes from TLS 1.2. Consequently, if we design an updated Finished calculation now, we can keep that in TLS 1.3 and just remove the signaling we now add for SSLv3 -> TLS 1.2. 3) Less likely to cause implementation problems This is just my guessing based on what I have heard. But if the client verify data is provided in RI, then it is not enough to recognize the extension. It is now also necessary to parse it, extract the data and to use it in a critical security check. I can't really judge how likely this is to cause more implementation problems or even implementations that appears to do the security check against previous handshakes, but actually just feeds it into the finished calculation blindly. But it feels like good design to eliminate/reduce this type of problems if possible. Especially if it is better security design at reasonable cost. /Stefan
- 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