IETF Logo Mail Archive

Re: [TLS] Unifying tickets and sessions

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Fri, 24 October 2014 17:28 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 368D31A1B3C for <tls@ietfa.amsl.com>; Fri, 24 Oct 2014 10:28:04 -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 aV8RJjHbdSfb for <tls@ietfa.amsl.com>; Fri, 24 Oct 2014 10:28:03 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD4D1A86F9 for <tls@ietf.org>; Fri, 24 Oct 2014 10:28:01 -0700 (PDT)
Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id A337DF984 for <tls@ietf.org>; Fri, 24 Oct 2014 13:27:59 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 8AE841FF32; Fri, 24 Oct 2014 13:27:45 -0400 (EDT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: tls@ietf.org
In-Reply-To: <CAOgPGoCfVyDL=Bz--=TWCGLJnizxH2C34JQ+GieZsnddttUaVg@mail.gmail.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>
User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-pc-linux-gnu)
Date: Fri, 24 Oct 2014 13:27:41 -0400
Message-ID: <871tpxxtrm.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/A7Ioz7O-IGs1ke6vksRxMl1TctQ
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 17:28:04 -0000

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.

Today, we have several forward-secret PSK ciphersuites:

0 dkg@alice:~$ gnutls-cli --list --priority NORMAL:-KX-ALL:+DHE-PSK:+ECDHE-PSK:-SIGN-ALL
Cipher suites for NORMAL:-KX-ALL:+DHE-PSK:+ECDHE-PSK:-SIGN-ALL
TLS_DHE_PSK_AES_128_GCM_SHA256                    	0x00, 0xaa	TLS1.2
TLS_DHE_PSK_AES_256_GCM_SHA384                    	0x00, 0xab	TLS1.2
TLS_DHE_PSK_CAMELLIA_128_GCM_SHA256               	0xc0, 0x90	TLS1.2
TLS_DHE_PSK_CAMELLIA_256_GCM_SHA384               	0xc0, 0x91	TLS1.2
TLS_DHE_PSK_AES_128_CBC_SHA1                      	0x00, 0x90	SSL3.0
TLS_DHE_PSK_AES_128_CBC_SHA256                    	0x00, 0xb2	TLS1.0
TLS_DHE_PSK_AES_256_CBC_SHA1                      	0x00, 0x91	SSL3.0
TLS_DHE_PSK_AES_256_CBC_SHA384                    	0x00, 0xb3	TLS1.0
TLS_DHE_PSK_CAMELLIA_128_CBC_SHA256               	0xc0, 0x96	TLS1.0
TLS_DHE_PSK_CAMELLIA_256_CBC_SHA384               	0xc0, 0x97	TLS1.0
TLS_DHE_PSK_3DES_EDE_CBC_SHA1                     	0x00, 0x8f	SSL3.0
TLS_DHE_PSK_ARCFOUR_128_SHA1                      	0x00, 0x8e	SSL3.0
TLS_ECDHE_PSK_AES_128_CBC_SHA1                    	0xc0, 0x35	SSL3.0
TLS_ECDHE_PSK_AES_128_CBC_SHA256                  	0xc0, 0x37	TLS1.0
TLS_ECDHE_PSK_AES_256_CBC_SHA1                    	0xc0, 0x36	SSL3.0
TLS_ECDHE_PSK_AES_256_CBC_SHA384                  	0xc0, 0x38	TLS1.0
TLS_ECDHE_PSK_CAMELLIA_128_CBC_SHA256             	0xc0, 0x9a	TLS1.0
TLS_ECDHE_PSK_CAMELLIA_256_CBC_SHA384             	0xc0, 0x9b	TLS1.0
TLS_ECDHE_PSK_3DES_EDE_CBC_SHA1                   	0xc0, 0x34	SSL3.0
TLS_ECDHE_PSK_ARCFOUR_128_SHA1                    	0xc0, 0x33	SSL3.0

Certificate types: CTYPE-X.509
Protocols: VERS-TLS1.2, VERS-TLS1.1, VERS-TLS1.0, VERS-SSL3.0, VERS-DTLS1.2, VERS-DTLS1.0
Compression: COMP-NULL
Elliptic curves: CURVE-SECP192R1, CURVE-SECP224R1, CURVE-SECP256R1, CURVE-SECP384R1, CURVE-SECP521R1
PK-signatures: none
0 dkg@alice:~$ 

It would be a shame to lose the ability to combine forward secrecy with
PSK.

        --dkg

v2.23.0 | Report a Bug | By Email