Re: [TLS] Martin Duke's Discuss on draft-ietf-tls-external-psk-importer-06: (with DISCUSS)

Christopher Wood <caw@heapingbits.net> Wed, 24 February 2021 00:36 UTC

Return-Path: <caw@heapingbits.net>
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 E389D3A1266; Tue, 23 Feb 2021 16:36:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=heapingbits.net header.b=oIJYh0Vw; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=baQzooMt
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 pXWyl1lcibXV; Tue, 23 Feb 2021 16:36:08 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4FFC3A1261; Tue, 23 Feb 2021 16:36:07 -0800 (PST)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 2CA955C005A; Tue, 23 Feb 2021 19:36:07 -0500 (EST)
Received: from imap4 ([10.202.2.54]) by compute4.internal (MEProxy); Tue, 23 Feb 2021 19:36:07 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm3; bh=va76IwOXpYMW4UTsGedVtH1DrNjy /aV0cDk5HnbuybU=; b=oIJYh0VwApAlruOmvI5dPoixaKcRARUynWIIdcobdpm6 qLyz0IpkTHUTPyOhl3p2G/UJT6mCfL7aW4qOqoaOzg2sz42o9IourwiQq8AbZ1Sq at3yy1B8fjyX/G2Y4DVSelsGKdBp7RRHDlC56EEsQt/hb8qg4z1fIIMEWEbdiz9t kcM6gjHC+iuYLaDWAwvm6PKzfIA5/f/1pcruXUsJHVGPEDycs4Tr4VACVIluwuQE yiqP+JExC90zrrvqUONAq7F12sNHFy8mmuVECJPfHHXp/ZqXZpkryq3k0l32qDtv FqO3UOTV0dgYczv4DgbGERIBGEKdOhZiArKFpwBeBA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=va76Iw OXpYMW4UTsGedVtH1DrNjy/aV0cDk5HnbuybU=; b=baQzooMtFwyJo0Eiy1K42T 14RrwEVwW+tYqKk5D+wj9djZz74se8CyKQYGYzOHvtVk9Gxc9RvOuDvJFq7TiauV fhTLdX7of6qAqAurdKLrpoINOPPH5btxTp10ATkGlAYVXaOQwhyUY8E6XEFJwmnd CRdmPj4JM1+QnXEkJeOzgELif5VPr0utTKV4AHPWo+i9QU0lILgxgX1Wu7wrujm4 OlAdrjlobQHP6iNmJXARivEVw38B6wD9vPGhEhKsIeUSgT6/vn6oBUvtLphIJHVU hnGihrlcHHodk6YwRlCh7bIIx952O81bn1Fcn6UsDHzkkfHuHV+MIFX4PUxNuF0A ==
X-ME-Sender: <xms:dp81YDFoCcyMcbWXGUO5x-oEQd8w0XQkzh0fv6NF5IoMhKhcKSCrsg> <xme:dp81YAV_vybcTlMQmcE_u2GNAKOQkU_5Vx0tYGF4atk_wnpIk9CB0dOQnvE3HxxgZ Y0QB7dRSFCfkTmnahA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrkeeigddvtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderreejnecuhfhrohhmpedfvehhrhhi shhtohhphhgvrhcuhghoohgufdcuoegtrgifsehhvggrphhinhhgsghithhsrdhnvghtqe enucggtffrrghtthgvrhhnpeeuiefgkeeileeukeevjedtueehjefhffffiefgvddtteeu gfdtledvheegfffhfeenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhivghtfhdroh hrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegt rgifsehhvggrphhinhhgsghithhsrdhnvght
X-ME-Proxy: <xmx:dp81YFLro_FxiL8lW9frziGj5e5Ayh5309u2jdgUEhrMctvtFa5zDQ> <xmx:dp81YBFKsnhjy2yfW3fZuxIQIxmzmbdm6vrchfFUs4IrKyrPfJqSxQ> <xmx:dp81YJWTZNTr-TwTCfE9mkKszlGFwKEPcVDBgVkuZ-Bj5bJWOQ3pww> <xmx:d581YPwZhbGjF9w7iGVWFmHU4Dhh6dQ9r_JbEE_JmQTe8SQDfzFvdQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id A8EDC160792; Tue, 23 Feb 2021 19:36:06 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-141-gf094924a34-fm-20210210.001-gf094924a
Mime-Version: 1.0
Message-Id: <c7824032-4020-4409-94b5-022382326450@www.fastmail.com>
In-Reply-To: <CAM4esxR97geh3Y=cNDECVXvY_uv6yTbhy6gxEigvy8EQV=j7Kg@mail.gmail.com>
References: <160980363454.20851.10184061700085456941@ietfa.amsl.com> <20210108003928.GR93151@kduck.mit.edu> <CABcZeBNpip-ue7iyx-K-u3eOC52TQ5sqpOHQb+moE=urxJYGSQ@mail.gmail.com> <CAM4esxRq5aJkWMWbqoxR_HF=v2XrWMgN6N849-gm_RR6WjEB_Q@mail.gmail.com> <CAM4esxR97geh3Y=cNDECVXvY_uv6yTbhy6gxEigvy8EQV=j7Kg@mail.gmail.com>
Date: Tue, 23 Feb 2021 16:35:45 -0800
From: Christopher Wood <caw@heapingbits.net>
To: Martin Duke <martin.h.duke@gmail.com>, Eric Rescorla <ekr@rtfm.com>
Cc: Benjamin Kaduk <kaduk@mit.edu>, "TLS@ietf.org" <tls@ietf.org>, draft-ietf-tls-external-psk-importer@ietf.org, The IESG <iesg@ietf.org>, TLS Chairs <tls-chairs@ietf.org>
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/kkI3oiAI8JAFcbnHCp8ftqLVee0>
Subject: Re: [TLS] Martin Duke's Discuss on draft-ietf-tls-external-psk-importer-06: (with DISCUSS)
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, 24 Feb 2021 00:36:10 -0000

