Re: [TLS] TLS 1.3 - method to request uncached shared secrets

Eric Rescorla <ekr@rtfm.com> Sun, 19 July 2015 20:27 UTC

Return-Path: <ekr@rtfm.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 019421B2BCB for <tls@ietfa.amsl.com>; Sun, 19 Jul 2015 13:27:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 muIsgPBB03hY for <tls@ietfa.amsl.com>; Sun, 19 Jul 2015 13:27:26 -0700 (PDT)
Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (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 F194B1B2BC9 for <tls@ietf.org>; Sun, 19 Jul 2015 13:27:25 -0700 (PDT)
Received: by wibxm9 with SMTP id xm9so76642595wib.0 for <tls@ietf.org>; Sun, 19 Jul 2015 13:27:24 -0700 (PDT)
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:from:date :message-id:subject:to:cc:content-type; bh=1ope7Jxcqeualc/mBO6pB4362FqdJpwGp3BqU+tTSCM=; b=jeHDboWR+mtkQidJr1B4po14/ZfFJ2pFjm1c8BP/qCw96aAqIyKsLL0q1dUUDL08ps orbIgpjpdOLT/XTLjoKxJSeeQS79tyl7VLzNv/jy4dd7oBmtIzZoFl1u50vJAWSdFEaw zDUdeyBjW1FRJSHqxr7vMy5I9zMB2m5Wx0xn07lwErBBcM74d4cG7tOoW+wZvBbzEKEe /3VMBiBow3Os60M14719JY35cwn5t2+VFtuVg2RGixzAIo8aSGKJ0ej6ryT2O1RgxHFs Qv8Q4bxll63MLoL3lJbHHGMg3b8pPX5lChEL3lGiybJ0+li5tgapZ6q70dlkVhE0kwoo zysw==
X-Gm-Message-State: ALoCoQkGxzujA2UGCov341iobglJx7luB6I3W1bDGZCWTcJcWSRVL+5cdGeNcC4d1WClDHSb82bP
X-Received: by 10.194.158.42 with SMTP id wr10mr48648942wjb.81.1437337644708; Sun, 19 Jul 2015 13:27:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.85.75 with HTTP; Sun, 19 Jul 2015 13:26:45 -0700 (PDT)
In-Reply-To: <CAFewVt7qc6pE_NNdO16FOAhohD=YCmiX1VmSYgpHzbjqtxJevw@mail.gmail.com>
References: <201507180037.56413.davemgarrett@gmail.com> <CAFewVt72efH+9qYzCSBh1heM7N9Ki-6VrVxbAc0=4UcSf5XbVg@mail.gmail.com> <201507181428.40766.davemgarrett@gmail.com> <20150719125016.GA17542@LK-Perkele-VII> <CABcZeBMDujpLqQBtsWG+vutVM8V3g69Ys0_teZ4or=dU-uRwNQ@mail.gmail.com> <20150719171657.GL28047@mournblade.imrryr.org> <CAFewVt7qc6pE_NNdO16FOAhohD=YCmiX1VmSYgpHzbjqtxJevw@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 19 Jul 2015 22:26:45 +0200
Message-ID: <CABcZeBPT2RZe1nR5hZCxSgO+GoHoYAPpmuV7FucZrX6TyRB-qQ@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>
Content-Type: multipart/alternative; boundary=089e013c6478bc4d17051b403f56
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/YX2yIEYVh5OkCk0fYHmnWAex9xk>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] TLS 1.3 - method to request uncached shared secrets
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: <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: Sun, 19 Jul 2015 20:27:28 -0000

On Sun, Jul 19, 2015 at 10:17 PM, Brian Smith <brian@briansmith.org> wrote:

> On Sun, Jul 19, 2015 at 1:16 PM, Viktor Dukhovni <ietf-dane@dukhovni.org>
> wrote:
>
>> On Sun, Jul 19, 2015 at 02:56:22PM +0200, Eric Rescorla wrote:
>>
>> > I'm not seeing a lot of value here. Remember that servers are not
>> > required (and have never been required) to do session resumption, but
>> > much of the overhead of doing it (having to have a database, session
>> > ticket machinery) is associated with being willing to do session
>> > resumption at all, so if a small fraction of clients would tell
>> > you that they're not interested in resumption, it's not clear that
>> > buys you much.
>> >
>> > Are there any server operators who think this is a useful feature
>> > and can explain why?
>>
>> These days, I'm operating servers that only support session tickets
>> (no server-side cache).  If the client does not send the session
>> ticket extension, no session is cached.
>>
>> So for servers that elect the same strategy, there's no need for
>> a separate means to signal the client's intentions.
>>
>
> First, I think that there should be only one way to do resumption in TLS
> 1.3 anyway. All I'm asking for is that the client have some way of
> indicating whether or not it supports resumption. Viktor's method seems
> fine with me.
>
> Maybe I'm misunderstanding, but it looks like the current TLS 1.3 draft
> actually contains a regression here. It seems like it is no longer possible
> for the server to indicate how long a PSK should be held by the client to
> resume a session,
>

Not unless I've made a mistake. NewSessionTicket contains a lifetime_hint
value.

http://tlswg.github.io/tls13-spec/#rfc.section.6.3.12


and it seems like it is no longer possible for the server to indicate that
> it doesn't support resumption.
>

Well, it can't indicate it, but if it doesn't supply a session ticket,
there's no way for
the client to do it.

-Ekr