Re: [TLS] Erik Kline's No Objection on draft-ietf-tls-external-psk-importer-06: (with COMMENT)

Erik Kline <ek.ietf@gmail.com> Wed, 30 December 2020 05:51 UTC

Return-Path: <ek.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 EF3BA3A0FBD; Tue, 29 Dec 2020 21:51:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 sQJBdn2sHMHy; Tue, 29 Dec 2020 21:51:18 -0800 (PST)
Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (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 446DB3A0FBA; Tue, 29 Dec 2020 21:51:18 -0800 (PST)
Received: by mail-oi1-x234.google.com with SMTP id s75so17773698oih.1; Tue, 29 Dec 2020 21:51:18 -0800 (PST)
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=qMZlYf8T0+mXIPXPEVCmZBNMQyzvIfzrE8eGTLhiC4E=; b=P3RLRWrRCY8F31D1TdoM/Y6QuIRnBQfPqFGoLXtOKTQaHbzvljQS0pQCzWlDkTn6aO rNb9uAf9gUI6MQMp6wuEoGxslHLG5K8ZSqGJ081FKMWvkZF7g2hmfI1GtZkqQ6BYx2A3 PQ5q099VAN2ZUg+9id8rD8bEbd3lhxy7E03Ze/Q11mIiQ2lG70f+Azp8ZranhvVOBzKM qbU0XIE+uDY1NAVI3M/B9f8efn3mKP3ofY8kDvNbftHuxvuu1/wNcGEWCiKvNjWZqpeq oLvh8KO+I5cgOGR1JvWUBCMgqcSM4kBwW7Fgvd+p3nBLLaPY221Jx9wxmxAjMWpc+4u9 dvmw==
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=qMZlYf8T0+mXIPXPEVCmZBNMQyzvIfzrE8eGTLhiC4E=; b=eu+5OkTsXdbDK9W1Y6WCcgjGngRQX72XTlEr0Dhqh3LzPOJFQ0XegN3vw3TzLp8Qj+ u4NDQG90qsAtGbxiOP0LxeeTfN6c5b+osEfHwFBSB3QuBqJbe7w7aQ7venxhpPKJUpzs +CJf7ums5ZQGWr1jB0SVaMt5dmCLa83CbrXmZQIw6rbdAxDe8bfud0HzhR3kP0sy0tu8 IB96lce3EyodakuXmd/1E9aIEuxVLLlZPi+p+mmrXEP2TLraCJPa5XSpQHiN1T0G+B+4 yctGl6wdYKJBKMF2/tYd096YZM9LtzVLK3wX/YRDyTFbr8SJ/7YLbcTbzYAqVZghZUO4 oIPQ==
X-Gm-Message-State: AOAM532qz/XfSINPBOf9luS/EDUvyBMkryBhKo994z+Tuz+P92c9qbBj GLIYNCg+cRW4WEtvmPiy1pd982mho98zgZ7dRT4=
X-Google-Smtp-Source: ABdhPJxcfSP+nDEnT3GT644JgERSjr4+YL1x078T/Mm5xfvHy6IDxvAprE/lzALd5mkXmkCBcgxIGNb89dSOhJm+Yo0=
X-Received: by 2002:a05:6808:1a:: with SMTP id u26mr4446856oic.77.1609307477476; Tue, 29 Dec 2020 21:51:17 -0800 (PST)
MIME-Version: 1.0
References: <160922462028.2520.9949069928879676107@ietfa.amsl.com> <20201230021632.GR89068@kduck.mit.edu>
In-Reply-To: <20201230021632.GR89068@kduck.mit.edu>
From: Erik Kline <ek.ietf@gmail.com>
Date: Tue, 29 Dec 2020 21:51:06 -0800
Message-ID: <CAMGpriVriEvp7qcVRSmJAip48e7p-O0+6+u+_H8cazCWaAtCOQ@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: The IESG <iesg@ietf.org>, joe@salowey.net, draft-ietf-tls-external-psk-importer@ietf.org, tls-chairs@ietf.org, tls@ietf.org
Content-Type: multipart/alternative; boundary="00000000000087888105b7a8181a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/5wVgHzhnsYjQp6AAaGavLe1Tlj4>
Subject: Re: [TLS] Erik Kline's No Objection on draft-ietf-tls-external-psk-importer-06: (with COMMENT)
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: Wed, 30 Dec 2020 05:51:20 -0000

Ah, I suspected I was missing something.  "|" here is used for alternation,
not concatenation, I (now) gather.  The existing text makes sense.

Probably no clarification is required for readers who are actually
implementers.  I suppose if someone wanted to add text then just a simple
parenthetical " (here '|' is used for alternation, not concatenation)"
would suffice.  But I've no strong feelings.

Thanks for the clue!

On Tue, Dec 29, 2020 at 6:16 PM Benjamin Kaduk <kaduk@mit.edu> wrote:

> On Mon, Dec 28, 2020 at 10:50:20PM -0800, Erik Kline via Datatracker wrote:
> > Erik Kline has entered the following ballot position for
> > draft-ietf-tls-external-psk-importer-06: No Objection
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-importer/
> >
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > [[ questions ]]
> >
> > [ section 4.2 ]
> >
> > * I'm insufficiently versed in TLS and HKDF to know for sure, but the
> text
> >   about "replace the string" and the diagrammed example don't seem to
> agree,
> >   **to my untrained eye**.  The example seems to show "imp binder"
> perhaps
> >   concatenated with the "standard" sequence, rather than "imp binder"
> >   /replacing/ "ext binder".
> >
> >   Am I way off base here? In other words, should
> >
> >     "ext binder" | "res binder" | "imp binder"
> >
> >   actually be (if I understand the use of the word "replace" correctly):
> >
> >     "imp binder" | "res binder"
> >
> >   ?
>
> I guess https://tools.ietf.org/html/rfc8446#section-7.1 does not cover
> this
> very well either, but the '|' notation is just shorthand for "there are
> multiple outputs, produced by using the different values as this input
> field".  It's not concatenation, just a different output corresponding to
> the different case of protocol operation.
>
> Suggestions for how to clarify that would, of course, be most welcome!
>
> Thanks,
>
> Ben
>