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

"Christopher Wood" <caw@heapingbits.net> Thu, 14 November 2019 16:24 UTC

Return-Path: <caw@heapingbits.net>
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 CF7D112023E for <tls@ietfa.amsl.com>; Thu, 14 Nov 2019 08:24:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=aaH53Krf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Xe4nJT1C
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 Gt7pVonMYJfe for <tls@ietfa.amsl.com>; Thu, 14 Nov 2019 08:24:55 -0800 (PST)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3623412000F for <tls@ietf.org>; Thu, 14 Nov 2019 08:24:55 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id D3F3522063; Thu, 14 Nov 2019 11:24:53 -0500 (EST)
Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Thu, 14 Nov 2019 11:24:53 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm2; bh=ZxYPEUnW2wlQxHsR/JvNu26cRVU8 glCPcaXFn5FfcGQ=; b=aaH53KrfaYIrKHo6mzicpodoTrcuuKOaCoPCBduK8PHZ XfqxL4s3O4eQmeCmf/0JUTPYoGMA7vi2PqhNg/9zz7IkRsqfTjZCCKnafsQzCeOf aGKMvnqM6ND0+KUOVQn91JdUpHfgr3vZLKjBs5t1U/RtZpfYbli/7SLWMzlngJFC hA+D3R2XmTc3SFbCvDRp5H6m/u0H5Wr7EZW4c/lVdSMcTM4Gbo99Ul27Y6B3Qad0 8MxGSEyup4pWVg0YmwAq1mDAVTawZj1XIRJs+QewETPdUV+VaDDnGixaB+ZQqS0z nVpVvMr4UxZTOyQEo3EGZBD7RpfVmLzBz453n7n0vg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=ZxYPEU nW2wlQxHsR/JvNu26cRVU8glCPcaXFn5FfcGQ=; b=Xe4nJT1Cg5xqFwoNGtlsrP zFwdRytUsbdmYtahD5M2DYCehnJ5M/OIgi0u5gIDFO8kiXxR+k6qg2qm8Qnp40gf 7+TY5/37qOxFvTKhjrqyIXcILM7HNdXiXK3C61cGrVWOsdPc/5+fxdNiVSfbzckn H823qrtvs4EdeXig6g12GcvNQulyLtIlSkYJv0KZ4h8CAs1Tr/2UZlQN7DtAEm6s W8q3TtdrfZ9OuAGfBqyXFzD4eSPUhOZ82yzmaA4yVm6WJZS/TU1f+M6fGfc7MPW6 py8l/gDjd4QGREee6JXDtr9JZhjxGwNboIDB/hk0uYQX8I/KyDP/xE7jMNgf8YWA ==
X-ME-Sender: <xms:1H_NXWW00rLwHJeSOseUgnMGjr9knw0U9GC-8vCVXYL-Hepv6ZGE3w>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudeffedgkeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdevhhhr ihhsthhophhhvghrucghohhougdfuceotggrfieshhgvrghpihhnghgsihhtshdrnhgvth eqnecuffhomhgrihhnpegtohhunhhtrdgrshdpihgvthhfrdhorhhgnecurfgrrhgrmhep mhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvghtnecuvehluhhsth gvrhfuihiivgeptd
X-ME-Proxy: <xmx:1H_NXVTiULEK5eQMBJ4bnD9UQqjcnjMupRFEH7Le2G3iY8yAiktrQA> <xmx:1H_NXX4DcAr6xrJhoIY0Hx61meX07DYkHxGX8XahnAAQCgPK4dAl7g> <xmx:1H_NXTsjISUnz4j_jX4OgUe0Bd1cgcripdc4VW5JG9ZM3C78EMp-xg> <xmx:1X_NXd6SwIJt5ZiVxcn4UlsGvzA4-bQQwErnd8LEvfhPrQy4Sp1Ypg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4BC5F3C00A1; Thu, 14 Nov 2019 11:24:52 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-562-gfd0633a-fmstable-20191114v1
Mime-Version: 1.0
Message-Id: <1cd34aff-915e-4f70-8f03-b644dab201c9@www.fastmail.com>
In-Reply-To: <CADZyTkkS-CipB00+JMRrjNZqXhyCTdBhV11oydCNCCeG_M6ORg@mail.gmail.com>
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>
Date: Thu, 14 Nov 2019 08:24:32 -0800
From: Christopher Wood <caw@heapingbits.net>
To: Daniel Migault <daniel.migault@ericsson.com>
Cc: "TLS@ietf.org" <tls@ietf.org>
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/KFLB4eZTlZ9Z66HEJCusIedUn9g>
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:24:58 -0000


On Thu, Nov 14, 2019, at 8:19 AM, Daniel Migault wrote:
> Hi Chris, 
> 
> Thanks for the responses, please see my comments inline. 
> 
> Yours, 
> Daniel
> 
> On Thu, Nov 14, 2019 at 11:02 AM Christopher Wood <caw@heapingbits.net> wrote:
> > On Thu, Nov 14, 2019, at 7:50 AM, Daniel Migault wrote:
> >  > 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.
> > 
> >  I disagree with this assessment. The document is clear on this:
> > 
> >  A supporting server MAY use TicketRequestContents.count when
> >  determining how many NewSessionTicket messages to send to a
> >  requesting client, and SHOULD place a limit on the number of tickets
> >  sent. The number of NewSessionTicket messages sent SHOULD be the
> >  minimum of the server's self-imposed limit and
> >  TicketRequestContents.count.
> > 
> >  As has been stated before, the count is a *hint* to the server, nothing more. 
> > 
> That is my point, in my opinion a hint is under specified. 

I acknowledge your opinion, but as I think I've made clear, I don't agree. Sorry!

> >  > 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.
> > 
> >  As above, I think you're misunderstanding the point of this document. Ticket requests are hints to servers.
> > 
> On the contrary, I think I understood it correctly. 
> >  > 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. 
> > 
> >  Right, nor should it. Again, that's not a goal.
> > 
> >  > 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.
> > 
> >  I don't think any text changes are needed to address these comments.
> > 
> >  > 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.
> > 
> >  I'm not convinced this is useful to add. The target here is the client (attacker) that requested tickets. 
> The target is the spoofed source IP address.

That would imply the attacker is able to complete a connection with this spoofed address, no?

> >  Best,
> >  Chris
> > 
> >  _______________________________________________
> >  TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls