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

Daniel Migault <daniel.migault@ericsson.com> Thu, 14 November 2019 16:57 UTC

Return-Path: <mglt.ietf@gmail.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 32F1C120849 for <tls@ietfa.amsl.com>; Thu, 14 Nov 2019 08:57:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 PBp3cUUo_aej for <tls@ietfa.amsl.com>; Thu, 14 Nov 2019 08:57:52 -0800 (PST)
Received: from mail-vs1-f48.google.com (mail-vs1-f48.google.com [209.85.217.48]) (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 5BB1E1202DD for <tls@ietf.org>; Thu, 14 Nov 2019 08:57:52 -0800 (PST)
Received: by mail-vs1-f48.google.com with SMTP id m6so4310218vsn.13 for <tls@ietf.org>; Thu, 14 Nov 2019 08:57:52 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0pWf05pZE1l2ZptVQxdTgsuJlC41DfNDY/gPyLo9Xl8=; b=Mb5a3aUry2Vp/KW6zm2SfhP5yRM2bQP3bRQkIrLXiWYH+DMq6CfQ3rJt+siDYk22n9 tVzYNcKojQtfOu1vHG6wHRPaFcXwL2UTI4prYTENDGPYDha2svCdSqTPgJzA58ffZjO7 9aaXSpp6Wa0WFnawlJQ234RnKKEtN0gnjphMxODYwbTT5gqTKCCz2KHKC4KfHELXBCjy cRH/0ufylUBh0XnUNoSDOX/fcJyp4eJsI+e578Ka+q9l0PXkG+YZxkCW9QFIQT6x5hK7 2oBxhNscxxHQwXF1EzwnM/ta/zoM6EPB5dVErcBZvGxKGx3dRM1TNi6+0uC8bdGPkfsT cTfw==
X-Gm-Message-State: APjAAAUEPmnQVCcnf9g6U+jiOPj7XRb5Wcs0f28D/JvBnNeYSbztqFiK 2I0s36D0LqQka433HX6Y6zHkLvY+wRoDg2Pxc0Q=
X-Google-Smtp-Source: APXvYqxfERmxu4uGQfbIXg6CwOw4q837pp/OEuW6htUF5OBp+laV54rCHFqBJlFBapJLou0VhI9n/GKjmdVn0wcpBZ0=
X-Received: by 2002:a67:bd05:: with SMTP id y5mr6404155vsq.180.1573750671385; Thu, 14 Nov 2019 08:57:51 -0800 (PST)
MIME-Version: 1.0
References: <2FB1D8AD-2C22-4A09-B7AF-0EFD6F0DBACA@sn3rd.com> <0469b84c-3009-427a-99ca-e7f6817f0b6c@www.fastmail.com> <CADZyTknhZDi2JD5WRbKEOGDafHjhTkUm6QhOhv1kkA9BT1nekw@mail.gmail.com> <37ff9a64-2749-4558-a675-5b251f06eb3a@www.fastmail.com> <CADZyTkkS-CipB00+JMRrjNZqXhyCTdBhV11oydCNCCeG_M6ORg@mail.gmail.com> <1cd34aff-915e-4f70-8f03-b644dab201c9@www.fastmail.com> <CADZyTknNN5vXifm3Qu=JnVpC5cD7MRb8xBMSbT9DDB07C4=gPg@mail.gmail.com> <99300d33-5a29-47e1-88ac-c83d385a9263@www.fastmail.com> <895cd06a-a75a-45f4-986d-c1eaa7d4c83d@www.fastmail.com>
In-Reply-To: <895cd06a-a75a-45f4-986d-c1eaa7d4c83d@www.fastmail.com>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Thu, 14 Nov 2019 11:57:40 -0500
Message-ID: <CADZyTknpHkugotJxKUmSXU=qLrFcxKLe1tKMzd+FqvWTchjMgw@mail.gmail.com>
To: Christopher Wood <caw@heapingbits.net>
Cc: "TLS@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bba638059751619b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/IK8bj04FHHxaU2Zl7nyb5lrIEYw>
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, 14 Nov 2019 16:57:54 -0000

Unless I am missing something, the text below seems to say otherwise.


Note: Although the resumption master secret depends on the client's
   second flight, a server which does not request client authentication
   MAY compute the remainder of the transcript independently and then
   send a NewSessionTicket immediately upon sending its Finished rather
   than waiting for the client Finished.  This might be appropriate in
   cases where the client is expected to open multiple TLS connections
   in parallel and would benefit from the reduced overhead of a
   resumption handshake, for example.



On Thu, Nov 14, 2019 at 11:52 AM Christopher Wood <caw@heapingbits.net>
wrote:

> On Thu, Nov 14, 2019, at 8:48 AM, Christopher Wood wrote:
> > On Thu, Nov 14, 2019, at 8:43 AM, Daniel Migault wrote:
> > > If tickets are sent right after the server Finished, before the the
> > > client Finished, these are only triggered by the clientHello - at
> least
> > > this is my understanding.
> >
> > Yes, that's correct. I thought your comment was about post-handshake
> > tickets (after confirmation from the client). Adding a note about this
> > pre-handshake completion is fine with me.
>
> Scratch that! I forgot we limited this extension to TLS 1.3, which
> prohibits sending NSTs until the client finished is received (
> https://tools.ietf.org/html/rfc8446#section-4.6.1).
>
> Best,
> Chris
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>