Re: [TLS] Inter-protocol attacks

Martin Thomson <martin.thomson@gmail.com> Fri, 15 August 2014 16:56 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 EC2A31A0060 for <tls@ietfa.amsl.com>; Fri, 15 Aug 2014 09:56:16 -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 QUyID1B6KIu0 for <tls@ietfa.amsl.com>; Fri, 15 Aug 2014 09:56:13 -0700 (PDT)
Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F01DC1A0054 for <tls@ietf.org>; Fri, 15 Aug 2014 09:56:12 -0700 (PDT)
Received: by mail-wi0-f181.google.com with SMTP id bs8so1072173wib.14 for <tls@ietf.org>; Fri, 15 Aug 2014 09:56:11 -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:content-transfer-encoding; bh=YXJze9EWY1ReHeqGNwqCM6p13061OWFQT+wvVHIELzQ=; b=I4bBL77DaxdpgK04ofRxI2gDxGkqxVgbTogIHlL/xEseicIrUB9R12LSJJ6khX23Og FHqShn+aXoYOKFWEL9fVWD/6MLBrNiVwzt7k+mDdljCGqAIUliQCqW3jJ8TxdAzyBfcL 5/oG8FYjkP0fUYD6vVoIzpMWSlf09ovaLFX2Q8S0gb/4oRg9yCTlfix8CQwn7Lk9XESh zq1jp1bQwkmpqktBgAgXBBGbZAQlYFEYGDHgw7LuYZhSC7yosQG9MgdejHSa99KlrV7j dZjU8yMNXSYXypbvli7IBM36bYmW1L35aBjRWsQ8L06g4fbHbDzrBkFZARer3s5oL43U IO3A==
MIME-Version: 1.0
X-Received: by 10.194.91.228 with SMTP id ch4mr22182291wjb.59.1408121771650; Fri, 15 Aug 2014 09:56:11 -0700 (PDT)
Received: by 10.194.6.229 with HTTP; Fri, 15 Aug 2014 09:56:11 -0700 (PDT)
In-Reply-To: <515ACDD8-F8F6-4A75-9F5E-E0EC5DB15D35@inria.fr>
References: <20140815015630.D29521AE0D@ld9781.wdf.sap.corp> <515ACDD8-F8F6-4A75-9F5E-E0EC5DB15D35@inria.fr>
Date: Fri, 15 Aug 2014 09:56:11 -0700
Message-ID: <CABkgnnXjSWQrPkZdo4r9PApLYiTCfJHtHZPxYqsJF8SZ1cwcdQ@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Karthikeyan Bhargavan <karthikeyan.bhargavan@inria.fr>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JiS_uNWsHRPV1KokUmtWvD1c4kM
Cc: Antoine Delignat-Lavaud <antoine@delignat-lavaud.fr>, "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: Fri, 15 Aug 2014 16:56:17 -0000

On 15 August 2014 05:36, Karthikeyan Bhargavan
<karthikeyan.bhargavan@inria.fr>; wrote:
> (c) TLS session tickets/resumption are underspecified. Session tickets
> should also include the server_identity, that is the server
> certificate/hash/server name, not just the client_identity (see
> http://tools.ietf.org/html/rfc5077#section-4). Then, during resumption, the
> client should indicate the certificate/server name it wishes to connect to
> (e.g. via SNI) so that S’ can check that the resumed connection is for the
> same certificate/server name.

I think that this is pretty much the right answer.  Since session
tickets are basically the server talking to itself, it's really only
something we can only recommend in a specification.  Deployments that
don't have multiple configurations aren't going to need a binding, but
those that do should be binding the ticket to the configuration.  In
the end, it's probably best to recommend the binding for all cases to
avoid usage issues.

I don't want to make applications responsible for this, at least to
the extent that is possible.