IETF Logo Mail Archive

Re: [TLS] Ticket request PR#20

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 01 May 2020 18:40 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 BCD3E3A19A3 for <tls@ietfa.amsl.com>; Fri, 1 May 2020 11:40:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level:
X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.82, 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 gohFrOg6VmG8 for <tls@ietfa.amsl.com>; Fri, 1 May 2020 11:40:26 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7E2F3A19DC for <tls@ietf.org>; Fri, 1 May 2020 11:39:58 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 11A15298532; Fri, 1 May 2020 14:39:58 -0400 (EDT)
Date: Fri, 01 May 2020 14:39:58 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20200501183958.GB76674@straasha.imrryr.org>
Reply-To: tls@ietf.org
References: <20200419222318.GY41308@straasha.imrryr.org> <CBE68A19-EBBE-4BF6-97B0-F6CEE9A90363@sn3rd.com> <20200501181131.GA76674@straasha.imrryr.org> <20200501181858.GF3811@akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20200501181858.GF3811@akamai.com>
User-Agent: Mutt/1.12.2 (2019-09-21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/1D4z3Hvjv5zAJjUTgY6iPgPg5m8>
Subject: Re: [TLS] Ticket request PR#20
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: Fri, 01 May 2020 18:40:28 -0000

On Fri, May 01, 2020 at 11:18:58AM -0700, Benjamin Kaduk wrote:

> > Declining this comes across hostile to me.  I read the objections to
> > "only {0, 0} means zero" as a blocking counter-measure against the
> > deferred discussion, and not a material objection on the merits. :-(
> 
> I don't think it's right to say that "only {0,0} means zero" -- after all,
> this is a *request*, not a command from the client to the server.

And yet, RFC 8446 C.4 says servers SHOULD always send at least one, and
so this draft is modifying that to say that it is now "OK" to sometimes
send no tickets based on the applicable counter.  All I am asking for is
that the "OK" condition be made more strict, requiring both counters to
zero before C.4 is overriden.

The server can still start WW-III upong seeing the extension, but that
does not preclude clarity about the *intended* meaning.  That's what
the MUSTs/SHOULDs/MAYs etc. are for.

-- 
    Viktor.

v2.23.0 | Report a Bug | By Email