[stir] Summary comments on draft-ietf-stir-* document trio at WG Last Call

[Dave Crocker <[e-mail]>]

Greetings,

I've done self-initiated reviews on the three documents that were put 
into the STIR Working Group Last Call:

    *  Secure Telephone Identity Credentials: Certificates
       draft-ietf-stir-certificates-07.txt
       "The use of certificates in establishing authority over telephone
       numbers"

    *  Persona Assertion Token
       draft-ietf-stir-passport-05
       "A token format for verifying with non-repudiation the sender
       of and authorization"

    *  Authenticated Identity Management in the Session Initiation
       Protocol (SIP)
       draft-ietf-stir-rfc4474bis-10.txt
       "A mechanism for securely identifying originators of SIP requests"


This note is a summary of the core comments and conclusions in those 
reviews, with some further thoughts.


The summary of all that follows is quite simple:

      These documents are in need of extensive additional work and after 
that is done, they still will not specify a coherent capability.  The 
worked need to turn this into a coherent capability is substantial and 
possibly risky.


My specific reviews are:

   Review of:  draft-ietf-stir-passport-05
   https://mailarchive.ietf.org/arch/msg/stir/vypQUp6ILfCitdB2PEWo_2bZmZw

   Review of: draft-ietf-stir-rfc4474bis-10
   https://mailarchive.ietf.org/arch/msg/stir/N334mEfCpWowtSnXNrx2ElPGr84

   Review: draft-ietf-stir-certificates-07
   https://mailarchive.ietf.org/arch/msg/stir/VkB0HMs5JrHRLcOrDmMukdIzD3A

Separately, I posted a comment about the choice of JWT/JSON:

   https://mailarchive.ietf.org/arch/msg/stir/8S0DnRRY6rb368Rt-k4zqQkbd90


Since I'm not a phone guy, I should preface with some information about 
my background that is relevant to the following comments, beyond noting 
that I have done technical work for quite a few decades and that I have 
extensive and varied IETF experience:  I've built and run a couple of 
national email services.  I'm a Senior Technical Advisor to M3AAWG 
<m3aawg.org>, which is an Internet anti-abuse trade association. I'm 
also a co-author of the current specification for DKIM, which provides 
an authenticated identifier for email.  Further I participate in a 
number ad hoc industry consortia that develop anti-abuse-related 
enhancements that are based on the use of DKIM and SPF.  I participated 
in the the STIR effort as it was chartered.  None of this guarantees 
that anything that follows is correct, but it should provide some 
context for my views about efforts to design technical services used to 
mitigate abuse...




Telephone spam is a serious, urgent, global problem, and has been for 
some years.   Efforts to mitigate it would be greatly aided by reliable, 
accurate caller-id authentication, similar to the benefits that already 
accrue for email anti-abuse efforts based on authentication.

The primary benefit will be to allow development of accurate reputation 
information for the caller-id, because then there is assurance that it 
has only been used by an authorized actor. In general, this promotes 
identification of calls from good actors, rather than directly serving 
to identify bad actors -- absent additional mechanisms, such as ones 
ensuring a semantic of exclusivity, with a guarantee that /all/ calls 
using the caller-id will be validated.(cf, DMARC)  However given some 
essential operational differences between telephony and email, this 
assurance is probably more easily made for telephony than it is for email.



Discussions to pursue a standardized telephony authentication mechanism 
began approximately 5 years ago. The IETF's STIR working group began 3 
years ago.

The technical aspects of global telephony probably preclude ever 
achieving a solution that will cover all phone service, everywhere.  The 
mix of telephone administrations is challenging, but the considerable 
mix of telephony technologies is the major impediment: differences in 
their underlying semantics and limitations to their extensibility make a 
comprehensive, hybrid solution highly problematic, if not impossible.

The STIR working group nonetheless originally pursued a set of hybrid 
solutions, only more recently gravitating toward a narrower effort, 
targeting a SIP-only initial capability for authenticated calls. 
Telephony is increasingly using SIP and there already is a significant 
global infrastructure using it.  In technical terms, SIP is more 
amenable to this kind of authentication enhancement, than are the legacy 
technologies, especially given that its use of header-fields for 
parameters and meta-data is almost identical to that of email, even to 
the point of having a "From" header field.




The nature of the basic tasks for this type of authentication service 
include:


     *  Deciding where to get the caller-id from.  The legitimate 
technical challenges here are that the SIP phone world has several forms 
of caller-id strings and several places they can occur.  So defining a 
deterministic algorithm is not necessarily straightforward.
However resolving the details in obtaining and processing the variations 
in caller-id appears to primarily be a matter of defining a precise and 
reliable algorithm.

The specifications have text that I believe is intended to provide this 
detail, but I was unable to converge on an understanding of what the 
deterministic behavior and results would be.  It appears to talk about 
possibilities, rather than provide a clear, reasonable and deterministic 
algorithm.


     *  Deciding on the authentication algorithms and data packaging -- 
data to hash, hashing algorithm, crypto algorithm, where to to put the 
result, etc.  This is quite a bit of detail and needs to be done 
correctly, but rarely involves creativity or any interesting debates. 
However, here too the specification seems to provide for alternatives 
rather than a single, simple, clear, interoperable solution, absent 
additional, unstated private agreements.


     *  Deciding how the public key is to be associated with the 
relevant 'identity' and deciding how it will be found and validated. 
That is, a key query service.  In most crypto services, this involves a 
'certificate' with an authority hierarchy.

        For common certs, these involve an independent public key cert 
infrastructure (PKI).  For DANE, the hierarchy matches the domain name 
hierarchy for the name having the key, which is stored in the DNS.  For 
DKIM, the key is self-certified: this key also is stored with the name 
and can (presumably) only be put there by the domain owner.

        Use of the 'common' PKI service is widely viewed as highly 
