Re: [stir] current draft charter

["Peterson, Jon" <[e-mail]>]

There are some more specific replies inline, but first this:

Upleveling, there are a set of problems out there in the world that are
caused by impersonation of calling numbers, and we have a choice here to
try to address them or not. The STIR proposal does make the foundational
assumption that we would have more leverage on the impersonation problem
if Internet devices could somehow rely on the authority structures over
numbering that are defined in the PSTN. I've tried here not to be overly
prescriptive about what the best way is to project those authority
structures onto the Internet.


Certainly we could just decide at the get-go "it's certificates, there'll
be a CA, based on existing CAs used by the numbering databases."
Personally I'd rather hear more discussion about the alternatives under
consideration, like putting credentials in the DNS. However, willingness
to explore alternatives and understand the design space is not
hand-waving, it's not sweeping things under the rug, it's not believing in
unspecified miracles.

Certificate authorities and the DNS are both fairly well understood
commodities. The operational and deployment characteristics of these
services are not particularly mysterious. If these are the possibilities
under consideration, then I don't think we're in unfamiliar waters. We can
examine these possibilities, and ultimately if appropriate we can allow
either or both, in rfc447bis and the related specifications. Once we have
the protocol machinery in place, maybe letting industry and regulators
build out structures until we see what works would be instructive.

As the PSTN transitions further onto the Internet in the coming years,
there are going to have to be systems in place for authority, for routing,
and so on that help bring telephone numbers onto the Internet. We don't
have all the answers today about what that world will look like. All we
can do is to move the ball forward, based on what we know today and what
is achievable today, and the challenges we face in this transitional and
transitioning system (like robocalling, vishing, swatting, etc). In order
to do this, we need to fix things like RFC4474 so that it has hooks for
supporting telephone numbers. That is the work in the proposed scope of
STIR.

On 6/17/13 8:41 AM, "Dave Crocker" <[e-mail]> wrote:

>On 6/16/2013 11:56 PM, Peterson, Jon wrote:
>>> As I understand it, this model of thousands of trust anchors is showing
>>> some very rough edges for scaling, accuracy, and scope. I believe it
>>> also has had a single semantic, unrelated to the one being proposed.
>>
>> Right, the rough edges there are why the current problem statement for
>> STIR suggests we do things a bit differently.
>
>In looking over the draft charter that you circulated last Tuesday, I'm
>not seeing text that obviously covers this.  In contrast, all of the
>list discussion about CAs appears to be based on the current model that
>uses very large numbers of anchors.

Obviously charters are at a low level of detail, as opposed to the input
documents, but if this is enough of a hot-button issue to warrant a
mention in the charter, I wouldn't oppose it.

And as for the list discussion, well, we're all still coming to understand
the problem space. I don't think I've heard people arguing that a very
large number of overlapping trust anchors would be a wise way to start off.

>Even with text in the charter, the deeper question is what changes are
>feasible to the current model that are viable with the scale, diversity
>and reliability needed for the proposed service?  Absent a vetted design
>approach, it won't mean much to have a charter task covering it; in fact
>it will be more appropriate as an IRTF task...

I think you need to be able to modularize in design to get anywhere. What
is actually in the scope of the proposed charter are a set of narrow and
achievable deliverables (at least for the first prong). It is not in the
scope of the charter to design that "proposed service," any more than it
is in the scope of the TLS working group to design web PKI. The TLS work
doesn't have to operationally prove out web PKI in order to get a charter,
and well, if it did, there are enough operational problems with web PKI
that some might argue TLS should never be chartered. However, SSL/TLS have
done a ton of good. Various efforts in the IETF and the industry at large
are working to improve web PKI.

If you'd like to form an IRTF working group to discuss the problems of
scale, diversity and reliability of various credential systems, I won't
stand in your way. The scope of this proposed working group is orthogonal
to that.

>>> I think I'm beginning to understand:  The provider that is giving SIP
>>> service is the one that vouches for its use.  In effect, the provider
>>> has the authority of the number owner, rather than the user to whom the
>>> number is assigned.
>...
>>> That's not subtle; it's quite basic.  It would be like requiring that
>>>my
>>> ISP be the one that vouches for my use of my domain name.
>>
>> If your ISP actually owned your domain name instead of you, sure. If in
>> fact you own your own domain name, RFC4474 lets you (as in, your UA) act
>> as your authentication service. The authentication service is a logical
>> function that can be instantiated by either the UA or an intermediary.
>>Who
>> should do it depends pretty much entirely on who owns the domain name.
>>
>> Do I own the email address "[e-mail]"? No, Neustar owns
>> it.
>
>Number portability changes this. The number does not belong to the
>service provider.

