Re: [TLS] Fwd: New Version Notification for draft-bmoeller-tls-downgrade-scsv-00.txt

Bodo Moeller <> Thu, 26 September 2013 14:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8B99421F92E7 for <>; Thu, 26 Sep 2013 07:29:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.491
X-Spam-Status: No, score=-1.491 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zWH0Uj6-CukI for <>; Thu, 26 Sep 2013 07:29:14 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D458F21F9991 for <>; Thu, 26 Sep 2013 07:29:12 -0700 (PDT)
Received: from ( []) by (node=mreu4) with ESMTP (Nemesis) id 0LhHE4-1WBmqc33BI-00ma5y; Thu, 26 Sep 2013 16:29:11 +0200
Received: by with SMTP id g12so757560oah.29 for <>; Thu, 26 Sep 2013 07:29:09 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3vOZu9omEFRglh2LlZc8nwr3YjivfPUwjF5VV3s8zP4=; b=kKGpoXYwOAXZm3BoFVRelS8JjXKcge9yqX6WXs53KnsOOZ5R1JBP8qCbfjHyed2y4n 2djLf0Xi+XlxqfvuchEtoTIzxeWnxTclFBxgZnk4guPf/+yuubZSdZxE2jmLWajnbFJd DX75d9meFjEZ5zorbNzMy+CkhvH5maJY4ts7PMLIlaPzKEDCXmlXUoW09v204ssHblaR 8mDKNTLrWwDpN2xz9mYXh6U7+u5OdXstzPzJFC8RrWRZG/lhXUlZfQwahagHHqk1auNc 3oYpnwt02CBndPZK7ThSdywxAkAQEGvM9ek/i5DLrWzKDR+VRyipGg0XuVGW4by+SYlM VcsA==
MIME-Version: 1.0
X-Received: by with SMTP id w3mr1047544oel.10.1380205749483; Thu, 26 Sep 2013 07:29:09 -0700 (PDT)
Received: by with HTTP; Thu, 26 Sep 2013 07:29:09 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Thu, 26 Sep 2013 16:29:09 +0200
Message-ID: <>
From: Bodo Moeller <>
To: Martin Rex <>
Content-Type: multipart/alternative; boundary=001a113346ce6a47b804e74a31e1
X-Provags-ID: V02:K0:3+oln3oDwzYA8tko+CYI9E7CC0KjzkUAqOnK8g4A5S9 ZBxm/XiaeWT3odemAGy5A+L71lbd0UWyrrtAmoNSzBKjzL79i6 CIDPGUfcaih1pCiHG90DCobhcK+w8s7vO92WB6wC5Ca7G/TPHJ k4ZvkWz0MVm2gXRYr/3fU2J0LP/wu2WpGgG5ZFPjiNPZMjAU5j rp08kL6o3VgibmlQ26YjEmCXD41SHLtWjBsn6LFVAbZlidsUMZ 8UbRAUOcpaS0tlD6H4Vnu/8HcD1QXwYrjq0TLHVhWXXQxm3u46 bL/vZ0s3RzUHe6v8Ge+6J2JMoNUsNWPgB7ji+8aknI4wSAgBY9 nz1sC5Q7jh5YCRx8i9Pc2j6T2+Pso9T1llXTt1mSl3hyontqeS xvXKDXTX4C3cVr4HkJxGCjNgH4lkrZkGQGLrjJfmRUyZII87yy vfo98
Cc: "" <>
Subject: Re: [TLS] Fwd: New Version Notification for draft-bmoeller-tls-downgrade-scsv-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: Thu, 26 Sep 2013 14:29:18 -0000

>    This section specifies server behavior when receiving the
>    TLS_DOWNGRADE_SCSV cipher suite from a client in
>    ClientHello.cipher_suites.
> [...]
> To me, this part of your document places two requirements on the _server_
> to abort the handshake.

Yes. My point is that there's no server-side guesswork involved -- no
"flawed or unjustified" assumptions. This is entirely client-directed

In a security protocol, it is a design failure to rely on a connection
> peer to enforce one's own policy (the connection peer may be an adversary),

If the authenticated handshake for a client-side protocol downgrade goes
through and you're actually talking to an adversarial server, the same
adversary could have negotiated the downgraded protocol version immediately
via proper TLS version negotiation.  This entire specification is only
about scenarios in which the client *is* willing to use the downgraded
protocol if necessary and *is*, in particular, willing to rely on it at
least for authentication and integrity-check purposes.  In other words, you
are not relying on an arbitrary connection peer, but on an authenticated