Re: [stir] AD Evaluation: draft-ietf-stir-passport-rcd

Chris Wendt <chris-ietf@chriswendt.net> Tue, 27 September 2022 16:35 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 42E09C1526FD for <stir@ietfa.amsl.com>; Tue, 27 Sep 2022 09:35:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 OcURLb-p6PMl for <stir@ietfa.amsl.com>; Tue, 27 Sep 2022 09:35:11 -0700 (PDT)
Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 E806FC1526E1 for <stir@ietf.org>; Tue, 27 Sep 2022 09:35:11 -0700 (PDT)
Received: by mail-il1-x12c.google.com with SMTP id a4so5368027ilj.8 for <stir@ietf.org>; Tue, 27 Sep 2022 09:35:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20210112.gappssmtp.com; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date; bh=37WaHCQPIzqCvpP6XLrmHoKT7pblkvEv5j6EmXNHnto=; b=6MzPT/wsstL6+Qba1M3GOVVFuHWXKwfLCnTyWyRI/DThkhVibMJ6LVCbRcFqhG9S1g d71IcgsjJcxp3Lhj6+2imbCevBRm92CMG741b0voL7g/Hz5plxoeuJIf38DBwhCsRyAD J/hiznxvyX1NvxYPgGOMbMBXesuyU4F+HxLQHjDC2+knExZX/G/kmiD88pkWCcM61REL x/p9WeSGVJk3wC2imO+lUHxHV/ccj1Wdb5Yxr09yPmhQm6AIXGrttZ7/Ue+inxjxxS4/ N7pF+E5MAtPINH5C1HyVkYyHITphAPqXmGprETJpaP+TPBGuP4SCCVNXYv1KpskUWpIy zbwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date; bh=37WaHCQPIzqCvpP6XLrmHoKT7pblkvEv5j6EmXNHnto=; b=eBpftpnpEAWVq84WW8bMse3osG2sFy6cUTA8FlGiCDK665vDaN8vi64w6tkhx7vIYg RwdQv8nLlQca42Wob+OAv/7DCzfk7OBUHuhpEDcENm59TXuBLMRC6R1OW221Q4cKDAQ6 kuNpPrblUAtx8qvHZe3MjFm/NEKf74oTroG38HoqoA7YuPqyuWURy/j/2Nx9ac3Pdj/j 0ub2I6hvBsLzeAk2oDrnhtIYJ3J/Vqv/0wYbfN2VoHVJhQAqDMqigxfzrgvYGreE/PVj 4yhR8+af+PubwnlBmcwZFK2QWyUYPHRkAeNriw2r2ElOTO3hvEu1n08qAUU+XzbGdf+c Moxg==
X-Gm-Message-State: ACrzQf1pTnS/QRYaOpz6+VUvFiuvgeWvYNUPVrbZ4uxGxQ/Y5CEgxPsy aQto7NPjxCD2efZZpQBjcBaLwg==
X-Google-Smtp-Source: AMsMyM4T52nDehjOdntZNAhcPiyf6xjvg3BhuNzAuFavJP3+LTRg5k1Ano0+1AcKVlWg12xEnKYVbQ==
X-Received: by 2002:a05:6e02:1522:b0:2f5:d59c:8639 with SMTP id i2-20020a056e02152200b002f5d59c8639mr12819754ilu.311.1664296510938; Tue, 27 Sep 2022 09:35:10 -0700 (PDT)
Received: from smtpclient.apple ([65.157.103.142]) by smtp.gmail.com with ESMTPSA id i6-20020a056638400600b0035a4fc36878sm774303jai.169.2022.09.27.09.35.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Sep 2022 09:35:10 -0700 (PDT)
From: Chris Wendt <chris-ietf@chriswendt.net>
Message-Id: <A26DC532-D4E0-41A2-8B35-822262AF2E62@chriswendt.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_16C40EA3-D109-4DC4-9243-109AA4EE6510"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Date: Tue, 27 Sep 2022 10:35:11 -0600
In-Reply-To: <018401d8d27b$9fa65c80$def31580$@numeracle.com>
Cc: "Murray S. Kucherawy" <superuser@gmail.com>, IETF STIR Mail List <stir@ietf.org>
To: "<pierce@numeracle.com>" <pierce@numeracle.com>
References: <CAL0qLwZaKc20eNus1wSj_-Zjys9prm1+55Ergtr=QDNi3G-sZg@mail.gmail.com> <22207E7F-87E9-41F1-B08E-5745F07353B5@chriswendt.net> <CAL0qLwZpMY+Far0skD9K4hnBMcp=DmxPwR+pSzWNTY8dxXYf4g@mail.gmail.com> <018401d8d27b$9fa65c80$def31580$@numeracle.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/BhgTf_IUYLqe3IF63Yvq-z7cpoc>
Subject: Re: [stir] AD Evaluation: draft-ietf-stir-passport-rcd
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: Tue, 27 Sep 2022 16:35:14 -0000

I agree Pierce, the first paragraph of the security considerations section does have text to say that content validation/vetting policies are out of scope specifically.

-Chris

> On Sep 27, 2022, at 8:15 AM, pierce@numeracle.com wrote:
> 
> IMHO, validation of content in icn, crn, nam, etc., is outside the scope of the RCD specification.  Perhaps that should be (part of) the message in Section 8.1?
>  
> Pierce
>  
> From: stir <stir-bounces@ietf.org> On Behalf Of Murray S. Kucherawy
> Sent: Monday, September 26, 2022 10:36 PM
> To: Chris Wendt <chris-ietf@chriswendt.net>
> Cc: IETF STIR Mail List <stir@ietf.org>
> Subject: Re: [stir] AD Evaluation: draft-ietf-stir-passport-rcd
>  
> On Mon, Sep 26, 2022 at 2:21 PM Chris Wendt <chris-ietf@chriswendt.net <mailto:chris-ietf@chriswendt.net>> wrote:
>> > How do we know that the reason placed in a "crn" claim is true?  Could this be abused?  If so, should this be called out in Section 13 or 18 (or somewhere else)?
>> 
>> Section 8.1 was intended to address this use of constraints if the signer is “non-authoritative”.  The general concept is that RCD information should be vetted by trusted participants in the eco-system.  “crn” is a claim that i think we conceptually provide a bit more latitude with just because call reason may more generally be a more dynamic field, but there is nothing in the specification that doesn’t allow for an eco-system using this specification to mandate the use of constraints.  This is a balance we have needed to support for most of the specs to allow for flexibility depending on use of the specs.
>  
> I'm not sure I follow.  The question I'm asking is: Is there anything stopping me from giving a false reason in a "crn" claim?  Could I, for instance, claim the call is an emergency of some type and thus get you to answer when I'm actually just going to try to sell you something?  If that's a risk, I think that should be explicit; it would be enough to say that there's no validation for what's in the "crn" claim (and couldn't possibly be).
>  
>> [...]
>> 
>> > For that matter, would ABNF be useful here?
>> 
>> Likely would but we haven’t included it in other relevant specs, i would hate to add at last minute.
>  
> I don't mind waiting if it's worth doing.  :-)
>  
> Thanks for the rest, looks good.
>  
> -MSK