Re: [stir] Comments on draft-ietf-stir-rfc4474bis-13.txt

"Peterson, Jon" <> Fri, 14 October 2016 17:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9CB8E1293D8 for <>; Fri, 14 Oct 2016 10:36:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.7
X-Spam-Status: No, score=-102.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 0TVx2Z5niCTc for <>; Fri, 14 Oct 2016 10:36:13 -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 16FA212987D for <>; Fri, 14 Oct 2016 10:36:05 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id u9EHXOoF015167; Fri, 14 Oct 2016 13:36:04 -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 : mime-version; s=neustar-biz; bh=3BpzdWgaYoJt5TXrt98VNs1QQHRH57L6JQJiYrZ/oMI=; b=KRw0S7OUlmdc4aUTGU6G1x+tNLQAU7U7fcRPPN+V+V4FfIQHVtlpehI7xEvQJI3GrABo kN0Uk2EwVoNsngUpdm3aHwjDlIA+XR+Sd2DO8yp8jk+V0NDjgcrYakwbgai2X1Z/ePfB lSWV8Ft7a4/1xBOWiEyTTrzJxIr4YZdyFUyPdoBRJsonGC9BnJ90j+M6EvNgP4c9pFDe Rlb2CxSaf9GOF+b/qWkup9z/a5LJYQCjp++3xR3S7E2vxTbeHFGYg7iz6b2drBVLha5J 3OvCjoqDXhG8452dERm9UUyfWGROAjO7zQUio/aB8S8yNAhVQSfy0xnZDMFlIWklWGi0 YQ==
Received: from ([]) by with ESMTP id 261qs36821-16 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Fri, 14 Oct 2016 13:36:04 -0400
Received: from ([]) by ([]) with mapi id 14.03.0279.002; Fri, 14 Oct 2016 13:35:44 -0400
From: "Peterson, Jon" <>
To: Alan Ford <>
Thread-Topic: [stir] Comments on draft-ietf-stir-rfc4474bis-13.txt
Date: Fri, 14 Oct 2016 17:35:44 +0000
Message-ID: <>
References: <24430040.96568.1475710389106.JavaMail.defaultUser@defaultHost> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D4267D641BE3A3jonpetersonneustarbiz_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-14_08:, , 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-1610140313
Archived-At: <>
Cc: "" <>
Subject: Re: [stir] Comments on draft-ietf-stir-rfc4474bis-13.txt
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: Fri, 14 Oct 2016 17:36:15 -0000

I’ve been coming at this from the wrong angle. I’ve been assuming we want to stop (or at least, detect) modification of A. But in fact, what you’re saying is you want to permit modification _as long as it can be canonicalised to the same thing_. Is that correct?

Right, more or less. We can't prevent the modification of A whether we want to or not - and detecting that something has been changed is only helpful if you know that changing things is a problem - and for the kinds of changes we observe in the wild, it usually isn't a problem. What we're trying to resist in the design is the temptation to invent an A-prime with the delusional assumption that it would be safe to give A-prime integrity protection, because we intermediaries will modify A but spare A-prime. As long as there are SBCs, we have to admit the possibility that anything in the message might be modified. But yes, we want to permit A to be modified, and we do just assume that the modifications performed will permit relying parties to canonicalize the eventual value of A to the same bit-exact string (the "real" A) that the creator of the PASSporT canonicalized it to.

In which case I get this - I think.

However, the cases where this would be useful are surely limited. This requires the verifier to know and understand modifications that could be applied along the path by non-STIR-aware entities.

The verifier doesn't have to anticipate or understand the modifications performed by intermediaries, it just needs to be able to look at the end result of those modifications and perform a canonicalization procedure.

This is the basically the same discussion we were previously having on the list about the value of canonicalization. I submit, anyway, that the sorts of modifications that are practically applied by non-STIR-aware entities will still result in call signaling being routable, and that in those conditions the canonicalization we've detailed will work. We can of course imagine that entities will do weird things to telephone numbers that will make canonicalization impossible, but in those cases calls probably won't route or work well anyway. There was a chorus of voices on this list saying things to the effect that operators have dealt with this since time immemorial. I don't think there's a practical problem here. It'll work when it works, and in cases where it doesn't work, identity shouldn't be verifiable.

“Full form”, being base64 encoded, gets around a simple search/replace here, which is probably an improvement.

I don't think that would be material. If this would fix it, then we could have used the original "canon" parameter and rot13'd it. The policies are the problem, not the encoding.

Jon Peterson
Neustar, Inc.