Re: [TLS] Cipher suite values to indicate TLS capability

Tom Ritter <tom@ritter.vg> Thu, 07 June 2012 23:23 UTC

Return-Path: <tom@ritter.vg>
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 C4BBA11E80E4 for <tls@ietfa.amsl.com>; Thu, 7 Jun 2012 16:23:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.827
X-Spam-Level:
X-Spam-Status: No, score=-2.827 tagged_above=-999 required=5 tests=[AWL=-2.149, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MANGLED_LOAN=2.3, RCVD_IN_DNSWL_LOW=-1]
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 V5gae3PrLEOv for <tls@ietfa.amsl.com>; Thu, 7 Jun 2012 16:23:48 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 75A2611E8088 for <tls@ietf.org>; Thu, 7 Jun 2012 16:23:28 -0700 (PDT)
Received: by obbeh20 with SMTP id eh20so1860992obb.31 for <tls@ietf.org>; Thu, 07 Jun 2012 16:23:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=W62zi85KWnLRhjIrgyh78HunAYLNdEmfDLIVLDdUbbo=; b=YrZ1MWNbnwbNW9kS6iMc8UZ5101k1NRnVN4oPuEcXO/ieyVIB4NvBTHLpstZj3WX40 XaC+69+3IfsesgYm/pCVm3QQrQ4aOLMw6Pt89n4djZhi28P4wmuUWMSXeHWPl8Mkvezi g+w1SydUqYtUwHlyDLnZgArJgrbdGvqE97yJ4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding:x-gm-message-state; bh=W62zi85KWnLRhjIrgyh78HunAYLNdEmfDLIVLDdUbbo=; b=dF15ACI3z5WcFy3bVcbyjysBIqk1OW/de8pGvxFAWHLNFkzMa2KiCoZPepTctH5Fk5 u7shBZLDO2izCqrdNmr0ZkeJ5Efz/Q0Tls+mg4zg9fRp+E9OtUvvwkJMrGa927Bxw3Xu 5F8pPQEt0N3e+0iEXK8zvScvxdtQET8iI4oLfFmKXVcG0htG5nYDUThOVqE6l2tsG2bK gGRbc/1+CafXm6jaSGq/Jklq+By+mYm7ymiWKQTmrvGVrqm8C13Ge0MSoDelTpH9U0mC JsJhN5i60jz0OspsGANLgb2/Y9D3yy51nXObrnSFAxDZHcbRtF3aN9uOiG3s83cH6Dlc OTvA==
Received: by 10.60.4.165 with SMTP id l5mr3981526oel.41.1339111408035; Thu, 07 Jun 2012 16:23:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.213.102 with HTTP; Thu, 7 Jun 2012 16:23:07 -0700 (PDT)
In-Reply-To: <CADKevbBxUGwRtLs=u-pmOHtQ9HP4ERvxpvKJE4BOecLrm8it2g@mail.gmail.com>
References: <CAL9PXLwdQctUub5oPx0tepsfveDo0bNKGBUaUBBFeq4u4D0BbA@mail.gmail.com> <CADKevbAnT7AVn_cN+7WcBLfK8G4vkKns3GqQP1QQQ__96SD_6A@mail.gmail.com> <002AA72F-D47E-4C7C-930C-D78A0E48D059@checkpoint.com> <CADKevbBxUGwRtLs=u-pmOHtQ9HP4ERvxpvKJE4BOecLrm8it2g@mail.gmail.com>
From: Tom Ritter <tom@ritter.vg>
Date: Thu, 07 Jun 2012 19:23:07 -0400
Message-ID: <CA+cU71nuGwgTc-dHkM_RrVUFZnOOoGkLeq-A2cQoYaobJFQ1zw@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQnusgisushz1dO6OoV9iamgYOtSog8PGWXjgrGwH84/UA4JozHH7hMmLyPjat/ETxisgOwY
Subject: Re: [TLS] Cipher suite values to indicate TLS capability
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 07 Jun 2012 23:23:49 -0000

On 7 June 2012 18:34, Chris Richardson <chris@randomnonce.org> wrote:
> Behind the SCSV is the suggestion is that SSLv3 should be considered
> harmful.  If SSLv3 is harmful, then why only reject it for
> TLSv1-capable clients?  Why not reject it for everyone?
>
> (One benefit of the SCSV that I can see is that a downgrade-to-SSLv3
> attack can be detected, which would be an indication that SSLv3 should
> be considered harmful, even if we don't know why.)

This proposal, and a few others being worked on in various places, aim
to address the problem we have with hard fail and backwards
capability. In some scenarios TLSv1, DNSSEC, DANE, etc all fail not
because someone is performing an attack, but because some piece of
software can't handle some portion of the secure protocol.  And
because Operating Systems and Browsers have an incentive to make
things work for their users, they retry will less, or no, security.
Attackers can exploit this mechanism to get the advantages of the
lesser form (less or no security).

If we don't move the line in the sand forward, if we don't make a
decision that says "We will support this buggy or incomplete software
no more", there's no point in defining new security protocols.  What's
the point in DNSSEC if it only is used when someone's not attacking
you?  What's the point in TLSv1, 1.1, or 1.2 if the security gains
(correct IV, DHE, AEAD, SHA256) will never be realized when there's an
attacker there?

If there's a practical way to detect an attacker trying to downgrade
you, that doesn't shred the protocol, I think it's pretty useful.
SCSV's are ugly and a slippery slope, but when someone in an accurate
position tells you "We're going to have the fallback behavior for a
long time" one or two more to gain the advantage of these new
protocols looks pretty good.  (The other approach being taken is
drawing a little enclave and saying "In this zone, we will hard fail,
and if your software can't handle TLS1.0 or DNSSEC, people can't
connect to you.", but that's not really applicable here.)

On 6 June 2012 03:12, Nikos Mavrogiannopoulos <nmav@gnutls.org> wrote:
> 2. Is that a user that did not want to use SSL 3.0? Then SSL 3.0
> should have been disabled.

I would say it was a user who wanted to use the more secure version of
the protocol available, and not be downgraded by an attacker.

On 6 June 2012 03:25, Geoffrey Keating <geoffk@geoffk.org> wrote:
> I think the whole fallback thing is terrible, and I don't agree with
> it at all.  But if we must do it, then this makes it slightly better,
> and does so without standardizing bad practice.  (I think it also
> works with many existing hosts, therefore making the deployment
> problem significantly simpler.)

Reusing a ECDHE ciphersuite is standardizing less of a bad practice,
but it's more un-intuitive. Does ECDHE indicate support of ECDHE or
TLS 1.0?  (An AES-GCM ciphersuite would conclusively indicate TLS 1.2
- until we have TLS 1.3)



Would it make sense to define all three: TLS_1_{0,1,2}_CAPABLE_SCSV
and send only the highest one from the client?  I think if people are
adding in the code to handle the SCSV, the code could be written in a
sturdy and reusable way such that adding a fourth later on wouldn't
even require a code change, just another item to an array.

-tom