Re: [TLS] Inter-protocol attacks

Martin Thomson <martin.thomson@gmail.com> Mon, 11 August 2014 06:06 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 578961A030F for <tls@ietfa.amsl.com>; Sun, 10 Aug 2014 23:06:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNi0pdqHkH28 for <tls@ietfa.amsl.com>; Sun, 10 Aug 2014 23:06:45 -0700 (PDT)
Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CDA91A030E for <tls@ietf.org>; Sun, 10 Aug 2014 23:06:45 -0700 (PDT)
Received: by mail-wg0-f44.google.com with SMTP id m15so7959505wgh.27 for <tls@ietf.org>; Sun, 10 Aug 2014 23:06:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6GxpX/E4ZIml19730QI2o19XjZxDbiqQGlJBI9H+bsg=; b=Ve5ulL+4+8X67j7k8+Ds0jQFNlJb6TLvWak/6OidFuCS3ucS5ApeICt+IQOl+eO71S BZ/lc/YAycnanVSliD1OO+8ZPVqovRKdlG/B5VJrbbpe2gyPkPCgwreg3FLKdOrVINXF w3PaVtW6TbQNG4Ry3yi+yiFi3foLfy3Eddt8H6KiHVoH9slFlGmWOZcTuEW6k8SJOZVH qGi8IDoaxhsD8VIiDfMHFIza8TqEA4UqwjEF0tsHFA2/8m6IFzGICKBZVnF0oDIcPsgv +PCipkmYZMUPfIH7TdNWYKiJ1TH1gHBcw/r26Vq07l2MkjtIgDjsP2DinIe9XfZUyUo5 sakA==
MIME-Version: 1.0
X-Received: by 10.180.103.74 with SMTP id fu10mr23191376wib.47.1407737204015; Sun, 10 Aug 2014 23:06:44 -0700 (PDT)
Received: by 10.194.6.229 with HTTP; Sun, 10 Aug 2014 23:06:43 -0700 (PDT)
In-Reply-To: <53E771B7.7060609@delignat-lavaud.fr>
References: <CACsn0cmrtZm63ao876ryJPV1o-m2f4Mjda-H5JkH8q=Jjbc=qA@mail.gmail.com> <53E771B7.7060609@delignat-lavaud.fr>
Date: Sun, 10 Aug 2014 23:06:43 -0700
Message-ID: <CABkgnnXqt5+cJ=b45R7Xdm+ckZ9GFLzcj1f=aXuTEEXprtWS1w@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Antoine Delignat-Lavaud <antoine@delignat-lavaud.fr>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/S08AYiPuXN5Eogwlt-mSJiCRbCQ
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Inter-protocol attacks
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 11 Aug 2014 06:06:47 -0000

On 10 August 2014 06:20, Antoine Delignat-Lavaud
<antoine@delignat-lavaud.fr> wrote:
> Chrome introduced a very significant change to the authentication model of
> TLS that went virtually unnoticed. In SPDY, the TLS client session cache is
> no longer indexed by domain and port, but instead by domain set, IP and
> port: in classic TLS, an established connection or session can only be
> reused for the same domain, whereas in SPDY, it can be reused for any domain
> in the certificate verified when the session was created, provided that it
> points to the same IP as the original connection. The DNS condition is
> obviously meaningless to a network attacker, which means that all security
> guarantees that were previously session-specific should now be considered
> certificate-specific.

The behaviour you describe isn't quite correct, because - I believe -
that it requires that the DNS resolve to the same IP (or that one of a
set of alternative values point there).  But that's not a particularly
important detail, DNS has never been a part of the security story for
https.  It's a big part of http, but we all know what you get there.

Either way, this behaviour has been discussed at some length and was
not found lacking in the SPDY/HTTP2 context.  Yes, HTTP/2 standardizes
this practice.  The poor handling of Host header fields in HTTP/1.1
means that it will probably never be advisable to do something like
this there.

As always, I caution that we have to be careful to distinguish between
attacks on implementations and attacks on standards.  I am aware that
there are bugs in implementations.  I'm also told that they are
somewhat difficult to exploit.