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

Eric Rescorla <ekr@rtfm.com> Sun, 19 July 2015 20:49 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 000A71B2C2B for <tls@ietfa.amsl.com>; Sun, 19 Jul 2015 13:49:53 -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 lmdhf2pJo8TG for <tls@ietfa.amsl.com>; Sun, 19 Jul 2015 13:49:52 -0700 (PDT)
Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (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 8CE8F1B2C2D for <tls@ietf.org>; Sun, 19 Jul 2015 13:49:51 -0700 (PDT)
Received: by wibxm9 with SMTP id xm9so10722455wib.1 for <tls@ietf.org>; Sun, 19 Jul 2015 13:49:50 -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=krmvfcI1VQNwgK7GblVU3ZHbFXcmTiooCkPLG14pYeQ=; b=l/n343sLdGv5sBkRlYZKIEWO/lJUZesTGzBNM4YImBCl1C/QqRt67mXhYZYzWp45xM rZRR+CZNEEstTb41KMX+21/eKh7xXCeFl+x3lPDA8DqFrKrN1VvgX3GrjhMk1lvj1+Cy EQIcxLxwNSlmo2iXJOhf/RiOOju6DcjRFw8GU1OQXylMBZjumMGKQJ1+dVzJo5XvapNx 9jSXzlzLDotHXwABOb0dRU7Vm6Scw6PAyjtOXfoN2Xlal6OShwmpZ/1WjaTcPzeu57hG ec5MTHo8sRVvo8zov4ckCeKymEUvJiZVgRTDQOIuISintC8VnIKLp7WP6EQVRuF67zL8 9qmQ==
X-Gm-Message-State: ALoCoQk3zHw/aOWFMQ5MjOH6iUF8w26bN03N0CvrXN1E6eBNN4K26dpcU/7wChxrx5gnuHqfs+Sw
X-Received: by 10.180.73.244 with SMTP id o20mr15494401wiv.31.1437338990345; Sun, 19 Jul 2015 13:49:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.85.75 with HTTP; Sun, 19 Jul 2015 13:49:10 -0700 (PDT)
In-Reply-To: <CAFewVt7tuJBpKggc2MND4m_LxLHb+iGupOAVAKRJBRPZMDVo3g@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> <CABcZeBPT2RZe1nR5hZCxSgO+GoHoYAPpmuV7FucZrX6TyRB-qQ@mail.gmail.com> <CAFewVt7tuJBpKggc2MND4m_LxLHb+iGupOAVAKRJBRPZMDVo3g@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 19 Jul 2015 22:49:10 +0200
Message-ID: <CABcZeBNpvf-rqYeevWxErhe3Queq76+jmvXZFssoDu7quNah_Q@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>
Content-Type: multipart/alternative; boundary=f46d0435c06af113b0051b408f1a
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/E5y4C3Vd9KQrld0KX3kLIsXLogU>
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:49:54 -0000

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

> Eric Rescorla <ekr@rtfm.com> wrote:
>
>> On Sun, Jul 19, 2015 at 10:17 PM, Brian Smith <brian@briansmith.org>
>> wrote:
>>
>>> 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.
>>
>
> Great. I was misunderstanding. Here's the part that is not is still not
> clear to me: Is the SessionTicket extension still to be used or not? It
> seems not, AFAICT. If the SessionTicket extension were to be used, then
> everything would work perfectly as Viktor suggested in his message: the
> absense of the SessionTicket extension in the ClientHello would be the way
> that a client can indicate that it doesn't want the session to be cached.
>

No, it's not used.


It seems weird that the server can supply a lifetime hint but the client
> can't, especially in cases like WebRTC where there is no functional
> difference between the two. But, that's a smaller issue than the lack of an
> indication that resumption machinery isn't wanted at all.
>

I don't think it's *that* odd, since tickets have at least two fundamental
asymmetries:

- The client needs to actually keep state and the server does not
(that being the point of tickets)
- The client (because they speak first) gets to offer the ticket for
resumption and the server can accept it or reject it.

-Ekr