IETF Logo Mail Archive

Re: [TLS] Unifying tickets and sessions

Manuel Pégourié-Gonnard <mpg@polarssl.org> Wed, 22 October 2014 23:27 UTC

Return-Path: <mpg@polarssl.org>
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 6CDC41A87A3 for <tls@ietfa.amsl.com>; Wed, 22 Oct 2014 16:27:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level:
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] 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 f-9yz3njtQpB for <tls@ietfa.amsl.com>; Wed, 22 Oct 2014 16:27:12 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50DE01A8781 for <tls@ietf.org>; Wed, 22 Oct 2014 16:27:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=CWSyRFIXhyeBaOjB8bID69h249YuK7VbPllgXIG8EB4=; b=oWqJ+B3/4xKJQfQhCYaEHTcAAW3hsmMO6JXJ6oFkTnqABwte17D3oIwlZjOV7tjF+B0nhH/OxmCpYKZaE+g99rn8fNKR6ly/KcT4B5bqh+JpsBo7GumbX0qvsu+6YyKcY/9dsb3pu4mviDjBXB1NmW/8FAHtWx1if7fMbm8sqgM=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <mpg@polarssl.org>) id 1Xh5J3-0007uc-0Q; Thu, 23 Oct 2014 01:27:05 +0200
Message-ID: <54483D4C.9060809@polarssl.org>
Date: Thu, 23 Oct 2014 01:27:08 +0200
From: Manuel Pégourié-Gonnard <mpg@polarssl.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Salz, Rich" <rsalz@akamai.com>, Nico Williams <nico@cryptonector.com>, "tls@ietf.org" <tls@ietf.org>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com> <5445775E.3050108@fussenegger.info> <54458113.1050304@polarssl.org> <20141020235832.GK19158@mournblade.imrryr.org> <CAK3OfOj9bZcSDdWhHGeGT0STg6XBkYaExW+rQFN-FFE4oaPLrw@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D3AF64EE4@USMBX1.msg.corp.akamai.com>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D3AF64EE4@USMBX1.msg.corp.akamai.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Rw9KiYiVuJJxAZDtTPy7_iM81Po
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: Wed, 22 Oct 2014 23:27:13 -0000

On 23/10/2014 00:18, Salz, Rich wrote:
> I understand the concern:  the ticket should be encrypted at least as
> strongly as the bulk encryption of the traffic.
> 
Yep.

> But that concern is misplaced (a server could have a one-time-pad and do
> XOR), and it is not up to the client to tell the server how to operate.  The
> client can always not send the ticket if it has concerns, and is able to
> justify/prove them.
> 
I don't think this is correct. Once the server emits the ticket (if we're
speaking about a ticket that contains session state including the MS), it's out
there in the clear* for an attacker to play with. That the client chooses to
ignore the ticket doesn't change that fact.

The server is fully responsible of protecting key material and not sending it
with a protection much weaker than the one used for the traffic.

* For TLS 1.2 I mean. For 1.3 that might be different.

Manuel.

v2.23.0 | Report a Bug | By Email