IETF Logo Mail Archive

Re: [TLS] Unifying tickets and sessions

Nico Williams <nico@cryptonector.com> Fri, 24 October 2014 18:42 UTC

Return-Path: <nico@cryptonector.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 F155F1A6FC8 for <tls@ietfa.amsl.com>; Fri, 24 Oct 2014 11:42:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.044
X-Spam-Level:
X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
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 a_UFb3YLf1JU for <tls@ietfa.amsl.com>; Fri, 24 Oct 2014 11:42:59 -0700 (PDT)
Received: from homiemail-a109.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A52091A6F98 for <tls@ietf.org>; Fri, 24 Oct 2014 11:42:58 -0700 (PDT)
Received: from homiemail-a109.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTP id 6B94720047B14 for <tls@ietf.org>; Fri, 24 Oct 2014 11:42:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=ZmgYWbO3XKUxxsPb2MIX XLU6B9c=; b=K3L94EkrqFH2iAe5EuziLZsqjCehdbDlTY5eQVoWxiVeyGo0GVZP oKANxPvmqKwFKbG2rMD0TN/DfeJ7oTGXB0ZchUXEDrKYKkXNVkk9hpyMDHoM8Idb Z3/3gmckf6cw35B0NKt62LLMW1n32QatBLzduTFcyomEDM7Q83MMXio=
Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTPSA id 206E320047B0E for <tls@ietf.org>; Fri, 24 Oct 2014 11:42:57 -0700 (PDT)
Received: by mail-wi0-f169.google.com with SMTP id q5so1893671wiv.4 for <tls@ietf.org>; Fri, 24 Oct 2014 11:42:56 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.20.43 with SMTP id k11mr5992562wie.28.1414176176948; Fri, 24 Oct 2014 11:42:56 -0700 (PDT)
Received: by 10.216.32.135 with HTTP; Fri, 24 Oct 2014 11:42:56 -0700 (PDT)
In-Reply-To: <871tpxxtrm.fsf@alice.fifthhorseman.net>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com> <11886639.VyNDkQ3oKj@pintsize.usersys.redhat.com> <54493904.7010807@fussenegger.info> <1730049.IgUL0REWQP@pintsize.usersys.redhat.com> <CAOgPGoCfVyDL=Bz--=TWCGLJnizxH2C34JQ+GieZsnddttUaVg@mail.gmail.com> <871tpxxtrm.fsf@alice.fifthhorseman.net>
Date: Fri, 24 Oct 2014 13:42:56 -0500
Message-ID: <CAK3OfOgHWqtBud3ikw8eZgwHDbbECJEO4Ojct1DNpvcWHPcT9w@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7t0Ihefs0jZFpgbjOCGWMHIqaqo
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Unifying tickets and sessions
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, 24 Oct 2014 18:43:00 -0000

On Fri, Oct 24, 2014 at 12:27 PM, Daniel Kahn Gillmor
<dkg@fifthhorseman.net> wrote:
> On Fri 2014-10-24 12:58:54 -0400, Joseph Salowey wrote:
>> [Joe] Personally, I don't think that PFS is a MUST for session resumption.
>>   I think an implementation can attempt to provide PFS like behavior, but
>> if one is really interested in PFS I think the full handshake is the way to
>> go.
>
> If we decide to merge session resumption with PSK as discussed at the
> interim meeting, then deciding that session resumption doesn't get
> forward secrecy means that forward secrecy wouldn't be an option with
> PSK.

Why would that follow?  Joe says that PFS should not be REQUIRED for
resumption.  That doesn't mean it shouldn't be possible at all.

It's true that without merging PSK and resumption there would be no
need to support PFS in resumption handshakes: the whole point of
resumption is to reduce the number of PK key exchanges.  But it's not
obvious that a merger can't provide PFS as an option [that typically
just wouldn't be used in the resumption case].

Nico
--

v2.23.0 | Report a Bug | By Email