Re: [TLS] Unifying tickets and sessions

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Fri, 24 October 2014 18:52 UTC

Return-Path: <dkg@fifthhorseman.net>
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 295B11A8948 for <tls@ietfa.amsl.com>; Fri, 24 Oct 2014 11:52:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 C9fvPKaSY2QB for <tls@ietfa.amsl.com>; Fri, 24 Oct 2014 11:52:06 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3361A8822 for <tls@ietf.org>; Fri, 24 Oct 2014 11:52:06 -0700 (PDT)
Received: from [10.70.10.51] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id C031AF984; Fri, 24 Oct 2014 14:52:03 -0400 (EDT)
Message-ID: <544A9FC6.3080604@fifthhorseman.net>
Date: Fri, 24 Oct 2014 14:51:50 -0400
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Icedove/32.0
MIME-Version: 1.0
To: Nico Williams <nico@cryptonector.com>
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> <CAK3OfOgHWqtBud3ikw8eZgwHDbbECJEO4Ojct1DNpvcWHPcT9w@mail.gmail.com>
In-Reply-To: <CAK3OfOgHWqtBud3ikw8eZgwHDbbECJEO4Ojct1DNpvcWHPcT9w@mail.gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="ggOjhXnRBk0EwaFjuSl9Iq06eCxXHuaBH"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/viAbG6C1NGDo-i_gXbez9Gpqsk4
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:52:08 -0000

On 10/24/2014 02:42 PM, Nico Williams wrote:
> 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.

Sure, understood.  I just want to make sure that we retain the
possibility to do both PSK and session resumption with forward secrecy
if the peers want it, and not drop that combination on the floor.

	--dkg