[stir] Setting Direction for the STIR WG Last Call

Russ Housley <housley@vigilsec.com> Wed, 17 August 2016 20:52 UTC

Return-Path: <housley@vigilsec.com>
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 BD97112D73A for <stir@ietfa.amsl.com>; Wed, 17 Aug 2016 13:52:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
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 t3KtvflikQ4T for <stir@ietfa.amsl.com>; Wed, 17 Aug 2016 13:52:51 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B1B512D6B5 for <stir@ietf.org>; Wed, 17 Aug 2016 13:52:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 5B6033004CA for <stir@ietf.org>; Wed, 17 Aug 2016 16:52:49 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id afw47uKYC8xx for <stir@ietf.org>; Wed, 17 Aug 2016 16:52:44 -0400 (EDT)
Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id 99B77300289 for <stir@ietf.org>; Wed, 17 Aug 2016 16:52:44 -0400 (EDT)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <07e0eb16-6758-cdf1-c571-1f1ed768e741@dcrocker.net>
Date: Wed, 17 Aug 2016 16:52:56 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <D9E1B04E-EE62-44AD-B98E-05A264FD044C@vigilsec.com>
References: <07e0eb16-6758-cdf1-c571-1f1ed768e741@dcrocker.net>
To: IETF STIR Mail List <stir@ietf.org>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/bew1ijIt3WfRQVvhJRUcIrwZSF0>
Subject: [stir] Setting Direction for the STIR WG Last Call
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, 17 Aug 2016 20:52:55 -0000

It is not fun for a WG Chair to take a vacation and then return to find that WG Last Call discussion has escalated from a straight forward document review to accusations of bad acts on the list.  Well, that is where I find myself, so I’d like to take a step back and try to focus this energy in a productive direction.  First, I think that recounting a bit of history may be helpful.

Well before the STIR BOF, there was consensus that the solution needed two parts.  First, there needed to be a digital signature that covered the claimed source telephone number and some other things to prevent replay.  Second, there needed to be credentials to provide the public key to validate that signature.

During the STIR WG chartering discussion we talked about where that signature might be carried.  We got direction from the Area Director that we should focus on in-band mechanisms before looking at out-of-band mechanisms.  The STIR WG charter gives direction:

   As its priority mechanism work item, the working group will specify a 
   SIP header-based mechanism for verification that the originator of a SIP 
   session is authorized to use the claimed source telephone number, where 
   the session is established with SIP end to end.

The WG decided that a replacement to RFC 4474 was the best way to accomplish this, and the first WG draft on that topic was adopted in June 2014.

Before the STIR BOF, there was discussion about the type of credential that would best scale to represent the telephone number space.  The WG recognized that using certificates for the credential meant that some aspects of the public key infrastructure associated would need to be left to the regulators in each country.  This is a political reality associated with telephone numbers.  This was discussed and understood.  See the hum results regarding credential format at IETF 90 in July 2014:

   https://www.ietf.org/proceedings/90/minutes/minutes-90-stir

The WG decided on certificates for the credential format, and the first WG draft on that topic was adopted in October 2014.

In most of 2015, the WG was making slow progress.  Frankly, I was a bit frustrated; with these fundamental decisions behind us, we could have made faster progress.  But then, we saw renewed energy starting in the Summer of 2015.  One recent example of this can been seen in the blog post from last month by FCC Chairman Wheeler:

   https://www.fcc.gov/news-events/blog/2016/07/22/cutting-robocalls

As part of the renewed energy, there was a suggestion to use the signature format specified by the JOSE WG instead of a bespoke design.  The result was PASSporT, and the first WG draft on that topic was adopted in February 2016.

Now, all three of these documents are in WG Last Call.  It seems that some of the fundamental decisions that were made almost two years ago are being called into question.  If there is a technical problem, let’s identify it and fix it.  If there is a lack of clarity, let’s fix that too.  However, WG Last Call is not the time to revisit each decision that brought the WG to this point.

If you are the author of a review that raises a large technical problem, I ask you to provide a concise description of the problem in a message of its own.  I am trying to separate the discussion of any such problems from the resolution of other document comments.

I ask the authors of each document to review the comments that have been posted and offer a way forward.

Thanks,
Russ