Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt

Adam Langley <> Wed, 25 September 2013 13:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 96C6121F9E0B for <>; Wed, 25 Sep 2013 06:11:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ci60J4QBnVPn for <>; Wed, 25 Sep 2013 06:11:44 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c04::22c]) by (Postfix) with ESMTP id 4DB2821F9DD0 for <>; Wed, 25 Sep 2013 06:11:39 -0700 (PDT)
Received: by with SMTP id x18so5008541lbi.17 for <>; Wed, 25 Sep 2013 06:11:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=OnpjsbpyRUzPQ6l6/mF9kURlQkHzUWGO0z+ij3fxMaQ=; b=HqLl+LCNXd/1153BkAIP6niPT/A92vaNcjj0t2rP1f+Li5beTYZxQn62xjMqZne0xh Iv6DHvgY5nzMBzxoobXyBfyIFFz6+7OcSBRGPZLTa2TDuUKLENIg4QgjM52uf+lUNXHT jFEW9Nw1Gqskt0iZWmv8DNVK6TIomFR+p1Bd9PQa5aK85c2JXVpmSJp0+KRwx/tUrT86 xNIJkgP7P3f9Irg5UGuhi/0nipox+Jo50w9K/JBo+sGN3qnx2nay445vW/lR4URz14YJ LfQu8r4CB1P/EZPwyd+BrDVTB5BTHg9r+cQik55J+H+kk8XCQPYYk2AGiGbcW9SEErSu hJvw==
MIME-Version: 1.0
X-Received: by with SMTP id q19mr30282961laa.16.1380114698172; Wed, 25 Sep 2013 06:11:38 -0700 (PDT)
Received: by with HTTP; Wed, 25 Sep 2013 06:11:38 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Wed, 25 Sep 2013 09:11:38 -0400
X-Google-Sender-Auth: inYuk__6gIoVp-iyjmajrdGKJ1E
Message-ID: <>
From: Adam Langley <>
To: Bodo Moeller <>
Content-Type: text/plain; charset=UTF-8
Cc: "<>" <>
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 25 Sep 2013 13:11:44 -0000

On Wed, Sep 25, 2013 at 7:03 AM, Bodo Moeller <> wrote:
> So maybe the right fix to this kind of problem is to adapt an idea from
> draft-rescorla-tls-version-cs-00 and create a signalling ciphersuite value
> that would *only* be used in SSL 3.0 connections by clients that have
> downgraded, and tells the server "If you can read this, tear down the
> connection because we shouldn't actually be using SSL 3.0 for this
> connection"?

(I think I would want such an SCSV to indicate TLS 1.2 support rather
than TLS 1.0 support, but that's just a detail.)

A possible problem with this approach is that there are both broken
servers and broken networks and I don't have good information about
the latter. (It's obviously much more difficult to detect.)

Broken networks can stop the transit of TLS based on version and that
has been observed, very rarely, in the wild. However, just because we
haven't observed it much doesn't mean that it's not happening, it just
means that we rarely get to observe it.

If it turns out that broken networks are insignificant then we can use
an SCSV to prevent version downgrade. (Using the renegotiation
extension for this would have been nice, but I think we've already
lost that battle.)

However, if they are not then we may need to run modern ciphersuites
in older versions.

The first step to figuring this out is that Chrome will stop
downgrading to SSLv3 when talking to Google servers soon. If that
works, and we're able to get to the point where we can remove fallback
completely without breaking networks, then that will answer the



Adam Langley