Re: [stir] Benjamin Kaduk's Discuss on draft-ietf-stir-enhance-rfc8226-03: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Sat, 03 July 2021 17:58 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DED873A1E91; Sat, 3 Jul 2021 10:58:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 DPHKPzs0BHTC; Sat, 3 Jul 2021 10:58:17 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 638D33A1E8E; Sat, 3 Jul 2021 10:58:17 -0700 (PDT)
Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 163HwAu0011189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 3 Jul 2021 13:58:15 -0400
Date: Sat, 03 Jul 2021 10:58:10 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Russ Housley <housley@vigilsec.com>
Cc: IESG <iesg@ietf.org>, IETF STIR Mail List <stir@ietf.org>, Ben Campbell <ben@nostrum.com>, Robert Sparks <rjsparks@nostrum.com>
Message-ID: <20210703175810.GZ17170@mit.edu>
References: <162491913776.24561.10295832590740387025@ietfa.amsl.com> <11C48644-9EED-4686-AC7D-FE43D626E92C@vigilsec.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <11C48644-9EED-4686-AC7D-FE43D626E92C@vigilsec.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/yMvLaoDlZif3F5MVIgyRdYuaHPo>
Subject: Re: [stir] Benjamin Kaduk's Discuss on draft-ietf-stir-enhance-rfc8226-03: (with DISCUSS and COMMENT)
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Jul 2021 17:58:19 -0000

Hi Russ,

Trimming the bits that look good...

On Tue, Jun 29, 2021 at 11:22:04AM -0400, Russ Housley wrote:
> Ben:
> 
> Turning to the comments ...
> 
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
[...]
> > Section 7
[...]
> >   Certificate issuers should not include an entry in mustExclude for
> >   the "rcdi" claim for a certificate that will be used with the
> >   PASSporT Extension for Rich Call Data defined in
> >   [I-D.ietf-stir-passport-rcd].  Excluding this claim would prevent the
> >   integrity protection mechanism from working properly.
> > 
> > I'd consider prefacing this paragraph with something like "For example",
> > as otherwise one might wonder why this particular claim is so important
> > to call out in this document's security considerations.
> 
> Rob asked for SHOULD NOT.  And if you look at the structure in [I-D.ietf-stir-passport-rcd], the integrity really does depend on this claim.

Yes, it's clear that the integrity of RCD does depend on the claim in
question.
It's less clear that enhance-rfc8226 is the best place to make that
restriction, which could also be imposed by draft-ietf-stir-passport-rcd
itself.  In short, "why is this claim so important that it gets called out
by name in an otherwise generic specification?".

What's in the document now is factually correct, so I don't mind having it
there; it just seems a little surprising to call out one specific external
claim and not say why only that one is mentioned.

Thanks again for all the updates,

Ben