Re: [stir] Second WG Last Call for RFC4474bis

Alissa Cooper <alissa@cooperw.in> Wed, 21 September 2016 01:41 UTC

Return-Path: <alissa@cooperw.in>
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 EA9FB12B15F for <stir@ietfa.amsl.com>; Tue, 20 Sep 2016 18:41:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level:
X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=tM0lhB5o; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=O9wIU40f
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 jryuAEPJ-DaA for <stir@ietfa.amsl.com>; Tue, 20 Sep 2016 18:41:27 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFA3912B046 for <stir@ietf.org>; Tue, 20 Sep 2016 18:41:26 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 1EE14206ED; Tue, 20 Sep 2016 21:41:26 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Tue, 20 Sep 2016 21:41:26 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=ysmWZcQoc2G7DEySYjKz4cY77OY=; b=tM0lhB 5oQJfxF9Z8G7UA8Bt/up9PxtoKf+6pT9tXDGxDcPF9/aHm8d5pE1mdYOGZp78Vu2 woAKJeAufVGJTqCxqMV35w0k4rureFnqWaxtIZP4ncmlNF+P+QlMlSkqDJzU+y5m /8q/IwPk0Niq9vjlICYYnUl7cP0YogThEWvJM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=ysmWZcQoc2G7DEy SYjKz4cY77OY=; b=O9wIU40fohQmSnxs4+CutJRsv3fnvCv3TvJqMKg27uGt3XP 5Ogi8OB/ov/RIPvvN/ULrs8EvYzRHl6DZiW0hqY17Efxl25Ef8yPuNwluVCnNk7a bm2y11Vv3g67PsNEACh61Qq8rliTSjPY8ST0u9XjBHiB+ZgRjZIesEQWqwF8=
X-Sasl-enc: yTNrJbH2iNCqiUmfDLy+GUQzMNnIEyHiB4SHVIeBLjec 1474422085
Received: from [10.24.25.193] (unknown [128.107.241.174]) by mail.messagingengine.com (Postfix) with ESMTPA id 35BD6F2988; Tue, 20 Sep 2016 21:41:25 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <10F4895C-4103-497A-B1E0-7B6CB617F13C@vigilsec.com>
Date: Tue, 20 Sep 2016 21:41:23 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <7D464687-370D-43CA-8AFA-2DE5C9C576E8@cooperw.in>
References: <C1E751BC-55E9-4D8C-A6A5-B5674835870E@vigilsec.com> <10F4895C-4103-497A-B1E0-7B6CB617F13C@vigilsec.com>
To: Russ Housley <housley@vigilsec.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/z9vYCfFl01S_r32KO-mBV5tJQz0>
Cc: IETF STIR Mail List <stir@ietf.org>
Subject: Re: [stir] Second WG Last Call for RFC4474bis
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: Wed, 21 Sep 2016 01:41:29 -0000

I did my AD review of this document early to try to expedite the process.

= General =

Should this document obsolete RFC 4474? Apologies if this was discussed and I'm failing to recall it. My answer would be yes I think, since new implementations of RFC 4474 are discouraged and this document is deprecating its syntax and its registries.

= Section 4.1 =

(1)
"Third, the JSON key "iat" MUST appear, set to the value of a
      quoted encoding of the value of the SIP Date header field as a
      JSON NumericDate (as UNIX time, per [RFC7519] Section 2)."

I think this needs one more sentence to explain that while RFC 7519 specifies that "iat" reflect the time the JWT was issued, there may be cases where an authorization service mints a JWT on behalf of an endpoint at some point later than what the SIP Date reflects. Given that the JWT is being created on behalf of the user (and how and why "iat" is used by 4474bis implementations), using the SIP Date rather than the time at which the JWT is actually created is acceptable.

(2)
"Defining how a SIP implementation
   would provision multiple originating or destination identities is
   left as a subject for future specification."

I'm assuming this meant to say that defining how a STIR implementation deals with multiple identities is what is left for future specification. Is that correct? If so, it would be helpful to clarify.

(3)
"Also note that in some cases, the
   "orig" and "dest" arrays might be populated with more than one value."

The passport spec says that "orig" MUST only have one value. Should this text align with that? Or is this meant to allow for future extensibility of passport?

= Section 8.3 =

(1)
"This will be the case, for
      example, for nationally-specific service numbers (e.g. 911, 112);
      however, the routing procedures associated with those numbers will
      likely make sure that the verification service understands the
      context of their use."

I don't understand what is meant by the text after the semi-colon. Is the point that the lack of canonicalization is ok because a verifier that is asked to verify 112 will be designed to know that 112 is special?

(2)
"If not, implementations SHOULD convert the number into E.164 format,
      adding a country code if necessary; this may involve transforming
      the number from a dial string (see [RFC3966]), removing any
      national or international dialing prefixes or performing similar
      procedures.  ... 
      Other transformations during canonicalization MAY be made in
      accordance with specific policies used within a local domain."

Aren't all of the "other transformations" subsumed under the umbrella of converting to E.164 format? I find it confusing to see these discussed as two separate requirements. I think it's fine to point out that some domains will need to take their own unique steps to eventually get their numbers into E.164 format, but that doesn't imply that there is one set of transformations that SHOULD happen and another set of transformations that MAY happen, right?  

= Section 13.3 =

Shouldn't the existing alg parameter have its reference updated to point to this document?


Nits:

= Section 1 =

A forward reference to Section 10 should be added to the last paragraph.

= Section 2 =

s/from an "identity field" a SIP request/from an "identity field" in a SIP request/

= Section 4.1 =

"the following elements message MUST be placed" -- I'm assuming "message" is extraneous and should be deleted? 

s/key "typ" key/key "typ"/

s/from addr-spec of the From header/from the addr-spec component of the From header/

OLD
This specification inherits
   from the PASSporT specification one value for the 'alg' parameter:
   'ES256', as defined in [RFC7519], which connotes an ECDSA P-256
   digital signature.  All implementations of this specification MUST
   support the required signing algorithms of PASSporT.

NEW
All implementations of this specification MUST support the required signing algorithms of PASSporT. At present there is one mandatory-to-support value for the 'alg' parameter:
   'ES256', as defined in [RFC7519], which connotes an ECDSA P-256
   digital signature.  
   
= Section 6.2.1 =

I think it would help to provide a little bit of rationale for this recommendation: "As a guideline, this specification recommends that only if a
   verifier determines all Identity header fields within a message are
   invalid should the request be considered to have an invalid identity."

= Section 6.2.2 =

s/reason phase/reason phrase/

= Section 10 =

OLD
it would likely fail the request due to the absence of an
   Identity-Info header field with a 436 response code.

NEW
it would likely fail the request with a 436 response code due to the absence of an
   Identity-Info header field.

= Section 13.4 =

I think this section should clearly instruct IANA to delete the registry.


Alissa


> On Sep 10, 2016, at 12:01 PM, Russ Housley <housley@vigilsec.com> wrote:
> 
> 
> A revised document to address the issues raised in the first WG Last Call
> on this document was posted yesterday.
> (https://www.ietf.org/id/draft-ietf-stir-rfc4474bis-12.txt).
> 
> This message starts a second two-week WG Last Call for this document,
> which will end on 24 September 2016.
> 
> Please review the document and send comments on it to the STIR WG mail
> list.  Please clearly state your opinion as to whether the document is
> ready for publication as a standards-track RFC.  Remember that support
> for publication is needed, so if you think the document is ready to go
> forward, please say so.
> 
> Thanks,
> Russ & Robert
> 
> 
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir