IETF Logo Mail Archive

Re: [TLS] Resumption ticket/PSK

Kyle Rose <krose@krose.org> Thu, 19 May 2016 19:09 UTC

Return-Path: <krose@krose.org>
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 1EA0A12D638 for <tls@ietfa.amsl.com>; Thu, 19 May 2016 12:09:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org
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 lWmaCQkcv-xr for <tls@ietfa.amsl.com>; Thu, 19 May 2016 12:09:25 -0700 (PDT)
Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C597C12D5B8 for <tls@ietf.org>; Thu, 19 May 2016 12:09:24 -0700 (PDT)
Received: by mail-qg0-x230.google.com with SMTP id 90so48904062qgz.1 for <tls@ietf.org>; Thu, 19 May 2016 12:09:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=BnSN2tEkMdLFoh0LDaiG6CZwOGw4t4imHxqb2ZtrIJU=; b=SSDjI5eYSxlYiDyCoRwA6hKrHugbiy/XM2kNiqAt0/7fONph0TyUPRbep+euNa9emp XLmBq4ufVBr4kwyBqVUtD4Llku68UoqEJBO91itDmyhgKZ5pJ/loamFd71+0KwUTaltl 5X2uFoJQPodvUq3jpmdiu9zsUu45Cu4XzLjMo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=BnSN2tEkMdLFoh0LDaiG6CZwOGw4t4imHxqb2ZtrIJU=; b=YyNdo0Z2Ct9W9hlBYbUGJBtOHp0rMmXU10Su6GLaRKdy17QfZ2g1Jv+sVe827oR8u0 FIE2RfDWdHZ+NaQo5wv8ZqjclvaZERsXOk8l9kGudh0/grTNi0W7HfovptDunElGQ7Ii OdLxxtznj1yRwq0AYfInQ+XifwY5SplBljxTAjmbTuaRoeXXeXC1Kf/WcrlRHQW0T00g ww/q7nvbFbYxsRmGXNp8r7lt5wpnMwoVzMD2gnCNkWKP2wJA8Zt3RJXo6IZv3ywFPC4p zKzFO8B7B/VsqumQCtR3TUyIrppTKO4XdamZYvnJP0/5/zwuy29B2WPfPDJeN1drjjtN m7cw==
X-Gm-Message-State: AOPr4FWPNxWBr0LPYPi0q3+WtNaADsMExPURiGBUWNEkWH6l+T7tb2qyZCz4aVJrh9NLe4jfLjvvZDnjPB+vLg==
MIME-Version: 1.0
X-Received: by 10.140.42.78 with SMTP id b72mr15100280qga.48.1463684963880; Thu, 19 May 2016 12:09:23 -0700 (PDT)
Received: by 10.55.96.130 with HTTP; Thu, 19 May 2016 12:09:23 -0700 (PDT)
X-Originating-IP: [2001:4878:8000:50:fc46:bf8d:218d:1fef]
In-Reply-To: <20160519190508.GE3300@mournblade.imrryr.org>
References: <CAJU8_nVhM+xOnt8D8UJ8qvWUFts3s5n3gOQvJZYs=XWymfVOVQ@mail.gmail.com> <CABcZeBM8R8LC0wQfxp63BzfjRvLh4sYh4HdT5KZ8LXe2uE3GgQ@mail.gmail.com> <20160519190508.GE3300@mournblade.imrryr.org>
Date: Thu, 19 May 2016 15:09:23 -0400
Message-ID: <CAJU8_nW5jqO3DSvZZNpNQThnCb3P4bCBjE47uhjPRPB1ix6_mg@mail.gmail.com>
From: Kyle Rose <krose@krose.org>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/c06S1tkASJwjz_iA0w6qltoKdGk>
Subject: Re: [TLS] Resumption ticket/PSK
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 19 May 2016 19:09:26 -0000

On Thu, May 19, 2016 at 3:05 PM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:

> I think this is much too complicated.  Simpler solution is for
> clients (browsers and the like for which tracking is an issue) to
> not reuse sessions when their IP address changes

I don't think this is sufficient. Reusing session tickets will reveal
distinguishing information about individual clients behind NAT exit
points, for instance, even when their internal/RFC1918 addresses don't
change.

> The burden of tracking counter-measures should fall squarely on
> the client.

I agree that it's up to the client, but there are measures the server
can take to assist the client while not adding to its full handshake
burden. IOW, it helps the server, as well.

Kyle

v2.23.0 | Report a Bug | By Email