Re: [TLS] Fwd: New Version Notification for draft-bmoeller-tls-downgrade-scsv-00.txt

mrex@sap.com (Martin Rex) Thu, 26 September 2013 11:35 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538AF21F9B90 for <tls@ietfa.amsl.com>; Thu, 26 Sep 2013 04:35:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.173
X-Spam-Level:
X-Spam-Status: No, score=-10.173 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhXSdY5iGuW2 for <tls@ietfa.amsl.com>; Thu, 26 Sep 2013 04:34:58 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2C55C21F9B6A for <tls@ietf.org>; Thu, 26 Sep 2013 04:34:54 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r8QBYoej021761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Sep 2013 13:34:50 +0200 (MEST)
In-Reply-To: <CADMpkc+1mJduJj6_Soh1u+m8naiYr_RaH+m51DJsUJ2p493k_w@mail.gmail.com>
To: Bodo Moeller <bmoeller@acm.org>
Date: Thu, 26 Sep 2013 13:34:50 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20130926113450.387DE1A9AA@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Fwd: New Version Notification for draft-bmoeller-tls-downgrade-scsv-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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/options/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 Sep 2013 11:35:03 -0000

Bodo Moeller wrote:
> 
> Martin Rex noted (in neighbor thread "[TLS] Comments/Questions on
> draft-gutmann-tls-encrypt-then-mac-00.txt" where this came up, but which I
> don't want to hijack entirely):
> 
> OH NO, not again!!
> >
> > Any kind of specification for TLS, that suggests to the server
> > to apply heuristics and make (often flawed or unjustified) assumptions
> > about what the client may want or may not want and have the _server_
> > abort the handshake rather than the client, are a REALLY BAD IDEA and
> > squarely against the IETF spirit to promote interop.
> 
> 
> I'm not sure to what extent I agree to this claim (for example, we do allow
> servers to abort with an insufficient_security alert if they don't agree
> with any of the ciphersuites listed in ClientHello.cipher_suites), but in
> any case please note that this is not actually what
> draft-bmoeller-tls-downgrade-scsv-00 specifies.

https://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-00#section-3

   This section specifies server behavior when receiving the
   TLS_DOWNGRADE_SCSV cipher suite from a client in
   ClientHello.cipher_suites.

   o  If TLS_DOWNGRADE_SCSV appears in ClientHello.cipher_suites and the
      highest protocol version supported by the server is higher than
      the version indicated in ClientHello.client_version, the server
      MUST respond with a (fatal) protocol_version alert.

   o  If TLS_DOWNGRADE_SCSV appears in ClientHello.cipher_suites and the
      ClientHello message does not include field
      client_hello_extension_list at all ([RFC3546], [RFC4366],
      [RFC5246]), the server MUST respond with a (fatal)
      protocol_version alert.

To me, this part of your document places two requirements on the _server_
to abort the handshake.  And the justification given for aborting the
handshake is *NOT* that the TLS connection characteristics proposed
in ClientHello is inacceptable to the servers' policy (which would be OK),
but that the TLS connection characteristics appear to be inconsistent
with the TLS connection charateristics alleged/assumed to be desired
by the client.

In a security protocol, it is a design failure to rely on a connection
peer to enforce one's own policy (the connection peer may be an adversary),
and it is necessary that each peer checks and enforces his own policy
himself.  But once it does that, there is no need (and less confusion)
if each peer takes care only of his own policy.


-Martin