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

Daniel Migault <mglt.ietf@gmail.com> Thu, 14 November 2019 15:50 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 F37C7120113 for <tls@ietfa.amsl.com>; Thu, 14 Nov 2019 07:50:38 -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 GcP2iV6wWzWT for <tls@ietfa.amsl.com>; Thu, 14 Nov 2019 07:50:36 -0800 (PST)
Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 94FDE1200BA for <tls@ietf.org>; Thu, 14 Nov 2019 07:50:36 -0800 (PST)
Received: by mail-vs1-xe2f.google.com with SMTP id m6so4147390vsn.13 for <tls@ietf.org>; Thu, 14 Nov 2019 07:50:36 -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=adwUv+7W6R5gDLqdmK5diDhyPOpt9RkVJIdpNw9QjBc=; b=uDG/ZNTwiXhFU7RyPFDvLMVLUbQnhRtRMVSFTcCAxvw0lGC15RRiLkOCBvPQJtNm9O 1s4lj1X85YehgzSkwo5ar/6kPSX+ngJukIy9FzbFLtvJreSzWxHYIqqE4FvzH76IFjLi rQ0Lyrd+xkNyIfyP13s1gVM5PADAoZJNKQObEnZKEtvbwQAiBlSurUNqyoifo/FNn8+L j8WpxeXfMXA3OdAwIO1hXRrTiiIXljFLBMKaHDMf72gpiD479rfhd5cPwWol6usSx/CQ DZhdNzoNyPFPx5njugQ741S0k9WUbzsKDOwySK7wqaZ7V2h158OS8USnZQwdMYk5ssKw d8Ag==
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=adwUv+7W6R5gDLqdmK5diDhyPOpt9RkVJIdpNw9QjBc=; b=YOsPkdMvavQ43qQYLQ2nuVX+UxgBp+aTcbx5XxFpYJe6pauatvE98TgG0EyUE5pRs+ /CYz/rzBQdx22JDRA1/J8uUCREirH8m3ttDKrDKaZejHMkXhjchsTlAwCmvLV/BHHRU/ bYE3tXVclIXSHru5Y3OgtlJy/3qj09GLnZYxc1VUFOaR007Lwulx3JFtMHRWTLDPfdmg Aa44JY4r91dcppym028UAFGo9y6/7hQaSwRug7u9WxdP/PgIpK/ZQ3uTp0FKyHB23lve 8k6qDtQuF7+PmLcfgR5j8XhNasbhSUyeaFXhZPg4mF5aXm6dGjEzfa1qzbRJOWePrOkX TQpg==
X-Gm-Message-State: APjAAAWCEmJ+bRBbBF5iQ88qx7NgVFiLRbgyj71MMpzSObKP1hwRF46f cVYtCisgLCH9YJCVypn1kotw2Gc63rURP1m7Tvo9oNu/p3M=
X-Google-Smtp-Source: APXvYqyGtMkRg9pqctT7HT/gManHNluC3xkdLSHyBhM2b1gPLUGpg8mQB7O15DPLRcWknR/JXRKTenUCDuXxo26VM0Y=
X-Received: by 2002:a67:e2d7:: with SMTP id i23mr5747269vsm.31.1573746635475; Thu, 14 Nov 2019 07:50:35 -0800 (PST)
MIME-Version: 1.0
References: <2FB1D8AD-2C22-4A09-B7AF-0EFD6F0DBACA@sn3rd.com> <0469b84c-3009-427a-99ca-e7f6817f0b6c@www.fastmail.com>
In-Reply-To: <0469b84c-3009-427a-99ca-e7f6817f0b6c@www.fastmail.com>
From: Daniel Migault <mglt.ietf@gmail.com>
Date: Thu, 14 Nov 2019 10:50:24 -0500
Message-ID: <CADZyTknhZDi2JD5WRbKEOGDafHjhTkUm6QhOhv1kkA9BT1nekw@mail.gmail.com>
To: Martin Thomson <mt@lowentropy.net>
Cc: tls <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002c91e30597507172"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/6XSH_9bhALAHrgDXry7UztziceM>
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 15:50:39 -0000

Hi,

The current version is clearer than the previous one. However, as I
understand the document, it still seems very asymmetric in the sense
that it does not provide the client the ability to enforce a number. I
believe more guidances/specifications are needed on how to interpret the
count value. Interpretation is usually based on implicit assumptions of
today's usages, and explicit signaling should, in my opinion, be preferred.
In
other words, I believe that long term interop will benefit from these
additional specifications.

The problem stated in the introduction is that the server needs some
information from the client in order to generate the appropriated number
of tickets. In fact the client is likely to be the one that better knows
the number of tickets to be generated, but the current text does not
enable the client to enforce that number. Instead this is entirely left
to the server.

Typically, if a device does not want to have more than one ticket. It
should be able to indicate one and be sure it will only receive one
ticket. The current specification does not prevent multiple tickets to
be sent by the server. The server can ignore the count value (MAY) even
though it is known to support the extension. This means that a server
could support the extension while still having a hard coded number of
tickets. In addition, (SHOULD) let the server determining the number of
tickets.

Possible ways to address my concerns could be to limit the count value
to the number of tickets generated during the KEX, and a server MUST NOT
exceed the counter value. The text would need more guidance on how the
server SHOULD behave when emitting at different time in the KEX - after
the Finished message and after the post handshake authentication.

The security consideration should in my opinion consider the fact that a
client over UDP/DTLS may use the count value as an amplification factor
to have the server flooding a target. The current text only seems to
consider the computation aspect, not the bandwidth. If that cannot
happen, it might be beneficial to add it. However, when a server sends
tickets right after the Finished, it seems to me that can be used as an
attack.


Yours,
Daniel


On Tue, Nov 5, 2019 at 8:32 PM Martin Thomson <mt@lowentropy.net>; wrote:

> There was a lengthy discussion after the last time this was discussed.
> Can I request that an editor (or a chair) summarize that discussion and the
> resulting actions (if any)?  I was involved in that discussion, but I don't
> see any changes from that.  I'm totally OK with publication as-is, but I
> want to make sure that nothing got dropped.
>
> p.s., it might make sense to include some advisory text on prioritization
> of tickets vs. application data.  I can see a naive implementation of this
> seriously degrading application performance.  For instance, it doesn't take
> that many tickets to fill an early TCP congestion window.
>
> p.p.s., yes, if you keep issuing last calls, I will keep finding new
> things.
>
> On Wed, Nov 6, 2019, at 03:05, Sean Turner wrote:
> > All,
> >
> > This is the working group last call for the "TLS Ticket Requests" draft
> > available at
> > https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/.
> > Please review the document and send your comments to the list by 2359
> > UTC on 19 November 2019.
> >
> > Note the the GH repo for this draft can be found at:
> > https://github.com/tlswg/draft-ietf-tls-ticketrequest
> >
> > Thanks - J&S
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> >
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


-- 
Daniel Migault
Ericsson