Thanks, Martin! Perhaps we can file an issue and track this as part of rfc8446bis?

   https://github.com/tlswg/tls13-spec/issues

Best,
Chris

On Tue, Feb 23, 2021, at 4:32 PM, Martin Duke wrote:
> After further consideration, the problem at hand is best resolved by 
> 8446, which has a generalized problem with subfield lengths that don't 
> add up to the field length. I will remove the DISCUSS
> 
> Nevertheless, here's a PR that may help implementers avoid a problem:
> https://github.com/tlswg/draft-ietf-tls-external-psk-importer/pull/41
> 
> 
> 
> On Tue, Jan 19, 2021 at 10:40 AM Martin Duke <martin.h.duke@gmail.com> wrote:
> > Ekr,
> > 
> > I appreciate that this is hard to represent in 8446 notation. Would it be possible to add some text in 4.1 that says "Due to the maximum size of the PSK extension, the external_identity and context fields MUST sum to a length of 2^16-5", or something to that effect?
> >  
> > IMO, it would be unfortunate if the PSK Importer interface allowed parameters that result in undefined behavior on the wire.
> > 
> > If this is unworkable or very very dumb for some other reason, I am willing to accept that feedback.
> > 
> > Martin
> > 
> > On Thu, Jan 7, 2021 at 4:57 PM Eric Rescorla <ekr@rtfm.com> wrote:
> >> 
> >> 
> >> On Thu, Jan 7, 2021 at 4:39 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
> >>> On Mon, Jan 04, 2021 at 03:40:34PM -0800, Martin Duke via Datatracker wrote:
> >>> > Martin Duke has entered the following ballot position for
> >>> > draft-ietf-tls-external-psk-importer-06: Discuss
> >>> > 
> >>> > 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/
> >>> > 
> >>> > 
> >>> > 
> >>> > ----------------------------------------------------------------------
> >>> > DISCUSS:
> >>> > ----------------------------------------------------------------------
> >>> > 
> >>> > This is probably just my own ignorance, but I see two potential problems in Sec
> >>> > 4.1.
> >>> > 
> >>> > - 'The identity of "ipskx" as sent on the wire is ImportedIdentity, i.e., the
> >>> > serialized content of ImportedIdentity is used as the  content of
> >>> > PskIdentity.identity in the PSK extension.' IIUC ImportedIdentity has a maximum
> >>> > length of 2^17 + 2. But the Identity field in the PSK option has a maximum
> >>> > length of 2^16-1. I presume this never actually happens, but the spec should
> >>> > handle the boundary condition, perhaps by limiting the first two fields of
> >>> > Imported Identity to sum to 2^16-5 bytes or something.
> >>> 
> >>> I'll leave this one for the authors.
> >> 
> >> I can see how someone would want this, but in practice that's not how it's
> >> generally done in TLS. Trying to compute the precise upper bounds gets
> >> complicated very fast when there are multiple fields. We do generally
> >> try to get the lower bound right, though even then there have been
> >> mistakes:
> >> 
> >> https://github.com/ekr/tls13-spec/pull/56/files
> >> 
> >> -Ekr