Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt

mrex@sap.com (Martin Rex) Wed, 25 September 2013 20:54 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 E272E21F9E40 for <tls@ietfa.amsl.com>; Wed, 25 Sep 2013 13:54:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.156
X-Spam-Level:
X-Spam-Status: No, score=-10.156 tagged_above=-999 required=5 tests=[AWL=0.093, 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 HmHlnA2dBgVe for <tls@ietfa.amsl.com>; Wed, 25 Sep 2013 13:54:44 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 8F43B21F9D95 for <tls@ietf.org>; Wed, 25 Sep 2013 13:54:31 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r8PKsO2s013741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Sep 2013 22:54:24 +0200 (MEST)
In-Reply-To: <CADMpkc+3ifDbnSxp9jiiPAKDPxaCWpkKHXTfgygpN3kOXMUFFQ@mail.gmail.com>
To: Bodo Moeller <bmoeller@acm.org>
Date: Wed, 25 Sep 2013 22:54:24 +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: <20130925205424.8DCFA1A9A7@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-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: Wed, 25 Sep 2013 20:55:01 -0000

Bodo Moeller wrote:
> > Instead of particular versions, it seems to me that an indicator of "I
> >> tried to connect using a higher version than I'm using now but had to
> >> fall back to this verion" would cover any case now or later.
> >>
> >
> > Indeed that's what I ended up writing down for an Internet Draft.
> >
> 
> Now here:
> 
> http://www.ietf.org/internet-drafts/draft-bmoeller-tls-downgrade-scsv-00.txt

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.

Fatal SSL alerts in particular, are worst of all, because they do often
do not give any clue, are not ever sent by a number of TLS implementations
(you just see the connection close/reset), and are hardly/poorly visualized
or not even accessible on many TLS clients.

If anything, then such a "downgrade protection discovery" signaling
cihper suites should cause the server to respond with a ServerHelloExtension
listing the features that the server supports and would be capable
of processing properly when present in ClientHello, and leave the
decision, whether to abort the handshake and whether to tell or ask
the user about any perceived problems first, entirely up to the client.


-Martin