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

Adam Langley <agl@google.com> Tue, 05 June 2012 21:23 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 7E0D821F884C for <tls@ietfa.amsl.com>; Tue, 5 Jun 2012 14:23:13 -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 AADk5ODJkw2D for <tls@ietfa.amsl.com>; Tue, 5 Jun 2012 14:23:13 -0700 (PDT)
Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id E7A2421F8841 for <tls@ietf.org>; Tue, 5 Jun 2012 14:23:12 -0700 (PDT)
Received: by ghbg16 with SMTP id g16so5282276ghb.31 for <tls@ietf.org>; Tue, 05 Jun 2012 14:23:12 -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 :content-type:x-system-of-record; bh=3s9T5vm9Cl+QLSadj6mNXKtvwd8XO1Tay0YLhE7AG4Y=; b=YQT2MIorMMKHzmRs7LeWSnlgnawXQg6ejLtbhSbi970oFO9o7d++JZrIvseufBwTSP N7tQO0KzsS9XcRKMUGc/fMtEJl6kNVx5T84edCTrTSOMYEgED9t9yLIfXfTtYv2BIpET oPkRazxBXSlVJg1CrTUWF/B8sy2xbzXTwOpgVjfSBD2tAt9T82xR8bNySnOYXxBFgpQU Cxsonv7Ea+70zKOSpSpeeKIIHHzDcInE5aNaoygnYejNr3BzP2ANwAYozk0TAseI//FW XqQxebmnkqwet+jD+QAXZm7YcGQ7lSEXKZWgk8HiHR/gD1cJ8T69kgTHC116komMgtpD fWIg==
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 :content-type:x-system-of-record:x-gm-message-state; bh=3s9T5vm9Cl+QLSadj6mNXKtvwd8XO1Tay0YLhE7AG4Y=; b=GkvMyPWdF76dTL2nsAnyKyzI6F7+ZNRflwiLFyRfvihV0hdf4QIOyLiaX4CYzQdXAl B7WW9B+PqCaBIcgWvGPixDs3bDadYhzsssNIGsRgYyHOMaV0XDgdVMYuhOaagGWn0Uq9 RezIOhVIideZdIi5Vqe+3PJ6mxt+0SuV4D+F9aG+ecgaIeE9hdgGjy2rJlbcz+h26B/c RAbaC9xhNsccbvNFk7V5k7Yk3+d/jBDfo6mKmvGAffk+VpwRfpK2scAYCqegbWZtd6Ip zf/mkxc6hC0kZJEeyZ0Pe4xM5Vgml1qIVDi6oHElCe8HvChQtueIrNF+dbEztcl2QgUZ fhpA==
Received: by 10.50.57.167 with SMTP id j7mr4491338igq.53.1338931392065; Tue, 05 Jun 2012 14:23:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.50.57.167 with SMTP id j7mr4491335igq.53.1338931391972; Tue, 05 Jun 2012 14:23:11 -0700 (PDT)
Received: by 10.231.5.201 with HTTP; Tue, 5 Jun 2012 14:23:11 -0700 (PDT)
In-Reply-To: <CAL9PXLwdQctUub5oPx0tepsfveDo0bNKGBUaUBBFeq4u4D0BbA@mail.gmail.com>
References: <CAL9PXLwdQctUub5oPx0tepsfveDo0bNKGBUaUBBFeq4u4D0BbA@mail.gmail.com>
Date: Tue, 05 Jun 2012 17:23:11 -0400
Message-ID: <CAL9PXLzQ5b1+9DH44SnJwAQ1eMx3mBYpGrSpU2vT+4P7Gb3MMg@mail.gmail.com>
From: Adam Langley <agl@google.com>
To: tls@ietf.org
Content-Type: text/plain; charset="UTF-8"
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQncxf1x0REfkIqJrETuPNmYJogsT5KqGvmbPenlG+XUSMX2hePDU94Cho5MIXSwrQY1DMrZscIYMicixIqEbNrcoDIRhGw2x6S/6Vqxz8aacmLp/c29ljRaLGcWfSpBjDJ0+qae
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: Tue, 05 Jun 2012 21:23:13 -0000

wtc pointed out
http://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-version-cs.txt
from last year. I didn't build on that because it didn't seem to go
anywhere, sadly.

Although it's worth noting that my previous comment:

"This doesn't really make the deployment of new TLS versions that much
easier. The client would still have to try 1.2, 1.1, 1.0 etc. What
would be helpful is if the server, seeing a TLS 1.2 SCSV, treated the
client as if it has advertised 1.2."

Has turned out to be false. We're now aware of networks which filter
on the version in the returned ServerHello.

Yngve's point about just using the renegotiation extension as an
indication, client-side, that we shouldn't have done a fallback is
still a possibility.


Cheers

AGL