Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

Nico Williams <nico@cryptonector.com> Thu, 21 November 2019 18:50 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D7A120B38 for <tls@ietfa.amsl.com>; Thu, 21 Nov 2019 10:50:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com
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 FY2ITw8PWL3T for <tls@ietfa.amsl.com>; Thu, 21 Nov 2019 10:50:47 -0800 (PST)
Received: from bongo.elm.relay.mailchannels.net (bongo.elm.relay.mailchannels.net [23.83.212.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD504120119 for <tls@ietf.org>; Thu, 21 Nov 2019 10:50:46 -0800 (PST)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 10FFC341200; Thu, 21 Nov 2019 18:50:46 +0000 (UTC)
Received: from pdx1-sub0-mail-a67.g.dreamhost.com (100-96-196-51.trex.outbound.svc.cluster.local [100.96.196.51]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 80E1F340A59; Thu, 21 Nov 2019 18:50:45 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a67.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Thu, 21 Nov 2019 18:50:45 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Robust-Duck: 039622d90e7fa291_1574362245784_1173083576
X-MC-Loop-Signature: 1574362245784:1487627048
X-MC-Ingress-Time: 1574362245783
Received: from pdx1-sub0-mail-a67.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a67.g.dreamhost.com (Postfix) with ESMTP id AE18EA9987; Thu, 21 Nov 2019 10:50:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=3M3xuPMynDcYXp RniNQO9KdMW68=; b=mhB5mS3GhcW1mYF6hUivDuV0rKBWtnsOEIg5bLS4GguKYn McnKYoYjzOhrBQiGRSh8VCoUqxgRMgqCO0mCifkHwwIj4IouhrDWqFS+Avjx9GH0 keKEBybPT42osleW6CeZXHS4NWcGXr0j8fxTTa5zGBYB1de3zne9fOIMiUxV0=
Received: from localhost (sdzac10-108-1-nat.nje.twosigma.com [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a67.g.dreamhost.com (Postfix) with ESMTPSA id 5AD06A997A; Thu, 21 Nov 2019 10:50:38 -0800 (PST)
Date: Thu, 21 Nov 2019 12:50:34 -0600
X-DH-BACKEND: pdx1-sub0-mail-a67
From: Nico Williams <nico@cryptonector.com>
To: David Schinazi <dschinazi.ietf@gmail.com>
Cc: tls@ietf.org
Message-ID: <20191121185034.GB26241@localhost>
References: <556d2210-4af7-b398-fbd7-eab2685d7c62@wizmail.org> <20191116210617.GS34850@straasha.imrryr.org> <20191116235952.GR20609@akamai.com> <20191117002249.GV34850@straasha.imrryr.org> <CADZyTkmaUVj=sFdgg93MuM2au0B=1M1k3yCA1XDoaAneVDmnNw@mail.gmail.com> <14690874-E301-4BC0-B385-00DEBCBA94C2@apple.com> <20191120034812.GQ34850@straasha.imrryr.org> <5FBFE820-8C53-4B32-9520-343279C1A6CC@apple.com> <20191120064819.GR34850@straasha.imrryr.org> <CAPDSy+6DFJ+OYRtYK6eEiUt1noiik4KxqrGFx0ro_RL2Mft_VA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAPDSy+6DFJ+OYRtYK6eEiUt1noiik4KxqrGFx0ro_RL2Mft_VA@mail.gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/RSVeF6_lhCEz7IVqoQkDdFdnFL8>
Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 21 Nov 2019 18:50:48 -0000

On Thu, Nov 21, 2019 at 11:19:36AM +0800, David Schinazi wrote:
> Regarding Viktor's suggestion, I personally believe it would increase the
> complexity of the proposal, and I don't see use-cases compelling enough
> to warrant that complexity. I would rather keep this proposal as simple as
> possible.

Complexity?  I don't see it -- and you didn't show it, only asserted it.

But the protocol is a bit broken -yes, broken- without that "option",
and here's why: the whole point of this extension is to

 - a) ensure that clients always have the resumption tickets they need,

 - and b) to reduce ticket issuance to the minimum necessary for (a),
   and, well...

 - that means only issuing resumption tickets when the client needs one
   to replace the one it's using,

 - and if the client and server are happy with ticket reuse, then it's
   up to the server to decide when the client's ticket may no longer be
   reused,

 - but the protocol as specified can't let the client say "give me a new
   ticket IFF you won't let me reuse this one any more",

 - and it doesn't let the server do such conditional issuance because
   the client might NOT want to reuse and the server can't know that if
   the client can't tell it.

That's the logical chain that leads me to declare this protocol broken.

The fix is trivial.  It most certainly isn't complex.  A plain assertion
that it's too complex is not responsive and insufficient to dismiss the
WGLC comment.

Nico
--