Re: [TLS] SCSV vs RI when both specified. Was: Updated draft
Martin Rex <mrex@sap.com> Mon, 21 December 2009 17:50 UTC
Return-Path: <mrex@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 E0F383A6A74 for <tls@core3.amsl.com>; Mon, 21 Dec 2009 09:50:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.194
X-Spam-Level:
X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.055, 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 pqcW7Qnf-AeN for <tls@core3.amsl.com>; Mon, 21 Dec 2009 09:50:31 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 099EA3A68AA for <tls@ietf.org>; Mon, 21 Dec 2009 09:50:30 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBLHoDBC027870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Dec 2009 18:50:13 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200912211750.nBLHoC6a024954@fs4113.wdf.sap.corp>
To: Pasi.Eronen@nokia.com
Date: Mon, 21 Dec 2009 18:50:12 +0100
In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7758409B30F1@NOK-EUMSG-01.mgdnok.nokia.com> from "Pasi.Eronen@nokia.com" at Dec 21, 9 09:57:19 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: tls@ietf.org
Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated draft
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@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: Mon, 21 Dec 2009 17:50:33 -0000
Pasi.Eronen@nokia.com wrote: > > Uri Blumenthal wrote: > > > OK. Karlsruhe server time-outs on me, so no chance to get enlightened > > by checking that thread. Please indulge me: the one short compelling > > reason why we don't want to say "when two signals are present use this > > one and ignore the other" instead of "when two signals are present - > > abort connection" - is...? > > Well, if the spec says "the client MUST not send two signals", then if > two signals are present, it's probably safer to abort (since the > client is not following the spec anyway, it's hard to guess > what its intent was...) There would only be an ambiguity when the signal could indicate two different semantics. The description of the semantics of TLS_RENEGO_PROTECTION_REQUEST in draft-tls-renegotiation-02 is defective and needs to be fixed. The currently flawed defintion for TLS_RENEGO_PROTECTION_REQUEST is what caused this: http://www.ietf.org/mail-archive/web/tls/current/msg05155.html http://www.ietf.org/mail-archive/web/tls/current/msg05186.html and resulted in this text in draft-tls-renegotiation-02.txt: 6.1 Client Considerations [TODO: this needs a discussion of what signal to send in legacy renegotiation to match the resolution of the paired TODO in Section 4.] The purpose of TLS_RENEGO_PROTECTION_REQUEST is to request _ONLY_ the new handshake semantics (which first-of-all concerns those peers in the communication that are performing a renegotiation handshake). The resistence to adopting the correct semantics for TLS_RENEGO_PROTECTION_REQUEST is probably because from the viewpoint of formal correctness proofing, the correct definition implies that this signal MUST be asserted on every ClientHello (because the absence, that would then indicate "old handshake semantics" would be incompatible with the presence of an TLS extension RI. But for the old renegotiation scenario, the result of the correct definition of TLS_RENEGO_PROTECTION_REQUEST would provide an obvious, intuitive and fully backwards interoperable solution. In addition, everyone would save code, and the solution would become less complex. What makes me feel slightly uneasy is that some people think the above is a special case that needs to be seperately addressed in the document. With a clean architecture, that is no special case. The problem with draft-tls-renegotiation-02 is, that it comes without architecture. It is an implementation of an unspecified solution architecture. And that leads to discussions about belief, rather than characteristics of a specific (spec-level) implementation of a solution architecture, where it is possible to check implementation details with methodologies used in formal correctness proofs. The reason why the TLS renegotiation vulnerability was not noticed for so long is quite related to this. The SSL and TLS protocols completely failed to describe its architecture, otherwise the defect would have been obvious. Once I had described the architecture of TLS renegotiation to Larry and Nico in the discussion about channel bindings early November, it became obvious to me, from last paragraph of this: http://www.ietf.org/mail-archive/web/tls/current/msg03922.html to this: http://www.ietf.org/mail-archive/web/tls/current/msg03928.html And that applies to all other problems recently discussed. The lack of an (explanation of) the architecture hides most of the problems, like identity change during renegotiation, the possibility of application data interleaved with renegotiation handshakes, the effect of TLS session resumption and TLS session caching strategies on certificate path validation. -Martin
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Michael D'Errico
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Michael D'Errico
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Martin Rex
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Steve Checkoway
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Blumenthal, Uri - 0662 - MITLL
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Steve Checkoway
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Blumenthal, Uri - 0662 - MITLL
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Steve Checkoway
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Martin Rex
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Blumenthal, Uri - 0662 - MITLL
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Pasi.Eronen
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Yoav Nir
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Blumenthal, Uri - 0662 - MITLL
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Martin Rex
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Michael D'Errico
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Dr Stephen Henson
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Martin Rex
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Michael D'Errico
- Re: [TLS] SCSV vs RI when both specified - consen… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified - consen… Nasko Oskov
- Re: [TLS] SCSV vs RI when both specified - consen… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified - consen… Michael D'Errico
- Re: [TLS] SCSV vs RI when both specified - consen… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Blumenthal, Uri - 0662 - MITLL
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Yoav Nir
- Re: [TLS] SCSV vs RI when both specified - consen… Yoav Nir
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Kemp, David P.
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Blumenthal, Uri - 0662 - MITLL
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Ben Laurie
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Kemp, David P.
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Blumenthal, Uri - 0662 - MITLL
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Martin Rex
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Martin Rex
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Steve Dispensa
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Kemp, David P.
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Martin Rex
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Martin Rex
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Martin Rex
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Kemp, David P.
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Martin Rex
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Kyle Hamilton