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

Alan Ford <> Thu, 13 October 2016 20:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 537EE1295DC for <>; Thu, 13 Oct 2016 13:07:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.719
X-Spam-Status: No, score=-2.719 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 JqLJ8BIoDneO for <>; Thu, 13 Oct 2016 13:07:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8860912954D for <>; Thu, 13 Oct 2016 13:07:38 -0700 (PDT)
Received: by with SMTP id q7so59110202qtq.1 for <>; Thu, 13 Oct 2016 13:07:38 -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=KoqgHri1I75P1wKoHa5d2zPR1HVit/afbZGuELykofE=; b=KeOu9kJ7ojeC5jvW6PRYdoO95PU5yBx26Ma5+Q1afhAKNeHFK6erqqp+qK6/7RUyuS T3YYCgcdzemx2YRgw7GbJsGPT9CnsNCnOHY8CXnz8ugGuIQ3/y2hUxbLbOQZkudARPSD juBOMhoLbAzpebQJQuSZLV/h5axH7qFKrrMEDwLHmgBwz1rK8iKSoz8AJRzRqK3z53Pk xnfDrc7bVUAu0aahICSzBw51MgnzsHh7yuX4R2JT+bk5IPU4/CsqGKRmXnJM/XHz6a8J 5yKyExGDAiMR0S4XeLR87IUW9UQ8rvJffxHNbwjCq2QdWFomfVN6CHt7nHcCDXKV2d6P uDSw==
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=KoqgHri1I75P1wKoHa5d2zPR1HVit/afbZGuELykofE=; b=ClcVg1p81Vk10Zj15RWnCUDPMX01OJuERqXJ/x2dzzVHneyxKw5cL596b/McxCt0Tn gOv0FfZRDgbbV9FYNaVZXq8Bk/MFMpRbJqrkISl573foL2q1togcAcyu/8pdWqZALByJ E0KlGx+JsQFEybm8CYtDpZtqt42Sud+uaG4/lP0UlFCTowwgNtaL9Sqm4gDrneFPbPy2 pZl+zGXlIDXuz00V2PIYC8aOEVtnllVXwUdiVDaKolLSu2sNXsydTfLoZEyGNdCeHE6U xB8CQnZr6raQfoQu/qOx5JfXb6DBHgpdfkaVt5Pjq/K1gr7Y4+AjrsN2ozhAouTccZUw uL1w==
X-Gm-Message-State: AA6/9RkgLR6Z+Ggg5ZIfpUtisd2eViKzGz+3tAu08VXc7rfn8peP7cPh7bEHmJYsw4APIw==
X-Received: by with SMTP id sm7mr8048262wjc.150.1476389197387; Thu, 13 Oct 2016 13:06:37 -0700 (PDT)
Received: from alans-mbp.lan ([]) by with ESMTPSA id za1sm21197312wjb.8.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 13 Oct 2016 13:06:36 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_4B61EFB4-BF1A-4037-807E-BADD7EF35421"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan Ford <>
In-Reply-To: <>
Date: Thu, 13 Oct 2016 21:06:36 +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 20:07:41 -0000

Hi Jon,

Thanks for the feedback. Comments inline… I think I’ve got what this is all about at long last, but I’ve left thought processes in place in case I’ve still got the wrong end of the stick ;-)

> On 13 Oct 2016, at 19:03, Peterson, Jon <> wrote:
>>> 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.

But in the latter case, the signature still won’t be valid. Unless it can be canonicalised to the same thing. In which case it is valid.

Are you saying that is if something’s in canon, the verifier may look at that and treat it as gospel, and assume that even though the From header has been changed, it “must” be a valid canonicalisation since the signature verifies? Surely that’s not what you’re saying?

If full form / canon is present, then surely the verifier must know if it is a valid canonicalisation (by its own rules) before it chooses whether to validate the signature?

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

Yes, that’s fine. However, A is not protected by a signature, but A-prime is. So given it’s protected, what’s the problem that canon / full form introduces?

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

Ah! Suddenly a lightbulb moment...

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?

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.

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