Re: [TLS] Fwd: New Version Notification for draft-wood-tls-ticketrequests-00.txt

Christopher Wood <> Fri, 13 April 2018 04:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7858B126BF0 for <>; Thu, 12 Apr 2018 21:14:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bWkVp9AZ3mWQ for <>; Thu, 12 Apr 2018 21:14:08 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 48016124239 for <>; Thu, 12 Apr 2018 21:14:08 -0700 (PDT)
Received: by with SMTP id f132so212329pgc.10 for <>; Thu, 12 Apr 2018 21:14:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FKAQssOC0P+zRw1oZVOManpF2OHSpGGoUA2HcEyo+ao=; b=tgwAvAykPtiUdKS3sD4d1xKI4EXe9f/LLlTNHf7JqsrqLC2A9gYrxGJSmguDWpsCuQ MdEJoXRKq+1yFbsJaK1mvaf7u2c5aIx7K9oLBitrEDULqgqqOHautuA8Fk30DvHB1iDt Oo0TGkaSWyNcLMss2cklZHSG8z7MrIGflBVzuZX93yijaagre5d/jrZ2ibHaY65XwAuW CnLUI6eqOUtM7pUo4VnfJIIdn72ARTBnHUTCv+LvUzkF/Qn5kQPKG8qz6t+icZytmoZU uImoI0YmvhVLUePUs8W6Ydi9l3h7MEGkU/DK8qTk4qPOh1P2J3DVXi7rOhC4kFkIDuFr pzSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FKAQssOC0P+zRw1oZVOManpF2OHSpGGoUA2HcEyo+ao=; b=e3mDIZOge/f3+IH1u1YjQ/UWMpzUEcSCsOp0S+TJxKMkcQKSAqAuQjbaHlCjEFm1kn VGMMQMK/mC7nvfim88O+Cktrm+qPwng7IiAYb6mjMpcgIWfvGTBwGUrNcJQcLA8nrImK OtATAHpNTFPr2DeYp+hYb4J7+sA5O3jCVIdFwvEb5kz86Wf15jcKr89eyYk4ruTnKIiY YNEOGTfsytjDsVKfzrCP/8r0KNaAl57f0yRO3nWMvMc+q99x9kFz3dnyarTBxX16XP8f j01s8L0qs0GsHSnWIuZfH+b4l/nOkDSKOR7mzJL/LDS2V1QrWbEsd1mt2uEgKiP17v2H W1Fg==
X-Gm-Message-State: ALQs6tC+CSfTq/Kd6mAXZvje6TL9WZzkjo9MS3Y2XDWjVrD2uXtEvKng V/dVVt/8v6cGFly4UuKPDb8=
X-Google-Smtp-Source: AIpwx483HVb2vYPQamSaK2wf60Wu8OUFMsDU9AA73SgC0HKb0bZiY2XFZNu1foWFB/trLJxZd2LA9g==
X-Received: by with SMTP id p21mr2848727pgd.154.1523592847481; Thu, 12 Apr 2018 21:14:07 -0700 (PDT)
Received: from ?IPv6:2601:647:4280:1565:5028:e94f:382a:731d? ([2601:647:4280:1565:5028:e94f:382a:731d]) by with ESMTPSA id n73sm12253881pfb.108.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Apr 2018 21:14:06 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Christopher Wood <>
X-Mailer: iPad Mail (15D100)
In-Reply-To: <>
Date: Thu, 12 Apr 2018 21:14:06 -0700
Cc: Chris Wood <>, "<>" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: Martin Thomson <>
Archived-At: <>
Subject: Re: [TLS] Fwd: New Version Notification for draft-wood-tls-ticketrequests-00.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 13 Apr 2018 04:14:09 -0000

> On Apr 12, 2018, at 9:07 PM, Martin Thomson <> wrote:
> On Fri, Apr 13, 2018 at 1:55 PM, Christopher Wood
> <> wrote:
>> Yes — we’re currently working on an I-D that would use the context for “special” tickets. Depending on where that goes, if anywhere, we may or may not need to keep the context. As you suggest, distinguishing between responses and spurious NSTs doesn’t *seem* like a problem.
> Maybe the right way to deal with this is to put an extensions block in
> the request.  Then you only have to resolve the question of whether
> NST answers the ClientHello or this new message...’

Indeed. That might work just as well, if not better. 

In any case, as written right now, we prohibit servers from sending spurious NSTs if both parties negotiate request support. If implementations honor that requirement, we won’t have a distinguishing problem. We then need only decide what is the best encoding strategy for request identity/context, if desired.