Re: [stir] Review of: draft-ietf-stir-rfc4474bis-10

"Peterson, Jon" <jon.peterson@neustar.biz> Thu, 18 August 2016 16:44 UTC

Return-Path: <prvs=1038733a47=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 E958712DD4A for <stir@ietfa.amsl.com>; Thu, 18 Aug 2016 09:44:59 -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 weL31Rbdpy0P for <stir@ietfa.amsl.com>; Thu, 18 Aug 2016 09:44:57 -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 BC13712DD1C for <stir@ietf.org>; Thu, 18 Aug 2016 09:44:57 -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 u7IGhLHX006893; Thu, 18 Aug 2016 12:44:55 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=neustar.biz; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=neustar.biz; bh=k4yuwABkNZ2rWP271sytGkmi7FhQb4RnnALIk12xx78=; b=P4zkNmS0LO/7ZRI7KSUuMO4VMx9dN+0aod5kYslJyfI2h+py+WhLi5UVFHLC7WLphKYq bBi49o39SOAw0qnhDWFVliDE2Mxgssk3cRUZbSKIJWJmRNOzekLXQQU0M9A/i66Cfcbb Pn3XuiwS6bIh/nmsXk0uA1wiI1Wg/TTK2aqng1nYLQzyIRy/nQS9pszGjT9hPretvpfU 7dLFFuj7jUQWzBzodY+2tEQ6215pQVIJrmsF9Oum98TzFNMKzVWRyb1XqDYwVNicNBpm GBfQrndI5nIhk/LfwhC7bhNV30fqD0aXpxYD1Xi+w5RiSqgqfp1qPDyPTA3/Zg+jlt9U Vg==
Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 24vsm3bpxf-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Thu, 18 Aug 2016 12:44:54 -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, 18 Aug 2016 12:43:00 -0400
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: Mary Barnes <mary.ietf.barnes@gmail.com>
Thread-Topic: [stir] Review of: draft-ietf-stir-rfc4474bis-10
Thread-Index: AQHR8fCmKQLsUYw9dka3+jdXHWkJhKBGVbYAgAd9kQCAAPWxAA==
Date: Thu, 18 Aug 2016 16:43:00 +0000
Message-ID: <D3DB2F21.1A7B5F%jon.peterson@neustar.biz>
References: <c3a85ffc-8340-ac54-4d8e-21a16fefd032@dcrocker.net> <D3D41210.1A72E4%jon.peterson@neustar.biz> <CAHBDyN7W8zkgGjeUqzGaxLfRD-nFDgD9R3kxioQ47Kbp4_B8EA@mail.gmail.com>
In-Reply-To: <CAHBDyN7W8zkgGjeUqzGaxLfRD-nFDgD9R3kxioQ47Kbp4_B8EA@mail.gmail.com>
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.89]
Content-Type: multipart/alternative; boundary="_000_D3DB2F211A7B5Fjonpetersonneustarbiz_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-08-18_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1608180216
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/skeCzbHu5kmrmllOyLbLFx5Fyro>
Cc: "stir@ietf.org" <stir@ietf.org>
Subject: Re: [stir] Review of: draft-ietf-stir-rfc4474bis-10
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, 18 Aug 2016 16:45:00 -0000

Hi Mary,

I think the use of terminology in the specification has proper background
and citations. Certainly Dave is correct that the text is pretty lax with
"header" vs. "header field" vs. "header field value," no denying that. If
people think this is a big deal, I will fix it. But the suggestion that
because this is true, terminology is loosely used to a point where it
would hamper implementation, that I think his comments don't really
substantiate.

[MB] As pendantic as it might seem, in my experience, the expectation is that we are precise with terminology in the specs, so that qualifying 'header' as 'header field' and 'parameter' as 'header field parameter' is a reasonable expectation. I've had to do that with the RFCs that I've authored and in re-reading this document recently, I think it adds to the readability/understanding in particular since the ABNF comes later. [/MB]

If people really feel like it needs to be fixed, I can fix it - but I do feel justified in pointing out that our track record with this in SIP documents isn't real strong. The original RFC4474 used "header" informally quite a bit. So does RFC4244, actually, if you scroll through that. So does the Replaces header spec. So I'm not sure we really do have much of an expectation about being precise with this. The reason why, I imagine, is because the common and casual way we use it isn't actually ambiguous - no one who sees the phrase "Date header" is confused about whether we mean a header or a header field.

But like I said, it isn't a huge deal to fix it - it's just that any pervasive edits like this can give rise to errors, and it's not clear that fixing this solves any real problem.

<snip>
I think enough of the concepts and protocol mechanisms of the original are
retained to warrant keeping this as a bis.

[MB] I'm not sure on this one, in particular given that it deprecates the header fields defined in RFC 4474 (per section 8).  And, unlike other -bis specs there is no summary section in this document of the differences between the two.  Also, currently this draft doesn't indicate what impact it has on 4474 in the header page. There is the sentence at the end of section 1 stating that this document "revises RFC 4474" but that's not particularly meaningful. Given that when we produced RFC 7044, we obsoleted RFC 4244 despite RFC 7044 being backwards compatible with RFC 4244, I really think that this draft should be documented as obsoleting RFC 4474. [/MB]

There is a summary of changes in the document; it's Section 15 "Changes from RFC4474". And well, the bis doesn't deprecate both the headers as such, it deprecates one header field and changes the syntax of the other. But more importantly, it keeps all the guts: the concept of an authentication and verification service, all the response codes, all the associated SIP behavior. The only real semantic change is the scope of protection of the signature itself, which has been reduced overall, and then with respects to the identities in particular has been honed to deal with telephone numbers better. Obsoleting the Identity-Info header and moving it into an "info" parameter of the Identity header is a just a syntactic change. Although we created some architectural modularity around credentials, the stir-certs mechanism still has the same properties as certs did in the original architecture. Allowing the Identity header to appear multiple times just removes a limitation in the original spec that doesn't seem useful in retrospect (and the way Identity-Info was originally done didn't allow it) rather than a change to how the header is to be understood.

All that said, I do agree it probably should obsolete RFC4474, not merely update it. Or at least that's how I remember the process is supposed to work. I'll defer to chairs/Ads on this one.

Overall, there are a handful of changes (beyond the typos, which again are
appreciated) I'd make based on the substance of Dave's review. Some of the
suggestions to rename sections seem harmless to me. Like some other people
who come to mind, he would like to see some more precise specification and
examples of how you break off the signature from JWT. He pointed out that
we really don't have any motivation for including multiple Identity
headers in there, and we probably do need an indication of what future
work might use that feature.
[MB] I would 3rd the need for examples.  That has been a usual practice for other RFCs defining new SIP header fields (and header field parameters). [/MB]

There will be more examples!

Jon Peterson
Neustar, Inc.