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

Daniel Migault <mglt.ietf@gmail.com> Mon, 03 February 2020 23:54 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 9B132120045 for <tls@ietfa.amsl.com>; Mon, 3 Feb 2020 15:54:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=gmail.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 lJgHMfo-HJ07 for <tls@ietfa.amsl.com>; Mon, 3 Feb 2020 15:54:49 -0800 (PST)
Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 1111912001A for <tls@ietf.org>; Mon, 3 Feb 2020 15:54:49 -0800 (PST)
Received: by mail-vs1-xe34.google.com with SMTP id n27so10225282vsa.0 for <tls@ietf.org>; Mon, 03 Feb 2020 15:54:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=z2Q0RXCTq4eeRZSt0IutTcjZ3OV0IGUfTyudINY0Ls8=; b=oaFzEBvfvPTULcaymHW1M8f4xQvEhXtc9oSThRx80r9yVIwmwL38GRvbx2HprioS72 evXRwm06Fon7LLzY04fiXQ5ghwlVX2td43GPc5gFek7mc/gba/GbskZWPIgeb3OJy+eb ovRDzEqTZQXaQ0m7NkVeaRVuInvGEkaze3OfylMCYnNE9DoE1wpp8qmdd2SYK0ZH/riF GgMe3C//WTdxrMdkW/A7sz41AKV9ieb2s7Tu/uqM9bgjpig9sWCYcv4YvGNne+8K9IXP l0u/yaASfFnl1kkiBN6gZ8qHS5OWq6bbFiGDTq5eddd5kC8vK1J/0ry8j2uJaOK0Tymh t5fg==
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=z2Q0RXCTq4eeRZSt0IutTcjZ3OV0IGUfTyudINY0Ls8=; b=TQ930q/qjxgxDoNz54TgCRc+rVcJ5HcP1GR5EIBuOvkmxLSrZkAOsTDNAU4JauqNd7 5+rOmYrFcBnUqn21VMKNdD7Ql19tuZQ7ZUEswmDGkvmTVpH85HDZJCPWA9+5rioW1//K rPu5zcZ3KNUJzlw/mxWs2Iyk5f2yZ5mA3R4HySMY9IqotJvNtVrvHXeAS19x4c7I+oBN MC/xvm4Omzrf3XMNh6K5hf7upJA95Vm2tFGR75L9FMDrMWqMzT/PZpx428EQ8AX7WFs8 h/YdKGGPYKviaEaFiMQFlFGs8OaFfwWLZx31NFwl/Sc4GsCsfyILkyAnYu+WFBUVZpsw 2eZg==
X-Gm-Message-State: APjAAAV3eQEm8/gAQ8N6LK+wcIse6jjD4e3v06RBd7fL25+lFv/Xj3MY A4FsbgmlvxJfMNKV41Eld+SiTipwMULOFUgknnc=
X-Google-Smtp-Source: APXvYqyCKHH3BwJmuQFPMbmwawXG8/u7d4S78I4Yk/2VLYW3vK5o1kWTK1HeXHWzU3EiAhdl4zCUMqyhDAsydUrX7ek=
X-Received: by 2002:a67:b309:: with SMTP id a9mr15843569vsm.97.1580774088209; Mon, 03 Feb 2020 15:54:48 -0800 (PST)
MIME-Version: 1.0
References: <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> <fd37bd2a-c799-4bf4-95b3-65943681683b@www.fastmail.com> <20200121055411.GJ73491@straasha.imrryr.org> <CABcZeBP=BetaxVo5v-khdykP0U3P6j-e+hL307o8Wn3KC9rmhA@mail.gmail.com> <20200121224610.GR73491@straasha.imrryr.org> <CABcZeBOq+mvY4mx+VT0QB08b67noqZyvr0NE-_YMGsz5VoSDuA@mail.gmail.com> <CADZyTkmvJRCNXMU4vS_4Q6soD3_+b2aHLSVdSXeK5+WCWQr+Ew@mail.gmail.com> <CAChr6SwkwEntnigHaQ8rnN0Ku_MKbGcFFh4EBSaUtrxfQaMdUg@mail.gmail.com> <CABcZeBPiq8-2xT_E2A8OtDCN6p3ZQuK19Cxso28+C1tCyeUs=w@mail.gmail.com>
In-Reply-To: <CABcZeBPiq8-2xT_E2A8OtDCN6p3ZQuK19Cxso28+C1tCyeUs=w@mail.gmail.com>
From: Daniel Migault <mglt.ietf@gmail.com>
Date: Mon, 03 Feb 2020 18:54:37 -0500
Message-ID: <CADZyTknMeeoAZJNPfQ3oRMGDyazmRDT8+LARt3XPs3gi4yOzQg@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: Rob Sayre <sayrer@gmail.com>, "<tls@ietf.org>" <tls@ietf.org>, Daniel Migault <daniel.migault=40ericsson.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ff7965059db4a58c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/lmSHqHiVZZHoQ-aXs6x2Et2X6UU>
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: Mon, 03 Feb 2020 23:54:52 -0000

C.4 is clearly in a context where privacy is needed and by writing "SHOULD
NOT" TLS 1.3 takes instead the position there are some cases this is not
required.

"""

C.4 <https://tools.ietf.org/html/rfc8446#appendix-C.4>.  Client
Tracking Prevention

   Clients SHOULD NOT reuse a ticket for multiple connections.  Reuse of
   a ticket allows passive observers to correlate different connections.
   Servers that issue tickets SHOULD offer at least as many tickets as
   the number of connections that a client might use; for example, a web
   browser using HTTP/1.1 [RFC7230
<https://tools.ietf.org/html/rfc7230>] might open six connections to a
   server.  Servers SHOULD issue new tickets with every connection.
   This ensures that clients are always able to use a new ticket when

   creating a new connection.
"""

On Mon, Feb 3, 2020 at 12:02 AM Eric Rescorla <ekr@rtfm.com> wrote:

>
>
> On Sun, Feb 2, 2020 at 7:40 PM Rob Sayre <sayrer@gmail.com> wrote:
>
>> On Sun, Feb 2, 2020 at 11:52 AM Daniel Migault <daniel.migault=
>> 40ericsson.com@dmarc.ietf.org> wrote:
>>
>>>
>>> On Sun, Feb 2, 2020 at 12:09 PM Eric Rescorla <ekr@rtfm.com> wrote:
>>>
>>>>
>>>>
>>>> 1. TLS 1.3 takes the position that reuse is bad and that position
>>>>    is for good reasons, so we shouldn't undercut it in a new
>>>>    extension.
>>>>
>>>>
>>
>>> . Appendix C.4 discourages tickets re-use when Client tracking is a
>>> concern. The section uses SHOULD and not MUST. So, in fact, TLS 1.3 takes
>>> position this is not mandatory to renew tickets.
>>>
>>
> Somehow I didn't get Daniel's email, so responding to it here.
>
> C.4 is not conditional. It simply says "Clients SHOULD NOT reuse a ticket
> for multiple connections." My point is not that servers which do not renew
> are not compliant but rather that TLS 1.3 has taken the position that reuse
> is bad and therefore we should not add an extension to facilitate it.
>
> -Ekr
>
>
>> thanks,
>> Rob
>>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


-- 
Daniel Migault
Ericsson