Again, I've just been trying to get us on the same page about what RFC4474
says - then we talk about what it should be amended to say about numbers
(or rather, that's the scope of the proposed work here).

You may know more about number portability than me, but I don't agree with
your assessment of it here. At best, I'd say that number portability in
America allows consumers to choose which carrier "owns" a number. This is
also a reason I keep putting scare quotes around "owns," because the
assumptions of the DNS don't apply to users of telephone numbers, at least
not in our current regulatory environment. If you are a registrant, you
have the authority to configure your zone - that sounds close enough to be
ownership to me (even though the UDRP or ICE can end your ownership under
extreme conditions). If you have a telephone number assigned to you, a
carrier still decides what number it rings.

>>> This sounds like a transitive trust model based on trust amongst
>>>telcos.
>>
>> Not really. example.com gets to vouch for example.com addresses, and the
>
>Unlike email addresses, the relationship between the service provider
>and the user is not built into the identifier.  What you've been
>describing is an unspecified service in the background that establishing
>this relationship.  It's key because it authorizes the provider to vouch
>for use of the number.

What I've been describing is the existing relationship between the service
provider and the user. Agreed that a credential should be able to allow a
service provider to vouch for the end user in some circumstances, just as
the owner of "example.com" vouches for "[e-mail]."

>>>> I'm not sure it's a new cert semantic, or a new trust structure, or
>>>>that
>>>> something needs to be "invented" to support this.
>>>
>>> Feel free to point to instances of each that are deployed and used.
>>
>> The structures that underly trust in the proposed STIR work are simply
>>the
>> extent ones in the telephone network.
>
>By way of considering edge cases, to the extent that this mechanism is
>going to validate uses of numbers for calls that do not originate from
>their home -- such as the mobile physician calling from someone else's
>phone -- the extant trust mechanisms don't cover them.

There are corner cases that are going to be challenging here that we won't
know the right way to address out of the gate. "Legitimate spoofing" is
one where I'm aware of a few possible approaches but I anyway don't yet
know which one would be best. This would be something for the working
group to examine. 
 
>In any event, the considerable barrier to adoption you've just described
>is adoption by all telcos.

I didn't just describe a system that requires adoption by all telcos, not
in the sense you mean.

In so far as all telcos are part of the PSTN where those structures are
codified already in various databases and credentials, telcos are already
part of a numbering authority system. For example, if you are a carrier in
North America, you get number blocks from your national regulator and
interface with databases that let you update routes or perform similar
administrative tasks. You get various kinds of credentials, with various
scopes of authority, to authenticate yourself to these systems.

Incrementally, systems on the Internet could begin to depend on that
authority, if it were projected onto the Internet in some fashion - like
through a CA, for example. It would not require every telco to suddenly
start using it for it to be useful. The STIR proposal also has a second
approach (the fallback mechanism) that tries to build grass-roots, bottom
credentials as well to cover more of the problem space.

>> There are currently number block
>> assignees, delegates of those assignees, and ultimately end users who
>> possess numbers. Databases exist that contain all that information, and
>> credentials exist that reflect those scopes of authority. The proposed
>> work is only to leverage those structures.
>
>Forgive me but I don't see any of that in the charter or discussions so
>far.  It seems to be left as the "then a miracle happens" part of the
>specification.  As such, it isn't possible to evaluate its practicality.

No, what's in the charter is the work that's in the scope of the IETF -
things like fixing RFC4474 so it could contain assertions that cover
telephone numbers. 

The creation of a certificate with a telephone number inside which you
fetch with a web get is not a miracle. It is possible to evaluate its
practicality. 

>On 6/17/2013 12:07 AM, Peterson, Jon wrote:>
>> I think the advantages below, with the exception of 4, would be true
>> of any golden root we created for whatever protocol, be it HTTP or
>> something else. I'm sure I could define an HTTP golden root such that
>
>The real point of practical leverage here is existing deployment.  It's
>easy to 'define' almost anything.  Getting deployment and adequate
>operational service is the hard part.

In the IETF, we define things. The world deploys and operates them. We
need to define things in a way that make it possible that they can be
deployed and operated, sure.

>> the verification service could synthesize the proper fetch request
>> from the URI in the From with an Identity-Info, one that updated in
>> real time so you never needed to worry about revocation, one for
>
>For any existing capability, I'm sure one can define a new service that
>contains it.  The question is what risks and benefits come with that new
>effort?

HTTP is not a "new service." Its trade-offs are fairly well understood.

Jon Peterson
Neustar, Inc,


>
>
>On 6/17/2013 5:03 AM, Henning Schulzrinne wrote:
>> It might be helpful to explicitly distinguish three models,
> > independent of whether the cert is stored in DNS or some HTTP-accessed
> > data store:
>
>Big +1 for this sort of analytic discipline in the effort...
>
>
>d/
>
>-- 
>Dave Crocker
>Brandenburg InternetWorking
>bbiw.net