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

Bodo Moeller <bmoeller@acm.org> Thu, 26 September 2013 09:47 UTC

Return-Path: <SRS0=fyqm=TG=acm.org=bmoeller@srs.kundenserver.de>
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 8FA6721F99CD for <tls@ietfa.amsl.com>; Thu, 26 Sep 2013 02:47:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.501
X-Spam-Level:
X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
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 N6oiM3N0lesC for <tls@ietfa.amsl.com>; Thu, 26 Sep 2013 02:47:30 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id EBB3311E8187 for <tls@ietf.org>; Thu, 26 Sep 2013 02:47:25 -0700 (PDT)
Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0Ls7Op-1VrhpL2Bqx-013MQU; Thu, 26 Sep 2013 11:47:25 +0200
Received: by mail-ob0-f179.google.com with SMTP id wn1so1572565obc.10 for <tls@ietf.org>; Thu, 26 Sep 2013 02:47:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=h5aFs8nLoChfCJsSKCOJfWLd2hFsXwcl5tcBwLPeQ2U=; b=R30NXJjrZlLJyAOfSsxZ2VitBsIt7dcNQCkSwM501Te0y7phi5sryZCOiA/chzcFxx REDHvMkpC4xdNckO1zRvSMAFekTM6yyPxOuR0Z/RSzB+0s+8uvzm0p8hhqxU46wtMna/ jiMg/Uskztrls1QRRBm0oJNA5MwlLwwWhLa/Hu3MrKfqld8/ymkfM6ULL4xlvTr6shYA qyghZYl1897yt/6Un+t0a19oyUnmB59q8yCqSQvXPQG9/V78wzOcQWgSs05Djmluo9Xd s9lBjJ5eVHqjn1iP9l959Dk8dq+bYTsK/WfGl2YZtlqg+GPB+MsZvuoAqWSK9Glpw/4k TbIw==
MIME-Version: 1.0
X-Received: by 10.182.84.132 with SMTP id z4mr874569oby.49.1380188843116; Thu, 26 Sep 2013 02:47:23 -0700 (PDT)
Received: by 10.60.115.72 with HTTP; Thu, 26 Sep 2013 02:47:23 -0700 (PDT)
In-Reply-To: <op.w3z7tycm3dfyax@killashandra.invalid.invalid>
References: <20130925202312.29986.21441.idtracker@ietfa.amsl.com> <CADMpkcJLr8P+4jFpTZBkAJQJ8Q=wd=h4tKpfX8FnWKY5jV4OtA@mail.gmail.com> <op.w3z7tycm3dfyax@killashandra.invalid.invalid>
Date: Thu, 26 Sep 2013 11:47:23 +0200
Message-ID: <CADMpkc+1mJduJj6_Soh1u+m8naiYr_RaH+m51DJsUJ2p493k_w@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=089e0111c09ab7904e04e74641fd
X-Provags-ID: V02:K0:3nBqp4Tt2/WmqDQ4B14EGMSqjnl+dcnVFDXoFb1Styr 1hQabxifflLTSii1ZMVE4Eh0viOorYYKMOIneh/dYYcn37wHW9 2EY/piCqON6ruCt9hQY/qJ2i65CvvS0NKhTYUGctJUF4cGjrFb 8Jl+VJkjL5K+AOUHasthlvzvoe27/LkiIV7KrFnXuyDLLtEgDm iRUwpKXLM3wzUUbbFm2eIoGtQ7fEex52smIMH2broJmnQoCiHA WbOroUmVpsSFhTAR0FaBkQdGtRcBiMojZ18oxbFjPjfJ4s867G 2Hc4PTcx5V6n3kOxqR3MkLCsCsQN+k3GCpz0kdpxbJ8daAugpG qUMwY2qGDoMXON5kHQ797nBDTLEg1h+H5FaTHTaVJ6rZqDCsK/ iOmsFa0WJBDVd7RWrAOmifXDHpkJLXiD6L655vb+I38OZnjJQW 71UxR
Subject: Re: [TLS] Fwd: New Version Notification for draft-bmoeller-tls-downgrade-scsv-00.txt
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: Thu, 26 Sep 2013 10:01:11 -0000

> Document: <http://www.ietf.org/id/draft-**pettersen-tls-version-**
> rollback-removal-02.txt<http://www.ietf.org/id/draft-pettersen-tls-version-rollback-removal-02.txt>
> >
> Tracker: <http://datatracker.ietf.org/**doc/draft-pettersen-tls-**
> version-rollback-removal/<http://datatracker.ietf.org/doc/draft-pettersen-tls-version-rollback-removal/>
> >
>


> The benefit of my proposal is that:
>
>  - it only needs to be deployed client-side.
>  - it does not require changes to the protocol, only to how the client
> handle a specific situation.
>  - once clients only accept renego patched server this method, *and* the
> version rollback functionality can be removed.
>
> There will initially be the downside of handling the .26% servers that are
> version/extension intolerant, but those can be quickly patched. There is
> also the problem of version/extension intolerant intermediates in the
> network that have been observed by the Google Chrome team.
>



> I'll also note that two other approaches (proposed by EKR and Adam
> Langley) for this have been discussed the past two years, using SCSVs, and
> these and mine were discussed at the IETF-84 TLS WG meeting.


Thanks for your comments!

Obviously all of the above proposals are somehow related.  Actually, I
think that your ID and mine in fact complement each other in
that draft-pettersen-tls-version-rollback-removal-02 provides heuristics
for how to handle (and avoid) protocol rollbacks in the *current*
implementation landscape, whereas draft-bmoeller-tls-downgrade-scsv-00
specifies a simple mechanism that can be used to avoid security problems
from protocol rollbacks in a very *general* way.




Martin Rex noted (in neighbor thread "[TLS] Comments/Questions on
draft-gutmann-tls-encrypt-then-mac-00.txt" where this came up, but which I
don't want to hijack entirely):

OH NO, not again!!
>
> Any kind of specification for TLS, that suggests to the server
> to apply heuristics and make (often flawed or unjustified) assumptions
> about what the client may want or may not want and have the _server_
> abort the handshake rather than the client, are a REALLY BAD IDEA and
> squarely against the IETF spirit to promote interop.


I'm not sure to what extent I agree to this claim (for example, we do allow
servers to abort with an insufficient_security alert if they don't agree
with any of the ciphersuites listed in ClientHello.cipher_suites), but in
any case please note that this is not actually what
draft-bmoeller-tls-downgrade-scsv-00 specifies.

Rather, the specification has very specific instructions for servers when
to abort the connection (certainly I'm all for encouraging
interoperability, but for a security protocol there clearly are limits to
this -- I'd rather not interoperate with man-in-the-middle-type attackers,
for example), and specifically leaves it to clients to request that
server-side behavior for a given handshake attempt or not.  The
specification includes recommendations that will ensure full security based
on the capabilities of the given client and server, but client
implementations are allowed to ignore these if there are appropriate
reasons.

(I think an essential difference to Eric's and Adam's earlier proposals is
that in my proposal, the client wouldn't enumerate its capabilities for the
purpose of server-side heuristics.  Instead, use is entirely directed by
the client, as needed by its protocol downgrade sequence.  In the ideal
case, with no client-side protocol downgrade taking place at all, nothing
happens.)

Bodo