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

Alan Ford <> Thu, 13 October 2016 17:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9908E12960E for <>; Thu, 13 Oct 2016 10:43:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 dnGnq4y841YS for <>; Thu, 13 Oct 2016 10:43:36 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 27E9F12961A for <>; Thu, 13 Oct 2016 10:43:36 -0700 (PDT)
Received: by with SMTP id x79so151392032lff.0 for <>; Thu, 13 Oct 2016 10:43:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=mciN8HWll4uw4H+7DDEFxIQJQfXKzX9n+AxJg+TnsZE=; b=vCk8wm+6sxEWmldQq5h8BYjq554XfU6UvhZdCrJcGQuc0adYc5KUBY4jPsisLszu9r 5OW18KMebEkXs7qDBbkQIvNUTDOl9qO2Qm6XF/lpYSaaXN8NlNa+pcSpiXZKQijjKfdQ B8GMaKCYDcvLsddSZcU3M0rk3sZI94EtmePG3Jn0o+03cc3flOQ5sE1ToclYXUC9RfgT j3RsJCzsTpa/cErPExzHVuFZ0vrm3UayxEFRnC3yWUv6Nq/1ESu4+FT+N3oKPO7aO9W+ rq5gA2458GofOoZdOrJwUf6sPjFNxNNZ5lbzlJPUtRrIIHI17Jxi8+jAVHxvgqTvlEK3 Zd+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=mciN8HWll4uw4H+7DDEFxIQJQfXKzX9n+AxJg+TnsZE=; b=Cby3qCfi0HD08tfW/HOG1J5rcs1CyG0bW0mVkk1dAnVl6kZFPxasRzW8VYj9P0hjsh cNKC4o73Yf2RYeqsGg/6SreTHv4wmMIrZNA6Q46Vj3GehaoKFska7fwrDaLD3GeSJPlH rOSOmUYq5ExW3BNUHO6UNY46OcRFRuiT5pHrqFWgF8bR84HVI37iQYTRAiriHu4FEcep nErH+DFzvvc6HXEo3YCfQoUJeqBwJLXEPNyL0aKQ1Q+55mfPypEAft1anNWplyJaDG4p 15CP5m0Pgq7bBI140UnkmLwuNJAjcyHxKFJR0oy3YSoeokXJlErW5rV7esB9lkqgeF5y ZT1g==
X-Gm-Message-State: AA6/9Rna7pVNJAjJZQDhI2VGUKzLhr8TfesbvBxuqBFTP8ziFj+t6IF4m+P33nreCVm5eQ==
X-Received: by with SMTP id x127mr2977568wmb.103.1476380614231; Thu, 13 Oct 2016 10:43:34 -0700 (PDT)
Received: from alans-mbp.lan ([]) by with ESMTPSA id q8sm24207671wjj.7.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 13 Oct 2016 10:43:33 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_194ADFF6-E012-4015-9FA5-02E69AEA4BC7"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan Ford <>
In-Reply-To: <>
Date: Thu, 13 Oct 2016 18:43:32 +0100
Message-Id: <>
References: <24430040.96568.1475710389106.JavaMail.defaultUser@defaultHost> <>
To: "Peterson, Jon" <>
X-Mailer: Apple Mail (2.3124)
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 17:43:40 -0000

Hi Jon,

I admit I came to this late, and so never saw this initial discussion you refer to, but I am really confused by what you write below. I hope you can clear up my confusion; comments inline...

> It's interesting - speculating about what B2BUAs might do is part of what inspired the compact form in the first place. Long before we tried to distinguish full from compact form or indeed incorporated PASSporT, the original specification of "canon" as the canonical original telephone number was kept optional as an Identity parameter in part because, as Hadriel and others feared, any place where that telephone number appeared in the message it could be a potential target for SBC modification. If SBCs want to modify the number in the From, do we really think we're going to stump them by putting a copy of the number in the "canon" parameter two headers down? They'll just go change that one too, it was argued.

OK, I can see that...

> 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.

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

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

So what exactly are you protecting against here?

> We wouldn't even need a terminating-side verification service canonicalization pass if we didn't need to defend against this possibility of SBC interference.

Right now this statement makes no sense to me - but if I can understand what threat you are protecting against above, this may make sense!

> What that means is that using the full form potentially makes the contents of the JWS header and payload a target for SBC modification - if the SBC is modifying the From header, why wouldn't an Identity-aware SBC modify the "orig" in the JWS payload too? The same argument can, unsurprisingly, be made for the Date header.

Sure it could, but it would also have to rewrite the signature. And if it couldn’t do so, since it doesn’t have an appropriate certificate, it would no longer verify. Which is surely what you want?

> The other motivation for compact form was just to save space in more constrained environments: not to add redundant bytes to the message unless you need to. Full form adds bytes, and it isn't a particularly small number of bytes. This is basically the motivation given in JWS Appendix F for having an abbreviated form of the payload when its being used in such an environment. Our usage of compact form here is well within the spirit of JWS design.

Certainly fair, however if you start to throw around 6KB SDPs (which is the norm in the video SIP world), the size of the Identity header suddenly doesn’t seem so significant.

> Does all of this add up to a RECOMMENDED compact form? It's real close. We could take out the recommendation and just leave this up to the STIR profiles to decide for themselves when they want to use compact or full, if people feel strongly about it. 

That seems reasonable.