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 (MET)
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