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

Brian Smith <brian@briansmith.org> Sun, 19 July 2015 21:28 UTC

Return-Path: <brian@briansmith.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 430D81B2D76 for <tls@ietfa.amsl.com>; Sun, 19 Jul 2015 14:28:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 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, SPF_PASS=-0.001] 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 lmjBieRCpzr8 for <tls@ietfa.amsl.com>; Sun, 19 Jul 2015 14:28:28 -0700 (PDT)
Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) (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 AC6411B2D72 for <tls@ietf.org>; Sun, 19 Jul 2015 14:28:28 -0700 (PDT)
Received: by obbgp5 with SMTP id gp5so92054002obb.0 for <tls@ietf.org>; Sun, 19 Jul 2015 14:28:28 -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:date :message-id:subject:from:to:cc:content-type; bh=4cpsWGgZisojq6nOvpkQ/PAQa5zooRUTIZNg+2DRGF8=; b=JTZ3rHU8dGaky65zLGtW78Gko498+RjW3ze7uPtABl6FmRMbRFXOT6fox6znVFt7v8 6SIkTpUXkOvLdLvPSDwJ3lCwdMf+tuZsKqOwEnAqOR4lbC1ShBpEEVZwJKWy0pnU+hhy F1B9MNVn+99C3RO5EhI0WL+89aX811DXcR3VTFhV4QneH4XGCORIPwgr1/K5yvc2XtiC YLv9B7g6VHBBF35H9zYmJaz6AkzFCVUp1n2t1XzM2URag4bk6F+TEr1zLQR96tpmA6rO fljTpAN4GJGu5b58fjuLt5StHcYrAVf3txGiClRr/zl4JBUCZOrqU60sj0A/wBehSjA8 hzLw==
X-Gm-Message-State: ALoCoQlJmoIhm8S62EeNUFvmfXpbX/g2lJ10RfVPX4dodvFzldGr57ot7/oPY1puZDjW1VVm+MRg
MIME-Version: 1.0
X-Received: by 10.202.210.68 with SMTP id j65mr21878914oig.68.1437341308071; Sun, 19 Jul 2015 14:28:28 -0700 (PDT)
Received: by 10.76.90.97 with HTTP; Sun, 19 Jul 2015 14:28:27 -0700 (PDT)
In-Reply-To: <CABcZeBNpvf-rqYeevWxErhe3Queq76+jmvXZFssoDu7quNah_Q@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> <CABcZeBNpvf-rqYeevWxErhe3Queq76+jmvXZFssoDu7quNah_Q@mail.gmail.com>
Date: Sun, 19 Jul 2015 17:28:27 -0400
Message-ID: <CAFewVt7cyF=7yXqYKHE=RK6x3_n8dgV_6fe2LD9-g-WU-z8BeA@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary=001a113d2b3816c6ba051b411a51
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/d63H6AXHsjE-d1vtRV3WgkpriR4>
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 21:28:30 -0000

Eric Rescorla <ekr@rtfm.com> wrote:

> On Sun, Jul 19, 2015 at 10:40 PM, Brian Smith <brian@briansmith.org>
> wrote:
>
>> 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)
>

It depends on how the server implements tickets. The server could implement
tickets the same way that it implements session ID-based resumption. That's
not a good idea, but I don't think the spec should prohibit that type of
implementation either since it unenforceable. Thus, because of that
possibility, it is valuable to have the client be able to say "don't cache
the session" and/or limit the session's lifetime, so the client can help
direct the level of forward secrecy for the session. Right now, only the
server has a say in how long a session will be forward-secret.

Note also that the NewSessionTicket extension precedes any application
data, so without a way to prevent an unwanted NewSessionTicket message from
being sent, the client has to waste effort and time to consume the
NewSessionTicket before it can do anything useful.

Anyway, I don't understand why you keep directing your question to server
vendors. The people that would be interested in such a feature are client
software vendors, for client software that wants to control the level of
forward secrecy for a session.

Cheers,
Brian