Re: [TLS] Verify data in the RI extension?
Bodo Moeller <bmoeller@acm.org> Fri, 27 November 2009 22:04 UTC
Return-Path: <SRS0=3D4J=HP=acm.org=bmoeller@srs.kundenserver.de>
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 E1CCC3A695D for <tls@core3.amsl.com>; Fri, 27 Nov 2009 14:04:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.249
X-Spam-Level:
X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100]
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 VH5sm4DC7J6z for <tls@core3.amsl.com>; Fri, 27 Nov 2009 14:04:10 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by core3.amsl.com (Postfix) with ESMTP id B58DD3A68A9 for <tls@ietf.org>; Fri, 27 Nov 2009 14:04:09 -0800 (PST)
Received: from [10.1.124.144] ([74.125.121.49]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MHtl3-1NHhon2IFp-003a8k; Fri, 27 Nov 2009 23:03:57 +0100
From: Bodo Moeller <bmoeller@acm.org>
To: Eric Rescorla <ekr@networkresonance.com>
In-Reply-To: <20091127192723.BF0EF6C37E9@kilo.networkresonance.com>
References: <20091127161724.3DF546C37C8@kilo.networkresonance.com> <20091127192723.BF0EF6C37E9@kilo.networkresonance.com>
Message-Id: <B426AFA2-00F2-4A5C-9392-9A1E817A3B94@acm.org>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 27 Nov 2009 23:03:55 +0100
X-Mailer: Apple Mail (2.936)
X-Provags-ID: V01U2FsdGVkX1+XgHtDI/Rpzvz8+tgO082keImMxnrNmxHAnAd PI0eNIW3LbU2Ysrfc/uABIgG9SZpNHrDnSUeQXafuT0T0yHUqJ MDJebcpLtqQ/elXH2IUhA==
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 22:05:15 -0000
On Nov 27, 2009, at 8:27 PM, Eric Rescorla wrote: > Thinking about this some more, consider the case of a client which > (improperly) ignores handshake messages which come out of sequence, > but still hashes them into handshake hashes. > > In the simple attack where the server thinks there is a rehandshake > and the client thinks it is the initial handshake, what if the > attacker between the client and the server injects the > replayed Client.Finished and Server.Finished messages into the message > stream going towards the client. The client would then ignore but hash > the messages with the result that the data hashed by the client being > the is the same as the data being hashed by the server and the attack > succeeds. Am I missing something here? > > Obviously, one could just say that the client is misbehaving here > and so this doesn't matter (though I would note that others have > expressed > concerns about what happens with implementation errors, and this is > only > requires an error by one side, not both). However, I think it's > illustrative > that we need to be pretty careful about introducing ambiguity between > messages that are on the wire and those that are merely hashed. While this looks a little far-fetched to me, many security issues found in practice seem far-fetched if you don't know that they're real -- what you're writing here is enough to convince me that if there's one canonical way to solve the security problem, it's with including explicit verify_data in renegotiation handshake hello extensions. The one thing I don't agree with in draft-ietf-tls- renegotiation-01.txt regarding the extensions is having the ServerHello concatenate the client and server verify_data. That's pointless given that the client sends its one verify_data in its extension -- the server should only send its own verify_data. I have one more concern with draft-ietf-tls-renegotiation-01.txt: The ID says "By default, TLS implementations conforming to this document MUST verify that once the peer has been identified and authenticated within the TLS handshake, the identity does not change on subsequent renegotiations. For certificate based cipher suites, this means bitwise equality of the end-entity certificate. If the other end attempts to authenticate with a different identity, the renegotiation MUST fail. If the server_name extension is used, it MUST NOT change when doing renegotiation." It makes sense to require this when a party conforming to this specification falls back to compatible mode, when it has determined that according to the handshake the peer does not conform to the specification. However, if the client and server *both* confirm to the specification and thus have secure channel binding across renegotiations, there's no point in forbidding "identity" changes (which may not be really identity changes, but other create and yet valid uses of TLS renegotiation -- for example, consider a server that uses a particular ciphersuite [requiring a special certificate] only with authenticated clients [and thus in a renegotiation handshake], to name just one example). There's no 1-to-1 mapping between certificate and "identities" -- at best a certificate is a particular "name", but a single entity can legitimately use multiple names. Bodo
- 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