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

"Peterson, Jon" <jon.peterson@neustar.biz> Thu, 13 October 2016 16:57 UTC

Return-Path: <prvs=30940ed6ed=jon.peterson@neustar.biz>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE6012955C for <stir@ietfa.amsl.com>; Thu, 13 Oct 2016 09:57:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.7
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neustar.biz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IpFLpsvgxqfh for <stir@ietfa.amsl.com>; Thu, 13 Oct 2016 09:57:09 -0700 (PDT)
Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F5DD1293D8 for <stir@ietf.org>; Thu, 13 Oct 2016 09:57:09 -0700 (PDT)
Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.16.0.17/8.16.0.17) with SMTP id u9DGrowC027872; Thu, 13 Oct 2016 12:57:04 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=neustar.biz; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=neustar-biz; bh=wxmc0KYsVB4dzlkPHUn7ay18N5I3AKtFmfHHZ9KLpLo=; b=gUKTAoKONdiyly+SCEQHT5wCIkrNQyo9wGaJaRMGcpFON6eN89nyTun4EERPc2SwNdFT GwfgJ5OotoUxJgoFqiO7dPEy5TC/5SQ0uJxotnKLXDMgbWXzXhOCnRrum1cDnxhxgG60 062VxpDf5zyX3AzYYSnA+rAWIyCcU60afbwWcNz4woH4pIkV1xyWZtQ+XqLQhmZXfhl5 vEZ6RkPyXF0mJTn5uabkrNjaKR66DTY1RJKXtv1CLtffFhNJaPs2q4jo7Pt+N34nf/C0 4CIseZwk2xPJgHxWCxvzVQ3NGHsFRs56RGxQ9jreKToJ7A3wsHH7GVKLzXZcOOElTLXX yA==
Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 261qsgbc3g-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Thu, 13 Oct 2016 12:57:03 -0400
Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Thu, 13 Oct 2016 12:57:02 -0400
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: "nweinronk@btinternet.com" <nweinronk@btinternet.com>, "stir@ietf.org" <stir@ietf.org>
Thread-Topic: [stir] Comments on draft-ietf-stir-rfc4474bis-13.txt
Thread-Index: AQHSH2DbTyBQGFRWDUSXYVpiyFA/m6Cmpt2A
Date: Thu, 13 Oct 2016 16:57:02 +0000
Message-ID: <D4252C98.1BE29E%jon.peterson@neustar.biz>
References: <24430040.96568.1475710389106.JavaMail.defaultUser@defaultHost>
In-Reply-To: <24430040.96568.1475710389106.JavaMail.defaultUser@defaultHost>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.3.160329
x-originating-ip: [10.96.12.81]
Content-Type: multipart/alternative; boundary="_000_D4252C981BE29Ejonpetersonneustarbiz_"
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=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1610130287
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/eekO9xUBLb5qla76ErfTCwWNrJQ>
Subject: Re: [stir] Comments on draft-ietf-stir-rfc4474bis-13.txt
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Oct 2016 16:57:11 -0000

I'll be implementing most of the fixes in Nick's comments along with other last call comments at the end of the week, but I did want to speak to this one issue in particular:


 4.1.1 para 2: I note the recommendation of the compact form of PASSporT here.

I do have concern over B2BUAs actions on Date header. Will B2BUA actions (stripping / replacing this header) actually mean that everyone in reality will have to use the full format of PASSporT anyway and probably without does the repeat after failure on the compact form ?

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

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. The full form resend mechanism in there today is a compromise intended to try to address some specific legacy behavior that we see out there today. I consider it our best guess, but I think I'd like some deployment experience before I come down hard on either side of this issue.

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.

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.

Are there other profiles of STIR than SHAKEN under development? Yes, if you consider SIPBRANDY a profile, which we probably should. It could use the compact form.

Jon Peterson
Neustar, Inc.