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

"Peterson, Jon" <> Thu, 13 October 2016 18:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C424B12961A for <>; Thu, 13 Oct 2016 11:03:46 -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 uQtwR-z2VSRr for <>; Thu, 13 Oct 2016 11:03:45 -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 E92001279EB for <>; Thu, 13 Oct 2016 11:03:44 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id u9DI3PPW013615; Thu, 13 Oct 2016 14:03:37 -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=mOQpV+fmu89S4ZbvCccuO8lgHVMnt+lxbKlivtswkF8=; b=S2K0uXcFd34LQ/bIj73XCxi5eGvqkCbD4haY1IB+CY6vCpEinhoqlv89Y6y+4m5UINQx OB15hAA2ZoLmhCGQbBS1uv6YX9+iSypZLCU/Vfp52RZZcV7TOlPwtLqSiwCO0OXrb9Ak RtJPwfZNzruUEqu0q027pSgX68b+f/2032u+QytpspaJ/Wp803W9BhFuGwhkn0VX5Iie YWCzC/Udrlf+Krqqz9OxYmj31rL5soEOjToTUhaPPtg/zAg/cb+kJxD3PlUzToA8lHHs 2jES7KVSDveXFpBlicQJmueGhZNVJ2+oOvjp9UagmewbDn5OGHR0HUfVOrDPvYy3ISjK rQ==
Received: from ([]) by with ESMTP id 261qs33kk7-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Thu, 13 Oct 2016 14:03:37 -0400
Received: from ([]) by ([::1]) with mapi id 14.03.0279.002; Thu, 13 Oct 2016 14:03:36 -0400
From: "Peterson, Jon" <>
To: Alan Ford <>
Thread-Topic: [stir] Comments on draft-ietf-stir-rfc4474bis-13.txt
Date: Thu, 13 Oct 2016 18:03:35 +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_D42541951BE2FCjonpetersonneustarbiz_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-13_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-1610130309
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: Thu, 13 Oct 2016 18:03:47 -0000

But by instead having the two ends do their own canonicalization, rather than trying to tunnel the canonicalized number from end to end in some special spot, we effectively removed the ability of SBCs to modify that canonical number.

...But this I don’t. Since if they modified what was carried in the canon / full form, the signature would no longer verify.

The distinction I am drawing is between the verifier using the bit-exact version of the originating telephone number in "canon" versus a verifier performing its own canonicalization procedure on the From header field. In the former case, if the SBC modifies "canon", obviously the signature won't be valid. In the latter case, provided that whatever is in the From can be canonicalized by the verifier, it uses that.

This argument (and again, to be clear, it was not my argument at the time) is effectively a regress argument. If we're afraid that SBCs could modify field A, we are tempted to create field A-prime which contains the "real" value of A, just in case A gets modified by an SBC. The problem is that as long as A-prime also goes through the SBC, the SBC can (and surely will) modify A-prime too - SBCs modify A in the first place to enforce some policy or constraint, and those policies apply equally well to A-prime. "canon" was just an A-prime in its original incarnation. The full form of PASSporT is readily analogous.

If they rewrote the signature, it would be from a certificate which isn’t authorised to represent that source domain.

I don't mean creating a new PASSporT or redoing the signature.

Or if it is authorised, then they could do that to the compact form too.

Sure, hypothetically.

So what exactly are you protecting against here?

By forcing both sides to build their own "real" version of A (the canonical telephone number) rather than having the originating side generate an A-prime that would be used by the terminating side, we remove the ability of an SBC to modify A-prime - because there is no A-prime. Instead the SBC can just modify A, but our canonicalization on the verifier side is (supposedly anyway) sufficient to turn that modified A into the "real" A.

I do get that this is a complicated argument: this was however the argument that moved the working group back in the day. I hesitate to reopen this discussion, but I do think people really need to understand that if we think using "iat" solves the problem of SBCs altering Date, it only does partially: it solves the problem of some legacy SBC modifying Date, but why is Date modified in the first place? Will the policies and constraints that cause that today extend to Identity-aware SBCs, as they come into being? The problem with designing anything that is supposed to cope with SBCs is that SBCs are undefined entities with unlimited powers. We need to see what happens in deployment to see how effective full form is at addressing this problem.

Jon Peterson
Neustar, Inc.