[secdir] secdir review of draft-ietf-stir-cert-delegation-04

Carl Wallace <carl@redhoundsoftware.com> Fri, 14 May 2021 10:32 UTC

Return-Path: <carl@redhoundsoftware.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 226343A2DCE for <secdir@ietfa.amsl.com>; Fri, 14 May 2021 03:32:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.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 d52grik5xzJe for <secdir@ietfa.amsl.com>; Fri, 14 May 2021 03:32:26 -0700 (PDT)
Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (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 AEC653A2DD0 for <secdir@ietf.org>; Fri, 14 May 2021 03:32:26 -0700 (PDT)
Received: by mail-qv1-xf2b.google.com with SMTP id ee9so4903753qvb.8 for <secdir@ietf.org>; Fri, 14 May 2021 03:32:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :mime-version:content-transfer-encoding; bh=D+lZkxEcUnbSNmfhT8bTIwoY+ysBghVt27K5fCarnzk=; b=MiltEGHFBtV2ArSvlVw6NZiNj/VrR1rSdhqbbiiLeLaD/B3SOHfN+4OiZ2sIh1yKnM efTDbYv9fuiYOKNndT307C6BuayVUZQgxT+L4Bg3QPX9BJzWsE2jJme5DqQm2x8gjaRB WWpRggv4szIiPHy5sbJT/mYPaOGmlKmVP4gQ4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:mime-version:content-transfer-encoding; bh=D+lZkxEcUnbSNmfhT8bTIwoY+ysBghVt27K5fCarnzk=; b=a+bxFgjyE0R0tbA4BhNq7MYzFzdSPn6jXkOxmFDQeZcKRUsjCh4yP2n4LFLNpXlVd5 uc7O1X8Ba8UHM2eKVd2rV2QZwg9choloje26Ax7fyKsbpocD/j8urbVWV/jE3apW1rE2 j/uPHEbCGHLikf+gJD3njFwAMow06Jm27ENonUFVTukiGi6wTJkWOSSV8kLkNLs/tPpw ssQh0lzpxHbbw+53Vw4IX2yjeAXL3NSLzyHD0qyaJbn5+tavFYY+E/lMQUIBtniP6mP6 8Zm9gBxajGPXsfgXA0wawGDJo9AywAnHOXaW5lOjncaerUuCE3vudIEp+9sHcGsIOY9Q DV8w==
X-Gm-Message-State: AOAM530EXXbPkcZ5mss2qtTRKLDgiML5Dm4pXZb08785L0BiRPIBFns0 RymGv7f/QiZ0IuwfzuVF+7DiP/y+abrc2j5w
X-Google-Smtp-Source: ABdhPJysLAlMxb2lynxQjWV+Pzg3yrouL0cbN5o5o38iOxI5KzBknYoU/ZCMBW3t7c9Z8qt9Flg3Dg==
X-Received: by 2002:a05:6214:11ab:: with SMTP id u11mr12133269qvv.32.1620988344334; Fri, 14 May 2021 03:32:24 -0700 (PDT)
Received: from [192.168.2.17] (pool-108-18-106-102.washdc.fios.verizon.net. [108.18.106.102]) by smtp.gmail.com with ESMTPSA id n17sm4518392qke.14.2021.05.14.03.32.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 May 2021 03:32:23 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/16.49.21050901
Date: Fri, 14 May 2021 06:32:23 -0400
From: Carl Wallace <carl@redhoundsoftware.com>
To: secdir@ietf.org
CC: draft-ietf-stir-cert-delegation.all@ietf.org, last-call@ietf.org
Message-ID: <5210316D-E025-4896-94CB-70AFF89E4B32@redhoundsoftware.com>
Thread-Topic: secdir review of draft-ietf-stir-cert-delegation-04
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/-wD2FqxjZtGUHZJm06ApKNpClHU>
Subject: [secdir] secdir review of draft-ietf-stir-cert-delegation-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 May 2021 10:32:31 -0000

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.

This document describes how authority over telephone numbers and related identifiers can be delegated from a parent certificate to a subordinate certificate. I previously reviewed -03 last summer.

The text that was the focus on my primary concern in the previous review remains in section 4.1 with regard to affirming a TNAuthList is encompassed by its ancestors: 

"This might be performed at the time the delegate certificate
   is issued, or at the time that a verification service receives an
   inbound call, or potentially both.  It is generally desirable to
   offload as much of this as possible to the certification process, as
   verification occurs during call setup and thus additional network
   dips could lead to perceptible delay, whereas certification happens
   outside of call processing as a largely administrative function."

Some new language has been added to the Security Considerations section that states "(h)ow encompassing is policed is therefore a matter outside the scope of this document." I don't think the question is so much how it is policed, which would seem to be a nod to something like CT, but how it is used to affirm "legitimate spoofing". I don't see how a verifier can know whether or not a check has been performed or not. That the primary information used to perform the check can be external to the certificate with no binding to the certificate, no replay protections, limited origin authentication/integrity, etc. heightens the need to know that the values being relied upon are true, i.e., that they pass the encompassing check.

Aside from this and not noted last time, some guidance regarding caching of external TNAuthLists and on verifying the HTTPS certificate may be warranted, given the importance of the external mechanism.