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

Viktor Dukhovni <ietf-dane@dukhovni.org> Sat, 01 February 2020 05:31 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 2817012002E for <tls@ietfa.amsl.com>; Fri, 31 Jan 2020 21:31:16 -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 kGfdX8vvj2Lf for <tls@ietfa.amsl.com>; Fri, 31 Jan 2020 21:31:14 -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 C0429120018 for <tls@ietf.org>; Fri, 31 Jan 2020 21:31:13 -0800 (PST)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id F195336E82; Sat, 1 Feb 2020 00:31:12 -0500 (EST)
Date: Sat, 1 Feb 2020 00:31:12 -0500
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20200201053112.GE49778@straasha.imrryr.org>
Reply-To: tls@ietf.org
References: <20200123193250.GD12073@localhost> <20200123210151.GG73491@straasha.imrryr.org> <5F5F670C-A0BD-4F38-BEFF-192C171EDAC1@apple.com> <20200131235533.GA18021@localhost> <CAChr6Sz6PEgQUQg8dB9Ym0z5_iRjmZE5g1hUCCgEOsA-7A=P-w@mail.gmail.com> <20200201011115.GB18021@localhost> <CAChr6SywucrTUsAeN6Aw26ufmhcB8txAmFVNGnUaeR3gG653VQ@mail.gmail.com> <4E7DC6E9-A04E-4016-A12A-CFC723E18219@dukhovni.org> <5E66E815-E649-4EE5-9780-AA2158F81744@apple.com> <9e4ada20-680e-6fa7-f8bb-e94c26440d82@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9e4ada20-680e-6fa7-f8bb-e94c26440d82@cs.tcd.ie>
User-Agent: Mutt/1.12.2 (2019-09-21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/mGBeY6zoDkQRzS6gReCxr-EuTLs>
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: Sat, 01 Feb 2020 05:31:16 -0000

On Sat, Feb 01, 2020 at 02:13:37AM +0000, Stephen Farrell wrote:

> #1 I don't get why it's not possible for Postfix to determine the best
>    way to manage tickets based on the destination port to which the
>    ClientHello is sent. I totally get why that won't solve 100% of
>    cases, but it would surely solve a huge percentage? Apologies if an
>    answer was already posted as part of this v. long thread.

The Postfix SMTP server does not actually create the listener socket,
and may not even be getting the traffic directly from the network
(e.g. haproxy, postscreen, DNAT, ...).

Such a heuristic would require action from the server administrator to
configure appropriate policy for each non-default instance of an SMTP
service, and would then still yield only approximately correct results.
SMTP relays aren't always on port 25, and services that are dedicated
MSAs are sometimes in fact on port 25.

Also, though I wish other MTAs that support TLS resumption would also
reuse tickets, avoiding waste.  I don't know what TLS stacks they use,
and whether they need or don't need fresh tickets.  And coversely not
every server Postfix connects to is also Postfix, and those may have a
different default behaviour.

So I'm looking for a mechanism (absolutely trivial per #2 below) to
allow the client to signal to the server its ticket-use preference
so that the server can vend the right number of tickets (which is
the scope of this extension).

> #2 I don't get why Viktor's request for special handling for value 255
>    is a real problem for anyone. We have another thread today
>    envisaging 2040 extensions flags, so I really have a hard time
>    seeing what here justifies rejecting Viktor's argument. FWIW, this
>    thread has not provided me with an obvious answer to #2 other than
>    "not- invented-here." I'm not sure that declaring things in the
>    rough where the only identifiable issue is NIH is the overall best
>    outcome, longer term.

I am also puzzled by the reticence to make the trivial change that makes
the mechanism more expressive at negligible cost, and move on.  That too
advances the draft.  I want to see this draft move forward, that's why
I am bothering to try and make it cover the missing piece of the puzzle.

There is NO obligation on either party to enable reuse even if the
client sends the "as necessary" sentinel (0).  The server can just vend
1 new ticket in that case, and the client would need to assume the
previous one invalid and use the new one for the next connection.

The proposal does not change the security posture of any systems that
don't want to support reuse.  Also the draft as written does not prevent
consenting peers from doing reuse, it just fails to provide them with a
simple mechanism to negotiate a mutually compatible policy.

When the two ends make differt assumptions you get either waste or
insufficient tickets to meet the client's needs.

Let's make a small change to the code points to enable more precise
negotiation and move on...

-- 
    Viktor.