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

Daniel Migault <daniel.migault@ericsson.com> Thu, 14 November 2019 16:43 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 8AE361208A0 for <tls@ietfa.amsl.com>; Thu, 14 Nov 2019 08:43:28 -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 U2javZsmHaS3 for <tls@ietfa.amsl.com>; Thu, 14 Nov 2019 08:43:26 -0800 (PST)
Received: from mail-vs1-f42.google.com (mail-vs1-f42.google.com [209.85.217.42]) (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 9EBBC120A36 for <tls@ietf.org>; Thu, 14 Nov 2019 08:43:24 -0800 (PST)
Received: by mail-vs1-f42.google.com with SMTP id b16so4288112vso.10 for <tls@ietf.org>; Thu, 14 Nov 2019 08:43:24 -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=SMohh9xTf3NEnPfFFhf255rbmt4aTr8CWqDDfNdx3F0=; b=SmWycI4VU2qVu1JwloidROcylLo8c0250Kgg92buUxmRIAjaPNVmezAhaqiq+Ayb1+ DoAeQTMTsTO8IJ2zJkjlIq8o19ed3k/phoDo9fJ88asV0Vip/GRezZ0xrttLX4K82HUW Fdih+zsqzmV3Epp3NLXsY4+BhBXkMxmk8eTtV9DcyJgVI6F5T2H9WHvpoQA0vzSFKxtG olaCCJFo1tNVxWCmZWlGBOwk+ZDW8xFFUIZ9vyO9SV9+e3pfHXAFnAwvx1HISZHWV3NX l7Vs06GWXwWas1KsfItAt9qSr7MYYekwso15Cg2ndDpSkBQTSB8lH8i2NmofaiE5mR4c Pwrg==
X-Gm-Message-State: APjAAAW+L2VUrKTkhq+KcFrAxX922o4XArAn0NMqyvm2nKpjjR+xMm23 ofH2srx6ixWnVNkDtFLS0q6byrGv6kx9yz5lKu0=
X-Google-Smtp-Source: APXvYqx2AmlhgChEjt5d3gUYZeqZ3RkC0wl9aG/qmOsIGAY6FelnDzmGxtxD02sYRT+tVnzq6129ox8BezRD5Ud9zvw=
X-Received: by 2002:a67:7a8d:: with SMTP id v135mr6133354vsc.97.1573749803631; Thu, 14 Nov 2019 08:43:23 -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>
In-Reply-To: <1cd34aff-915e-4f70-8f03-b644dab201c9@www.fastmail.com>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Thu, 14 Nov 2019 11:43:12 -0500
Message-ID: <CADZyTknNN5vXifm3Qu=JnVpC5cD7MRb8xBMSbT9DDB07C4=gPg@mail.gmail.com>
To: Christopher Wood <caw@heapingbits.net>
Cc: "TLS@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000002caf30597512edd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/hPvpAf4HG-PcsHMSszpmckjPU_c>
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:43:31 -0000

Hi,

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.

Yours,
Daniel


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

>
>
> 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
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>