Re: [stir] Ben Campbell's Yes on draft-ietf-stir-rfc4474bis-15: (with COMMENT)
"Ben Campbell" <ben@nostrum.com> Thu, 03 November 2016 14:30 UTC
Return-Path: <ben@nostrum.com>
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 E71A6129A69; Thu, 3 Nov 2016 07:30:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.397
X-Spam-Level:
X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=unavailable 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 WHVu1csW3aM5; Thu, 3 Nov 2016 07:30:16 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 590FE1299E6; Thu, 3 Nov 2016 07:29:42 -0700 (PDT)
Received: from [10.0.1.21] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uA3ETcRM031133 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 3 Nov 2016 09:29:38 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.21]
From: Ben Campbell <ben@nostrum.com>
To: "Peterson, Jon" <jon.peterson@neustar.biz>
Date: Thu, 03 Nov 2016 09:29:37 -0500
Message-ID: <4830C88D-F5C4-4071-B475-E39F531DAB9D@nostrum.com>
In-Reply-To: <D440B25F.1C1FA7%jon.peterson@neustar.biz>
References: <147812990930.24070.2354048411520933419.idtracker@ietfa.amsl.com> <ED1485E0-A24F-449F-A362-BEAAE70A63FA@fastmail.fm> <D440B25F.1C1FA7%jon.peterson@neustar.biz>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.5r5263)
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/gZc_u5zd_uurDqOd96bRg4u39Rw>
Cc: "draft-ietf-stir-rfc4474bis@ietf.org" <draft-ietf-stir-rfc4474bis@ietf.org>, Alexey Melnikov <aamelnikov@fastmail.fm>, "stir@ietf.org" <stir@ietf.org>, The IESG <iesg@ietf.org>, "stir-chairs@ietf.org" <stir-chairs@ietf.org>, "rjsparks@nostrum.com" <rjsparks@nostrum.com>
Subject: Re: [stir] Ben Campbell's Yes on draft-ietf-stir-rfc4474bis-15: (with COMMENT)
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 03 Nov 2016 14:30:19 -0000
On 3 Nov 2016, at 9:16, Peterson, Jon wrote: > >> >>> On 2 Nov 2016, at 23:38, Ben Campbell <ben@nostrum.com> wrote: >>> >>> - 6.2, step 4: This says that if the full form of passport is >>> included, >>> and the Date header and iat do not match, use iat if it is fresh. >>> I'm >>> curious why not just use iat in the first place? >> >> Good point. >> >>> What should one do if >>> Date is fresh, but iat is not? >> >> Then it might be a cut & paste attack. > > That is the most material threat. > But to the question of "why not use > what's in the JWT claims in the first place?" this is largely a > philosophical question about whether we want to use JWT as a check > that > the SIP header field values are properly attested, or whether we want > to > use SIP as a delivery vehicle for JWT and have its values be > authoritative > instead of SIP's values. I guess I thought about this largely in terms > of > how I want SIP user agents to behave: like, when it came to the > originating identity, did I want the SIP From header field value to > kind > of cede its place to the value in the "orig" claim of JWT? I guess > what I > want is for SIP user agents to render to users the value of the From > header field, and to use "orig" as a I'm okay with a general preference for Date, but does the issue of a stale iat but fresh date change that? > >> >>> -6.2.2: This section recommends specific result code reason phrases >>> for >>> a >>> couple of circumstances. I assume the idea is that one should use a >>> "helpful" reason phrase, and these are examples of phrases helpful >>> for >>> the circumstances. But it reads as if you mean to standardize those >>> specific reason phrases. If the intent is really to offer examples, >>> please clarify. I'd hate to see us back in the days of commonly >>> seeing >>> SIP code break due to unexpected reason phrases. >> >> This essentially a better version of my comment. > > Well, agreed on that last point. We can soften the language here. What > we > wanted to do is to differentiate conditions that are signaled by the > same > reason code, and to use new reason codes sparingly. The rough > guideline I > use is that programmatic behavior has to trigger off the codes only, > but > human behavior can rely on the reason phrases. We're not asking an > automaton to react to "Stale Date" or "Use Supported PASSporT Format," > say. Softening the language would make me happier. I note that elsewhere in this draft (and also in 4474), there are similar statements that use "For example,..." > > Jon Peterson > Neustar, Inc. >
- [stir] Ben Campbell's Yes on draft-ietf-stir-rfc4… Ben Campbell
- Re: [stir] Ben Campbell's Yes on draft-ietf-stir-… Alexey Melnikov
- Re: [stir] Ben Campbell's Yes on draft-ietf-stir-… Peterson, Jon
- Re: [stir] Ben Campbell's Yes on draft-ietf-stir-… Ben Campbell
- Re: [stir] Ben Campbell's Yes on draft-ietf-stir-… Alexey Melnikov