Re: [stir] Ben Campbell's Yes on draft-ietf-stir-rfc4474bis-15: (with COMMENT)

"Peterson, Jon" <> Thu, 03 November 2016 14:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E7919129A57; Thu, 3 Nov 2016 07:16:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.701
X-Spam-Status: No, score=-102.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b_X6_-Ku37m2; Thu, 3 Nov 2016 07:16:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A993D1296D4; Thu, 3 Nov 2016 07:16:42 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id uA3ECudG003393; Thu, 3 Nov 2016 10:16:40 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=neustar-biz; bh=uNnr5x8/P20xIad5wf51lY3FrROcjuA6JwoNoOrb0YY=; b=ZVCdvB46ZNf4YLaQuJ/q663DfH+++ZVDGm7OJwaHmFvPoyePh3IKHy9akFOQroHI+eP+ +pWpGbYbXkl0MmrORnN/v4FGKPNqwA5LYt5tdKzhHn6mfnGeQ68LX3qYCh4KJSOt8S3h sE+MWNnHGyeH6gc+fNK3ZKw9mDoILnS85vxlpKmc4aeXIaPRGGxUlgN5FqeUg4jovlko /r4ipP1lG7a1SSCYjTZ60/SqEezn60lmEl9+1ODVK/NWG/RPsNiLQs5VOeClk8L3ZNDx smWPTP+Darg9KAvPrYt9CTB2oRuepIEd5OTLZyryNnusCUZKPXX1AZC2eWMHjae5nBeM 9A==
Received: from ([]) by with ESMTP id 26crse0uk6-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 03 Nov 2016 10:16:40 -0400
Received: from ([]) by ([::1]) with mapi id 14.03.0279.002; Thu, 3 Nov 2016 10:16:39 -0400
From: "Peterson, Jon" <>
To: Alexey Melnikov <>, Ben Campbell <>
Thread-Topic: Ben Campbell's Yes on draft-ietf-stir-rfc4474bis-15: (with COMMENT)
Date: Thu, 03 Nov 2016 14:16:38 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-11-03_04:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611030267
Archived-At: <>
Cc: "" <>, "" <>, "" <>, The IESG <>, "" <>
Subject: Re: [stir] Ben Campbell's Yes on draft-ietf-stir-rfc4474bis-15: (with COMMENT)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Telephone Identity Revisited <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 Nov 2016 14:16:54 -0000

>> On 2 Nov 2016, at 23:38, Ben Campbell <> 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

>> -6.2.2: This section recommends specific result code reason phrases for
>> 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.

Jon Peterson
Neustar, Inc.