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

Nikos Mavrogiannopoulos <nmav@gnutls.org> Fri, 08 June 2012 22:08 UTC

Return-Path: <n.mavrogiannopoulos@gmail.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 BFD0411E80E8 for <tls@ietfa.amsl.com>; Fri, 8 Jun 2012 15:08:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 YnbHuHKn0k-c for <tls@ietfa.amsl.com>; Fri, 8 Jun 2012 15:08:59 -0700 (PDT)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id E4D9411E80AA for <tls@ietf.org>; Fri, 8 Jun 2012 15:08:58 -0700 (PDT)
Received: by eekd4 with SMTP id d4so1772913eek.31 for <tls@ietf.org>; Fri, 08 Jun 2012 15:08:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=IyucPbNu2Xm8hbdta45H/cKkg9EbODDIdaah6We/fZY=; b=EsevBeFwuf7+Ey9jQaXiq39nF16eJGcjvEhT26Kjo1BrYpVDt6VCIGDGHdUAA+yxj2 nsq9H+VgaVM/kVjj+WfhWEc/TENv1Naibygi6vglHPAPVyNtwr8zQomiiNaK94bzw7sx iTChZnWZZtcNDNC6F+mhEZz+7WjJdVKBPKn1irPdSqrG1Xe4Gr2oYA/A/a5FQB6yYISp OVyGaBXg0UXjJkaMj/5Yz7+6QiIkv55fGeCAM/pigQmOxNL9VMbWFh0DSg81sQn21g6v SqrelyHoK2XUnWPGOwJ2ofklelRlDgI5VjYDASEq/yknZNobyS4FlWs61Gf9FTFBObvd bCSw==
Received: by 10.14.53.6 with SMTP id f6mr4029341eec.169.1339193337865; Fri, 08 Jun 2012 15:08:57 -0700 (PDT)
Received: from [10.100.2.14] (d51A49E78.access.telenet.be. [81.164.158.120]) by mx.google.com with ESMTPS id q53sm26405944eef.8.2012.06.08.15.08.56 (version=SSLv3 cipher=OTHER); Fri, 08 Jun 2012 15:08:56 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <4FD277F2.30603@gnutls.org>
Date: Sat, 09 Jun 2012 00:08:50 +0200
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20120510 Icedove/10.0.4
MIME-Version: 1.0
To: Adam Langley <agl@google.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> <CA+cU71nuGwgTc-dHkM_RrVUFZnOOoGkLeq-A2cQoYaobJFQ1zw@mail.gmail.com> <4FD1AB25.7070101@gnutls.org> <CAL9PXLynKsz+3x9BGOKgN1HdULGFckB3Z1wkRXSzca-C_yzoZA@mail.gmail.com>
In-Reply-To: <CAL9PXLynKsz+3x9BGOKgN1HdULGFckB3Z1wkRXSzca-C_yzoZA@mail.gmail.com>
X-Enigmail-Version: 1.4.1
OpenPGP: id=96865171
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
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: Fri, 08 Jun 2012 22:08:59 -0000

On 06/08/2012 05:18 PM, Adam Langley wrote:

> On Fri, Jun 8, 2012 at 3:35 AM, Nikos Mavrogiannopoulos <nmav@gnutls.org> wrote:
>> If you want to only prevent against the attacker that wants to rollback
>> the session to SSL 3.0, then all you need to do is to perform the proper
>> TLS protocol negotiation, which protects against that. If it doesn't
>> work warn the user.
> Yes, the aim is to prevent an attacker performing a downgrade attack to SSLv3.
> Warning the user assumes that the user can understand what we're
> trying to tell them which is not true here.


It may not be true, but what would you do if the SCSV check fails?
Wouldn't you warn the user? Why do you think he'd better understand that
warning? 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).

>> What happens if we have a buggy server that incorrectly implements the
>> fallback detection mechanism? We define another one?
> The SCSV for the renegotiation indication extension was deployed
> without any serious issues, which is strong evidence that we can
> viably deploy other SCSV values.


Indeed, but this was the case in initial TLS deployments. You rarely
have issues when you implement the protocol you defined, the issues
arise when 3rd parties try to implement their understanding of your
protocol. What if a new server comes out that the SCSV fails for some
random reason? I agree that it helps to mitigate some problem, but my
concern is, does any gain obtained justify the introduced protocol
complexity?

regards,
Nikos