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

Adam Langley <agl@google.com> Mon, 11 June 2012 15:29 UTC

Return-Path: <agl@google.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 341C821F864F for <tls@ietfa.amsl.com>; Mon, 11 Jun 2012 08:29:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level:
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 7ffuTnSQD9MD for <tls@ietfa.amsl.com>; Mon, 11 Jun 2012 08:29:51 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFFD21F859E for <tls@ietf.org>; Mon, 11 Jun 2012 08:29:51 -0700 (PDT)
Received: by yhq56 with SMTP id 56so3112318yhq.31 for <tls@ietf.org>; Mon, 11 Jun 2012 08:29:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=YdVH0KIPHUvPmcGHWBI3Htb5Y1z5j76FVY2VYEOOapI=; b=kbYT0urodB6nyxJ/Kcg9VGqLs5mitnLgJ0CuR5ZKLR//WqU9MX5xqvij0Iktib6MeD EHcMgi/9WL0vDWq5ot+3OBTyxE0diIxnFWZ1IiieVM6kTFzDbaxtFBlM2bwkxBu1dOX6 lI30ywE0/WNRuGB5Mi74OCGkyazrs1mQKFDROLuqZE6JzUZIhPNOhgWRhg897AdepEP4 3pGX5N2KlPFlpCoqtz01fi/72WSYeZ9wdZD4rURriSU8S7VFlixDmg6yX7+UZZYhwQrg 6tuGwYCFMgi/fe+aamphQaFrkcZMCy5W114kMmPiDcr5vQcVRdj8O0wzCdnrl3Rdq3LL 0mRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=YdVH0KIPHUvPmcGHWBI3Htb5Y1z5j76FVY2VYEOOapI=; b=axF0xGlrHjUSlZuphWgNcbbdtOAQgS6lI1+Vl0a+vbZueDq8ZTkKw2RE/cOtHRb6As wenPrWUkJNBMdGs7wHv10rvtW7WJ0xbKgT/O1Wult+k4CDyOb1zRNBA83UGx1lcirjMc vYE4LGUFDQQdp9ti7SXEr0qve03/uaNca1aJjPGGNCA1/QrgHB1U+vO/MpnQODu8x3ih GeeJ4w6SrRMGwVw0zuEW0+J7NpYzhetFs/VhJs6BJDA0yHUdbFILi0jsHPk718duAnJj Qm+z/LJpHpkbx2xM4l1mletdWtioPZNFUOijBpGDO0AcSWyArdb84kxMmbVv3sxCJ8DY z/Qg==
Received: by 10.50.190.163 with SMTP id gr3mr6731132igc.22.1339428586913; Mon, 11 Jun 2012 08:29:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.50.190.163 with SMTP id gr3mr6730974igc.22.1339428585064; Mon, 11 Jun 2012 08:29:45 -0700 (PDT)
Received: by 10.231.5.201 with HTTP; Mon, 11 Jun 2012 08:29:44 -0700 (PDT)
In-Reply-To: <4FD277F2.30603@gnutls.org>
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> <CA+cU71nuGwgTc-dHkM_RrVUFZnOOoGkLeq-A2cQoYaobJFQ1zw@mail.gmail.com> <4FD1AB25.7070101@gnutls.org> <CAL9PXLynKsz+3x9BGOKgN1HdULGFckB3Z1wkRXSzca-C_yzoZA@mail.gmail.com> <4FD277F2.30603@gnutls.org>
Date: Mon, 11 Jun 2012 11:29:44 -0400
Message-ID: <CAL9PXLwmEDcUy3006fNHKA8OBeR5Tw=oM_YsKxUvi6zdNwUeVA@mail.gmail.com>
From: Adam Langley <agl@google.com>
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
Content-Type: text/plain; charset="UTF-8"
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQnyDj0vDQArCxss1+RVb7coK5RbOuHX/FDjpM8qSZE70sRb0Dc54m/vNBK+nSmINW2AJ8axA+Mn+h8UfT/S/BAvyU58BMEEVoJQ2j5Uha3+vzkCFZsaRouqOaCFyu15RVmxIu1F
Cc: "tls@ietf.org" <tls@ietf.org>
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: Mon, 11 Jun 2012 15:29:52 -0000

On Fri, Jun 8, 2012 at 6:08 PM, Nikos Mavrogiannopoulos <nmav@gnutls.org> wrote:
> It may not be true, but what would you do if the SCSV check fails?
> Wouldn't you warn the user?

We would either go back to TLS, or return the original network error
that caused the fallback. We're not going to try telling the user that
they "may be under attack" or such.

> Most probably he'd say that your browser doesn't work. Let's
> try the other one (which doesn't support SCSV and thus wouldn't detect a
> possible attack).

That's always a possibility but the argument that users will try other
browsers, while true, is also true of many other changes that we've
made: rejecting tiny EDH groups, rejecting RSA keys < 1024-bits,
rejecting MD4 and MD5 signatures. With each of these we have,
undoubtedly, lost users to browsers that don't implement these things.
But we have also motivated people to fix things and provided cover for
other browsers to make the same changes. This tension between breaking
things for the common good and keeping users happy always exists in
large software and I know that this proposal, even for just SSLv3,
will break users behind a certain vendor's firewall product. But
that's a cost to be balanced rather than a fatal flaw (and I'm already
taking to that vendor).

> What if a new server comes out that the SCSV fails for some
> random reason?

Once we start to use the SCSV, we draw a line in the sand and it's
much less likely that there will be compatibility problems in the
future.

> I agree that it helps to mitigate some problem, but my
> concern is, does any gain obtained justify the introduced protocol
> complexity?

Well, the complexity decision depends substantially on an individual's
preferences. I obviously believe that this is worthwhile: the SCSV is
a relatively minor addition and the downgrade attack is real. But from
my point of view the protocol is already subject to several of these
warts [1] that the specified protocol doesn't include. This would be a
rather obvious wart on the spec, even if it's not so big compared to
my reality.

[1] http://www.imperialviolet.org/2011/02/04/oppractices.html


Cheers

AGL