problematic, particularly in terms of making serious reliance on proper 
authentication, for more than mitigating man-in-the-middle attacks.

        DKIM has extensive deployment and operational experience, 
however its authority hierarchy only aligns nicely with domain names.

        The DANE model does not have significant deployment penetration 
or operational experience.  Also as with DKIM, it's authority alignment 
is with domain names, not telephone number administration.

        OAuth is a recent capability that might provide a reasonable 
cert model that can be applied here, but I don't know enough yet to be sure.

        Caller-ids based on classic telephone numbers, however, are 
problematic.  Especially due to number portability, the authority 
hierarchy for numbers does not align at all well with the string of 
numbers.  In effect, any next number in a sequence can be administered 
by a different entity.  Worse, a prior attempt at an inter-organization 
query service based on telephone number (ENUM) was not successful.


        In other words, the requirement to have an inter-organization 
query and validation capability for keys associated with caller-ids 
should be viewed as both difficult and discouraging, essentially at the 
level of a open research task:  We have no global experience with a 
successful version of a comparable inter-provider service, or at least 
not at the necessary scale.  But we do have examples of failure...



In any event nothing in the current specification specifies how to find 
and validate the associated key.  All that is supplied is very general 
commentary.  And this fact is worth repeating:  The trio of documents do 
not attempt to specify the highest-risk component to the authentication 
service:  a complete and interoperable key query mechanism.





Based on the discussions on the working group mailing list and from 
various private discussions, it appears that folk think that what 
remains to be done are mere details, or policies, rather than 
development of core technologies or mechanisms, and that these will be 
settled elsewhere (ATIS-SIP Forum, or the like).  But the work remaining 
includes basic functional capabilities, not mere administrative or 
operational (policy) details.  Perhaps these will indeed get resolved in 
those later discussions, but it will require quite a bit of additional 
effort and time. I suspect it will require far more effort than is 
currently appreciated.

My sense is that the folk intending to pursue use of this work have an 
underlying expectation that there will be a set of bilateral and/or 
multilateral provider-based agreements that determine the remaining 
details, rather than there being an integrated public service.  This has 
been, after all, common in the telephone industry.  However it is at 
odds with the IETF's approach to the definition of open, interoperable 
services that work at scale.




Further, the IETF's publishing the current specifications will mean that 
the IETF is blessing a set of documents that do not offer a coherent, 
usable technical capability.  I believe that is somewhere between 
unusual and unprecedented.




The proffered drafts do not include any coherent description of the 
integrated service that is being specified.  Simple architectural charts 
that show the components and how they are functionally connected, with 
descriptions of their roles and interactions, go quite a long way 
towards developing a shared, community understanding of what is being 
done.  An essential example here is to delineate relevant administrative 
trust boundaries.

Note that even very recent discussions on the list demonstrate a basic 
lack of this shared understanding, such as where validation will be done 
and what will be done with the result. And this example has profound 
import to the service model, since validation at end-user devices 
requires a key query service that will operate over the open Internet, 
whereas validation only amongst 'authorized' providers won't.

Some individuals seem to have a clear model for this.  However the group 
does not.




The design has chosen use of a JSON/JWT for a "Passport" abstraction of 
a common "token" collecting together identity, key and other 'claims' 
information.  In terms of computer science design, it looks reasonable; 
it is modular, based on some standardized technologies, and appears to 
be extensible.  And my original reaction to it was that while it was not 
necessary to the immediate task, it might have some long-term appeal. 
However the more I have slogged through the specifications and tried to 
discuss issues with individuals, it has become clear to me that it is 
adding quite a bit of complexity to the reading and probably to the 
software, for literally /no/ immediate benefit.  In fact, it is not 
merely additional overhead:  my sense is that it has made it more 
difficult to find various errors in the detail of the specifications. 
There is no JSON already in the SIP environment that is being signed; 
the extensibility is easily obtained more directly; and the aggregate 
specifications are significantly more difficult to comprehend.



The certificate draft is not a specification.  It is a discussion, often 
about basic concepts or about a hypothetical future.  Hence, the 
highest-risk component to the proposed capability remains entirely 
unspecified.



For all three documents, the writing often is bloated and opaque and 
error-prone, where the reader apparently is expected to have quite a bit 
of very detailed background that is not stated in the documents. One of 
the drafts had not even been processed through a spelling corrector, 
although this was a Las Call Verion.  Also, non-trivial algorithms are 
written as complex prose rather than simple algorithms. I suspect these 
have errors but can't be sure.  It often was not clear to me what was 
meant -- or it was clear that the text had not specified what it claimed 
to specify. The specifications are also often incomplete, with respect 
to the scope of the document.  That is, they simply don't cover what 
they say they will (and which they need to cover.)  The documents 
purport to provide modularity, but contain enough cross-references, 
cross-discussion and bi-directional dependencies to defeat this.




All of the above suggests a working group that did not seek to specify a 
complete capability, did not diligently participate in the specification 
and review of these documents, and does not have a precise and workable 
shared understanding of what the target service will be nor how that 
service will be achieved.  The difference between being able to validate 
at the callee's independent SIP implementation, versus requiring 
validation to be done by a service provider, is merely one of many 
examples of these problems with the working group effort..


I should also make at least a quick comment about the process problems 
that have been so clearly demonstrated on the list during my review 
effort:  In roughly 30 years of participating in the IETF and doing 
reviews of working group documents, I have never before seen an almost 
complete lack of public engagement in dealing with a review. 
Disagreement is common.  Silence is not.  The authors have refused to 
engage in substantive, public discussion about these reviews, promising 
instead to make back-room decisions as they see fit.  The rest of the 
working group has so far been almost completely silent on the substance 
of the reviews.



d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net