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

Daniel Migault <daniel.migault@ericsson.com> Thu, 14 November 2019 16:20 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 593CD1201DC for <tls@ietfa.amsl.com>; Thu, 14 Nov 2019 08:20:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level:
X-Spam-Status: No, score=-1.648 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, 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 SejDIIQ_qVJt for <tls@ietfa.amsl.com>; Thu, 14 Nov 2019 08:20:07 -0800 (PST)
Received: from mail-vk1-f182.google.com (mail-vk1-f182.google.com [209.85.221.182]) (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 176A8120113 for <tls@ietf.org>; Thu, 14 Nov 2019 08:20:07 -0800 (PST)
Received: by mail-vk1-f182.google.com with SMTP id f27so1597730vkl.11 for <tls@ietf.org>; Thu, 14 Nov 2019 08:20:07 -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=8XRJqhihbZtCJd44Cb5kh3PHNZXroLCIluP2QKPH7O0=; b=FKUNuBql3bElXnzFMqMJK3OoT+pLZgphMUYFCNeXNzwBj0HJ8HMOHtKuKDqtkMOQSI C5HemtYwMq76jbO6PmQ4DGgzJyuksjgHbXYTiz+LQeV11LTiXYokP8yjhhtF2LcxnNjb b3jdrme4QtzzxCq3ojdJuYMm5+1j2C/nJo6RBqHtnLc9Z3pxq8PGuwHdwCYR0x2meneD t8PfSb21uXcg1ktJJRRS8iw6HNVy2ZpCo2XVp1I8rZYncH+JGrWlEGXM91l0DcCXQGqG KuOnwu1GwLgHt83Wavza1JIbN348Q5uAVu+6anbn2iq0VXWxlJd5UphC5uRZwAsYijoD 6xdw==
X-Gm-Message-State: APjAAAWC0lpEe2r3hAibNrpkNMOjJRdRN6qgvmjmMSaFVAAYdQ8ZjWyv hlKlRVZVK/Mx5eS7srR7WKK/Ls+I06t5HBtsUvfmV4qp
X-Google-Smtp-Source: APXvYqx3agQTJQw/JLrLqFO3dgYYTBAaDHQC5RYfdt1Tqj3pkZcif7SKbUT/gPZBzX+QHQ3MVCVZSfxTqS+mSpH4frI=
X-Received: by 2002:a1f:a592:: with SMTP id o140mr2003573vke.30.1573748405906; Thu, 14 Nov 2019 08:20:05 -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>
In-Reply-To: <37ff9a64-2749-4558-a675-5b251f06eb3a@www.fastmail.com>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Thu, 14 Nov 2019 11:19:55 -0500
Message-ID: <CADZyTkkS-CipB00+JMRrjNZqXhyCTdBhV11oydCNCCeG_M6ORg@mail.gmail.com>
To: Christopher Wood <caw@heapingbits.net>
Cc: "TLS@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b33102059750da09"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/TvLVGR6rPq3y4T9SRcBOV-fnbyg>
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:20:09 -0000

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.


> > 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.

>

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