Re: [stir] Secdir last call review of draft-ietf-stir-passport-rcd-21

Chris Wendt <chris-ietf@chriswendt.net> Sun, 16 October 2022 15:58 UTC

Return-Path: <chris-ietf@chriswendt.net>
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 3393CC14F721 for <stir@ietfa.amsl.com>; Sun, 16 Oct 2022 08:58:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20210112.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9MkCHBvlkXN for <stir@ietfa.amsl.com>; Sun, 16 Oct 2022 08:58:36 -0700 (PDT)
Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E6C6C14CE47 for <stir@ietf.org>; Sun, 16 Oct 2022 08:58:15 -0700 (PDT)
Received: by mail-qk1-x72a.google.com with SMTP id x13so5374124qkg.11 for <stir@ietf.org>; Sun, 16 Oct 2022 08:58:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20210112.gappssmtp.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=wspHpvMV3ETMwik75e8TZvRRwn96wNqCkbmBW7s8x+8=; b=fA0T6FwhY3DywCxNQpKZqMk8tUeKmDIoq+N2zRBtyqrFBq5ooEyqsmoMg/AT+UPAEV ClLQXRx1XYHStxAX6JSiZB35DViSfy/nw/s75CrIU7JNzMS0huRNmgm7OPhY1kXHLC+R jvG8MubNybiPFhPHPYORKW8N+0s5J+9n3Po3b/wU77O1u3AuC029Tl6kDrnxWjGFofMR vPOnkIPmPfmEwKff/sZT2oS0osGqdAmzEIGSyfNnws0ktMYEJUFqNpX7qySptPzNPmt9 1dcPZ3nFjWsZ6ZzegFr9c6jLc2DrTMK7lWmp7HXGXWUBd/2UggJsEFK6eFjAsPasIbSo 9GYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=wspHpvMV3ETMwik75e8TZvRRwn96wNqCkbmBW7s8x+8=; b=CWXwKIF9bjoSQqjzdoDdq6SWJXMwXXSv5bAaWuHZkmbr5pcC21IVjyBwf2/gdvX0di uxsfXvzQbYMA7EsgwuuRMS7jgOCJh9Famve9JIPvjeNljMkUoRlIkGBd/YTD4+UlO+kD JT7wXW6ArGlfjFdCYtM82remDGaFDEaKheVufpll8tvFgiY/yF2K/4ynI+tifzsfZJB/ WqB0Hi8k82gs2ZsSAhNPxA+2HG4OzyYdClPIKpZ1h32h1u4KMD3y3yYE+28hwl633zFb wUd9J//ncvS7p/NazDtKMEHapWlHwe+h24MLDA1eSoztOG9QYQVewG1XsKSbHjkgL47j FgXQ==
X-Gm-Message-State: ACrzQf15vm0wuo4jXMcnFiZPK4DmTHeZWEKEZqkJiigsJVxa3uA+/yCV JteYeEtO+rfwZoPcleqfzEydHg==
X-Google-Smtp-Source: AMsMyM5TtJFu/0TarTScFofFbhW0fpcFqUigsd6NStVF1aRBA1QDvMFVJTF9oDvH3d8rrsw3++VzCg==
X-Received: by 2002:a05:620a:484c:b0:6ee:9acb:dfdc with SMTP id ec12-20020a05620a484c00b006ee9acbdfdcmr4899097qkb.594.1665935894861; Sun, 16 Oct 2022 08:58:14 -0700 (PDT)
Received: from smtpclient.apple ([172.58.243.114]) by smtp.gmail.com with ESMTPSA id q4-20020a05620a2a4400b006e54251993esm7524525qkp.97.2022.10.16.08.58.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 16 Oct 2022 08:58:14 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: Chris Wendt <chris-ietf@chriswendt.net>
In-Reply-To: <166558042002.23954.16108286265265543453@ietfa.amsl.com>
Date: Sun, 16 Oct 2022 11:58:18 -0400
Cc: secdir@ietf.org, draft-ietf-stir-passport-rcd.all@ietf.org, last-call@ietf.org, stir@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <271A6CD3-312B-4040-8020-6C866E451B06@chriswendt.net>
References: <166558042002.23954.16108286265265543453@ietfa.amsl.com>
To: Vincent Roca <vincent.roca@inria.fr>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/d-NhJJxma7Digiut9ICC07WnJzo>
Subject: Re: [stir] Secdir last call review of draft-ietf-stir-passport-rcd-21
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.39
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: Sun, 16 Oct 2022 15:58:37 -0000

Hi Vincent,

Thanks for the review, responses inline:

> On Oct 12, 2022, at 9:13 AM, Vincent Roca via Datatracker <noreply@ietf.org> wrote:
> 
> Reviewer: Vincent Roca
> Review result: Not Ready
> 
> Hello,
> 
> I have reviewed this document as part of the security directorate’s ongoing
> effort to review all IETF documents being processed by the IESG. These
> comments were written primarily for the benefit of the security area
> directors. Document editors and WG chairs should treat these comments just
> like any other last call comments.
> 
> Summary: not ready
> 
> Globally, the security considerations section addresses all topics that come to
> my mind, given my understanding. The only comment I have is WRT the last
> paragraph of section 18.1. The wording: "Excluding this claim", seems ambiguous
> to me since I don't understand if it refers to the "rcdi claim" or "an entry in
> mustExclude". Also, I don't understand the core problem (why does a mustExclude
> tag compromize integrity protection). I think the issue deserves more details.
> Finally, isn't "MUST NOT" more appropriate than "SHOULD NOT" since the
> consequences of not following this rule are major.

So i do agree this last paragraph is confusing where its essentially meant to be a stating the obvious type of comment.  I believe it was actually written when RFC9118 was created specifically to address Section 18 related security concerns.  My proposal is to just remove that paragraph.  There is nothing preventing someone from using mustExclude for ‘rcdi’ which is why i didn’t say MUST NOT. This scenario simply would not make much sense since injecting an ‘rcdi’ is an extremely ineffective form of attack by the nature of the claim. I think it just refers to what would be essentially the logical conclusion of any implementer of the spec. I think the former paragraph in 18.1 covers what is required for general guidance around the use of JWTClaimConstraints to maintain integrity and constraint of the content of the claims via the certificate.

> 
> A few, minor, additional comments:
> - Section 18, 1st sentence: s/its identities/it is identities/

Fixed with ’the identities'

> - Section 18, 2nd paragraph: I don't understand "over in a using protocol",
> please fix typo. -

Fixed with 'Baseline PASSporT has no particular confidentiality requirement, as the information it signs in many current base communications protocols, for example SIP, is information that carried in the clear anyway.'

> Section 18, 3rd paragraph: s/availbility/availability/

Fixed

> 
> Cheers,
> 
> Vincent
> 
> 
>