Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt

Rob Sayre <sayrer@gmail.com> Thu, 03 October 2019 04:24 UTC

Return-Path: <sayrer@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 1748E120835 for <tls@ietfa.amsl.com>; Wed, 2 Oct 2019 21:24:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 rSX0UMMhUErK for <tls@ietfa.amsl.com>; Wed, 2 Oct 2019 21:23:59 -0700 (PDT)
Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 2BF49120825 for <tls@ietf.org>; Wed, 2 Oct 2019 21:23:58 -0700 (PDT)
Received: by mail-io1-xd2e.google.com with SMTP id a1so2433647ioc.6 for <tls@ietf.org>; Wed, 02 Oct 2019 21:23:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bAVdVfRDNmMmXwK5H+jmJBN0+3f2+NADH0xa4+hn2/8=; b=CwHlVM34sB0d/+6lL2QAM2skDmcleX2SZtXhPVVT+lIR5suvqqlTtM/7Vx+6AZ1RuA OWqmq2Yc3kp3L+hnuYQsLG/nBAEuY/bfhusZFqfsCm7eRBoGeMdRsOE/crr+0NIptxuU DdJiEqleyftOjN133vNl+ThXWHJy+oppyJBr0uGHm+3EupYBCYLjY1OqHL30O8KO+Btb Hj8Gpwal8E38bwb7EmFNz0FECM88xEO1gmyTlLSNX8Cbn7GkdXBme6JT7fGgu6xo9CYH V6Ml9M2P+cUYK5wURW1bTbbVXykP/6H4Imsedp9sSh7krpp5HhZrlZSxKeS3A51g1ybY q0UQ==
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=bAVdVfRDNmMmXwK5H+jmJBN0+3f2+NADH0xa4+hn2/8=; b=jz4yuTFZXhfUxaqnaoczVtkb/B+4FpsA4kO98kLnFdVEMxzfAKSIg+MtGV5Bu9XDMk WgoELQ57mUDT1a1GsNd9wvxcQMtppg3scv+5r97GsM/jrGXijfn09qAVhIcX2OWKBRZS pMbsutplQlqRxPx1o/+ur4sDX6lnhXZwnS7SWAM+JFmIQap1UmaZVJfGbhVpyTZSej7C HfOTbSRcUeffvSuWPD9pCmcxrqx/6pcMUdf463WrqqH0LqVmpss0ljKREVX+IzF/hRXh mVCHNl7aBkIk0h0jC+wu93lB9UfWKRvePLPRpK+c+595RNZvsZQ76XCCtWM1/kBI5PEx QZDg==
X-Gm-Message-State: APjAAAVH9KWzej+z0zpm8Ybc+7SaFZjhDWzfxx4CgSOYwddDf2e5d7LC 12w9HLjj3a2EydESjUHuQqeasvB1C/FXI38GbutOPWTOZKOgoA==
X-Google-Smtp-Source: APXvYqwf9MtZjZCxf9VKs+oG8BbvEzydccm9eqqdPPgnPKboZr9Eqcxp2e9Dk7E/5ZuWPoRw/LYGGw9NhetnLeAwzpg=
X-Received: by 2002:a02:c049:: with SMTP id u9mr7744641jam.131.1570076637813; Wed, 02 Oct 2019 21:23:57 -0700 (PDT)
MIME-Version: 1.0
References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> <1971068.D9yiD15FoS@pintsize.usersys.redhat.com> <851aded9-70a7-4a9a-abd5-b75f98f86baf@www.fastmail.com> <1708345.JU3unZtj4k@pintsize.usersys.redhat.com> <350020eb-c43b-4941-93e9-06ea9a0cacc3@www.fastmail.com> <CADZyTkm-MRF_ucy-_crC5SeTYZ9=VdPuF+TL5fLkU1gbb=7rfQ@mail.gmail.com> <945ac286-bb40-4a41-8612-3183f28b68e5@www.fastmail.com> <CAChr6Sx9smPR+paGUbXnrKN0TbRo0U5pnikRS3wDiMdhAq5Tdw@mail.gmail.com> <16d1473c-8ee9-4007-b71e-eef38134d331@www.fastmail.com>
In-Reply-To: <16d1473c-8ee9-4007-b71e-eef38134d331@www.fastmail.com>
From: Rob Sayre <sayrer@gmail.com>
Date: Thu, 3 Oct 2019 11:23:45 +0700
Message-ID: <CAChr6SyEsC3sKtNozjMpPiPRcE0bUmk3xwkzuuh==JxVwinj5A@mail.gmail.com>
To: Christopher Wood <caw@heapingbits.net>
Cc: Daniel Migault <daniel.migault@ericsson.com>, "TLS@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000445f5d0593f9f4a6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/YogBUOC0ZujSAxHVp8H0oIjJm3Y>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt
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, 03 Oct 2019 04:24:03 -0000

On Thu, Oct 3, 2019 at 10:19 AM Christopher Wood <caw@heapingbits.net>
wrote:

> On Wed, Oct 2, 2019, at 8:08 PM, Rob Sayre wrote:
> > On Thu, Oct 3, 2019 at 3:54 AM Christopher Wood <caw@heapingbits.net>
> wrote:
> > >
> > >  > I understand the meaning of count is the higher limit of ticket and
> the
> > >  > server can provides any tickets between 0 and count. If that is
> > >  > correct, this could be clearly stated and indication to chose an
> > >  > appropriated value for each cases may be provided.
> > >
> > >  The document states this:
> > >
> > >  A supporting server MAY vend TicketRequestContents.count
> > >  NewSessionTicket messages to a requesting client, and SHOULD NOT send
> > >  more than TicketRequestContents.count NewSessionTicket messages to a
> > >  requesting client.
> > >
> > >  Is this not sufficient clear? If not, how can it be improved?
> >
> > RFC2119 "SHOULD/SHOULD NOT" requirements are usually clearer with some
> > examples of "valid reasons in particular circumstances to ignore a
> > particular item" [RFC2119]. Otherwise, those requirements can be
> > cryptic, and perhaps better-described by MAY or MUST language.
>
> I understand, though I'm not sure more text is needed here. If you
> disagree, can you please suggest text to make it more clear?
>

The current text the describes the interaction well enough, but I don't
understand the requirement. I can suggest two alternatives:

1) A supporting server [...] MAY send more than TicketRequestContents.count
NewSessionTicket messages to a requesting client. The client might not be
able to use all of them.
2) A supporting server [...] MUST NOT send more than
TicketRequestContents.count NewSessionTicket messages to a requesting
client.

The draft uses "SHOULD NOT". Why is that? Perhaps that trailing sentence I
added to 1) seems obvious to the authors? I did not automatically assume
the consequences of sending extra NewSessionTicket messages would be so
innocuous. If that's the case, it seems like MAY would be better, since
clients need to handle extra NewSessionTicket messages, even if they just
discard them.

thanks,
Rob