IETF Logo Mail Archive

Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00

Hanno Böck <hanno@hboeck.de> Wed, 15 October 2014 12:01 UTC

Return-Path: <hanno@hboeck.de>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4310B1A1B51 for <tls@ietfa.amsl.com>; Wed, 15 Oct 2014 05:01:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Level:
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqoDsOpFNT3J for <tls@ietfa.amsl.com>; Wed, 15 Oct 2014 05:01:53 -0700 (PDT)
Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ED211A1B5D for <tls@ietf.org>; Wed, 15 Oct 2014 05:01:52 -0700 (PDT)
Received: from pc.my-domain (tmo-102-72.customers.d1-online.com [::ffff:80.187.102.72]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Wed, 15 Oct 2014 14:01:49 +0200 id 0000000000000091.00000000543E622D.00006177
Date: Wed, 15 Oct 2014 14:01:58 +0200
From: Hanno Böck <hanno@hboeck.de>
To: tls@ietf.org
Message-ID: <20141015140158.41a1faf8@pc.my-domain>
In-Reply-To: <CADMpkcJLrQEtiUGi9B7ZS5402cXTBvvThL9-YwUUhncaXQaVsA@mail.gmail.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543E2D81.1050700@redhat.com> <7F8CB03B-6882-41E7-9705-7126A8F2F44D@gmail.com> <CADMpkcJLrQEtiUGi9B7ZS5402cXTBvvThL9-YwUUhncaXQaVsA@mail.gmail.com>
X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.24; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-24951-1413374510-0001-2"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9WG12Bb8d2vGUqem-DbbyfEwHTQ
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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/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, 15 Oct 2014 12:01:55 -0000

Am Wed, 15 Oct 2014 11:22:51 +0200
schrieb Bodo Moeller <bmoeller@acm.org>:

> Note that if your server does not support formally obsolete protocol
> versions, TLS_FALLBACK_SCSV support is a no-op.
> 
> Otherwise, you're making real-world tradeoffs, and I think
> TLS_FALLBACK_SCSV is a reasonable one to make (with minimal
> server-side logic to achieve the objective), not "punishment".

Can you quantify that tradeoff? How many devices are there really out
there that would break? I'd like to have this discussions with
hard numbers.

I mean we are not talking about legacy compatibility. We're talking
about compatibility with broken stuff.

I want to weight my voice in support of Florian. What we have here is
an out-of-protocol workaround with security and compatibility
implications and a solution that adds another workaround on top of that.

To compare the two:

One solution (keeping downgrade-workarounds and add SCSV):
* Compatiblity with a likely small number (but I'm waiting for hard
  numbers here) of broken legacy hard/software
* Add more complexity to TLS
* Support people who deploy broken stuff, punish people who support
  completely correct configs

Other solution (remove downgrade-workarounds):
* Break some compatiblity with broken devices
* Reduce complexity of TLS in browsers
* Support people who deploy correct implementations, punish people who
  support broken stuff

I think the argument is clearly in favor of the latter solution unless
you have some very good counterarguments.

cu,
-- 
Hanno Böck
http://hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: BBB51E42

v2.23.0 | Report a Bug | By Email