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

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 21 January 2020 17:44 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 EB6E31209F9 for <tls@ietfa.amsl.com>; Tue, 21 Jan 2020 09:44:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 g0BHiAe8YtrV for <tls@ietfa.amsl.com>; Tue, 21 Jan 2020 09:44:02 -0800 (PST)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECC8A1209FE for <tls@ietf.org>; Tue, 21 Jan 2020 09:44:01 -0800 (PST)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 41CD94972C; Tue, 21 Jan 2020 12:44:01 -0500 (EST)
Date: Tue, 21 Jan 2020 12:44:01 -0500
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20200121174401.GN73491@straasha.imrryr.org>
Reply-To: tls@ietf.org
References: <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> <97de6364-c628-45aa-8613-ba1a32cc41b2@www.fastmail.com> <CABcZeBMCWSmiRWQuQO60U0EGhpAcwisbWYFAqPUTZ5eb19Q3aQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABcZeBMCWSmiRWQuQO60U0EGhpAcwisbWYFAqPUTZ5eb19Q3aQ@mail.gmail.com>
User-Agent: Mutt/1.12.2 (2019-09-21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/2c-dKscH6iMKeHPDoOj9zU7XL8o>
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: Tue, 21 Jan 2020 17:44:05 -0000

On Tue, Jan 21, 2020 at 07:17:05AM -0800, Eric Rescorla wrote:

> I agree with Martin that this is unnecessary complexity.

The objections stated are non-responsive, and dismiss a valid
use-case.

There is ZERO additional complexity.

   - Servers will already range-check the requested ticket count and
     impose some local policy limit.  Treating a request for 255
     as "no tickets please" is NOT complex.

   - Clients that want fresh tickets will send the same request
     they already would have but capped at 254 instead of 255
     tickets.  That's NOT complex.

My proposal only excludes 255 as a valid ticket count.  Nobody can
justifiably insist that it is essential for servers to be able to vend
up to exactly 255 (and not up to 254) tickets.

The extension as *currently* formulated breaks ticket re-use when
employed, it is not possible for a client to signal that it would prefer
to re-use its ticket.

When the extension is not sent, the server can't distinguish between
clients that have not yet adopted it, and clients that wish re-use
tickets, so has to make the wrong guess for at least one of the two
cases.

> In addition, I would note that switching to a new ticket *does* help even
> if the server is using the same STEK because it improves privacy.

But, as I've explained already, SMTP MTAs are a legitimate use case in
which privacy is explicitly not expected.

   * SMTP MTAs do not and cannot expect privacy against network-layer
     traffic analysis.

     They operate from fixed IPs, with PTRs mapping back to their
     hostnames, whose "reputation" they rely on for deliverability, and
     announce their identity in 220 greetings, EHLO commands and EHLO
     responses in the clear!

     [VALID USE CASE]

   * My proposal, does not FORCE anyone to use either of the special
     values 0 or 255, they can still ask for 1..254 tickets, with
     *zero* change of behaviour.

     Only clients that want to not get a ticket at all, or not get
     one every time, are affected by the change.  Other clients
     do nothing different, they just send an extension asking for
     a number of tickets in [1,254].

     [ZERO COST TO PRIVACY USE CASE]

   * All servers have to do is:

        - Send [1,254] (likely fewer at the high end) tickets when
          that many are requested, as before.  [ With or without
          my proposal, they'll still do a range check of some
          sort to compare with their local policy limits. ]

        - Send no tickets when 255 are requested, a negligible
          adjustment to their range check.

        - Send 1 ticket when 0 are requested and they don't support
          re-use, or the received ticket is invalid (support for
          ticket re-use which worked

        - send 0 tickets are 0 are requested and the received ticket is
          still valid.

      [ZERO COST TO SERVER USE CASE, plus makes possible to signal
       and support ticket reuse]

It is unjust to deny a ZERO COST valid use-case just because that's not
the use-case one is most familiar with.

This is the TLS working group, not the browser HTTPS working group, and
needs to be open to more than than one use-case.

-- 
    Viktor.