Subject: [stir] Draft STIR Charter

From: Russ Housley <[email-masked]>
Date: Thu, 11 Jul 2013 10:21:42 -0400

Dear STIR Mail List Participants:

Brian and I have tried to pull together charter text based on the discussion to date.

The closer we can get to consensus on the list before the BOF, the more likely that we can get a WG shortly after Berlin.  To this end, please review and comment on the attached text.  Brian and I will hold the pen for updates to the text.

Russ

= = = = =

Name: Secure Telephone Identity Revisited (stir)
Area: RAI

Chairs: TBD
Area Advisor: Richard Barnes

Mailing list: [email-masked]
To Subscribe: https://www.ietf.org/mailman/listinfo/stir

Over the last decade, a growing set of problems have resulted from the lack of security mechanisms for attesting the origins of real-time communications.  As with email, the claimed source identity of a SIP request is not verified, and this permits unauthorized use of source identities as part of deceptive and coercive activities, such as robocalling (bulk unsolicited commercial communications), vishing (voicemail hacking, and impersonating banks) and swatting (impersonating callers to emergency services to stimulate unwarranted large scale law enforcement deployments).  This working group will define a deployable mechanism to validate the identity of the calling party that can be verified by entities in the path of a call.  

SIP is one of the main VoIP technologies used by parties that want to present an incorrect origination.  A number of previous efforts have tried to secure the origins of SIP communications, including RFC 3325, RFC 4474, and the VIPR working group. To date, however, true validation of the source of SIP calls has not seen any appreciable deployment.  Several factors contributed to this lack of success, including: failure of the problem to be seen as critical at the time; lack of any real means of asserting authority over telephone numbers; misalignment of the mechanisms proposed by RFC 4474 with the complex deployment environment that has emerged for SIP; lack of end-to-end SIP session establishment; and inherent operational problems with a transitive trust model.

Initially, the working group will specify an in-band mechanism to authenticate the originator of a SIP session where the identity being authenticated is a telephone number and the session is established with SIP end to end.  The working group will consider choices for protecting the identity information and the credentials used, but will likely be similar to the methods described in RFC 4474, which employs a signature over a set of information in the SIP headers using a credential assigned to the identity.  In order to be authoritative, credentials used with this mechanism will be derived from existing telephone number assignment and delegation models.  That is, when a telephone number or range of telephone numbers is delegated to an entity, a credential will accompany such delegation.  The mechanism must allow parties who are not delegated a telephone number, but are preauthorized by the entity who is delegated the number, to place calls using the identity.  Expansion of the authentication mechanism to identities using the user@domain form should be considered in the initial design.  After completing the SIP end to end solution, the working group will consider session establishment where there are one or more non-SIP hops, most likely using an out-of-band authentication mechanism.  However, the in-band and out-of-band mechanisms should share as much in common as possible, especially the credentials.

The working group will coordinate with the Security Area on credential management.

The working group will coordinate with other working groups in the RAI Area regarding signaling through existing deployments, including INSIPID.

Authenticated identity is closely linked to privacy, and one frequently comes at the cost of the other. This working group is not chartered to mandate the presence of identity in SIP requests, and to the extent feasible it will find privacy-friendly solutions that leak minimal information about calls to third parties.

Input to working group discussions shall include:

Private Extensions to the Session Initiation Protocol (SIP)
for Asserted Identity within Trusted Networks
RFC 3325

Enhancements for Authenticated Identity Management in the
Session Initiation Protocol (SIP)
RFC 4474

Secure Call Origin Identification
http://tools.ietf.org/html/draft-cooper-iab-secure-origin-00

Secure Origin Identification: Problem Statement, Requirements,
and Roadmap
http://tools.ietf.org/html/draft-peterson-secure-origin-ps-00

Authenticated Identity Management in the Session Initiation
Protocol (SIP)
http://tools.ietf.org/html/draft-jennings-dispatch-rfc4474bis-00

The working group will deliver the following:

- A problem statement detailing the deployment environment and
  situation that motivate work on secure telephone identity

- A mechanism document describing the SIP end-to-end with telephone
   number-based identities 

- A document describing the credentials required to support secure
  telephone identity

- A fallback mechanism to allow out-of-band identity establishment
  during call setup

Milestones

Sep 2013   Submit problem statement for Informational
Nov 2013   Submit RFC4474bis for Proposed Standard
Feb 2014   Submit credential specification for Proposed Standard
Jun 2014   Submit fallback for Proposed Standard

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Thu, 11 Jul 2013 16:56:48 +0000

Russ
Brian,

Are we really doing a RFC4474bis or  something that is 4474-like, but with a smaller scope WRT the first task of " Initially, the working group will specify an in-band mechanism to authenticate the originator of a SIP session where the identity being authenticated is a telephone number and the session is established with SIP end to end. "?

I would appreciate the clarification.

Regards,

Martin 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Thursday, July 11, 2013 10:22 AM
To: [email-masked]
Cc: Richard Barnes; Brian Rosen; Gonzalo Camarillo
Subject: [stir] Draft STIR Charter

Russ

= = = = =

Chairs: TBD

Initially, the working group will specify an in-band mechanism to authenticate the originator of a SIP session where the identity being authenticated is a telephone number and the session is established with SIP end to end.  The working group will consider choices for protecting the identity information and the credentials used, but will likely be similar to the methods described in RFC 4474, which employs a signature over a set of information in the SIP headers using a credential assigned to the identity.  In order to be authoritative, credentials used with this mechanism will be derived from existing telephone number assignment and delegation models.  That is, when a telephone number or range of telephone numbers is delegated to an entity, a credential will accompany such delegation.  The mechanism must allow parties who are not delegated a telephone number, but are preauthorized by the entity who is delegated the number, to place calls using the identity.  Expansion of the
  authentication mechanism to identities using the user@domain form should be considered in the initial design.  After completing the SIP end to end solution, the working group will consider session establishment where there are one or more non-SIP hops, most likely using an out-of-band authentication mechanism.  However, the in-band and out-of-band mechanisms should share as much in common as possible, especially the credentials.

Milestones

_______________________________________________
stir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/stir

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 11 Jul 2013 17:01:24 +0000

The text says:
The working group will consider choices for protecting the identity information and the credentials used, but will likely be similar to the methods described in RFC 4474, which employs a signature over a set of information in the SIP headers using a credential assigned to the identity.

"Consider choices" means we don't have to do anything like 4474 if we don't want to.  "similar to" is 4474-like

I would say it's up to the WG if the RFC replaces 4474 or not, but it certainly has smaller scope than 4474 currently does.

Is that acceptable?

Brian

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Thu, 11 Jul 2013 17:03:21 +0000

Brian,

Yes, but the milestone should reflect that.

Thanks,

Martin 

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]] 
Sent: Thursday, July 11, 2013 1:01 PM
To: DOLLY, MARTIN C
Cc: Russ Housley; [email-masked]; Richard Barnes; Gonzalo Camarillo
Subject: Re: [stir] Draft STIR Charter

The text says:

Is that acceptable?

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 11 Jul 2013 17:08:20 +0000

Ahh, missed that.  Let's change that text to:
Nov 2013   Submit in-band mechanism for Proposed Standard

Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Jul 2013 13:08:40 -0400

> I would say it's up to the WG if the RFC replaces 4474 or not, but it certainly has smaller scope than 4474 currently does.

ISTM the scope is *different* from 4474, not necessarily smaller.
- 4474 only covers email-style addresses, not phone numbers
- this work (at least initially) only covers phone numbers
Trying to decide which is bigger is a useless task.

> Is that acceptable?

I'm not Martin, but IMO yes.

	Thanks,
	Paul

>> Initially, the working group will specify an in-band mechanism to authenticate the originator of a SIP session where the identity being authenticated is a telephone number and the session is established with SIP end to end.  The working group will consider choices for protecting the identity information and the credentials used, but will likely be similar to the methods described in RFC 4474, which employs a signature over a set of information in the SIP headers using a credential assigned to the identity.  In order to be authoritative, credentials used with this mechanism will be derived from existing telephone number assignment and delegation models.  That is, when a telephone number or range of telephone numbers is delegated to an entity, a credential will accompany such delegation.  The mechanism must allow parties who are not delegated a telephone number, but are preauthorized by the entity who is delegated the number, to place calls using the identity.  Expansion of 
 t
>   he

---

From: Dave Crocker <[email-masked]>
Date: Thu, 11 Jul 2013 10:16:05 -0700

On 7/11/2013 10:01 AM, Rosen, Brian wrote:
> The text says:
> The working group will consider choices for protecting the identity information and the credentials used,
 > but will likely be similar to the methods described in RFC 4474, 
which employs a signature over a set of information in the SIP headers 
using a credential assigned to the identity.
> I would say it's up to the WG if the RFC replaces 4474 or not, but it certainly has smaller scope than 4474 currently does.

However "will likely be similar to the methods described in RFC 4474" is 
text that is explicitly and formally biasing.

Worse, there are no criteria that make it possible to know what 'similar 
to the methods in RFC 4474' does and does not mean.  Hence, the text 
actually adds ambiguity to the charter.

At a minimum, it creates an extra barrier to any approach or details 
that differ from 4484, since it will impose a charter-based requirement 
to justify the deviation.

Why is it important to cite 4474 in this way?  In chartering, working 
group management and engineering terms, what is the benefit in having 
that text?  What is lost by eliminating it?

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 11 Jul 2013 17:23:27 +0000

We are trying to limit the scope.

We do have an assumption that we're crypto-signing a set of info from SIP headers using some kind of credential.  We are assuming 4474-like solutions.

That might, in the end, not work, but yes, I think we should have to justify a deviation.  The way the text is written, we don't have to recharter to change the approach.

I think limiting scope and stating intended direction is helpful.  It makes it more of an engineering problem and less of a research effort.

Brian

On Jul 11, 2013, at 1:16 PM, Dave Crocker <[email-masked]>
 wrote:

> > but will likely be similar to the methods described in RFC 4474, which employs a signature over a set of information in the SIP headers using a credential assigned to the identity.
>> 
> However "will likely be similar to the methods described in RFC 4474" is text that is explicitly and formally biasing.
> 
> Worse, there are no criteria that make it possible to know what 'similar to the methods in RFC 4474' does and does not mean.  Hence, the text actually adds ambiguity to the charter.
> 
> At a minimum, it creates an extra barrier to any approach or details that differ from 4484, since it will impose a charter-based requirement to justify the deviation.
> 
> Why is it important to cite 4474 in this way?  In chartering, working group management and engineering terms, what is the benefit in having that text?  What is lost by eliminating it?
> 
> d/
> -- 
> Dave Crocker

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 11 Jul 2013 17:28:25 +0000

>>
>>
>>
>> I would say it's up to the WG if the RFC replaces 4474 or not, but it
>>certainly has smaller scope than 4474 currently does.
>

Not true. See Section 11; RFC4474 does contain some (unhelpful) guidance
about telephone numbers. This is guidance STIR will be replacing, no
matter what.

>- this work (at least initially) only covers phone numbers

The scope of this proposed working group is to solve the impersonation
problems associated with robocalling, yes, but that doesn't necessarily
mean that a work we do to address that problems won't also have
applicability to other problems.

If we still believe that some SIP requests will originate from greenfield
SIP URIs, then I think we need a story about verification service behavior
that's going to at least acknowledge both of these cases exist. If a
service that validates for telephone numbers could conceivably get a
request from a non-TN URI, I think at least we need to have a hook for how
it will behave in that case. If the answer is, "do roughly the procedures
in RFC4474," then that's telling for how we should structure the work.

Moreover, it's not like the proposed reductions to the scope to the
digest-string shouldn't apply equally to the greenfield SIP URI case as
the TN case. If those changes were unique to the TN case, I could see
arguing this should be separate work. Again, we're going to want
implementations that do identity to not use the digest-string of RFC4474
but instead use the one coming out of this work.

But that said, I don't think we need the milestone in the charter to say
"RFC4474bis," so I'm fine if it doesn't. There are however good reasons
for the work here to be an RFC4474bis.

Jon Peterson
Neustar, Inc.

>>> Are we really doing a RFC4474bis or  something that is 4474-like, but
>>>with a smaller scope WRT the first task of " Initially, the working
>>>group will specify an in-band mechanism to authenticate the originator
>>>of a SIP session where the identity being authenticated is a telephone
>>>number and the session is established with SIP end to end. "?
>>>
>>> The closer we can get to consensus on the list before the BOF, the
>>>more likely that we can get a WG shortly after Berlin.  To this end,
>>>please review and comment on the attached text.  Brian and I will hold
>>>the pen for updates to the text.
>>>
>>> Russ
>>>
>>> = = = = =
>>>
>>> Over the last decade, a growing set of problems have resulted from the
>>>lack of security mechanisms for attesting the origins of real-time
>>>communications.  As with email, the claimed source identity of a SIP
>>>request is not verified, and this permits unauthorized use of source
>>>identities as part of deceptive and coercive activities, such as
>>>robocalling (bulk unsolicited commercial communications), vishing
>>>(voicemail hacking, and impersonating banks) and swatting
>>>(impersonating callers to emergency services to stimulate unwarranted
>>>large scale law enforcement deployments).  This working group will
>>>define a deployable mechanism to validate the identity of the calling
>>>party that can be verified by entities in the path of a call.
>>>
>>> SIP is one of the main VoIP technologies used by parties that want to
>>>present an incorrect origination.  A number of previous efforts have
>>>tried to secure the origins of SIP communications, including RFC 3325,
>>>RFC 4474, and the VIPR working group. To date, however, true validation
>>>of the source of SIP calls has not seen any appreciable deployment.
>>>Several factors contributed to this lack of success, including: failure
>>>of the problem to be seen as critical at the time; lack of any real
>>>means of asserting authority over telephone numbers; misalignment of
>>>the mechanisms proposed by RFC 4474 with the complex deployment
>>>environment that has emerged for SIP; lack of end-to-end SIP session
>>>establishment; and inherent operational problems with a transitive
>>>trust model.
>>>
>>> Initially, the working group will specify an in-band mechanism to
>>>authenticate the originator of a SIP session where the identity being
>>>authenticated is a telephone number and the session is established with
>>>SIP end to end.  The working group will consider choices for protecting
>>>the identity information and the credentials used, but will likely be
>>>similar to the methods described in RFC 4474, which employs a signature
>>>over a set of information in the SIP headers using a credential
>>>assigned to the identity.  In order to be authoritative, credentials
>>>used with this mechanism will be derived from existing telephone number
>>>assignment and delegation models.  That is, when a telephone number or
>>>range of telephone numbers is delegated to an entity, a credential will
>>>accompany such delegation.  The mechanism must allow parties who are
>>>not delegated a telephone number, but are preauthorized by the entity
>>>who is delegated the number, to place calls using the identity.
>>>Expansion of 
> t
>>   he
>>>   authentication mechanism to identities using the user@domain form
>>>should be considered in the initial design.  After completing the SIP
>>>end to end solution, the working group will consider session
>>>establishment where there are one or more non-SIP hops, most likely
>>>using an out-of-band authentication mechanism.  However, the in-band
>>>and out-of-band mechanisms should share as much in common as possible,
>>>especially the credentials.
>>>
>>> The working group will coordinate with other working groups in the RAI
>>>Area regarding signaling through existing deployments, including
>>>INSIPID.
>>>
>>> Authenticated identity is closely linked to privacy, and one
>>>frequently comes at the cost of the other. This working group is not
>>>chartered to mandate the presence of identity in SIP requests, and to
>>>the extent feasible it will find privacy-friendly solutions that leak
>>>minimal information about calls to third parties.
>>>

---

From: Dave Crocker <[email-masked]>
Date: Thu, 11 Jul 2013 10:37:29 -0700

On 7/11/2013 10:23 AM, Rosen, Brian wrote:
> We do have an assumption that we're crypto-signing a set of info from
> SIP headers using some kind of credential.  We are assuming 4474-like
> solutions.
>
> That might, in the end, not work, but yes, I think we should have to
> justify a deviation.  The way the text is written, we don't have to
> recharter to change the approach.
>
> I think limiting scope and stating intended direction is helpful.  It
> makes it more of an engineering problem and less of a research
> effort.

Limiting scope is good.

Unfortunately the cited text doesn't really achieve that.  Rhere's no 
obvious and clear meaning to "similar to 4474".

On the other hand, the phrase in your response is, I think, extremely 
clear and helpful.  Cast as charterese, it would be something like:

      The solution is expected to be based on the use of cryptographic 
signing of a set of SIP headers, with authentication of the associated 
identifier employing some type of credential mechanism.

I think such language is both technically meaningful and politically 
neutral, in that it entirely avoids any of the current set of 
controversies on the list.

d/

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 11 Jul 2013 18:54:53 +0100

Hi Russ,

I think this looks pretty good. A few wordsmithing changes
and a question below but I have one addition to suggest:

Somewhere this should say that the solution chosen needs to
have an acceptable overhead at both signer and verifer or
else it also won't be deployed. There may be some on here
who could suggest indicative timing or networking constraints
(e.g. not having to do ~5 OCSP transactions to possibly
anywhere in the world) and if so, that'd be a good thing
to include IMO.

On 07/11/2013 03:21 PM, Russ Housley wrote:
> please review and comment on the attached text.  Brian and I will
> hold the pen for updates to the text.
> 
> Russ
> 
> = = = = =
> 
> Name: Secure Telephone Identity Revisited (stir) Area: RAI
> 
> Chairs: TBD Area Advisor: Richard Barnes
> 
> Mailing list: [email-masked] To Subscribe:
> Over the last decade, a growing set of problems have resulted from
> the lack of security mechanisms for attesting the origins of
> real-time communications.  As with email, the claimed source identity
> of a SIP request is not verified, and this permits unauthorized use
> of source identities as part of deceptive and coercive activities,
> such as robocalling (bulk unsolicited commercial communications),
> vishing (voicemail hacking, and impersonating banks) and swatting
> tried to secure the origins of SIP communications, including RFC
> 3325, RFC 4474, and the VIPR working group. To date, however, true
> validation of the source of SIP calls has not seen any appreciable
> deployment.  Several factors contributed to this lack of success,
> including: failure of the problem to be seen as critical at the time;
> lack of any real means of asserting authority over telephone numbers;
> misalignment of the mechanisms proposed by RFC 4474 with the complex
> deployment environment that has emerged for SIP; lack of end-to-end
> SIP session establishment; and inherent operational problems with a
> transitive trust model.
> 
> authenticated is a telephone number and the session is established
> with SIP end to end.  The working group will consider choices for
> protecting the identity information and the credentials used, but
> will likely be similar to the methods described in RFC 4474, which
> employs a signature over a set of information in the SIP headers

I suggest replacing the above with

"will likely be based on a digital signature mechanism that is
cryptographically similar to the one described in RFC 4474 and
where the signature continues to be represented in SIP headers."

Saying "methods" and 4474 is a bit vague and could be read to
mean "s/mime-based" or "cms based" or "x.509 based" whereas
what I think we want is just to say its a signature.

Similarly "assigned to the identity" is very ambiguous and
probably better just omitted for now.

>  In order to be
> authoritative, credentials used with this mechanism will be derived
> from existing telephone number assignment and delegation models.

No specific change suggested but are we using credential here to
mean the private key or a (set of) TN(s) associated with a
public key? I think it ought be the latter.

> That is, when a telephone number or range of telephone numbers is
> delegated to an entity, a credential will accompany such delegation.

That's problematic with either definition of credential. I think
it'd be ok to say:

  That is, when a telephone number or range of telephone numbers is
  delegated to an entity, relevant credentials will be generated (or
  modified) to reflect such delegation.

> The mechanism must allow parties who are not delegated a telephone
> number, but are preauthorized by the entity who is delegated the
> number, to place calls using the identity.  

No specific change suggested, but I've always wondered if this
requirement is real. I'd argue enough good would be done without
try to stretch for this. But I defer to those who know more about
the application.

> Expansion of the
> should be considered in the initial design.  

To be honest, I didn't read that thread (one too many:-) but I'm
surprised that this is to be part of the initial design. But
"considered" is sort of weasel-wordy so I'm not sure what's
really meant - what is "considered" meant to mean here?

Cheers,
S.

> After completing the SIP
> and out-of-band mechanisms should share as much in common as
> possible, especially the credentials.
> 
> The working group will coordinate with other working groups in the
> RAI Area regarding signaling through existing deployments, including
> INSIPID.
> 
> Private Extensions to the Session Initiation Protocol (SIP) for
> Asserted Identity within Trusted Networks RFC 3325
> 
> Enhancements for Authenticated Identity Management in the Session
> Initiation Protocol (SIP) RFC 4474
> 
> Secure Origin Identification: Problem Statement, Requirements, and
> Roadmap 
> Authenticated Identity Management in the Session Initiation Protocol
> (SIP) 
> Sep 2013   Submit problem statement for Informational Nov 2013
> Submit RFC4474bis for Proposed Standard Feb 2014   Submit credential
> specification for Proposed Standard Jun 2014   Submit fallback for
> Proposed Standard
> 
> _______________________________________________ stir mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/stir
> 
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 11 Jul 2013 18:11:00 +0000

Inline

> anywhere in the world) and if so, that'd be a good thing
I'll think about how to add some text for this.  I think "deployable" is really, really important in this effort.

> probably better just omitted for now.
We're discussing changes to this text on this thread.

> public key? I think it ought be the latter.
Of  course it's both - the sender needs the private key to sign and the verifier needs the public key to verify, so "credentials" means both.
We're trying not to start with a firm assumption of X.509 certs, so it's intentionally somewhat vague.
A credential is associated with a (set of) TN(s).

>  modified) to reflect such delegation.
I am fine making this edit

> try to stretch for this. But I defer to those who know more about
It's very real and we could not deploy without it.  An easy example is a contracted outbound call center operating on behalf of your bank.  The bank wants it's number used as the calling party number, not the call center's trunk assignment.  Among other things, it wants a return call resulting from the outbound call.  The bank explicitly permits this.  In our terms, it would do another level of delegation.

> really meant - what is "considered" meant to mean here?
The problem we're solving is existing robocalling, vishing and swatting, which presently is TN based.  I think we all want to anticipate greenfield sip uri's, lest we fix one problem and cause another.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 11 Jul 2013 19:23:16 +0100

Hiya,

Sorry one other thing I forgot before. There was a longish thread
on what's a phone number (full E.164, local etc.) that I thought
did reach a sort of conclusion that full E.164 will be the thing
that is signed. If that's your and Russ' reading of the result
then it might be good to say that too. If you and Russ are less
sure then I guess the current text is right.

And a little more below...

On 07/11/2013 07:11 PM, Rosen, Brian wrote:
> Inline On Jul 11, 2013, at 1:54 PM, Stephen Farrell
> <[email-masked]> wrote:
> 
>> 
>> Hi Russ,
>> 
>> I think this looks pretty good. A few wordsmithing changes and a
>> question below but I have one addition to suggest:
>> 
>> Somewhere this should say that the solution chosen needs to have an
>> acceptable overhead at both signer and verifer or else it also
>> won't be deployed. There may be some on here who could suggest
>> indicative timing or networking constraints (e.g. not having to do
>> ~5 OCSP transactions to possibly anywhere in the world) and if so,
>> that'd be a good thing to include IMO.
> I'll think about how to add some text for this.  I think "deployable"
> is really, really important in this effort.

Fully agree and look forward to seeing that text.

>>> The closer we can get to consensus on the list before the BOF,
>>> the more likely that we can get a WG shortly after Berlin.  To
>>> this end, please review and comment on the attached text.  Brian
>>> and I will hold the pen for updates to the text.
>>> 
>>> Russ
>>> 
>>> = = = = =
>>> 
>>> Over the last decade, a growing set of problems have resulted
>>> from the lack of security mechanisms for attesting the origins
>>> of real-time communications.  As with email, the claimed source
>>> identity of a SIP request is not verified, and this permits
>>> unauthorized use of source identities as part of deceptive and
>>> coercive activities, such as robocalling (bulk unsolicited
>>> commercial communications), vishing (voicemail hacking, and
>>> impersonating banks) and swatting (impersonating callers to
>>> emergency services to stimulate unwarranted large scale law
>>> enforcement deployments).  This working group will define a
>>> deployable mechanism to validate the identity of the calling 
>>> SIP is one of the main VoIP technologies used by parties that
>>> want to present an incorrect origination.  A number of previous
>>> efforts have tried to secure the origins of SIP communications,
>>> including RFC 3325, RFC 4474, and the VIPR working group. To
>>> date, however, true validation of the source of SIP calls has not
>>> seen any appreciable deployment.  Several factors contributed to
>>> this lack of success, including: failure of the problem to be
>>> seen as critical at the time; lack of any real means of asserting
>>> authority over telephone numbers; misalignment of the mechanisms
>>> proposed by RFC 4474 with the complex deployment environment that
>>> has emerged for SIP; lack of end-to-end SIP session
>>> establishment; and inherent operational problems with a 
>>> transitive trust model.
>>> 
>>> Initially, the working group will specify an in-band mechanism
>>> to authenticate the originator of a SIP session where the
>>> identity being authenticated is a telephone number and the
>>> session is established with SIP end to end.  The working group
>>> will consider choices for protecting the identity information and
>>> the credentials used, but will likely be similar to the methods
>>> described in RFC 4474, which employs a signature over a set of
>>> information in the SIP headers using a credential assigned to the
>>> identity.
>> 
>> Saying "methods" and 4474 is a bit vague and could be read to mean
>> "s/mime-based" or "cms based" or "x.509 based" whereas what I think
>> we want is just to say its a signature.
>> 
>> Similarly "assigned to the identity" is very ambiguous and probably
>> better just omitted for now.

Yeah. Consider the above another suggestion along the lines
of what (I think) Dave was getting at (I think - I've been
known to get that wrong before:-)

>>> In order to be authoritative, credentials used with this
>>> mechanism will be derived from existing telephone number
>>> assignment and delegation models.
>> 
>> mean the private key or a (set of) TN(s) associated with a public
>> key? I think it ought be the latter.
> Of  course it's both - the sender needs the private key to sign and
> the verifier needs the public key to verify, so "credentials" means
> both. We're trying not to start with a firm assumption of X.509
> certs, so it's intentionally somewhat vague. A credential is
> associated with a (set of) TN(s).

Probably best to leave the precise definition to the WG so I
won't quibble with the above (yet:-).

>>> That is, when a telephone number or range of telephone numbers
>>> is delegated to an entity, a credential will accompany such
>>> delegation.
>> 

Great.

>>> The mechanism must allow parties who are not delegated a
>>> telephone number, but are preauthorized by the entity who is
>>> delegated the number, to place calls using the identity.
>> 
> It's very real and we could not deploy without it.  An easy example
> is a contracted outbound call center operating on behalf of your
> bank.  The bank wants it's number used as the calling party number,
> not the call center's trunk assignment.  Among other things, it wants
> a return call resulting from the outbound call.  The bank explicitly
> permits this.  In our terms, it would do another level of
> delegation.

Fair enough.

> 
> 
>> 
>>> Expansion of the authentication mechanism to identities using the
>>> user@domain form should be considered in the initial design.
>> 
>> "considered" is sort of weasel-wordy so I'm not sure what's really
>> meant - what is "considered" meant to mean here?
> The problem we're solving is existing robocalling, vishing and
> swatting, which presently is TN based.  I think we all want to
> anticipate greenfield sip uri's, lest we fix one problem and cause
> another.

So your response doesn't help me interpret "considered." Maybe
it is meant as weasel-wording and sometimes that is the right
thing to do, but I suspect it reads a bit too strong - as if
the WG are gonna spend a lot of time on non-E.164 names so I'd
say weakening it at least and ideally being more precise about
what "considered" means would be good and might avoid later
problems.

Cheers,
S.

> 
>> 
>> Cheers, S.
>> 
>>> After completing the SIP end to end solution, the working group
>>> will consider session establishment where there are one or more
>>> non-SIP hops, most likely using an out-of-band authentication
>>> mechanism.  However, the in-band and out-of-band mechanisms
>>> should share as much in common as possible, especially the
>>> credentials.
>>> 
>>> The working group will coordinate with other working groups in
>>> the RAI Area regarding signaling through existing deployments,
>>> including INSIPID.
>>> 
>>> frequently comes at the cost of the other. This working group is
>>> not chartered to mandate the presence of identity in SIP
>>> requests, and to the extent feasible it will find
>>> privacy-friendly solutions that leak minimal information about
>>> calls to third parties.
>>> 
>>> Session Initiation Protocol (SIP) RFC 4474
>>> 
>>> - A mechanism document describing the SIP end-to-end with
>>> telephone number-based identities
>>> 
>>> - A document describing the credentials required to support
>>> secure telephone identity
>>> 
>>> - A fallback mechanism to allow out-of-band identity
>>> establishment during call setup
>>> 
>>> Milestones
>>> 
>>> Submit RFC4474bis for Proposed Standard Feb 2014   Submit
>>> credential specification for Proposed Standard Jun 2014   Submit
>>> fallback for Proposed Standard
>>>

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 11 Jul 2013 18:29:06 +0000

So maybe where we say "where the identity being authenticated is a telephone number" add "in e.164 format"?

Brian

---

From: Dave Crocker <[email-masked]>
Date: Thu, 11 Jul 2013 11:45:24 -0700

> I'll think about how to add some text for this.  I think "deployable" is really, really important in this effort.

I assume Stephen means computational overhead.  There's also the matter 
of administrative overhead, which has been a much higher barrier to 
adoption for DKIM and DMARC.

To say "acceptable" invites debate about what it means.

If the charter simply says "the design will attend to computational and 
administrative overhead, and exchange latency", it raises the necessary 
flags while avoiding concern for criteria in the charter.

d/

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 11 Jul 2013 19:53:23 +0100

> telephone number" add "in e.164 format"?

Better all right. Some people were saying "full e.164" which I
guess means including country code and a +, which'd be even
better, if its not already implied in e.164.

S

> 
> Brian
> 
> On Jul 11, 2013, at 2:23 PM, Stephen Farrell
>> that is signed. If that's your and Russ' reading of the result then
>> it might be good to say that too. If you and Russ are less sure
>> then I guess the current text is right.
>> 
>>>> I think this looks pretty good. A few wordsmithing changes and
>>>> a question below but I have one addition to suggest:
>>>> 
>>>> have an acceptable overhead at both signer and verifer or else
>>>> it also won't be deployed. There may be some on here who could
>>>> suggest indicative timing or networking constraints (e.g. not
>>>> having to do ~5 OCSP transactions to possibly anywhere in the
>>>> world) and if so, that'd be a good thing to include IMO.
>>> I'll think about how to add some text for this.  I think
>>> "deployable" is really, really important in this effort.
>> 
>>>>> The closer we can get to consensus on the list before the
>>>>> BOF, the more likely that we can get a WG shortly after
>>>>> Berlin.  To this end, please review and comment on the
>>>>> attached text.  Brian and I will hold the pen for updates to
>>>>> the text.
>>>>> 
>>>>> Russ
>>>>> 
>>>>> = = = = =
>>>>> 
>>>>> Over the last decade, a growing set of problems have
>>>>> resulted from the lack of security mechanisms for attesting
>>>>> the origins of real-time communications.  As with email, the
>>>>> claimed source identity of a SIP request is not verified, and
>>>>> this permits unauthorized use of source identities as part of
>>>>> deceptive and coercive activities, such as robocalling (bulk
>>>>> unsolicited commercial communications), vishing (voicemail
>>>>> hacking, and impersonating banks) and swatting (impersonating
>>>>> callers to emergency services to stimulate unwarranted large
>>>>> scale law enforcement deployments).  This working group will
>>>>> define a deployable mechanism to validate the identity of the
>>>>> calling party that can be verified by entities in the path of
>>>>> a call.
>>>>> 
>>>>> SIP is one of the main VoIP technologies used by parties
>>>>> that want to present an incorrect origination.  A number of
>>>>> previous efforts have tried to secure the origins of SIP
>>>>> communications, including RFC 3325, RFC 4474, and the VIPR
>>>>> working group. To date, however, true validation of the
>>>>> source of SIP calls has not seen any appreciable deployment.
>>>>> Several factors contributed to this lack of success,
>>>>> including: failure of the problem to be seen as critical at
>>>>> the time; lack of any real means of asserting authority over
>>>>> telephone numbers; misalignment of the mechanisms proposed by
>>>>> RFC 4474 with the complex deployment environment that has
>>>>> emerged for SIP; lack of end-to-end SIP session 
>>>>> Initially, the working group will specify an in-band
>>>>> mechanism to authenticate the originator of a SIP session
>>>>> where the identity being authenticated is a telephone number
>>>>> and the session is established with SIP end to end.  The
>>>>> working group will consider choices for protecting the
>>>>> identity information and the credentials used, but will
>>>>> likely be similar to the methods described in RFC 4474, which
>>>>> employs a signature over a set of information in the SIP
>>>>> headers using a credential assigned to the identity.
>>>> 
>> Yeah. Consider the above another suggestion along the lines of what
>> (I think) Dave was getting at (I think - I've been known to get
>> that wrong before:-)
>> 
>>>> No specific change suggested but are we using credential here
>>>> to mean the private key or a (set of) TN(s) associated with a
>>> Of  course it's both - the sender needs the private key to sign
>>> and the verifier needs the public key to verify, so "credentials"
>>> means both. We're trying not to start with a firm assumption of
>>> X.509 certs, so it's intentionally somewhat vague. A credential
>>> is associated with a (set of) TN(s).
>> 
>> Probably best to leave the precise definition to the WG so I won't
>> quibble with the above (yet:-).
>> 
>>>>> That is, when a telephone number or range of telephone
>>>>> numbers is delegated to an entity, a credential will
>>>>> accompany such delegation.
>>>> 
>>>> That's problematic with either definition of credential. I
>>>> think it'd be ok to say:
>>>> 
>>>> is delegated to an entity, relevant credentials will be
>>>> generated (or modified) to reflect such delegation.
>>>>  requirement is real. I'd argue enough good would be done
>>>> without try to stretch for this. But I defer to those who know
>>>> more about the application.
>>> It's very real and we could not deploy without it.  An easy
>>> example is a contracted outbound call center operating on behalf
>>> of your bank.  The bank wants it's number used as the calling
>>> party number, not the call center's trunk assignment.  Among
>>> other things, it wants a return call resulting from the outbound
>>> call.  The bank explicitly permits this.  In our terms, it would
>>> do another level of delegation.
>> 
>> Fair enough.
>> 
>>> 
>>> 
>>>> 
>>>>> Expansion of the authentication mechanism to identities using
>>>>> the user@domain form should be considered in the initial
>>>>> design.
>>>> 
>>>> To be honest, I didn't read that thread (one too many:-) but
>>>> I'm surprised that this is to be part of the initial design.
>>>> But "considered" is sort of weasel-wordy so I'm not sure what's
>>> anticipate greenfield sip uri's, lest we fix one problem and
>>> cause another.
>> 
>> So your response doesn't help me interpret "considered." Maybe it
>> is meant as weasel-wording and sometimes that is the right thing to
>> do, but I suspect it reads a bit too strong - as if the WG are
>> gonna spend a lot of time on non-E.164 names so I'd say weakening
>> it at least and ideally being more precise about what "considered"
>> means would be good and might avoid later problems.
>> 
>> Cheers, S.
>> 
>>> 
>>>> 
>>>> Cheers, S.
>>>> 
>>>>> After completing the SIP end to end solution, the working
>>>>> group will consider session establishment where there are one
>>>>> or more non-SIP hops, most likely using an out-of-band
>>>>> authentication mechanism.  However, the in-band and
>>>>> out-of-band mechanisms should share as much in common as
>>>>> The working group will coordinate with other working groups
>>>>> in the RAI Area regarding signaling through existing
>>>>> deployments, including INSIPID.
>>>>> 
>>>>>  frequently comes at the cost of the other. This working
>>>>> group is not chartered to mandate the presence of identity in
>>>>> SIP requests, and to the extent feasible it will find 
>>>>> privacy-friendly solutions that leak minimal information
>>>>> about calls to third parties.
>>>>> 
>>>>> for Asserted Identity within Trusted Networks RFC 3325
>>>>> 
>>>>> Secure Origin Identification: Problem Statement,
>>>>> Requirements, and Roadmap 
The working group will deliver the following:
>>>>> 
>>>>> - A problem statement detailing the deployment environment
>>>>> and situation that motivate work on secure telephone
>>>>> identity
>>>>> 
>>>>> Sep 2013   Submit problem statement for Informational Nov
>>>>> 2013 Submit RFC4474bis for Proposed Standard Feb 2014
>>>>> Submit credential specification for Proposed Standard Jun
>>>>> 2014   Submit fallback for Proposed Standard
>>>>> 
>>>>> _______________________________________________ stir mailing
>>>>> list [email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 11 Jul 2013 19:56:53 +0100

> flags while avoiding concern for criteria in the charter.

Something like that'd be a good improvement I think. The more
concrete it can be, without diving into specific solutions the
better it'd be as well IMO.

But in asking for more, I'm assuming that there are accepted and
reasonably well understood limits to those types of overhead and
maybe there aren't.

S.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 11 Jul 2013 19:00:28 +0000

E.164 implies full phone number.

>From E.164, Section 6.2:

The international ITU-T E.164-number is composed of a variable number of decimal digits
arranged in specific code fields. The international ITU-T E.164-number code fields are the country
code (CC) and remaining fields are specific to the use being made of the international ITU-T E.164
number as shown in Figures 1 to 5.
A numbering plan does not include prefixes, suffixes, and additional information required to
complete a call.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Thursday, July 11, 2013 2:53 PM
To: Rosen, Brian
Cc: Richard Barnes; <[email-masked]>; Russ Housley; Gonzalo Camarillo
Subject: Re: [stir] Draft STIR Charter

> telephone number" add "in e.164 format"?

Better all right. Some people were saying "full e.164" which I guess means including country code and a +, which'd be even better, if its not already implied in e.164.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 11 Jul 2013 12:09:45 -0700

> reasonably well understood limits to those types of overhead and

My understanding is that for DKIM, most/all sites implementing it to 
sign all outgoing mail have not had to increase their processing 
infrastructure at all.  As with all financial predictions, past 
performance is no guarantee of...

In any event, one purpose of the suggested language is to defer the 
question of any specific numbers, limits, etc., to the wg.

d/

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 11 Jul 2013 19:10:45 +0000

Getting technical:
What we're describing is an "international ITU-T E.164-number for geographic areas", which "is composed of decimal digits arranged in two code fields: the country code (CC) and the national (significant) number N(S)N"

The "+" convention is actually not part of e.164, but is a very common way to denote that the digit string is an E.1640-number for geographic areas.

Brian

---

From: Dave Crocker <[email-masked]>
Date: Thu, 11 Jul 2013 12:11:38 -0700

> A numbering plan does not include prefixes, suffixes, and additional information required to

Sounds like a globally-unique string, on a par with FQDN.

It might be worth having the charter note the mapping function that will 
often be required, to convert a local-form of telephone number in the 
 From field to it's standardized E.164 form.

d/

---

From: "Dwight, Timothy M \(Tim\)" <[email-masked]>
Date: Thu, 11 Jul 2013 15:13:35 -0400

How about "International E.164 number"?  That's the phrase actually used in Rec. E.164 to refer to the combination of Country Code and National Significant Number.

The practice of preceding an International E.164 number with a '+' comes from Rec. E.123, "Notation for national and international telephone numbers, e-mail addresses and web addresses".  E.123 addresses how certain types of addresses should be expressed, for maximum clarity.  It refers to the '+' symbol, by the way, as the "International prefix symbol".  In principle the '+ is not part of the number, it is a "visual clue" to the reader, reminding him or her to dial the international prefix (e.g., '01' in the U.S.).

tim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Thursday, July 11, 2013 1:53 PM
To: Rosen, Brian
Cc: Richard Barnes; <[email-masked]>; Russ Housley; Gonzalo Camarillo
Subject: Re: [stir] Draft STIR Charter

S

>> Sorry one other thing I forgot before. There was a longish thread on 
>> what's a phone number (full E.164, local etc.) that I thought did 
>> reach a sort of conclusion that full E.164 will be the thing that is 
>> signed. If that's your and Russ' reading of the result then it might 
>> be good to say that too. If you and Russ are less sure then I guess 
>> the current text is right.
>> 
>>>> ~5 OCSP transactions to possibly anywhere in the
>>>>> more likely that we can get a WG shortly after Berlin.  To this 
>>>>> end, please review and comment on the attached text.  Brian and I 
>>>>> will hold the pen for updates to the text.
>>>>> 
>>>>> Russ
>>>>> 
>>>>> = = = = =
>>>>> 
>>>>> real-time communications.  As with email, the claimed source 
>>>>> deployable mechanism to validate the identity of the calling party 
>>>>> that can be verified by entities in the path of a call.
>>>>> 
>>>>> SIP is one of the main VoIP technologies used by parties that want 
>>>>> to present an incorrect origination.  A number of previous efforts 
>>>>> have tried to secure the origins of SIP communications, including 
>>>>> RFC 3325, RFC 4474, and the VIPR working group. To date, however, 
>>>>> true validation of the source of SIP calls has not seen any 
>>>>> appreciable deployment.
>>>>> including: failure of the problem to be seen as critical at the 
>>>>> time; lack of any real means of asserting authority over telephone 
>>>>> numbers; misalignment of the mechanisms proposed by RFC 4474 with 
>>>>> the complex deployment environment that has emerged for SIP; lack 
>>>>> of end-to-end SIP session establishment; and inherent operational 
>>>>> problems with a transitive trust model.
>>>>> 
>>>>> authenticate the originator of a SIP session where the identity 
>>>>> being authenticated is a telephone number and the session is 
>>>>> established with SIP end to end.  The working group will consider 
>>>>> choices for protecting the identity information and the 
>>>>> credentials used, but will likely be similar to the methods 
>> (I think) Dave was getting at (I think - I've been known to get that 
>> wrong before:-)
>> 
>>>>> In order to be authoritative, credentials used with this mechanism 
>>>>> will be derived from existing telephone number assignment and 
>>>>> delegation models.
>>>> 
>>> the verifier needs the public key to verify, so "credentials"
>>> X.509 certs, so it's intentionally somewhat vague. A credential is 
>>> not the call center's trunk assignment.  Among other things, it 
>>> wants a return call resulting from the outbound call.  The bank 
>>> explicitly permits this.  In our terms, it would do another level of 
>>> delegation.
>> 
>> Fair enough.
>> 
>>> 
>>> 
>>>> 
>>>> surprised that this is to be part of the initial design.
>> So your response doesn't help me interpret "considered." Maybe it is 
>> meant as weasel-wording and sometimes that is the right thing to do, 
>> but I suspect it reads a bit too strong - as if the WG are gonna 
>> spend a lot of time on non-E.164 names so I'd say weakening it at 
>> least and ideally being more precise about what "considered"
>>>>> mechanism.  However, the in-band and out-of-band mechanisms should 
>>>>> share as much in common as possible, especially the credentials.
>>>>> 
>>>>> RAI Area regarding signaling through existing deployments, 
>>>>> including INSIPID.
>>>>> 
>>>>> not chartered to mandate the presence of identity in SIP requests, 
>>>>> and to the extent feasible it will find privacy-friendly solutions 
>>>>> that leak minimal information about calls to third parties.
>>>>> 
The working group will deliver the following:
>>>>> 2013 Submit RFC4474bis for Proposed Standard Feb 2014 Submit 
>>>>> credential specification for Proposed Standard Jun

---

From: Michael Hammer <[email-masked]>
Date: Thu, 11 Jul 2013 19:17:32 +0000

We could refer to the use of associated delimiters/tags, such as the "+" as
needed.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Dwight, Timothy M (Tim)
Sent: Thursday, July 11, 2013 3:14 PM
To: Stephen Farrell; Rosen, Brian
Cc: Richard Barnes; <[email-masked]>; Russ Housley; Gonzalo Camarillo
Subject: Re: [stir] Draft STIR Charter

How about "International E.164 number"?  That's the phrase actually used in
Rec. E.164 to refer to the combination of Country Code and National
Significant Number.

The practice of preceding an International E.164 number with a '+' comes
from Rec. E.123, "Notation for national and international telephone numbers,
e-mail addresses and web addresses".  E.123 addresses how certain types of
addresses should be expressed, for maximum clarity.  It refers to the '+'
symbol, by the way, as the "International prefix symbol".  In principle the
'+ is not part of the number, it is a "visual clue" to the reader, reminding
him or her to dial the international prefix (e.g., '01' in the U.S.).

tim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stephen Farrell
Sent: Thursday, July 11, 2013 1:53 PM
To: Rosen, Brian
Cc: Richard Barnes; <[email-masked]>; Russ Housley; Gonzalo Camarillo
Subject: Re: [stir] Draft STIR Charter

> telephone number" add "in e.164 format"?

Better all right. Some people were saying "full e.164" which I guess means
including country code and a +, which'd be even better, if its not already
implied in e.164.

S

---

From: Michael Hammer <[email-masked]>
Date: Thu, 11 Jul 2013 19:20:22 +0000

It is more than just computation.  It is the question of call setup time,
which is very important for telephony.
You don't want to have people hang up and dial again and again because they
think the system is not working right.
It is a quality of experience measure.  We don't want the cure to be worse
than the disease.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave
Crocker
Sent: Thursday, July 11, 2013 2:45 PM
To: Rosen, Brian
Cc: Richard Barnes; <[email-masked]>; Russ Housley; Gonzalo Camarillo;
Stephen Farrell
Subject: Re: [stir] Draft STIR Charter

On 7/11/2013 11:11 AM, Rosen, Brian wrote:
>> acceptable overhead at both signer and verifer or else it also won't 
>> be deployed. There may be some on here who could suggest indicative 
>> timing or networking constraints (e.g. not having to do ~5 OCSP 
>> transactions to possibly anywhere in the world) and if so, that'd be 
>> a good thing to include IMO.

I assume Stephen means computational overhead.  There's also the matter of
administrative overhead, which has been a much higher barrier to adoption
for DKIM and DMARC.

d/

---

From: "Dwight, Timothy M \(Tim\)" <[email-masked]>
Date: Thu, 11 Jul 2013 15:22:55 -0400

Henning,

I think what you describe is what Rec. E.164 calls an International E.164 number.  It also discusses National (Significant) Numbers, which are the International E.164 number minus the Country Code.

tim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: Thursday, July 11, 2013 2:00 PM
To: 'Stephen Farrell'; Rosen, Brian
Cc: Richard Barnes; <[email-masked]>; Russ Housley; Gonzalo Camarillo
Subject: Re: [stir] Draft STIR Charter

>From E.164, Section 6.2:

The international ITU-T E.164-number is composed of a variable number of decimal digits arranged in specific code fields. The international ITU-T E.164-number code fields are the country code (CC) and remaining fields are specific to the use being made of the international ITU-T E.164 number as shown in Figures 1 to 5.
A numbering plan does not include prefixes, suffixes, and additional information required to complete a call.

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 11 Jul 2013 19:25:06 +0000

Send text please.  I'm willing to add something, buy don't see consensus on what yet.
I'd rewrite Dave's suggestion to use "consider" as opposed to "attend to", but what do you want to do?

Brian

---

From: Russ Housley <[email-masked]>
Date: Thu, 11 Jul 2013 15:31:07 -0400

> anywhere in the world) and if so, that'd be a good thing

Does this single sentence capture your point?

To make deployment of this solution more likely, consideration must be given to the overhead for the call source and all verifiers.

> probably better just omitted for now.

Some means of associating the identity with the public key is needed.

How about:

The working group will consider choices for protecting the identity information and the credentials used, but will likely be based on a digital signature mechanism that covers a set of information in the SIP headers, and verification will employ a credential that contains the public key and is associated with the identity. 

> public key? I think it ought be the latter.

Does the above also resolve this question?

>  modified) to reflect such delegation.

This seems fine to me.

> really meant - what is "considered" meant to mean here?

If we come up with a clean way to handle both identity forms (telephone numbers and user@domain), then this would be really useful for everyone.  But, we are chartered for telephone numbers...

Russ

---

From: Michael Hammer <[email-masked]>
Date: Thu, 11 Jul 2013 19:32:22 +0000

Tim,

The national specific part is a sub-component of the complete E.164 number.

You wouldn't call a car complete if you took the engine out.  :)

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Dwight, Timothy M (Tim)
Sent: Thursday, July 11, 2013 3:23 PM
To: Henning Schulzrinne; 'Stephen Farrell'; Rosen, Brian
Cc: Richard Barnes; <[email-masked]>; Russ Housley; Gonzalo Camarillo
Subject: Re: [stir] Draft STIR Charter

Henning,

I think what you describe is what Rec. E.164 calls an International E.164
number.  It also discusses National (Significant) Numbers, which are the
International E.164 number minus the Country Code.

tim

-----Original Message-----
Henning Schulzrinne

>From E.164, Section 6.2:

The international ITU-T E.164-number is composed of a variable number of
decimal digits arranged in specific code fields. The international ITU-T
E.164-number code fields are the country code (CC) and remaining fields are
specific to the use being made of the international ITU-T E.164 number as
shown in Figures 1 to 5.
A numbering plan does not include prefixes, suffixes, and additional
information required to complete a call.

---

From: Michael Hammer <[email-masked]>
Date: Thu, 11 Jul 2013 19:39:23 +0000

The solution must not noticeably degrade the end-user's usage experience,
e.g. call setup times unacceptably delayed.

The WG can assess what an acceptable trade-off might be.

Mike

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]] 
Sent: Thursday, July 11, 2013 3:25 PM
To: Michael Hammer
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [stir] Draft STIR Charter

Send text please.  I'm willing to add something, buy don't see consensus on
what yet.
I'd rewrite Dave's suggestion to use "consider" as opposed to "attend to",
but what do you want to do?

Brian

On Jul 11, 2013, at 3:20 PM, Michael Hammer <[email-masked]>
 wrote:

> It is more than just computation.  It is the question of call setup 
> time, which is very important for telephony.
> You don't want to have people hang up and dial again and again because 
> they think the system is not working right.
> It is a quality of experience measure.  We don't want the cure to be 
> worse than the disease.
> 
> Mike
> 
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Dave Crocker
> I assume Stephen means computational overhead.  There's also the 
> matter of administrative overhead, which has been a much higher 
> barrier to adoption for DKIM and DMARC.
> 
> If the charter simply says "the design will attend to computational 
> and administrative overhead, and exchange latency", it raises the 
> necessary flags while avoiding concern for criteria in the charter.
> 
> d/
> 
> --
> Dave Crocker

---

From: Russ Housley <[email-masked]>
Date: Thu, 11 Jul 2013 15:41:23 -0400

Dave:

> I assume Stephen means computational overhead.  There's also the matter of administrative overhead, which has been a much higher barrier to adoption for DKIM and DMARC.

I took Stephen's point to be computational, memory, bits on the wire, and administrative.  All of them will be part of the engineering trade off.

Russ

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 11 Jul 2013 19:45:54 +0000

Yes, that would be the more precise term.

-----Original Message-----
From: Dwight, Timothy M (Tim) [mailto:[email-masked]] 
Sent: Thursday, July 11, 2013 3:23 PM
To: Henning Schulzrinne; 'Stephen Farrell'; Rosen, Brian
Cc: Richard Barnes; <[email-masked]>; Russ Housley; Gonzalo Camarillo
Subject: RE: [stir] Draft STIR Charter

Henning,

tim

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 11 Jul 2013 20:22:12 +0000

My understanding was that certain nationally-specific numbers, such as
freephone numbers, actually don't fall under the E.164 plan, and that thus
restricting this to "E.164 numbers" may rule out some numbers we probably
want to provide identity for. These numbers have the quality that they
aren't reachable internationally. No?

Jon Peterson
Neustar, Inc.

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 11 Jul 2013 20:29:35 +0000

Yeah, well, let's talk about that, because you are right.

It really would be a good idea to be able to get a call which had a called party number of 9-1-1 or 1-1-2 and was verifiably from that number.

We certainly want to be able to handle "toll free" numbers, which in many cases are not actually e.164s, even though they look like them.

The problem is that while the latter is usually easy to handle, because even if 18005551212 is not truly an e.164, we certainly could canonicalize them as if they were and everything would work, doing that with 1-1-2 is another story.

Probably not worth dealing with these issues in charter language.

So, Stephen, unless someone can come up with some wording that works, I'd prefer to defer the discussion to the work group (if/when we get one), rather than do it in charter language.

Brian

---

From: "Dwight, Timothy M \(Tim\)" <[email-masked]>
Date: Thu, 11 Jul 2013 16:52:00 -0400

The national (significant) part is what you dial any time you're calling a number in your own country code.  Which is for most of us the normal case.  Therefore the national (significant) part is the thing most closely associated with "telephone number".  Only if you specify "International" format, is it clear that you meant for the country code to be included.

The car analogy brings back a college course in philosophy, in which I recall spending a session trying to define whether there was some essential notion of "chairness" possessed by all chairs.  I'll happily refrain from going down that path again :-).

tim

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]] 
Sent: Thursday, July 11, 2013 2:32 PM
To: Dwight, Timothy M (Tim); [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [stir] Draft STIR Charter

Tim,

Mike

-----Original Message-----

Henning,

tim

---

From: Michael Hammer <[email-masked]>
Date: Thu, 11 Jul 2013 20:53:04 +0000

It could just note that the WG may consider whether non-E.164 numbers should
also be authenticated, and if so, how.

BTW, I would not expect the 9-1-1 or 1-1-2 to be sending me calls.
After all, the 9-1-1 could be routed to a variety of actual emergency
responders.
I would expect that a another number might be provided that could be
validated.

Mike

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]] 
Sent: Thursday, July 11, 2013 4:30 PM
To: Peterson, Jon
Cc: Michael Hammer; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [stir] Draft STIR Charter

It really would be a good idea to be able to get a call which had a called
party number of 9-1-1 or 1-1-2 and was verifiably from that number.

We certainly want to be able to handle "toll free" numbers, which in many
cases are not actually e.164s, even though they look like them.

The problem is that while the latter is usually easy to handle, because even
if 18005551212 is not truly an e.164, we certainly could canonicalize them
as if they were and everything would work, doing that with 1-1-2 is another
story.

So, Stephen, unless someone can come up with some wording that works, I'd
prefer to defer the discussion to the work group (if/when we get one),
rather than do it in charter language.

Brian

On Jul 11, 2013, at 4:22 PM, "Peterson, Jon" <[email-masked]>
 wrote:

> freephone numbers, actually don't fall under the E.164 plan, and that 
> thus restricting this to "E.164 numbers" may rule out some numbers we 
> probably want to provide identity for. These numbers have the quality 
> that they aren't reachable internationally. No?
> 
> Jon Peterson
> Neustar, Inc.
> 
>> Of Dwight, Timothy M (Tim)
>> I think what you describe is what Rec. E.164 calls an International 
>> E.164 number.  It also discusses National (Significant) Numbers, 
>> which are the International E.164 number minus the Country Code.
>> 
>> tim
>> 
>> Of Henning Schulzrinne
>> The international ITU-T E.164-number is composed of a variable number 
>> of decimal digits arranged in specific code fields. The international 
>> ITU-T E.164-number code fields are the country code (CC) and 
>> remaining fields are specific to the use being made of the 
>> international ITU-T E.164 number as shown in Figures 1 to 5.
>> Of Stephen Farrell
>> Better all right. Some people were saying "full e.164" which I guess 
>> means including country code and a +, which'd be even better, if its 
>> not already implied in e.164.
>>

---

From: Michael Hammer <[email-masked]>
Date: Thu, 11 Jul 2013 21:02:18 +0000

I am happy with using as many words ad needed to be clear, so no objection
to saying "international E.164 number".

My concern is that as telephony has evolved we have needed to get less
provincial and more global, especially with the Internet and mobility coming
into play.
We used to think of number within an exchange as sufficient to route, then
it became 7-digit dialing, then with area code overlays, you soon needed the
full 10 digits.
I am just pushing that to the international level, since with mobile
internet, it really helps to have the CC as well.  It is then unambiguous.
Go to an international meeting and ask for their "telephone number " and see
what you get.

No worries,
Mike

-----Original Message-----
From: Dwight, Timothy M (Tim) [mailto:[email-masked]] 
Sent: Thursday, July 11, 2013 4:52 PM
To: Michael Hammer; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [stir] Draft STIR Charter

The national (significant) part is what you dial any time you're calling a
number in your own country code.  Which is for most of us the normal case.
Therefore the national (significant) part is the thing most closely
associated with "telephone number".  Only if you specify "International"
format, is it clear that you meant for the country code to be included.

The car analogy brings back a college course in philosophy, in which I
recall spending a session trying to define whether there was some essential
notion of "chairness" possessed by all chairs.  I'll happily refrain from
going down that path again :-).

tim

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Thursday, July 11, 2013 2:32 PM
To: Dwight, Timothy M (Tim); [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [stir] Draft STIR Charter

Tim,

Mike

-----Original Message-----

Henning,

tim

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 11 Jul 2013 21:02:31 +0000

The original text just used "telephone number" and Stephen suggested we may want to further qualify that.  
I'm suggesting that we don't want to restrict to e.164s, and it may be that just sticking with "telephone numbers" is best.

It depends on the country, but in the U.S. you very often do get a call back from the Public Safety Answering Point.  If the call is from a police officer, it may make more sense to use another number.  

Brian

---

From: "Dwight, Timothy M \(Tim\)" <[email-masked]>
Date: Thu, 11 Jul 2013 17:11:54 -0400

Well, some toll free numbers *are* reachable internationally, and for that reason *are* considered International E.164 numbers (they're called Universal International Freephone Numbers or UIFNs).  But that point aside, I think what you're pointing out is that while we want the user part formatted as an International E.164 number, we don't want to restrict our scope to user parts for which there is an identical E.164 number.  That allows e.g., country-specific (or region-specific for that matter) freephone numbers to be considered in scope.  

tim

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]] 
Sent: Thursday, July 11, 2013 3:22 PM
To: Michael Hammer; Dwight, Timothy M (Tim); [email-masked]; [email-masked]; Rosen, Brian
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Draft STIR Charter

My understanding was that certain nationally-specific numbers, such as freephone numbers, actually don't fall under the E.164 plan, and that thus restricting this to "E.164 numbers" may rule out some numbers we probably want to provide identity for. These numbers have the quality that they aren't reachable internationally. No?

Jon Peterson
Neustar, Inc.

On 7/11/13 12:32 PM, "Michael Hammer" <[email-masked]> wrote:

>E.164 number.  It also discusses National (Significant) Numbers, which 
>are the International E.164 number minus the Country Code.
>
>tim
>
>ITU-T E.164-number code fields are the country code (CC) and remaining 
>fields are specific to the use being made of the international ITU-T 
>E.164 number as shown in Figures 1 to 5.

---

From: "Dwight, Timothy M \(Tim\)" <[email-masked]>
Date: Thu, 11 Jul 2013 17:20:32 -0400

Wouldn't it need to be the case that the number has a single owner?  Otherwise, if its ownership depends on where you are when you reference it, it'd be very hard to validate.

For emergency services maybe we could identify a single 'owner' (e.g., NENA for 9-1-1).  But who would "own" the call-before-you-dig number (811)?

You're probably right about leaving this to the WG to sort out.

Tim

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]] 
Sent: Thursday, July 11, 2013 3:30 PM
To: Peterson, Jon
Cc: Michael Hammer; Dwight, Timothy M (Tim); [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Draft STIR Charter

Brian

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 11 Jul 2013 17:37:21 -0400

+1 or something like that. 

The "FQDN" MUST be properly presented to the appropriate network element.
The E. 164 'name' and it is an name anywhere LNP exists, should  presented
in its full canonical form which by common acceptance the + <TN> denotes
that fact. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave
Crocker
Sent: Thursday, July 11, 2013 3:12 PM
To: Henning Schulzrinne
Cc: Richard Barnes; Russ Housley; Gonzalo Camarillo; <[email-masked]>; Rosen,
Brian; 'Stephen Farrell'
Subject: Re: [stir] Draft STIR Charter

On 7/11/2013 12:00 PM, Henning Schulzrinne wrote:
> fields are specific to the use being made of the international ITU-T E.164

It might be worth having the charter note the mapping function that will
often be required, to convert a local-form of telephone number in the  From
field to it's standardized E.164 form.

d/

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 11 Jul 2013 17:45:38 -0400

Moore's law solves most problems.  I know this specially with the DNS vs SIP
redirect discussion carriers have over number translation. The delta is now
virtually insignificant. 

As I mentioned before the way the national regulators and certainly
Congressional members feel they would helicopter money or investment tax
credits to any carrier willing to implement the solution.    But Public
Hanging is still an option. :-)   The guillotine is certainly an option in
Europe.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Michael Hammer
Sent: Thursday, July 11, 2013 3:20 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [stir] Draft STIR Charter

Mike

-----Original Message-----

d/

---

From: "Baskin, James F \(Jim\)" <[email-masked]>
Date: Thu, 11 Jul 2013 18:27:18 -0400

Regarding the "+", we shouldn't forget this paragraph from E.164 [ANNEX B]:

"B.7 Calling/connected line identity
Calling/connected line identity (CLI/COLI) is address information that is passed across the network to provide supplementary services such as calling (or connected) line identification presentation. The format of the CLI and COLI for international calls should be the full international ITU-T E.164-number, i.e., country code (CC), national destination code (NDC) and subscriber number (SN). No other information, such as prefixes or symbols (e.g., "+"), should be included, although a sub-address may be associated with the CLI/COLI. However, in a country where network-specific numbers are utilized for identifying customers or network services, it remains a national matter. When implemented, the NPI (numbering plan identifier) TON (type of number) mechanism should define the numbering status of the calling/connected line. The authorization to pass CLI/COLI across an international boundary is a national matter."

SEVERAL very interesting statements are contained in this paragraph.  
1) the format of the CLI SHOULD be the full international E.164 number.
2) NO prefixes or symbols (e.g., "+") SHOULD be included.
3) various things are NATIONAL matters, including "The authorization to pass CLI/COLI across an international boundary."

Jim Baskin
Verizon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Shockey
Sent: Thursday, July 11, 2013 5:37 PM
To: [email-masked]; 'Henning Schulzrinne'
Cc: 'Richard Barnes'; 'Russ Housley'; 'Gonzalo Camarillo'; [email-masked]; 'Rosen, Brian'; 'Stephen Farrell'
Subject: Re: [stir] Draft STIR Charter

The "FQDN" MUST be properly presented to the appropriate network element.
The E. 164 'name' and it is an name anywhere LNP exists, should  presented in its full canonical form which by common acceptance the + <TN> denotes that fact. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave Crocker
Sent: Thursday, July 11, 2013 3:12 PM
To: Henning Schulzrinne
Cc: Richard Barnes; Russ Housley; Gonzalo Camarillo; <[email-masked]>; Rosen, Brian; 'Stephen Farrell'
Subject: Re: [stir] Draft STIR Charter

It might be worth having the charter note the mapping function that will often be required, to convert a local-form of telephone number in the  From field to it's standardized E.164 form.

d/

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 11 Jul 2013 17:54:25 -0400

3 digit codes are nationally specific like short codes for mobile operators.
Really Brian you know all of this by heart. 

+1 8XX is in the NANP.  Leave it to the NA national regulators to bring out
the baseball bat or ... goalie stick for the CRTC and the rest of the NANP
to deal with them.  However if the EU maybe possibly want to go forward with
ETNS that is then their problem. 

Stop speculating on what the National Regulatory Authorities may or may not
do. Our job is tools. NOT policy. But here we are. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Rosen, Brian
Sent: Thursday, July 11, 2013 4:30 PM
To: Peterson, Jon
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; Michael Hammer;
[email-masked]; [email-masked]
Subject: Re: [stir] Draft STIR Charter

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 12 Jul 2013 00:07:26 +0000

I know what the 3 digit codes are.  They aren't short codes, they are usually called "service codes". Officially, in the NANP, there is a specific "N11" code set.  1 8XX may be in the NANP, but they are not e.164s.

Regardless of what you call them, it may make sense, in some areas, to allow them to be used as calling party numbers and be verified as authentic.
I think that only has affect on wording in the mechanism discussions.  We may need to be careful when we write the text.  I don't think it belongs in the charter.

Brian

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 11 Jul 2013 20:18:44 -0400

Jim.  Thanks for your expert input here. It is most appreciated.  Generally
we might be looking at how SIP/IMS IPX???  Signaling in network or between
consenting AS operators are the issue.  IMHO the representation of the fully
canonical E.164 address somewhere in the in band SIP headers using + does
make sense operationally. The edge SBC or CSCF network elements could see
the + as useful depending on where it is actually expressed.  Where the
source origin and target is expressed and then how it is signed and by what
means in what system is the problem at hand. 

I'm a great believer that the E.164 is as close to a FQDN as we are going to
see.  I didn't chair IETF ENUM for as long as I did for no reason. :-) 
The international issues are TBD. 

God knows I fear for the day ITU SG 2 grabs a hold of this. Let's fix it
here in the IETF and not in Geneva. 

Best wishes my friend... 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Baskin, James F (Jim)
Sent: Thursday, July 11, 2013 6:27 PM
To: Richard Shockey; [email-masked]
Subject: Re: [stir] Draft STIR Charter

"B.7 Calling/connected line identity
Calling/connected line identity (CLI/COLI) is address information that is
passed across the network to provide supplementary services such as calling
(or connected) line identification presentation. The format of the CLI and
COLI for international calls should be the full international ITU-T
E.164-number, i.e., country code (CC), national destination code (NDC) and
subscriber number (SN). No other information, such as prefixes or symbols
(e.g., "+"), should be included, although a sub-address may be associated
with the CLI/COLI. However, in a country where network-specific numbers are
utilized for identifying customers or network services, it remains a
national matter. When implemented, the NPI (numbering plan identifier) TON
(type of number) mechanism should define the numbering status of the
calling/connected line. The authorization to pass CLI/COLI across an
international boundary is a national matter."

SEVERAL very interesting statements are contained in this paragraph.  
1) the format of the CLI SHOULD be the full international E.164 number.
2) NO prefixes or symbols (e.g., "+") SHOULD be included.
3) various things are NATIONAL matters, including "The authorization to pass
CLI/COLI across an international boundary."

Jim Baskin
Verizon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Richard Shockey
Sent: Thursday, July 11, 2013 5:37 PM
To: [email-masked]; 'Henning Schulzrinne'
Cc: 'Richard Barnes'; 'Russ Housley'; 'Gonzalo Camarillo'; [email-masked];
'Rosen, Brian'; 'Stephen Farrell'
Subject: Re: [stir] Draft STIR Charter

-----Original Message-----

d/

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 11 Jul 2013 20:46:52 -0400

<sigh>  I know what 3 dig codes are and the mobile shorts codes as well.
Where did you think I worked for 10 years?   What is the status of 8XX is of
orthogonal interest to STIR but critical interest since it represents a
staggering level of North American enterprise voice traffic and probably a
huge level of spoofing as well.  To repeat myself for the Nth squared time
there is a clear delineation between national numbering policy and the
solutions we may come up with.

You are correct none of this belongs in the charter. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Rosen, Brian
Sent: Thursday, July 11, 2013 8:07 PM
To: Richard Shockey
Cc: Peterson, Jon; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>;
<[email-masked]>; Michael Hammer; <[email-masked]>;
<[email-masked]>
Subject: Re: [stir] Draft STIR Charter

I know what the 3 digit codes are.  They aren't short codes, they are
usually called "service codes". Officially, in the NANP, there is a specific
"N11" code set.  1 8XX may be in the NANP, but they are not e.164s.

Regardless of what you call them, it may make sense, in some areas, to allow
them to be used as calling party numbers and be verified as authentic.
I think that only has affect on wording in the mechanism discussions.  We
may need to be careful when we write the text.  I don't think it belongs in
the charter.

Brian

On Jul 11, 2013, at 5:54 PM, Richard Shockey <[email-masked]> wrote:

> +1 8XX is in the NANP.  Leave it to the NA national regulators to 
> +bring out
> the baseball bat or ... goalie stick for the CRTC and the rest of the 
> NANP to deal with them.  However if the EU maybe possibly want to go 
> forward with ETNS that is then their problem.
> 
> Stop speculating on what the National Regulatory Authorities may or 
> may not do. Our job is tools. NOT policy. But here we are.
> 
> 
> 
> Of Rosen, Brian
> It really would be a good idea to be able to get a call which had a 
> called party number of 9-1-1 or 1-1-2 and was verifiably from that number.
> 
> We certainly want to be able to handle "toll free" numbers, which in 
> many cases are not actually e.164s, even though they look like them.
> 
> The problem is that while the latter is usually easy to handle, 
> because even if 18005551212 is not truly an e.164, we certainly could 
> canonicalize them as if they were and everything would work, doing 
> that with 1-1-2 is another story.
> 
> So, Stephen, unless someone can come up with some wording that works, 
> I'd prefer to defer the discussion to the work group (if/when we get 
> one), rather than do it in charter language.
> 
> Brian
> 
>> My understanding was that certain nationally-specific numbers, such 
>> as freephone numbers, actually don't fall under the E.164 plan, and 
>> that thus restricting this to "E.164 numbers" may rule out some 
>> numbers we probably want to provide identity for. These numbers have 
>> the quality that they aren't reachable internationally. No?
>> 
>> Jon Peterson
>> Neustar, Inc.
>> 
>>> The international ITU-T E.164-number is composed of a variable 
>>> number of decimal digits arranged in specific code fields. The 
>>> international ITU-T E.164-number code fields are the country code 
>>> (CC) and remaining fields are specific to the use being made of the

---

From: Michael Hammer <[email-masked]>
Date: Fri, 12 Jul 2013 00:54:25 +0000

Don't be silly.  Since when did Moore's Law conquer the speed of light?

As some programmers have found out with chatty RESTful protocols, there is
an RTT penalty for badly designed solutions.

And yes, I did see you equivocate with "most", but I couldn't resist.  :)

Mike

-----Original Message-----

Mike

-----Original Message-----

d/

---

From: Michael Hammer <[email-masked]>
Date: Fri, 12 Jul 2013 00:58:48 +0000

Hi Jim,

I also assume it is a national matter whether to accept calls across
international boundary with or without CLI/COLI.

Mike

-----Original Message-----

Jim Baskin
Verizon

-----Original Message-----

d/

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Fri, 12 Jul 2013 01:05:47 +0000

Business agreement

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Hammer
Sent: Thursday, July 11, 2013 8:59 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Draft STIR Charter

Hi Jim,

Mike

-----Original Message-----

Jim Baskin
Verizon

-----Original Message-----

d/

---

From: Dave Crocker <[email-masked]>
Date: Thu, 11 Jul 2013 18:58:59 -0700

On 7/11/2013 2:45 PM, Richard Shockey wrote:
> Moore's law solves most problems.

Not in networking.

This has already been noted, but I thought reducing to a pithy retort 
could aid folks' memories as the group goes forward.

Moore seems to have solved the computational overhead problem some years 
ago, and never will solve transmission latency problems.

By the way, it also does not solve timezone differences.  (That's not an 
issue for this wg, but I thought I'd toss it in for free.O

d/

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 11 Jul 2013 22:37:59 -0400

On Jul 11, 2013, at 10:21 AM, Russ Housley <[email-masked]> wrote:

> Initially, the working group will specify an in-band mechanism to authenticate the originator of a SIP session where the identity being authenticated is a telephone number and the session is established with SIP end to end.  The working group will consider choices for protecting the identity information and the credentials used, but will likely be similar to the methods described in RFC 4474, which employs a signature over a set of information in the SIP headers using a credential assigned to the identity.  In order to be authoritative, credentials used with this mechanism will be derived from existing telephone number assignment and delegation models.  That is, when a telephone number or range of telephone numbers is delegated to an entity, a credential will accompany such delegation.  

This is a bit of a nitpick, but the solution does not have to accompany a delegation with credentials.  It could, for example, instead accompany a delegation with access rights to the same or another database to upload a public-key for the delegated number.  Or it could even divorce the process of number delegation from STIR altogether - for example we could rely on existing number-lookup databases providing a SPID of the delegated-to carrier, and use a separate web-pki model for certificate signing of SPIDs (instead of directly relating the signing to indicate authority of numbers).

> The mechanism must allow parties who are not delegated a telephone number, but are preauthorized by the entity who is delegated the number, to place calls using the identity.  Expansion of the

I think you mean "STRAW", not INSIPID.  Or maybe you mean both STRAW and INSIPID.  It is not at all clear we can or should use the INSIPID WG's output, for example.

[snip]
> - A fallback mechanism to allow out-of-band identity establishment

In other text of this charter it only says we will likely use an out-of-band solution.  But here it has a deliverable and below it has a milestone for an out-of-band mechanism.  Was this intentional or just legacy wording from previous charter versions?

---

From: Hala Mowafy <[email-masked]>
Date: Fri, 12 Jul 2013 05:20:03 +0000

Stephen,
If I understand your question correctly AND you're emulating the same ringing patterns that customers are used to in the PSTN, the called party would expect to see the caller ID before the second ring.  So, in effect, you have 2 sec ON (first ring) - 4 sec OFF (silence) to get that caller ID verified and delivered before the second ring (6 sec total).  That's in North America.  In the UK and other parts of the world the ringing cadence varies but I believe it is shorter (~ 3 seconds total).
So, all authorization transactions PLUS any other session setup time with the phone, etc., have to fit in those timeframes, even though you don't need those ring times for a SIP call - per se; you're just preserving the customer experience.

My question to the OCSP experts is:  what is an average OCSP query response time if we just stay within one country?  are we talking milliseconds or seconds?
Hala

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Thursday, July 11, 2013 1:55 PM
To: Russ Housley
Cc: Richard Barnes; [email-masked]; Gonzalo Camarillo; Brian Rosen
Subject: Re: [stir] Draft STIR Charter

Hi Russ,

I think this looks pretty good. A few wordsmithing changes and a question below but I have one addition to suggest:

Somewhere this should say that the solution chosen needs to have an acceptable overhead at both signer and verifer or else it also won't be deployed. There may be some on here who could suggest indicative timing or networking constraints (e.g. not having to do ~5 OCSP transactions to possibly anywhere in the world) and if so, that'd be a good thing to include IMO.

On 07/11/2013 03:21 PM, Russ Housley wrote:
> RFC 4474, and the VIPR working group. To date, however, true 
> protecting the identity information and the credentials used, but will 
> likely be similar to the methods described in RFC 4474, which employs 
> a signature over a set of information in the SIP headers using a 
> credential assigned to the identity.

"will likely be based on a digital signature mechanism that is cryptographically similar to the one described in RFC 4474 and where the signature continues to be represented in SIP headers."

Saying "methods" and 4474 is a bit vague and could be read to mean "s/mime-based" or "cms based" or "x.509 based" whereas what I think we want is just to say its a signature.

Similarly "assigned to the identity" is very ambiguous and probably better just omitted for now.

> from existing telephone number assignment and delegation models.

No specific change suggested but are we using credential here to mean the private key or a (set of) TN(s) associated with a public key? I think it ought be the latter.

> delegated to an entity, a credential will accompany such delegation.

That's problematic with either definition of credential. I think it'd be ok to say:

> number, to place calls using the identity.

No specific change suggested, but I've always wondered if this requirement is real. I'd argue enough good would be done without try to stretch for this. But I defer to those who know more about the application.

> should be considered in the initial design.

To be honest, I didn't read that thread (one too many:-) but I'm surprised that this is to be part of the initial design. But "considered" is sort of weasel-wordy so I'm not sure what's really meant - what is "considered" meant to mean here?

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 12 Jul 2013 11:32:55 +0100

> one), rather than do it in charter language.

Given the amount of discussion this caused (sorry for that:-), I
agree.

S.

> 
> Brian
> 
> On Jul 11, 2013, at 4:22 PM, "Peterson, Jon"
> <[email-masked]> wrote:
> 
>> 
>> numbers we probably want to provide identity for. These numbers
>> have the quality that they aren't reachable internationally. No?
>> 
>> Jon Peterson Neustar, Inc.
>> 
>>> -----Original Message----- From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of Dwight, Timothy M
>>> (Tim) Sent: Thursday, July 11, 2013 3:23 PM To: Henning
>>> Schulzrinne; 'Stephen Farrell'; Rosen, Brian Cc: Richard Barnes;
>>> <[email-masked]>; Russ Housley; Gonzalo Camarillo Subject: Re:
>>> [stir] Draft STIR Charter
>>> 
>>> Henning,
>>> 
>>> I think what you describe is what Rec. E.164 calls an
>>> International E.164 number.  It also discusses National
>>> (Significant) Numbers, which are the International E.164 number
>>> minus the Country Code.
>>> 
>>> tim
>>> 
>>> -----Original Message----- From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of Henning Schulzrinne 
>>> Sent: Thursday, July 11, 2013 2:00 PM To: 'Stephen Farrell';
>>> Rosen, Brian Cc: Richard Barnes; <[email-masked]>; Russ Housley;
>>> Gonzalo Camarillo Subject: Re: [stir] Draft STIR Charter
>>> 
>>> (CC) and remaining fields are specific to the use being made of
>>> the international ITU-T E.164 number as shown in Figures 1 to 5. 
>>> A numbering plan does not include prefixes, suffixes, and
>>> additional information required to complete a call.
>>> 
>>> -----Original Message----- From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of Stephen Farrell Sent:
>>> Thursday, July 11, 2013 2:53 PM To: Rosen, Brian Cc: Richard
>>> Barnes; <[email-masked]>; Russ Housley; Gonzalo Camarillo Subject:
>>> Re: [stir] Draft STIR Charter
>>> 
>>> 
>>> 
>>>> So maybe where we say "where the identity being authenticated
>>>> is a telephone number" add "in e.164 format"?
>>> 
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/stir 
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/stir
>> 
> 
>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 12 Jul 2013 11:37:55 +0100

Hi Russ,

On 07/11/2013 08:31 PM, Russ Housley wrote:
> To make deployment of this solution more likely, consideration must
> be given to the overhead for the call source and all verifiers.

That's fine.

> The working group will consider choices for protecting the identity
> information and the credentials used, but will likely be based on a
> digital signature mechanism that covers a set of information in the
> SIP headers, and verification will employ a credential that contains
> the public key and is associated with the identity.

Lovely.

> Does the above also resolve this question?

Yep.

>> modified) to reflect such delegation.

Lovelier.

> If we come up with a clean way to handle both identity forms
> (telephone numbers and user@domain), then this would be really useful
> for everyone.  But, we are chartered for telephone numbers...

Fair enough. I think if you make that explicit the wg might avoid
some ratholes. How about if it said:

  Expansion of the authentication mechanism to identifiers using the
  user@domain form should be considered in the initial design but
  the main focus of the working group is to develop a solution
  for telephone numbers.

Feel free to use that or not, as you prefer.

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 12 Jul 2013 11:51:38 +0100

On 07/12/2013 06:20 AM, Hala Mowafy wrote:
> Stephen, If I understand your question correctly AND you're emulating
> the same ringing patterns that customers are used to in the PSTN, the
> called party would expect to see the caller ID before the second
> ring.  So, in effect, you have 2 sec ON (first ring) - 4 sec OFF
> (silence) to get that caller ID verified and delivered before the
> second ring (6 sec total).  That's in North America.  In the UK and
> other parts of the world the ringing cadence varies but I believe it
> is shorter (~ 3 seconds total). So, all authorization transactions
> PLUS any other session setup time with the phone, etc., have to fit
> in those timeframes, even though you don't need those ring times for
> a SIP call - per se; you're just preserving the customer experience.
> 
> My question to the OCSP experts is:  what is an average OCSP query
> response time if we just stay within one country?  are we talking
> milliseconds or seconds? 

There're some netcraft numbers. [1,2] Browsers are perhaps
more sensitive to delays (or maybe not) but they've found
this to be an issue, to the point where a solution that
includes pre-cooked OCSP responses in the TLS handshake
(stapling) was developed. [3,4]

So OCSP works but if you build a complex PKI for the delegations
it might become problematic, esp. if there's much chance of
some of the OCSP responders being flakey or far away since
you have to get an OCSP response for each certificate in
each certificate chain in the general case.

S.

[1]
http://news.netcraft.com/archives/2013/04/22/ocsp-server-performance-in-march-2013.html
[2]
http://uptime.netcraft.com/perf/reports/performance/OCSP?orderby=epercent&tn=march_2013
[3] https://tools.ietf.org/html/rfc6961
[4] https://en.wikipedia.org/wiki/OCSP_Stapling

> Thursday, July 11, 2013 1:55 PM To: Russ Housley Cc: Richard Barnes;
> [email-masked]; Gonzalo Camarillo; Brian Rosen Subject: Re: [stir]
> Draft STIR Charter
> 
> 
> Hi Russ,
> 
>> appreciable deployment.  Several factors contributed to this lack
>> of success, including: failure of the problem to be seen as
>> critical at the time; lack of any real means of asserting authority
>> over telephone numbers; misalignment of the mechanisms proposed by
>> RFC 4474 with the complex deployment environment that has emerged
>> for SIP; lack of end-to-end SIP session establishment; and inherent
>> operational problems with a transitive trust model.
>> 
>> choices for protecting the identity information and the credentials
>> used, but will likely be similar to the methods described in RFC
>> 4474, which employs a signature over a set of information in the
>> SIP headers using a credential assigned to the identity.
> 
> cryptographically similar to the one described in RFC 4474 and where
> the signature continues to be represented in SIP headers."
> 
> No specific change suggested but are we using credential here to mean
> the private key or a (set of) TN(s) associated with a public key? I
> think it ought be the latter.
> 
> requirement is real. I'd argue enough good would be done without try
> to stretch for this. But I defer to those who know more about the
> application.
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 12 Jul 2013 12:59:52 +0000

If you want to reject unwanted unvalidated calls, rather than just label the caller ID as valid, the validation needs to occur before the INVITE (or moral SS7/ISDN/MF equivalent) reaches the callee, i.e., it is part of the post-dial delay, the delay between dialing the last number and the start of ringing. I had previously, on this list, referenced a UK guideline for acceptable PDD, which varies widely. We are used to fairly long PDD for cell phones (5-10 seconds), as there are several database lookups for those calls, among other delays. For landline, PDD has typically been much shorter. The main problem with long PDD is call abandonment, particularly if there is silence on the calling side, so that the caller believes erroneously that something is not working. (Faking ringback has its own set of issues.)

As also discussed already, caching can greatly reduce any RTT-induced delays, given that most numbers would not change their public keys all that often. (For example, a carrier could cache all entries, and then use publish-subscribe event notification from the numbering authority to be informed of any porting or key revocation changes.)

With roughly 800 million US numbers, and 1 kB for each cert, you can fit all of these on a $100 disk, with a worst-case assumption that each number has its own cert, rather than number ranges.

Henning

________________________________________
From: [email-masked] [[email-masked]] on behalf of Hala Mowafy [[email-masked]]
Sent: Friday, July 12, 2013 1:20 AM
To: Stephen Farrell; Russ Housley
Cc: Richard Barnes; [email-masked]; Brian Rosen
Subject: Re: [stir] Draft STIR Charter

Stephen,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Thursday, July 11, 2013 1:55 PM
To: Russ Housley
Cc: Richard Barnes; [email-masked]; Gonzalo Camarillo; Brian Rosen
Subject: Re: [stir] Draft STIR Charter

Hi Russ,

Cheers,
S.

---

From: <[email-masked]>
Date: Fri, 12 Jul 2013 14:13:26 +0000

Regarding tool free and the like, I would agree to defer this to a WG discussion. I think we're now confusing reachability (which a relative concept even in the so called _P_STN) and uniqueness. There are lots of E.164 numbers that are not globally reachable.  

Whether this applies only to geographic country codes or to any E.164 country codes is an interesting question. All I've read so far most applies to geographic country codes,... well, groups of countries in fact, mmmh... +1 actually :)

Re. national only numbers, I'd prefer dealing with this at a later stage. (I'm not even sure it calls for a significantly different solution, other than the URI format, that is)  

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rosen, Brian
Sent: Thursday, July 11, 2013 10:30 PM
To: Peterson, Jon
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Michael Hammer; [email-masked]; [email-masked]
Subject: Re: [stir] Draft STIR Charter

Brian

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 12 Jul 2013 14:18:00 +0000

Can we conclude this discussion by leaving the text alone, so it refers to vague "telephone numbers" and not even try to define them further?

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 12 Jul 2013 14:25:16 +0000

> This is a bit of a nitpick, but the solution does not have to accompany a delegation with credentials.  It could, for example, instead accompany a delegation with access rights to the same or anoth…
Okay, but please send text.  "Accompany" was meant to not imply all of those.  We deliberately stayed away from mentioning how any one got the credential, what kind of databases existed, etc, just that there was a credential that mirrored the delegation which was used to sign and verify.

> I think you mean "STRAW", not INSIPID.  Or maybe you mean both STRAW and INSIPID.  It is not at all clear we can or should use the INSIPID WG's output, for example.
I was thinking INSIPID because I thought we agreed early on that the INSIPID ID was what we wanted for a  call id to prevent replay.  I don't have a problem with STRAW and INSIPID if you think STRAW coordination would be beneficial.

> In other text of this charter it only says we will likely use an out-of-band solution.  But here it has a deliverable and below it has a milestone for an out-of-band mechanism.  Was this intentiona…
Legacy cut/paste problem, we will reword.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 12 Jul 2013 07:32:41 -0700

> Given the amount of discussion this caused (sorry for that:-), I

In fact the amount of discussion suggests that this is enough of an 
issue to be worth calling out the issue explicitly in the charter.

Perhaps adding something like:

    The mechanism will use a canonical form of telephone number, based 
on the contents of the SIP From field. The working group will specify 
the details of the form, as well as any mapping that might be needed 
between the From field and the canonical form.

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 12 Jul 2013 14:39:24 +0000

I don't have a problem with that concept.

There is the difficulty that we may have to deal with PAI instead of From in some cases.  We may even need to send the number in some other new header, although I hope we don't have to.  We haven't settled that issue yet.  

The mechanism will likely also use the destination TN, which has the same issue.  

I edited the text to remove references to specific headers.   We could have "The mechanism will use a canonical form of telephone number, based on the contents of the SIP header fields. The working group will specify the details of the form, as well as any mapping that might be needed between the header fields and the canonical form."

On Jul 12, 2013, at 10:32 AM, Dave Crocker <[email-masked]>
 wrote:

> In fact the amount of discussion suggests that this is enough of an issue to be worth calling out the issue explicitly in the charter.
> 
>   The mechanism will use a canonical form of telephone number, based on the contents of the SIP From field. The working group will specify the details of the form, as well as any mapping that might be needed between the From field and the canonical form.
> 
> 
> -- 
> Dave Crocker

---

From: <[email-masked]>
Date: Fri, 12 Jul 2013 14:28:44 +0000

AFAIAC, what matters is a) uniqueness and/therefore b) the fact that it is published as an "E.164 number" by entity that manages the CC so the appropriate term should be "international E.164 number" as defined by the recommendation for reasons pointed out by others. Whether one number is reachable or only partially reachable doesn't really matter that much. 

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]] 
Sent: Friday, July 12, 2013 4:18 PM
To: FOUQUART Philippe OLNC/OLN
Cc: Peterson, Jon; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Michael Hammer; [email-masked]; [email-masked]
Subject: Re: [stir] Draft STIR Charter

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 12 Jul 2013 14:34:40 +0000

Philippe

The problem with using international E.164 number wording in the charter is that we would like to be able to verify numbers that are not International E.164 numbers.  One example we use is national toll free numbers, which in some cases are not international E.164 numbers.  The other example I used is a service number like 1-1-2.  Those may be valid, desirable called party numbers which we would like to be able to send and verify using the mechanisms to be defined in this work.  We would therefore like less restrictive wording that would permit us to cover these cases.  When we write standards documents, we will have to use more words, more defined terms and cover multiple cases explicitly.  I don't think that complexity would help in the charter language, so I am suggesting we keep the current "telephone number" text.

Brian

---

From: <[email-masked]>
Date: Fri, 12 Jul 2013 14:43:24 +0000

Brian,

My apologies, I thought the intent was not to cover short codes and the like in the charter and address that at a later stage possible with some rechartering. If people prefer some flexibility in the first place, I'm fine with using that generic term (as I said I might be wrong but I don't think the solution would be much different other than the format in which the number is conveyed) 

Regards, 

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]] 
Sent: Friday, July 12, 2013 4:35 PM
To: FOUQUART Philippe OLNC/OLN
Cc: Peterson, Jon; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Michael Hammer; [email-masked]; [email-masked]
Subject: Re: [stir] Draft STIR Charter

Philippe

Brian

---

From: Dave Crocker <[email-masked]>
Date: Fri, 12 Jul 2013 07:46:57 -0700

> I edited the text to remove references to specific headers.   We could have "The mechanism will use a canonical form of telephone number, based on the contents of the SIP header fields. The working…

As charter text, that works for me.

d/

---

From: <[email-masked]>
Date: Fri, 12 Jul 2013 15:06:41 +0000

Tim, 

I think I see what you mean, but that's not what you wrote :): actually, the (N)SN is not what you _dial_ for national calls for most dialling plans on the planet because a large number of them use a "National (trunk) prefix", eg the 'recommended' 0). As you pointed out the N(S)N is just the [full] international E.164 number without the CC. 

Generally speaking, for such terms, people can just look up http://www.itu.int/rec/T-REC-E.164-201011-I.   

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dwight, Timothy M (Tim)
Sent: Thursday, July 11, 2013 10:52 PM
To: Michael Hammer; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Draft STIR Charter

tim

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]] 
Sent: Thursday, July 11, 2013 2:32 PM
To: Dwight, Timothy M (Tim); [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [stir] Draft STIR Charter

Tim,

Mike

-----Original Message-----

Henning,

tim

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Jul 2013 11:27:56 -0400

> I was thinking INSIPID because I thought we agreed early on that the INSIPID ID was what we wanted for a  call id to prevent replay.  I don't have a problem with STRAW and INSIPID if you think STRA…

As its shaping up, the INSIPID ID isn't known if full to the caller 
until a response is received. So it will be a problem to use that ID (in 
full) to generate a signature in the initial request.

But maybe the caller's half of the id would be sufficient for the purpose.

But it doesn't hurt to have such a loose reference to INSIPID.

	Thanks,
	Paul

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 12 Jul 2013 11:44:32 -0400

As its shaping up, I have my doubts the INSIPID ID will be unchanged end-to-end.  I don't think we should rely on it for STIR whatsoever.  We need to have as few dependencies as possible if we really want this thing to be deployed sooner rather than later.
-hadriel

Sent from my iPhone

On Jul 12, 2013, at 11:27 AM, Paul Kyzivat <[email-masked]> wrote:

> As its shaping up, the INSIPID ID isn't known if full to the caller until a response is received. So it will be a problem to use that ID (in full) to generate a signature in the initial request.
>

---

From: "Dwight, Timothy M \(Tim\)" <[email-masked]>
Date: Fri, 12 Jul 2013 11:47:36 -0400

Let's at least not make it a "charter change" to implement this mechanism to validate PAI.  Because that's a likely deployment scenario.

tim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rosen, Brian
Sent: Friday, July 12, 2013 9:39 AM
To: <[email-masked]>
Cc: [email-masked]; Stephen Farrell
Subject: Re: [stir] Draft STIR Charter

On Jul 12, 2013, at 10:32 AM, Dave Crocker <[email-masked]>
 wrote:

>>> >I'd prefer to defer the discussion to the work group (if/when we 
>>> >get one), rather than do it in charter language.

---

From: "Dwight, Timothy M \(Tim\)" <[email-masked]>
Date: Fri, 12 Jul 2013 11:48:33 -0400

+1

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave Crocker
Sent: Friday, July 12, 2013 9:47 AM
To: Rosen, Brian
Cc: [email-masked]; Stephen Farrell
Subject: Re: [stir] Draft STIR Charter

d/

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 12 Jul 2013 15:49:04 +0000

Yes, that's why we used the term "SIP header" rather than mention any specific header.

Brian

---

From: "Dwight, Timothy M \(Tim\)" <[email-masked]>
Date: Fri, 12 Jul 2013 11:50:35 -0400

Ah, now you're asking me to acknowledge that there's a world outside North America... which we Americans are predisposed not to do...

Thanks for the clarification :-)

Tim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, July 12, 2013 10:07 AM
To: Dwight, Timothy M (Tim)
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Terminolgy (was: RE: [stir] Draft STIR Charter)

Tim, 

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dwight, Timothy M (Tim)
Sent: Thursday, July 11, 2013 10:52 PM
To: Michael Hammer; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Draft STIR Charter

tim

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Thursday, July 11, 2013 2:32 PM
To: Dwight, Timothy M (Tim); [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [stir] Draft STIR Charter

Tim,

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dwight, Timothy M (Tim)
Sent: Thursday, July 11, 2013 3:23 PM
To: Henning Schulzrinne; 'Stephen Farrell'; Rosen, Brian
Cc: Richard Barnes; <[email-masked]>; Russ Housley; Gonzalo Camarillo
Subject: Re: [stir] Draft STIR Charter

Henning,

tim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Thursday, July 11, 2013 2:53 PM
To: Rosen, Brian
Cc: Richard Barnes; <[email-masked]>; Russ Housley; Gonzalo Camarillo
Subject: Re: [stir] Draft STIR Charter

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 12 Jul 2013 11:59:39 -0400

Sent from my iPhone

> Okay, but please send text.  "Accompany" was meant to not imply all of those.  We deliberately stayed away from mentioning how any one got the credential, what kind of databases existed, etc, just…
As long as we're cool with keeping it open, I'm cool with letting the current wording stay.  As I said it was a bit of a nitpick.  :)

-hadriel

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 12 Jul 2013 11:57:16 -0400

Yes I think that's the right thing to do for the charter.  Even during WG work, we're not really trying to authenticate E.164 numbers per se, but rather the caller-id telephone number.  It just happens that handling it as an E.164 makes it a lot easier/straight-forward.
-hadriel

Sent from my iPhone

---

From: Russ Housley <[email-masked]>
Date: Fri, 12 Jul 2013 16:08:16 -0400

> This is a bit of a nitpick, but the solution does not have to accompany a delegation with credentials.  It could, for example, instead accompany a delegation with access rights to the same or anoth…

Does this change that was made based on Stephen's comments also address your concern?  If so, please say so on the list.  If not, please tell us on list what concern remains.

Russ

---

From: Russ Housley <[email-masked]>
Date: Fri, 12 Jul 2013 16:27:32 -0400

How about (with a bit more surrounding text to make sure we all see the context):

Initially, the working group will specify an in-band mechanism to authenticate the originator of a SIP session where the identity being authenticated is a telephone number and the session is established with SIP end to end.  The mechanism will use a canonical telephone number representation specified by the working group, including any mappings that might be needed between the SIP header fields and the canonical telephone number representation.   ...

Russ

---

From: Dave Crocker <[email-masked]>
Date: Fri, 12 Jul 2013 15:18:35 -0700

On 7/12/2013 1:27 PM, Russ Housley wrote:
> Initially, the working group will specify an in-band mechanism to authenticate the originator of a SIP session where the identity being authenticated is a telephone number and the session is established with SIP end to end.  The mechanism will use a canonical telephone number representation specified by the working group, including any mappings that might be needed between the SIP header fields and the canonical telephone number representation.

Looks good.

For what it's worth, the "Initially" is superfluous as charter text. 
Charters are very existential.  There's here and now; the work to be 
done as chartered.  Everything else is fantasy, because it can't be 
promised.

d/

---

From: Russ Housley <[email-masked]>
Date: Fri, 12 Jul 2013 19:04:59 -0400

I have tried to pull all of the discussion into an updated charter.  I have also attached a diff to make it easier to review.

Russ

= = = = = = = = = =

Chairs: TBD

Over the last decade, a growing set of problems have resulted from the
lack of security mechanisms for attesting the origins of real-time
communications.  As with email, the claimed source identity of a SIP
request is not verified, and this permits unauthorized use of source
identities as part of deceptive and coercive activities, such as
robocalling (bulk unsolicited commercial communications), vishing
(voicemail hacking, and impersonating banks) and swatting (impersonating
callers to emergency services to stimulate unwarranted large scale law
enforcement deployments).  This working group will define a deployable
mechanism to validate the identity of the calling party that can be
verified by entities in the path of a call.

SIP is one of the main VoIP technologies used by parties that want to
present an incorrect origination.  Several previous efforts have tried to
secure the origins of SIP communications, including RFC 3325, RFC 4474,
and the VIPR working group.  To date, however, true validation of the
source of SIP calls has not seen any appreciable deployment.  Several
factors contributed to this lack of success, including: failure of the
problem to be seen as critical at the time; lack of any real means of
asserting authority over telephone numbers; misalignment of the
mechanisms proposed by RFC 4474 with the complex deployment environment
that has emerged for SIP; lack of end-to-end SIP session establishment;
and inherent operational problems with a transitive trust model.  To make
deployment of this solution more likely, consideration must be given to
user experience as well as overhead for the call source and all
verifiers.

As its first work item, the working group will specify an in-band
mechanism to authenticate the originator of a SIP session where the
identity being authenticated is a telephone number and the session is
established with SIP end to end.  The mechanism will use a canonical
telephone number representation specified by the working group, including
any mappings that might be needed between the SIP header fields and the
canonical telephone number representation.  The working group will
consider choices for protecting the identity information and the
credentials used, but will likely be based on a digital signature
mechanism that covers a set of information in the SIP headers, and
verification will employ a credential that contains the public key and is
associated with the identity.  In order to be authoritative, credentials
used with this mechanism will be derived from existing telephone number
assignment and delegation models.  That is, when a telephone number or
range of telephone numbers is delegated to an entity, relevant
credentials will be generated (or modified) to reflect such delegation.
The mechanism must allow parties who are not delegated a telephone
number, but are preauthorized by the entity who is delegated the number,
to place calls using the identity.  Expansion of the authentication
mechanism to identities using the user@domain form should be considered
in the initial design, but the main focus of the working group is to
develop a solution for telephone numbers.  After completing the SIP end
to end solution, the working group will consider session establishment
where there are one or more non-SIP hops, most likely using an
out-of-band authentication mechanism.  However, the in-band and
out-of-band mechanisms should share as much in common as possible,
especially the credentials.

The working group will coordinate with the Security Area on credential
management.

The working group will coordinate with other working groups in the RAI
Area regarding signaling through existing deployments.

Authenticated identity is closely linked to privacy, and one frequently
comes at the cost of the other.  This working group is not chartered to
mandate the presence of identity in SIP requests, and to the extent
feasible it will find privacy-friendly solutions that leak minimal
information about calls to third parties.

Milestones

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 12 Jul 2013 19:34:51 -0400

Yup works for me.

-hadriel

---

From: Dave Crocker <[email-masked]>
Date: Fri, 12 Jul 2013 16:43:39 -0700

Meta-point:

      The text is only about authentication, but the discussion has been 
about authorization.  For example one might have an authenticated 
originator value that is not the string displayed as Caller-ID.[*]  I 
understood the purpose of the wg to be ensuring that the displayed 
string was authorized by its assignee.

      If no one cares about this distinction and everyone feels that 
"authenticate the originator" is sufficiently precise and accurate, 
fine, but I thought it worth making sure.

>      To make

In this form, the text is sufficiently generic so that it applies to 
essentially all protocol work ever done in the IETF.  It would help to 
have it provide some substantive guidance and/or constraint.  The list 
that was developed in the earlier discussion seemed reasonable for this:

      To ensure usability, consideration will be given to computational 
and administrative overhead, exchange latency, and real-time performance 
within call-setup limits.

> identity being authenticated is a telephone number and the session is

Thinking about having someone read this who hasn't already tracked the 
discussion:  The meaning of 'in-band' might not be at all obvious.

Perhaps:

    the working group will specify a mechanism to authenticate the 
originator of a SIP session, where the identity being authenticated is a 
telephone number based on information in SIP headers, the session is 
established end to end, and the mechanism works within the SIP session 
(in-band).

The reference to SIP headers is core to what's been discussed and it 
provides context for the reference in the next sentence.

> number, but are preauthorized by the entity who is delegated the number,

      preauthorized -> authorized

The 'pre' actually confused me for awhile

> develop a solution for telephone numbers.  After completing the SIP end

'Considered...but main focus' essentially calls for solving the issue in 
the current effort.

Instead:

      Expansion of the authentication mechanism to identifiers using the 
user@domain form is deferred.

This creates awareness of the issue and implies an intent to deal with 
it (later).

> especially the credentials.

These two draft sentence essentially require defining an out-of-band 
mechanism; if they don't they are meaningless or a distraction.

Instead:

      Consideration of out-of-band mechanisms, to deal with transit 
across non-SIP hops, is deferred.

> The working group will coordinate with the Security Area on credential

On advice of others, the draft text I had circulated for this was:

      The working group will coordinate with the Security Area, for any
proposal details that utilize classic security mechanisms, such as
cryptography and certificate credentials.

>    - A document describing the credentials required to support secure

'secure'?  that's quite generic, and probably far beyond the scope of 
this working group.

>    - A fallback mechanism to allow out-of-band identity establishment

I thought there was agreement to drop this deliverable.  It seems to 
have crept back in.

> Jun 2014   Submit fallback for Proposed Standard

ditto.

[*] Since provides such a wealth of odd experience, I'll note that DKIM 
is an example of creating an authenticated identifier that says nothing 
about the author address.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 13 Jul 2013 00:50:45 +0100

> Yup works for me.

Same here.

S.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 14 Jul 2013 17:42:53 -0700

On Fri, Jul 12, 2013 at 4:43 PM, Dave Crocker <[email-masked]> wrote:

> I thought there was agreement to drop this deliverable.  It seems to have
> crept back in.

I don't recall such an agreement. I certainly recall that there were voices
on
both sides. Seems like something that would be useful to discuss at the BOF.

-Ekr

---

From: Dave Crocker <[email-masked]>
Date: Sun, 14 Jul 2013 18:28:38 -0700

On 7/14/2013 5:42 PM, Eric Rescorla wrote:
> On Fri, Jul 12, 2013 at 4:43 PM, Dave Crocker <[email-masked]
> <mailto:[email-masked]>> wrote:
> I don't recall such an agreement. I certainly recall that there were
> voices on

Why wait?  Mailing lists are better for thoughtful exploration of 
issues.  It would be quite helpful to go into the f2f meeting with a 
clear understanding of the issues.  I suspect we lack that as of now.

A number of basic concerns with an out-of-band approach have been raised 
and I don't recall seeing them resolved or even extensively responded to.

For one thing, the meaning of term and, more importantly, the scope of 
the mechanism's use, have been subject to different explanations.  At 
this point, it is not clear when it is expected to apply or with what 
what actors.  That puts it into the category of "abstract concept" 
rather than "engineering task".

One of the critical components to answering the above, pragmatically, is 
how it can be viable in concert with the pure-SIP (in-band) mechanism. 
One offered scenario that Jon Peterson confirmed was that it would be 
fully redundant with in-band, having originator set it up and callee do 
parallel verification.  I'm not aware of any other Internet service that 
has attempted end-to-end redundancy.  Perhaps you are?

Lastly is the question of having a working group pursue two 
different-but-redunant solutions at the same time.  I'm also not aware 
of that having been done successfully, but perhaps you are?

d/

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 15 Jul 2013 03:26:08 +0000

I don't believe I've "confirmed" on the list that out-of-band would be
fully redundant with in-band. Instead, what I've said is that there are
different applicabilities for these two proposed mechanisms. I don't think
anyone could reasonably maintain that an in-band solution for SIP would be
a complete solution for the robocalling or voicemail hacking out there in
the wild today. At best, in-band handles IP-to-IP cases, and maybe (if it
were cast something like Hadriel's ikes draft) it could handle
IP-to-something-to-IP cases. There are however plenty of IP-to-PSTN cases,
and PSTN-to-PSTN cases. In fact, those two would seem to be the dominant
use cases for calls for the foreseeable future.

What I have said in the past that may have confused you is that I
envisioned that an authentication service (i.e., the originating side)
that supported both in-band and out-of-band should ideally use both, since
it couldn't anticipate which would work, as callers can't anticipate where
calls will land and what the intervening network or capabilities at the
terminating side will be. But of course, if the originating side isn't
signaling SIP, then you're not going to be doing in-band from originating
side, say. So no, it's not in any meaningful sense "fully redundant." And
again, this is just based on my own sketch of how the two mechanisms might
interact. Maybe we could do better.

To me, this out-of-band question is a question about the problem we're
aiming to solve, not the solution mechanisms. Are we going to try to do
anything about the parts of the robocalling and voicemail hacking problem
where SIP is not the protocol used on both side, or are we going to skip
that? And if the latter, are we addressing enough of the problem for this
to be worth our effort?

Jon Peterson
Neustar, Inc.

---

From: Dave Crocker <[email-masked]>
Date: Sun, 14 Jul 2013 20:51:22 -0700

On 7/14/2013 8:26 PM, Peterson, Jon wrote:
> fully redundant with in-band.

Actually, you did:

>> Subject: Re: [stir] Out-of-band vs. in-band
>> Date: Mon, 24 Jun 2013 17:18:01 +0000
>> From: Peterson, Jon <[email-masked]>
>> To: [email-masked] <[email-masked]>
>> CC: [email-masked] <[email-masked]>
>> ....
>> To your refined question, about using two approaches "always and
>> simultaneously," some STIR deployments would be capable of doing both, and
>> yes under the model I at least have in mind they would do both.

That describes usage that is fully redundant.

Perhaps you didn't mean it or that you meant something else.  This 
merely underscores the confusion I cited about what exactly is meant by 
an out-of-band mechanism, who it's actors would be and when it would be 
used -- I'll also toss in how the actors will know they are to use it.

Without a fair sense of answers to all of the above, we can't have any 
idea what the engineering challenges for the mechanism will be, or even 
whether the mechanism is viable.

> Instead, what I've said is that there are
> different applicabilities for these two proposed mechanisms.

So sometimes use one, sometimes use the other, sometimes use both?

There's a nice term for such an approach and, I might add, quite a bit 
of experience with its applicability.  The term is "non-interoperable'.

> I don't think
> the wild today.

Right.  So it's a good thing, indeed, that no one has attempted to 
maintain that, isn't it?

> that supported both in-band and out-of-band should ideally use both,

And you don't think that makes it fully redundant for the caller? (And 
fully redundant for /some/ callees.)

> that? And if the latter, are we addressing enough of the problem for this

So a proposed solution isn't about solutions but about the problem? 
Sorry, but I've no idea what this paragraph means or how it responds.

Really, my note asked very simple, very basic technical questions about 
the out-of-band 'proposal'.  Very simple.  Very basic.

For those promoting an immediate effort at producing an out-of-band 
solution, the answers also out to be very simple and basic.

d/

---

From: <[email-masked]>
Date: Mon, 15 Jul 2013 10:07:31 +0000

It looks good to me. Probably a minor point, but where the second paragraph reads:
Several factors contributed to this lack of success, including: [...] lack of any real means of asserting authority over telephone numbers;

I'd prefer something like:
"lack of any technical means of producing a proof of authority over telephone numbers" 

The point being that strictly speaking and contrary to what the text seems to imply, there are real means of asserting the authority over a number range, luckily enough: for many numbering plans, there's an NRA ruling for number ranges, generally made public, sometimes on-line, there are NPDBs when numbers are portable... So, depending on the number, both would provide a real means with which the authority over a number (range) can be asserted. The problem, however, is that there's indeed no technical way of producing (, conveying for in-band) and checking that proof of authority 'over the wire', which make these 'real means' technically unfit for the purpose described in the first/second paragraph. 

Apologies, this could have gone with the first round. 

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

From: [email-masked] [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Saturday, July 13, 2013 1:05 AM
To: IETF STIR Mail List
Subject: Re: [stir] Draft STIR Charter

Russ

= = = = = = = = = =

Chairs: TBD

Milestones

---

From: Michael Hammer <[email-masked]>
Date: Mon, 15 Jul 2013 13:54:13 +0000

+1

Especially about authorization.  I thought that was the #1 point.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave
Crocker
Sent: Friday, July 12, 2013 7:44 PM
To: Russ Housley
Cc: IETF STIR Mail List
Subject: Re: [stir] Draft STIR Charter

Meta-point:

      The text is only about authentication, but the discussion has been
about authorization.  For example one might have an authenticated originator
value that is not the string displayed as Caller-ID.[*]  I understood the
purpose of the wg to be ensuring that the displayed string was authorized by
its assignee.

      If no one cares about this distinction and everyone feels that
"authenticate the originator" is sufficiently precise and accurate, fine,
but I thought it worth making sure.

>      To make
> deployment of this solution more likely, consideration must be given 
> to user experience as well as overhead for the call source and all 
> verifiers.

In this form, the text is sufficiently generic so that it applies to
essentially all protocol work ever done in the IETF.  It would help to have
it provide some substantive guidance and/or constraint.  The list that was
developed in the earlier discussion seemed reasonable for this:

      To ensure usability, consideration will be given to computational and
administrative overhead, exchange latency, and real-time performance within
call-setup limits.

Perhaps:

Instead:

Instead:

ditto.

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 15 Jul 2013 14:42:51 -0400

On Jul 12, 2013, at 7:43 PM, Dave Crocker <[email-masked]> wrote:

> Meta-point:
> 
>     The text is only about authentication, but the discussion has been about authorization.  For example one might have an authenticated originator value that is not the string displayed as Caller-ID.[*]  I understood the purpose of the wg to be ensuring that the displayed string was authorized by its assignee.
> 
>     If no one cares about this distinction and everyone feels that "authenticate the originator" is sufficiently precise and accurate, fine, but I thought it worth making sure.

It took me a while to grok what you mean, because from my perspective STIR is about verifying the received Caller-ID is authentic for a given call request, and authenticating it to be so - not that STIR is authorizing the originator to make a call.  But really what you mean is STIR is about verifying the originator of the call request is authorized to use the claimed caller-id.

How about this:
    As its first work item, the working group will specify a SIP 
    header-field-based mechanism to verify the originator of a 
    SIP session is authorized to use the claimed source identifier, 
    where the identity is a telephone number and the session is 
    established with SIP end to end.

-hadriel

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 15 Jul 2013 14:45:30 -0400

You know I have to agree with Dave here.  The central problem with any out
of band mechanism is trying to understand if its is actually deployable. 

First the existing TDM Class infrastructure is not going to be modified in
any way shape or form. That has to be considered a given here.

The conversion of the PSTN to the Public SIP Telephony Network is
progressing a breathtaking pace. I would hazard a guess that fully 50% or
more of all voice in the US will use SIP/IMS in the core within 3 years once
the conversion of the mobile networks to VoLTE begins and it is coming.

I read EKR's draft with some amusement since it attempts, again to rely on
endpoints actually being intelligent, when in fact they may not be and the
vast majority of SIP endpoints will continue to be "black phone B2BUA's"
with SIP used for switching and interconnection.  This will certainly be
true in residential and SMB markets.  This is what is happening in the
market today with anyone with a voice service from Cable Operator, ATT
Verizon etc that have "digital voice services".  Not to mention I'm equally
skeptical such validation methods will reach the smartphone handsets. 

This statement is simply incorrect.

"While the core network of the PSTN remains fixed, the endpoints of
   the telephone network are becoming increasingly programmable and
   sophisticated.  Landline "plain old telephone service" deployments,
   especially in the developed world, are shrinking, and increasingly
   being replaced by three classes of intelligent devices:  smart
   phones, IP PBXs, and terminal adapters.  All three are general
   purpose computers, and typically all three have Internet access as
   well as access to the PSTN.  This provides a potential avenue for
   building an authentication system that changes only the endpoints
   while leaving the PSTN intact."

I take it you have a unlimited data roaming plan? 

I have enormous trouble believing for one instant that CUA's are going to
play a meaningful role in Validation/Authentication/Authorization. IMHO this
is a network service. To additionally postulate that consumers and business
are going to sign up for some rendezvous call placement service is almost
preposterous. That is what a SIP proxy CSCF should do and I'm happy to pay
Verizon etal  to do that.  That is why they are called "service providers"
irrespective of what the access device is and what the last mile
infrastructure is.

I'm certainly willing to listen to ideas about out of band solutions
especially at the wholesale carrier GW layer. But right now its clear to me
the shortest first path to success is defining what in band looks like
within the SIP headers so it's possible to move on to the real heavy lifting
of what the directory look up system might look like.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave
Crocker
Sent: Sunday, July 14, 2013 11:51 PM
To: Peterson, Jon
Cc: IETF STIR Mail List
Subject: Re: [stir] Draft STIR Charter

Actually, you did:

>> simultaneously," some STIR deployments would be capable of doing 
>> both, and yes under the model I at least have in mind they would do both.

Perhaps you didn't mean it or that you meant something else.  This merely
underscores the confusion I cited about what exactly is meant by an
out-of-band mechanism, who it's actors would be and when it would be used --
I'll also toss in how the actors will know they are to use it.

Without a fair sense of answers to all of the above, we can't have any idea
what the engineering challenges for the mechanism will be, or even whether
the mechanism is viable.

> Instead, what I've said is that there are different applicabilities 
> for these two proposed mechanisms.

There's a nice term for such an approach and, I might add, quite a bit of
experience with its applicability.  The term is "non-interoperable'.

d/

---

From: Michael Hammer <[email-masked]>
Date: Mon, 15 Jul 2013 18:55:41 +0000

Would you want to say:  "to verify the *authenticated* originator"

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hadriel Kaplan
Sent: Monday, July 15, 2013 2:43 PM
To: [email-masked]
Cc: IETF STIR Mail List; Russ Housley
Subject: Re: [stir] Draft STIR Charter

It took me a while to grok what you mean, because from my perspective STIR
is about verifying the received Caller-ID is authentic for a given call
request, and authenticating it to be so - not that STIR is authorizing the
originator to make a call.  But really what you mean is STIR is about
verifying the originator of the call request is authorized to use the
claimed caller-id.

How about this:

-hadriel

---

From: "Cannon, Matthew" <[email-masked]>
Date: Mon, 15 Jul 2013 15:07:31 -0400

It seems to me that there is a pretty large implication to this small
change in wording. Providing a SIP header mechanism that allows a called
party to authenticate the claimed source identifier was really provide by
the originator is very different than a header that lets a called party
authenticate that the claimed source identifier was really provide by the
originator and that the originator is authorized to use that source
identifier.

Considering the various national variations on how a service provider is
'authorized' to represent a callers TN in an originating call, this might
be more than a bit of a challenge as far as a solution goes.

matt

On 7/15/13 2:42 PM, "Hadriel Kaplan" <[email-masked]> wrote:

>It took me a while to grok what you mean, because from my perspective
>STIR is about verifying the received Caller-ID is authentic for a given
>call request, and authenticating it to be so - not that STIR is
>authorizing the originator to make a call.  But really what you mean is
>STIR is about verifying the originator of the call request is authorized
>to use the claimed caller-id.
>
>How about this:

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 15 Jul 2013 19:11:31 +0000

Today, millions of users subscribe to end-system based call filtering and rating services on smart phones, so there is some existence proof that they fulfill a need, however limited these service are by necessity. There are at least a dozen such apps available on the various app stores. Given that more than half of all cell phones are smartphones, this is not a trivial market, recognizing that it doesn't help many users.

I suspect we'd all prefer a solution that achieves 100% coverage by network providers, sooner rather than later.

Some may prefer a solution that offer 80% coverage by network providers supplemented by 15% by end-to-end solutions to leaving those 20% exposed to the tender mercies of Rachel from Credit Card Services.

Rather than a somewhat-unhelpful discussion on general principles, maybe it would be more conducive to forward progress to see how we can deal with various kinds of non-implementation by having mechanisms that work together, e.g., share the keying/certificate infrastructure, and maybe even other components. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Shockey
Sent: Monday, July 15, 2013 2:46 PM
To: [email-masked]; 'Peterson, Jon'
Cc: 'IETF STIR Mail List'
Subject: Re: [stir] Draft STIR Charter

You know I have to agree with Dave here.  The central problem with any out of band mechanism is trying to understand if its is actually deployable. 

First the existing TDM Class infrastructure is not going to be modified in any way shape or form. That has to be considered a given here.

The conversion of the PSTN to the Public SIP Telephony Network is progressing a breathtaking pace. I would hazard a guess that fully 50% or more of all voice in the US will use SIP/IMS in the core within 3 years once the conversion of the mobile networks to VoLTE begins and it is coming.

I read EKR's draft with some amusement since it attempts, again to rely on endpoints actually being intelligent, when in fact they may not be and the vast majority of SIP endpoints will continue to be "black phone B2BUA's"
with SIP used for switching and interconnection.  This will certainly be true in residential and SMB markets.  This is what is happening in the market today with anyone with a voice service from Cable Operator, ATT Verizon etc that have "digital voice services".  Not to mention I'm equally skeptical such validation methods will reach the smartphone handsets. 

I have enormous trouble believing for one instant that CUA's are going to play a meaningful role in Validation/Authentication/Authorization. IMHO this is a network service. To additionally postulate that consumers and business are going to sign up for some rendezvous call placement service is almost preposterous. That is what a SIP proxy CSCF should do and I'm happy to pay Verizon etal  to do that.  That is why they are called "service providers"
irrespective of what the access device is and what the last mile infrastructure is.

I'm certainly willing to listen to ideas about out of band solutions especially at the wholesale carrier GW layer. But right now its clear to me the shortest first path to success is defining what in band looks like within the SIP headers so it's possible to move on to the real heavy lifting of what the directory look up system might look like.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave Crocker
Sent: Sunday, July 14, 2013 11:51 PM
To: Peterson, Jon
Cc: IETF STIR Mail List
Subject: Re: [stir] Draft STIR Charter

Perhaps you didn't mean it or that you meant something else.  This merely underscores the confusion I cited about what exactly is meant by an out-of-band mechanism, who it's actors would be and when it would be used -- I'll also toss in how the actors will know they are to use it.

Without a fair sense of answers to all of the above, we can't have any idea what the engineering challenges for the mechanism will be, or even whether the mechanism is viable.

There's a nice term for such an approach and, I might add, quite a bit of experience with its applicability.  The term is "non-interoperable'.

> I don't think
> anyone could reasonably maintain that an in-band solution for SIP 
> would be a complete solution for the robocalling or voicemail hacking 
> out there in the wild today.

Right.  So it's a good thing, indeed, that no one has attempted to maintain that, isn't it?

d/

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 15 Jul 2013 19:20:58 +0000

I think the classical terms of "authentication" and "authorization" don't quite apply here, as we're trying to ascertain the right to use an identifier, not authenticate to a service (establish identity) or be authorized to use a service (establish capability). In some cases, the caller may well authenticate to the provider or the carrier may authenticate to the number administrator and be authorized to retrieve a public key or certificate, but that's a separate component.

One way to phrase this is to state simply "is the caller entitled to use the telephone number in the callerID information", avoiding the a*e vs. a*o debate altogether and, I think, stating the goal reasonably accurately.

One indication that this is different is that none of us have been talking about using RADIUS/DIAMETER or 802.1.x or Kerberos for this - not just as a specific protocol, but as a model. I'm guessing that neither DKIM or SPF consider that authorization. (A quick check of RFC 4871 shows only 3 uses of the term authorize, and they seem to relate to authorization to use an outgoing mail server. The term "authentication" appears more frequently, if loosely, mostly as "authenticated email" or "authenticity".)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Hammer
Sent: Monday, July 15, 2013 2:56 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [stir] Draft STIR Charter

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
Sent: Monday, July 15, 2013 2:43 PM
To: [email-masked]
Cc: IETF STIR Mail List; Russ Housley
Subject: Re: [stir] Draft STIR Charter

>     The text is only about authentication, but the discussion has been
about authorization.  For example one might have an authenticated originator value that is not the string displayed as Caller-ID.[*]  I understood the purpose of the wg to be ensuring that the displayed string was authorized by its assignee.
>     If no one cares about this distinction and everyone feels that
"authenticate the originator" is sufficiently precise and accurate, fine, but I thought it worth making sure.

How about this:

-hadriel

---

From: Brian Rosen <[email-masked]>
Date: Mon, 15 Jul 2013 15:36:14 -0400

As an individual, I strongly support the notion we need an out of band solution to get to the goal.  Exactly how that works isn't yet clear to me, but it's necessity is, because I don't believe we will have enough "end to end" SIP in the time frame we need solutions.

I wanted to respond to one little tidbit:

> But right now its clear to me

If we do something along the lines of 4474 for the in band solution, we need a non-centralized storage for credentials that can be used to dereference a URI in the header which leads to the credential, but we don't need any look-up mechanism.

If you want to call the thing that delivers the credential from a URI obtained from the SIP header a "look up mechanism", okay, but it's not a public TN to credential mapping service.

EKR's proposal needs one of those, but the in-band mechanism doesn't.

One of the reasons to at least consider out of band mechanisms is the effect it has on credential storage.  If you have something along the lines of my proposed alternative (new DB written by SIP->SS7 and queried by SS7-SIP GW which restores the signature), it doesn't need one either.

Brian

---

From: Michael Hammer <[email-masked]>
Date: Mon, 15 Jul 2013 19:59:25 +0000

Whether you want to say "authorization" or "entitlement checking" doesn't
matter as much to me.
The important point is that authenticating a self-signed certificate may
prove nothing.
There needs to be some traceability of the private key used to sign back to
the chain of assignments from the number resource authority.

This is an odd cat.  It doesn't tell you who signed, just that the tel# to
private key binding was delegated appropriately.

Mike

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Monday, July 15, 2013 3:21 PM
To: Michael Hammer
Cc: [email-masked]
Subject: RE: [stir] Draft STIR Charter

I think the classical terms of "authentication" and "authorization" don't
quite apply here, as we're trying to ascertain the right to use an
identifier, not authenticate to a service (establish identity) or be
authorized to use a service (establish capability). In some cases, the
caller may well authenticate to the provider or the carrier may authenticate
to the number administrator and be authorized to retrieve a public key or
certificate, but that's a separate component.

One way to phrase this is to state simply "is the caller entitled to use the
telephone number in the callerID information", avoiding the a*e vs. a*o
debate altogether and, I think, stating the goal reasonably accurately.

One indication that this is different is that none of us have been talking
about using RADIUS/DIAMETER or 802.1.x or Kerberos for this - not just as a
specific protocol, but as a model. I'm guessing that neither DKIM or SPF
consider that authorization. (A quick check of RFC 4871 shows only 3 uses of
the term authorize, and they seem to relate to authorization to use an
outgoing mail server. The term "authentication" appears more frequently, if
loosely, mostly as "authenticated email" or "authenticity".)

-----Original Message-----

Mike

-----Original Message-----

How about this:

-hadriel

---

From: Dave Crocker <[email-masked]>
Date: Mon, 15 Jul 2013 13:03:53 -0700

> The important point is that authenticating a self-signed certificate may

That depends upon the derivation of the certificate.  For example, DKIM 
uses self-signed certificates, but they are stored in a place in the DNS 
that belongs to the owner of the name being authenticated.  Hence, the 
presence of the key in that location means that the owner of the name 
put it there.

d/

---

From: Michael Hammer <[email-masked]>
Date: Mon, 15 Jul 2013 20:15:11 +0000

This would seem to be circular logic since we are trying to discover who is
the "owner" of the name.
Would that not mean that the national authority needs to maintain that place
and self-sign all the certs?

Mike

-----Original Message-----
From: Dave Crocker [mailto:[email-masked]] 
Sent: Monday, July 15, 2013 4:04 PM
To: Michael Hammer
Cc: [email-masked]
Subject: self-signing certificates ( was Re: [stir] Draft STIR Charter )

On 7/15/2013 12:59 PM, Michael Hammer wrote:
> The important point is that authenticating a self-signed certificate 
> may prove nothing.

That depends upon the derivation of the certificate.  For example, DKIM uses
self-signed certificates, but they are stored in a place in the DNS that
belongs to the owner of the name being authenticated.  Hence, the presence
of the key in that location means that the owner of the name put it there.

d/

---

From: Dave Crocker <[email-masked]>
Date: Mon, 15 Jul 2013 13:19:53 -0700

> This would seem to be circular logic since we are trying to discover who is

Not quite.  We're trying to verify that the owner has authorized the use 
of the number in the caller-id field for this call.

This is usefully different; for one thing, it is an easier 
privacy-maintaining function.

> and self-sign all the certs?

There does needs to be a basis for trust the storage 'place' for the 
key, yes...

d/

---

From: Dan York <[email-masked]>
Date: Mon, 15 Jul 2013 20:25:40 +0000

>presence of the key in that location means that the owner of the name

This sounds a whole lot like one mode of DANE where you store the entire
certificate (self-signed or CA-signed) in the TLSA record.  You could say
that the presence of the key in the TLSA record means that the owner of
the name put it there.  Of course, DANE is used in conjunction with DNSSEC
to *prove* that the owner of the name put it there. (Although to be
precise, DANE/DNSSEC proves that the *operator* of the zone put that
information in there.)

Dan

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 15 Jul 2013 16:59:38 -0400

> As an individual, I strongly support the notion we need an out of band solution to get to the goal.  Exactly how that works isn't yet clear to me, but it's necessity is, because I don't believe we…

We seem to be repeating the same arguments using different words, so I'll repeat mine too:

I fully agree that there is a large market of smartphones, apps, and a billion uses for them; and that caller-id verification could be one of those uses.  I fully agree that a smartphone-to-smartphone solution would cover some percentage of calls.  I generally agree in theory that the overall coverage would be improved if there were multiple usable and actually-used ways of verifying caller-id.  For that matter, having two dozen different mechanisms might improve overall coverage too.

But that's not sufficient justification for forming a working group, nor for creating a specific solution.  Even if we had interested IETF participants for doing it, just because we publish an RFC means absolutely nothing.  If we don't want to waste everyone's time, we need to know (1) the requirements for such a mechanism, (2) the features/capabilities such a mechanism needs to be successful, and (3) some indication that it would be useful and actually *used* by people. 

To get those three things, we need participation from multiple potential implementers of the technology, and participation from potential deployers/administrators of it.  Otherwise we're just shooting darts at a dartboard.  We've done that before in RAI, and were then shocked that no one implemented the resulting RFCs, or we didn't publish an RFC because we realized it was futile.  We did it with numerous RFCs, and we did it when we formed ATOCA, BLISS, P2PSIP, and SPLICES WGs.  We need to learn from our mistakes.

Forming a working group or specifying a solution without the right participants involved is a complete waste of time.  And we don't have the right participants involved for a smartphone app-based out-of-band solution.

We could try and find some of them, but that hasn't happened.  My personal belief is they don't want our help, and don't need our help.  Afaict, you don't need an IETF standard to deploy such a thing today, and you wouldn't want to be constrained by an IETF spec or process timeline to begin with.

-hadriel

---

From: Brian Rosen <[email-masked]>
Date: Mon, 15 Jul 2013 17:05:54 -0400

You are making assumptions I am not.

I am not assuming the endpoints are the only entities that use the out of band solution - an SP may use them on it's behalf.  EKR agrees.

I am not assuming out of band means end to end.  I've proposed alternatives that work with SS7 hops that don't depend on UUI transparency for example.

I agree that creating documents that don't get implemented is not helpful for this work.

Brian

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 15 Jul 2013 17:22:52 -0400

> Some may prefer a solution that offer 80% coverage by network providers supplemented by 15% by end-to-end solutions to leaving those 20% exposed to the tender mercies of Rachel from Credit Card Ser…

I don't think the math will work out that way though.  I have a hunch that the 15% coverage for smartphone-based caller-id verification would 99% overlap the 80% coverage by network providers doing in-band.  In other words, my guess is the mobile phone providers would almost all be the type of network providers who would do the in-band thing anyway, and my guess is they'd even be among the early-adopters.

The 20% of network providers who wouldn't do the in-band thing, are the type of providers who serve purely TDM access, without smartphones, and for customers who wouldn't/couldn't do an out-of-band thing either.  There's no solution for them no matter what we do.

In a Venn diagram, my guess is the in-band coverage almost completely overlaps any smartphone-app coverage, if we do a good job with in-band.

-hadriel

---

From: Michael Hammer <[email-masked]>
Date: Mon, 15 Jul 2013 21:24:18 +0000

Squeezing the balloon?  :)

I would hope that it is intuitively obvious to validate the chain of trust.
At least as obvious as tracing a series of certificates to a well-known one.

Mike

-----Original Message-----
From: Dave Crocker [mailto:[email-masked]] 
Sent: Monday, July 15, 2013 4:20 PM
To: Michael Hammer
Cc: [email-masked]; [email-masked]
Subject: Re: self-signing certificates ( was Re: [stir] Draft STIR Charter )

On 7/15/2013 1:15 PM, Michael Hammer wrote:
> This would seem to be circular logic since we are trying to discover 
> who is the "owner" of the name.

Not quite.  We're trying to verify that the owner has authorized the use of
the number in the caller-id field for this call.

d/

---

From: Brian Rosen <[email-masked]>
Date: Mon, 15 Jul 2013 17:29:47 -0400

You are assuming that the pink carriers interwork with the mobile carriers with a SIP path in the timeframe we can deploy.

The pink guy starts out SIP, but you have to posit the wireless networks doing SIP interwork with Tier 2 CLECs in a couple years.  That seems unlikely from where I sit.

Much more likely that a VoIP carrier does than a wireless carrier.  We'll see of course.  

Brian

---

From: Dave Crocker <[email-masked]>
Date: Mon, 15 Jul 2013 14:37:26 -0700

> I am not assuming the endpoints are the only entities that use the out of band solution - an SP may use them on it's behalf.  EKR agrees.

Hadriel isn't making an assumption. He, I and I think others are simply 
hearing some folks consistently point specifically (and exclusively) to 
the end-to-end approach of doing Out-of-band.

At the least, you and EKR seem to be entertaining importantly different 
models.

 From EKR's draft:

>      Abstract:
...
>      This document describes a mechanism for two compliant endpoints.

The Abstract does not mention other actors participating in the 
validation mechanism.

 >    Introduction
...
 >    This provides a potential avenue for
 >    while leaving the PSTN intact.

Again, no mention of other uses in the Introduction.

> 2.  Operating Environment

We finally see activity in gateways, but only as a limited alternative:

>              Similarly, the gateway
>    would verify Alice's identity, generate the right caller-id
>    information and provide caller-id information to Bob using ordinary
>    POTS mechanisms.

Section 3 is only in terms of end-points.

> 4.1.  Phone Number Authentication
...
>              For purposes of exposition we will assume
>    that ownership is associated with the endpoint (e.g., a smartphone)
>    but it might well be associated with a gateway acting for the
>    endpoint instead.  It might be the case that multiple entities are

And the exclusively end-to-end use of out-of-band has been pressed by 
others.

There has been minimal acknowledgement of the possible role of other 
components in the sequence.

Using this function as a gateway trick for dealing with intermediary 
PSTN hops could make quite a bit of sense.  But that sort of 'tunneling' 
approach has significantly different OA&M characteristics than the 
end-to-end one.

d/

---

From: Dave Crocker <[email-masked]>
Date: Mon, 15 Jul 2013 14:43:07 -0700

> You are assuming that the pink carriers interwork with the mobile carriers with a SIP path in the timeframe we can deploy.

He's assuming that the math is more delicate than what is otherwise 
being offered and that there are likely to be interaction effects 
distorting the sampling and therefore affecting the numbers.  That is, 
these are not entirely independent populations being sampled.

In other words, he's right.

Rather than criticize the details of his criticism, anyone promoting 
effort on a second mechanism has an affirmative obligation to make a 
solid argument for its success.

Solid arguments for "sufficient" use deal with implementation, 
deployment and use, and the basis for predicting the likelihood and 
scale of each.

d/

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 15 Jul 2013 22:38:16 +0000

Inline.

>That describes usage that is fully redundant.

I don't think there's much value in arguing over what you think what I
said means, but in my last mail of the current thread, I already referred
to having said exactly what you reproduce above, but I certainly didn't
use the words "fully redundant" or anything that I believe encourages that
interpretation. For the two approaches to be "fully redundant," there
would be no case you could use one where you couldn't use the other, and
no use of one that the other couldn't also fulfill. That isn't the case
with in-band and out-of-band.

I said there are some STIR deployments that would be capable of doing
both, in the model I have in mind. For example, I have in mind a model
where out-of-band support could be implemented in smart phones, and
in-band support in a network element. A smart phone could have no idea
that the network is using in-band, nor the network about the smart phone's
usage of out-of-band. In that environment, sure, both could be used on the
originating side. And potentially, both could even be consumed by
mutually-unaware elements on the terminating side, or maybe just one
element, or maybe none.

>used -- I'll also toss in how the actors will know they are to use it.

I think people are arguing for slightly different scopes for out-of-band,
and that under different models there could be different actors. Saying
that this constitutes "confusion" is, like "fully redundant," an
interpretation projected onto the situation.

>whether the mechanism is viable.

Some few times in this thread, people have mentioned the existence of
smart phone services that do a form of out-of-band verification today.
People have pointed to services like iMessage that coordinate out-of-band
rendezvous between smartphones and provide identity assertions. That VIPR
thing did get some deployment too. So we believe there are existence
proofs that it is possible to field something along these lines. Agreed
that there are possible approaches to out-of-band that would not be
viable, and we'd be wise not to choose one.

>of experience with its applicability.  The term is "non-interoperable'.

Well, sometimes, DKIM gets used. And sometimes PGP gets used. The entities
that use DKIM and the entities that use PGP aren't really the same. They
don't coordinate. I'm sure it happens that sometimes both are used
simultaneously. The interoperability failure there isn't apparent to me.

>fully redundant for /some/ callees.)

In the case where in-band and out-of-band on the originating are literally
being managed by the same device or service, I think it's about as
redundant as a SIP INVITE proposing two codecs in the hope that the far
side supports one of them. You do it when you can't anticipate the
capabilities of the far side, as it increases your chances of
interoperating successfully. That doesn't mean the two codecs have
identical properties, though: one might be much higher-bandwidth, say, and
thus preferred. I don't think that's "full" redundancy, and I don't think
it is in this proposed STIR case either.

Now that much said, I also think the case where both an in-band and
out-of-band would be provided by literally the same device is probably
less likely than the smartphone/out-of-band network/in-band simultaneous
usage. Again, much like it must happen for email.

>Sorry, but I've no idea what this paragraph means or how it responds.

If the problem is to try to address robocalling and voicemail hacking, and
those problems are not limited than the IP world, then should the scope of
our work be limited to the IP world?

>solution, the answers also out to be very simple and basic.

I don't have all the answers about the solution. I do think we have a
reasonable idea of what the problem is, and what some approaches are -
enough to charter it and to work on it. As with many things in the IETF,
different proposals for addressing problems will arise, and we sort
through them, and hopefully we pick a good answer.

Jon Peterson
Neustar, Inc.

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 15 Jul 2013 22:39:35 +0000

There are some smartphone operating system vendors participating pretty
actively in the IETF. Some of the things we're thinking about might be
things it would be better for operating system vendors to address.

Perhaps more materially, the scope of out-of-band isn't limited to smart
phones. It includes things like IP PBX makers. At least one IP PBX maker
has previously come to the IETF with an interest in working on an
out-of-band mechanism here.

So, not sure I agree, but I agree it's a valid question.

Jon Peterson
Neustar, Inc.

On 7/15/13 1:59 PM, "Hadriel Kaplan" <[email-masked]> wrote:

>> As an individual, I strongly support the notion we need an out of band
>>solution to get to the goal.  Exactly how that works isn't yet clear to
>>me, but it's necessity is, because I don't believe we will have enough
>>"end to end" SIP in the time frame we need solutions.
>
>I fully agree that there is a large market of smartphones, apps, and a
>billion uses for them; and that caller-id verification could be one of
>those uses.  I fully agree that a smartphone-to-smartphone solution would
>cover some percentage of calls.  I generally agree in theory that the
>overall coverage would be improved if there were multiple usable and
>actually-used ways of verifying caller-id.  For that matter, having two
>dozen different mechanisms might improve overall coverage too.
>
>But that's not sufficient justification for forming a working group, nor
>for creating a specific solution.  Even if we had interested IETF
>participants for doing it, just because we publish an RFC means
>absolutely nothing.  If we don't want to waste everyone's time, we need
>to know (1) the requirements for such a mechanism, (2) the
>features/capabilities such a mechanism needs to be successful, and (3)
>some indication that it would be useful and actually *used* by people.
>
>To get those three things, we need participation from multiple potential
>implementers of the technology, and participation from potential
>deployers/administrators of it.  Otherwise we're just shooting darts at a
>dartboard.  We've done that before in RAI, and were then shocked that no
>one implemented the resulting RFCs, or we didn't publish an RFC because
>we realized it was futile.  We did it with numerous RFCs, and we did it
>when we formed ATOCA, BLISS, P2PSIP, and SPLICES WGs.  We need to learn
>from our mistakes.
>
>Forming a working group or specifying a solution without the right
>participants involved is a complete waste of time.  And we don't have the
>right participants involved for a smartphone app-based out-of-band
>solution.
>
>We could try and find some of them, but that hasn't happened.  My
>personal belief is they don't want our help, and don't need our help.
>Afaict, you don't need an IETF standard to deploy such a thing today, and
>you wouldn't want to be constrained by an IETF spec or process timeline
>to begin with.
>
>-hadriel
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 15 Jul 2013 20:08:28 -0400

> You are assuming that the pink carriers interwork with the mobile carriers with a SIP path in the timeframe we can deploy.

Nope - the "pink" carriers aren't the originators/terminators we care about.  They're what let the robocallers in to begin with.  They're "pink" for a reason, and the polite reason would be that they're too under-staffed or inexperienced to have put customer caller-id policing controls in place already today.  They'll continue to be "pink" even when we have in-band or out-of-band.  We're not going to get the bad guys telling us they're bad.  We can only get the good guys telling us they're good.

What I am assuming is that the path between the set of call originators who are the type that would publish their info into an out-of-band thing, and the set of call receivers who are the type that would retrieve the info from an out-of-band thing, will mostly be a SIP path by the time we could have specified an out-of-band thing and gotten it widely deployed.  At least that's my assumption for North America, and in certain countries in Europe, Asia, Middle East, and at least one country in Africa. 

> The pink guy starts out SIP, but you have to posit the wireless networks doing SIP interwork with Tier 2 CLECs in a couple years.  That seems unlikely from where I sit.

How so?  The wireless carriers have to use SIP to peer, yes, but not with Tier-2 CLECs.  They can SIP peer to Tier-1 carriers, and those can SIP peer with Tier-2 CLECs.  It's not a full mesh connection model, and never has been - you know that, so I'm confused by your statement. (maybe I'm missing something?)

If the Tier-1 carriers don't SIP peer with Tier-2 CLECs, then it's for one of two reasons: (1) the Tier-2 CLEC still uses SS7/TDM itself, in which case the Tier-2 isn't going to be doing squat for caller-id anyway, or (2) it's just a short SS7 hop into a SIP-based CLEC, in which case they can either use the UUI model or bite the bullet and move to SIP peering.

And it's not a "couple years".  It will take us longer than that just to get an out-of-band solution published as an RFC, let alone the timeframe needed for it to be deployed and a Tier-2 CLEC or its customers to use it.

Let's say it takes 2 years to get an out-of-band into an RFC.  After that more time for the vendors implement it, getting tested in carriers, etc.  Even 3 years altogether would be a minor miracle.  Meanwhile, how long do you think before a significant majority of the carriers in North America interconnect using SIP?  5 years?  Let's say it's 7 years.  The time difference between the 3 years to get out-of-band and 7 years for in-band would be 4 years.  We'd do all that work, carriers would spend all that time and money, all for a 4-year lifespan for 15% caller-id coverage?!?  How does that make any sense?

-hadriel

---

From: Dave Crocker <[email-masked]>
Date: Mon, 15 Jul 2013 21:53:08 -0700

Jon,

On 7/15/2013 3:38 PM, Peterson, Jon wrote:
> said means, ...
> For the two approaches to be "fully redundant," there
> no use of one that the other couldn't also fulfill.

Since you say arguing is of little value, it's odd that you then went on 
to impose a definition that significantly conflicts with the 
characterization I provided repeatedly:  The caller creates the 
authentication information for every call, using both mechanisms.

> I think people are arguing for slightly different scopes for out-of-band,

End-to-end vs. only in gateways vs.  ...? are not "slight" differences. 
They probably have significant technical differences and are certain to 
have substantial operational differences.

> smart phone services that do a form of out-of-band verification today.

That's not terribly important, since I don't recall anyone saying that 
it was not technically feasible to perform the function.

The concern has been about costs and likely (or unlikely) scaling of 
adoption and use, in terms of the general problem that is motivating the 
group.

> Well, sometimes, DKIM gets used. And sometimes PGP gets used.

Jon, seriously?  You're invoking that one again?

One of the hallmarks of constructive exchange is that both sides must 
pay attention to what the other says and must incorporate it into 
following responses.  This permits some degree of incremental progress.

Instead, here you seem to have entirely missed the response I offered 
when you earlier attempted to call DKIM and PGP 'redundant'.

Since repetition seems to be the hallmark of today's mailing list 
activity: they are entirely different mechanisms, in terms of syntax and 
semantics.  In other words: they have nothing to do with each other.

So whatever you intended to demonstrate by the DKIM/PGP reference, 
again, the reality is that it's irrelevant to the current discussion.

> The entities

And this seems to continue the irrelevancy to somehow claim that it 
shouldn't be classed as an interoperability failure and this somehow is 
responsive to my own reference?

So let's be clear:  interoperability failure means that two (or more) 
entities that are seeking to interoperate using the same protocols fail 
to do so.

My previous reference to non-interoperability was pointing out that the 
caller and callee are seeking to validate the Caller-ID value and that 
having the usage mixture of mechanisms that you described is likely to 
lead to one of them using one mechanism and the other use a different 
one, thereby ensuring that they fail to achieve the validation they both 
wanted.

> redundant as a SIP INVITE proposing two codecs in the hope that the far

You think that including an offer list -- a list of options -- is 
comparable cost to the caller's doing all the work of performing two 
authentication functions?

Really?

(Now, if you had cited MIME multipart/alternative, it might be a bit 
more interesting, but you didn't, so it isn't...)

> our work be limited to the IP world?

As you state it, that's not the issue here.  The issue here is how to 
approach dealing with a very complex operational environment.

A term like "divide and conquer" is often applied.  More specifically -- 
and quite common to IETF efforts that are successful -- is to start with 
developing the smallest useful solution that can be deployed, and then 
add to it... over time.

So the most important issue is about project (working group) sequencing.

In particular, /start/ with a clean, SIP-based mechanism.  After that is 
done, consider enhancements that extend its utility.

> enough to charter it and to work on it.

If the listed "approaches" are clear enough to permit engineering 
estimates of feasibility, you are correct.

Unfortunately, we are not doing very well in garnering such technical 
substance.

d/

---

From: <[email-masked]>
Date: Tue, 16 Jul 2013 08:56:08 +0000

Charter-wise I would also prefer this phrasing than referring to authentication or "authenticate the originator of a SIP session". 

> "is the caller entitled to use the telephone number in the callerID information"

I understand that in some cases asserting that the caller is entitled to use a phone number may be enough for the receiving end to provide a given service and can therefore be used as some 'weak' or implicit authentication mechanism - all networks have to do that sometimes. 

Given the context, however, I'm with Dave's "meta point" on this. Using authentication would be confusing for me (mostly because of what the term conveys with regard to the network the sip user is registered with):
a) such authentication is generally carried out to provide a service to the subscriber with the TN, here the calling party, more rarely the called party; and 
b) it implies that the primary piece of information with which you identify the user is indeed the TN, whereas as a rule, [not all but] a large number of networks (SIP-based and others) generally try and separate what you identify/authenticate users with and what other users employ (the TNs) to set up a session/call with them - ie precisely try and not use TNs for the purpose of identification/authentication. 

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Hammer
Sent: Monday, July 15, 2013 2:56 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [stir] Draft STIR Charter

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
Sent: Monday, July 15, 2013 2:43 PM
To: [email-masked]
Cc: IETF STIR Mail List; Russ Housley
Subject: Re: [stir] Draft STIR Charter

How about this:

-hadriel

---

From: <[email-masked]>
Date: Tue, 16 Jul 2013 12:54:43 +0000

I'll use Hadriel's aside note (or was it?) as an opportunity to point out that in addition to the timeframe related to the introduction of the stir technology itself in the network elements, endpoints etc (which I don't disagree with), the 'administrative' part of that effort must also be considered/added: apologies if I'm stating the obvious or completely missed the purpose of all this, but it seems to me that it all relies on credentials being issued directly or indirectly by the "numbering plan authority/administrator".

This 'administrative' part could indeed be done in parallel and I appreciate that this effort may be more focused on some numbering plans than others, which may speed up the work for those, but 
a) it is to me quite as much on the critical path as the pure implementation part, which would be pointless without it, 
b) contrary to technology deployment, incremental/gradual introduction of such a framework under a given CC doesn't really make sense, it's pretty much on/off and 
c) it will be far from trivial for a lot of numbering plans and may take considerable effort and education. 

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
Sent: Tuesday, July 16, 2013 2:08 AM
To: Brian Rosen
Cc: IETF STIR Mail List; Henning Schulzrinne
Subject: Re: [stir] Draft STIR Charter

[snip]

-hadriel

---

From: Michael Hammer <[email-masked]>
Date: Tue, 16 Jul 2013 13:11:30 +0000

Philippe,

If the solution is kept simple, the education part should not require much
effort.

I don't see why the numbering plan would have any effect on how trivial it
might be, since asking the question what is your E.164 number should be easy
to answer.
Yes,  it is possible to make administrative aspects complicated, but if that
is painful, don't go there.  Could you elaborate more on that?

For example, if ultimately what is needed is a cert that binds a private key
with an E.164 number, it could be made more complicated by also including
the chain of service providers through which the key is delegated, but that
conflation of delegation complexity with the act of knowing a private key
matches with an E.164 number may be an act of shooting oneself in the foot.

I still like Occam's Razor and think that would be very useful here.

Thanks,
Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, July 16, 2013 8:55 AM
To: Hadriel Kaplan; Brian Rosen
Cc: IETF STIR Mail List; Henning Schulzrinne
Subject: [stir] Rollout timeframe (was: RE: Draft STIR Charter)

I'll use Hadriel's aside note (or was it?) as an opportunity to point out
that in addition to the timeframe related to the introduction of the stir
technology itself in the network elements, endpoints etc (which I don't
disagree with), the 'administrative' part of that effort must also be
considered/added: apologies if I'm stating the obvious or completely missed
the purpose of all this, but it seems to me that it all relies on
credentials being issued directly or indirectly by the "numbering plan
authority/administrator".

This 'administrative' part could indeed be done in parallel and I appreciate
that this effort may be more focused on some numbering plans than others,
which may speed up the work for those, but
a) it is to me quite as much on the critical path as the pure implementation
part, which would be pointless without it,
b) contrary to technology deployment, incremental/gradual introduction of
such a framework under a given CC doesn't really make sense, it's pretty
much on/off and
c) it will be far from trivial for a lot of numbering plans and may take
considerable effort and education. 

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----

[snip]

And it's not a "couple years".  It will take us longer than that just to get
an out-of-band solution published as an RFC, let alone the timeframe needed
for it to be deployed and a Tier-2 CLEC or its customers to use it.

Let's say it takes 2 years to get an out-of-band into an RFC.  After that
more time for the vendors implement it, getting tested in carriers, etc.
Even 3 years altogether would be a minor miracle.  Meanwhile, how long do
you think before a significant majority of the carriers in North America
interconnect using SIP?  5 years?  Let's say it's 7 years.  The time
difference between the 3 years to get out-of-band and 7 years for in-band
would be 4 years.  We'd do all that work, carriers would spend all that time
and money, all for a 4-year lifespan for 15% caller-id coverage?!?  How does
that make any sense?

-hadriel

____________________________________________________________________________
_____________________________________________

Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
exploites ou copies sans autorisation. Si vous avez recu ce message par
erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.

This message and its attachments may contain confidential or privileged
information that may be protected by law; they should not be distributed,
used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.

---

From: Brian Rosen <[email-masked]>
Date: Tue, 16 Jul 2013 09:16:52 -0400

This is an important point, and it's not something the IETF does particularly well, especially the "take considerable effort and education" part.  
The IETF has been paying more attention to relationships with governments and regulators lately, and I hope we will be able to leverage that effort.

Brian

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 16 Jul 2013 09:18:29 -0400

> things it would be better for operating system vendors to address.

Just because someone from Google, Apple, Microsoft, or RIM attend the IETF doesn't mean much.  The IETF is a big place, and operating system vendors do a lot of other things.  It's like saying the DIME Working Group could work on a SQL-based backend API description, because I happen to also attend the IETF and my employer does a lot of SQL stuff.  I know nothing about the SQL world, and I don't attend DIME. :)

> out-of-band mechanism here.

I would like to talk to them.  I am not an expert in their area at all, but as I understand it most IP PBXs offer a scripting/plugin model capability for third-parties/partners to write plugins, with an internal API to access call data and make call control decisions, and with external protocol access such as HTTP or LDAP or whatever.  I have looked at three big PBX vendors, and they all seem to have that model.  (heck, even my employer's SBCs offer that now, and plugins are much less applicable to us than to a PBX vendor)

The reason I mention it is because out-of-band STIR stuff is an obvious application for such a plugin model.  You deploy a database service, you partner with (pay) the 3 or 4 big PBX vendors and write plugins for their PBXs to talk to your database, and you write smartphone apps to talk to your database and give the app out for free.  You then could, for example, offer caller-id verification service for free, but charge money to Enterprises or consumers for putting additional related data into the database/call, such as business-card type information, company logo icon, etc.  Or you resell that type of service through the carriers, letting them sell the service to Enterprises for a cut of the revenue.

That's why I keep saying I don't understand why a smartphone-app-based solution provider would want to come to the IETF.  They shouldn't need a standardized spec to follow, shouldn't want to be constrained to what such a spec would make them do, and shouldn't want to wait for one to be produced by the IETF.

If anything, they might be helped by standardizing the plugin APIs used for call data and control, in the smartphones and PBXs - but that's not really possible or practical, for obvious reasons.

-hadriel

---

From: Brian Rosen <[email-masked]>
Date: Tue, 16 Jul 2013 09:23:00 -0400

There are a couple of aspects:
1. The number plan administrator has to create a credential issuing mechanism mirroring its number delegation processes.  That admin may not have any knowledge of how to do that, and we need it done well to avoid DigiNotar problems
2. The service providers have to create processes to handle the credentials issued by the number plan administrator and issue credentials to its customers
3. Some Tier 2/3 service providers in places where number resell is permitted have to develop processes with their number suppliers to handle credentials
4. We want to avoid having to chase a chain of credentials (each with OSCP or equivalent checks) at verification time.  This has some implications on how the above mechanisms work.

Brian

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 16 Jul 2013 09:35:51 -0400

Well remember you are perilously close to the precipice of dealing with
National Regulatory Authorities on Numbering.  It is a history that some of
us have ugly memories of.  I of course, mean ENUM and e164.arpa. This has
not reached the radar screen beyond the North American context..yet.

That said the problem clearly has reached some level of pain where
legislative/regulatory action may be required. I would certainly like to see
some study done by someone on the scope of the problem in other
jurisdictions.  The data here is very thin.

The good news is, current religious arguments aside, we may have a general
view of how the problem can be addressed. If we could understand the
structure of the SIP headers in some revision of 4474 and some mechanism
such as CIDER/DNS. Deploying a trial would not be unreasonable as proof of
concept.  Trials BTW are very popular at the FCC these days. :-) 

I have very little confidence that this can be flash cut into the existing
network. Proposing a technical solution will not make sense if regulatory
framework does not exist to support it and that really takes some time.  The
key is enforcement. Can/should service providers be required to implement a
STIR solution or do they believe it is in their economic best interests to
comply if for no other reason than the reduction in consumer complaints.
FYI part of the reason US carriers deployed an ENUM/MMS solutions was to
reduce consumer complaints on lack of interoperability. 

I actually believe INSIPID is equally important to the overall task since it
is the track and trace elements of this that can ultimately enable some
enforcement. I wish there was some more discussion on how the mechanisms
would work at the edge SIP/SS7 network gateways since that clearly has been
the center of most of the reported problems.  I still think something needs
to be done to police that traffic but that is still ultimately a regulatory
effort.

-----Original Message-----

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----

[snip]

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 16 Jul 2013 10:06:07 -0400

+1.

I think Philippe's point is more critical to ultimate success than the rest of the stuff we've been arguing about.

But we don't need the official number authorities to be involved to start this thing and get it useful.  We can start "trials" by just using a commonly-agreed-upon anchor or two in a given country.  Even if the trials grow to include multiple countries with different anchors for each country, it will still be manageable.  In fact, all ~160 country-codes could each define their own anchor and it would still be manageable.  Even for the +1 country-code, which is probably the most complicated in terms of numbering plan, authorities, and number of carriers - even for that we'd only really need a handful of the bigger carriers in a country-code to do it, and the rest would join up soon enough.

Ultimately, in some future time, we would likely want/need the numbering authorities to be involved.  But as Brian said, it's not something the IETF does particularly well.  We're an engineering organization mostly.  And as far as I can tell, much of our regulatory contact seems to be North American. (though I could easily be wrong about that)  For European regulators I would expect 3GPP and ETSI might help us out some on this issue. For Asia, South America, Middle East, and Africa, we could wait for this to percolate, or 3GPP might be able to help with them too.

I assume that the IETF does have formal or informal liaisons with at least the RIRs, and they might be able to make contact with the telephone numbering authorities in various countries.  Also, I've been told ISOC tries to help with IETF-related education/evangelism around the world too, but I'm not sure about dealing with regulators. (Dan: do you know?)

-hadriel

---

From: <[email-masked]>
Date: Tue, 16 Jul 2013 14:12:16 +0000

Mike,

I wasn't referring to the _structure_ of the numbering plan, sorry. I agree
it's pretty much orthogonal to the difficulty of that part of the task. 

Along the same line as Brian's post, I was referring to the time that would
be necessary for putting in place procedures and an operational framework
whereby when a decision is made by and under the control of the
administrator of assigning a range/number/... to... anyone say, the
corresponding credentials are issued; when ranges are reclaimed, credentials
are revoked; when assignment rulings are renewed by that administrator,
they're consistently renewed; what it all means when number ranges are
transferred between assignees, when they're suballocated to third parties if
it's permitted by the national policies, prohibited if it's not; what it
means when numbers are ported if portability applies etc.... 

Yes, maybe I'm overcomplicating things or being too pragmatic, I'm just
trying to see how that fits in the real life of a national numbering plan in
fact (given that there are national variations and that the generally people
in charge wouldn't contemplate applying for a security area AD position, no
more than I would, considering...) and how that translates into an
infrastructure upon which the mechanisms this group develops can rely. 

Not that I think the group could have some leverage on this administrative
part (and I agree with Richard that that part is indeed leaning towards
regulatory issues) other than making sure the documents that are developed
here are accessible to the layman, I was merely observing that it could
take... "quite some time".

Regards,

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]] 
Sent: Tuesday, July 16, 2013 3:12 PM
To: FOUQUART Philippe OLNC/OLN; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [stir] Rollout timeframe (was: RE: Draft STIR Charter)

Philippe,

Thanks,
Mike

-----Original Message-----

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----

[snip]

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 16 Jul 2013 10:21:13 -0400

> to be done to police that traffic but that is still ultimately a regulatory

I agree we need a tracking/tracing mechanism, but in my opinion we cannot and should not rely on INSIPID Session-ID at all for that.  They have gone beyond benign troubleshooting-type purposes now, which means there is absolutely no guarantee the Session-ID will make it intact across service providers in all cases.  In fact, my hunch is it won't.

Regardless, the Session-ID isn't what we really need for tracing a bad caller-id call.  Even without Session-ID, the service provider's CDRs or logs can be used to trace it back to the peering connection and peer upstream provider the call came in from.  What we also need is a list of SPIDs the call request has crossed through, so we can trace it back further upstream.  Kinda like a Via header, but with very different properties and purpose.  We've talked about doing that before, back when there was talk about creating a registry of SPIDs.  What ever happened to having a registry of SPIDs?

-hadriel

---

From: Brian Rosen <[email-masked]>
Date: Tue, 16 Jul 2013 10:45:01 -0400

If INSIPID's session ID won't survive end to end, what do you suggest we use here to avoid replay?

Brian

---

From: Brian Rosen <[email-masked]>
Date: Tue, 16 Jul 2013 10:48:51 -0400

Agree

The LoST notion of a Forest Guide may be useful here - the basic applicable notion is that there is some entity trusted by most/all providers in a country to refer queries not understood locally to the right service.  The forest guides cooperate with one another without a golden root.  They use administrative processes to determine who they should trust, and develop their own, small database of places to refer out of country requests to.   This has a very good chance of working here.

Brian

---

From: Dave Crocker <[email-masked]>
Date: Tue, 16 Jul 2013 07:57:02 -0700

> If INSIPID's session ID won't survive end to end, what do you suggest we use here to avoid replay?

Folks,

Question to the group:

There are a number of different styles of replay attack, with different 
likelihoods and different effects (nature/degree of damage).

What specific replay scenarios does the group deem it essential to 
prevent and why?

I've seen situations in which it was deemed acceptable to allow some 
types of potential replay attacks, because the potential for its 
occurrence and/or damage it would do were not a serious concern.

d/

---

From: Stephen Kent <[email-masked]>
Date: Tue, 16 Jul 2013 11:01:16 -0400

Phillipe,

> Charter-wise I would also prefer this phrasing than referring to authentication or "authenticate the originator of a SIP session".
 From a security terminology perspective, authentication is an 
appropriate term. For example,
RFC 4949 (Internet Security Glossary, v2) defines the term as follows:

authenticate
(I) Verify (i.e., establish the truth of) an attribute value
claimed by or for a system entity or system resource.

So, in this context, verifying that the TN asserted by a caller is 
accurate is a
reasonable use of the term.
> b) it implies that the primary piece of information with which you identify the user is indeed the TN, whereas as a rule, [not all but] a large number of networks (SIP-based and others) generally t…
Whether a TN or some other form of identifier may be authenticated in 
the proposed system
has a lot to do with who is providing the assertion about the ID. If 
there is one thing
we have learned from the browser trust anchor mess, it's that allowing a 
third party to
make assertions about identities for which it is not authoritative, is a 
very, very bad idea.
That's why. in the RPKI context, the certs are issued only by entities 
that are authoritative
for the resources for which they vouch, and the names that appear in 
these certs are,
intentionally, not human meaningful.

Steve

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 16 Jul 2013 11:02:56 -0400

Hadriel you are referring to the concept of a Global-SPID, which we have in
the North American numbering databases as the SPID, Alt-SPID or the NECA OCN
but are nonexistent on a global basis. 

This was an idea floated by some of the International Carriers within
i3Forum which is the rough grouping of International interconnects to create
the international equivalent of what we can do in NA which is determine who
is the originating/terminating carrier of record from entries in the
numbering databases. 
 
The running theory was a namespace could be created by IANA and populated by
and run by the RIR's which cold issue the credentials for a nominal fee
since IANA can't charge for registries and the Enterprise numbers and ITAD's
are rather "polluted" name spaces. You could also create some WHOIS like
mechanism as well.

I spoke to some of the RIR about this and they were supportive but needed a
full push from the International Carriers to participate in the RIR process
but this was not forthcoming. 

Like so many things timing is critical and use cases change over time if a
sufficiently large group of International carries wanted to do this I still
think it could be done..  I'm sad to hear that INSIPID is not working out as
planned.  That said at least we are in some agreement that STIR is not a
silver bullet but one of many mechanisms that need to be put in place. 
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hadriel Kaplan
Sent: Tuesday, July 16, 2013 10:21 AM
To: Richard Shockey
Cc: IETF STIR Mail List
Subject: Re: [stir] Rollout timeframe (was: RE: Draft STIR Charter)

On Jul 16, 2013, at 9:35 AM, "Richard Shockey" <[email-masked]> wrote:

> I actually believe INSIPID is equally important to the overall task 
> since it is the track and trace elements of this that can ultimately 
> enable some enforcement. I wish there was some more discussion on how 
> the mechanisms would work at the edge SIP/SS7 network gateways since 
> that clearly has been the center of most of the reported problems.  I 
> still think something needs to be done to police that traffic but that 
> is still ultimately a regulatory effort.

I agree we need a tracking/tracing mechanism, but in my opinion we cannot
and should not rely on INSIPID Session-ID at all for that.  They have gone
beyond benign troubleshooting-type purposes now, which means there is
absolutely no guarantee the Session-ID will make it intact across service
providers in all cases.  In fact, my hunch is it won't.

Regardless, the Session-ID isn't what we really need for tracing a bad
caller-id call.  Even without Session-ID, the service provider's CDRs or
logs can be used to trace it back to the peering connection and peer
upstream provider the call came in from.  What we also need is a list of
SPIDs the call request has crossed through, so we can trace it back further
upstream.  Kinda like a Via header, but with very different properties and
purpose.  We've talked about doing that before, back when there was talk
about creating a registry of SPIDs.  What ever happened to having a registry
of SPIDs?

-hadriel

---

From: Michael Hammer <[email-masked]>
Date: Tue, 16 Jul 2013 15:07:47 +0000

Brian,

1.  The DigiNotar problem points out two problems:  complexity of the
delegation and lack of oversight to the distributed processes.  It does not
say they lost faith in the mathematics of the certificates, since they
simply replaced the incompetent with other more competent administrators.
In fact, the delegation process seems to be source of the weakness of the
system.  So, may be good to learnt he right lessons there.

2.  Yes, there have to be processes for requesting an updated certificate
for a number, generating the certificate, distributing the certificate.
However, the distribution does not have to be tied to any hierarchy.  DNS
could do this via caching, but without the hierarchy complexity.  The reason
for updating a cert could be due to number portability, but the key trigger
is just knowing that it has ported and who the new SP is so that the private
key could be sent to the correct number-holder party.  We don't need all the
other complex routing trappings that NP already covers for routing, which is
not the issue here.

3.  The administrative chain and the cert distribution do not have to be the
same.

4.  By keeping the certificate validation NOT tied to a distribution
hierarchy you can simplify the validation process and not require private
systems such as CIDER suggests.

5.  From a hacker attach surface consideration, I do not think it a good
idea to make the DNS or some specific part of it a target more than it
already is.  Keeping this more about "information routing" and "how secure
is the mathematics breakability" questions improves both security and
deployability. 

I hope we start generating some requirements list, because I can think of
some that might make things simpler.

Mike

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, July 16, 2013 9:23 AM
To: Michael Hammer
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [stir] Rollout timeframe (was: RE: Draft STIR Charter)

There are a couple of aspects:
1. The number plan administrator has to create a credential issuing
mechanism mirroring its number delegation processes.  That admin may not
have any knowledge of how to do that, and we need it done well to avoid
DigiNotar problems 2. The service providers have to create processes to
handle the credentials issued by the number plan administrator and issue
credentials to its customers 3. Some Tier 2/3 service providers in places
where number resell is permitted have to develop processes with their number
suppliers to handle credentials 4. We want to avoid having to chase a chain
of credentials (each with OSCP or equivalent checks) at verification time.
This has some implications on how the above mechanisms work.

Brian

On Jul 16, 2013, at 9:11 AM, Michael Hammer <[email-masked]>
wrote:

> Philippe,
> 
> If the solution is kept simple, the education part should not require 
> much effort.
> 
> I don't see why the numbering plan would have any effect on how 
> trivial it might be, since asking the question what is your E.164 
> number should be easy to answer.
> Yes,  it is possible to make administrative aspects complicated, but 
> if that is painful, don't go there.  Could you elaborate more on that?
> 
> For example, if ultimately what is needed is a cert that binds a 
> private key with an E.164 number, it could be made more complicated by 
> also including the chain of service providers through which the key is 
> delegated, but that conflation of delegation complexity with the act 
> of knowing a private key matches with an E.164 number may be an act of
shooting oneself in the foot.
> Of [email-masked]
> I'll use Hadriel's aside note (or was it?) as an opportunity to point 
> out that in addition to the timeframe related to the introduction of 
> the stir technology itself in the network elements, endpoints etc 
> (which I don't disagree with), the 'administrative' part of that 
> effort must also be
> considered/added: apologies if I'm stating the obvious or completely 
> missed the purpose of all this, but it seems to me that it all relies 
> on credentials being issued directly or indirectly by the "numbering 
> plan authority/administrator".
> 
> This 'administrative' part could indeed be done in parallel and I 
> appreciate that this effort may be more focused on some numbering 
> plans than others, which may speed up the work for those, but
> a) it is to me quite as much on the critical path as the pure 
> implementation part, which would be pointless without it,
> b) contrary to technology deployment, incremental/gradual introduction 
> of such a framework under a given CC doesn't really make sense, it's 
> pretty much on/off and
> Of Hadriel Kaplan
> And it's not a "couple years".  It will take us longer than that just 
> to get an out-of-band solution published as an RFC, let alone the 
> timeframe needed for it to be deployed and a Tier-2 CLEC or its customers
to use it.
> 
> Let's say it takes 2 years to get an out-of-band into an RFC.  After 
> that more time for the vendors implement it, getting tested in carriers,
etc.
> Even 3 years altogether would be a minor miracle.  Meanwhile, how long 
> do you think before a significant majority of the carriers in North 
> America interconnect using SIP?  5 years?  Let's say it's 7 years.  
> The time difference between the 3 years to get out-of-band and 7 years 
> for in-band would be 4 years.  We'd do all that work, carriers would 
> spend all that time and money, all for a 4-year lifespan for 15% 
> caller-id coverage?!?  How does that make any sense?
> 
> -hadriel
> 
> ______________________________________________________________________
> ______ _____________________________________________
> 
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi 
> que les pieces jointes. Les messages electroniques etant susceptibles 
> d'alteration, Orange decline toute responsabilite si ce message a ete 
> altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law; they should not 
> be distributed, used or copied without authorisation.

---

From: Michael Hammer <[email-masked]>
Date: Tue, 16 Jul 2013 15:11:58 +0000

++1  Administrative complexity counts.

But, let us leverage existing painfully wrought systems such as number
portability rather than reinvent them.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hadriel Kaplan
Sent: Tuesday, July 16, 2013 10:06 AM
To: Brian Rosen; [email-masked]
Cc: IETF STIR Mail List; Dan York
Subject: Re: [stir] Rollout timeframe (was: RE: Draft STIR Charter)

+1.

I think Philippe's point is more critical to ultimate success than the rest
of the stuff we've been arguing about.

But we don't need the official number authorities to be involved to start
this thing and get it useful.  We can start "trials" by just using a
commonly-agreed-upon anchor or two in a given country.  Even if the trials
grow to include multiple countries with different anchors for each country,
it will still be manageable.  In fact, all ~160 country-codes could each
define their own anchor and it would still be manageable.  Even for the +1
country-code, which is probably the most complicated in terms of numbering
plan, authorities, and number of carriers - even for that we'd only really
need a handful of the bigger carriers in a country-code to do it, and the
rest would join up soon enough.

Ultimately, in some future time, we would likely want/need the numbering
authorities to be involved.  But as Brian said, it's not something the IETF
does particularly well.  We're an engineering organization mostly.  And as
far as I can tell, much of our regulatory contact seems to be North
American. (though I could easily be wrong about that)  For European
regulators I would expect 3GPP and ETSI might help us out some on this
issue. For Asia, South America, Middle East, and Africa, we could wait for
this to percolate, or 3GPP might be able to help with them too.

I assume that the IETF does have formal or informal liaisons with at least
the RIRs, and they might be able to make contact with the telephone
numbering authorities in various countries.  Also, I've been told ISOC tries
to help with IETF-related education/evangelism around the world too, but I'm
not sure about dealing with regulators. (Dan: do you know?)

-hadriel

On Jul 16, 2013, at 9:16 AM, Brian Rosen <[email-masked]> wrote:

> This is an important point, and it's not something the IETF does
particularly well, especially the "take considerable effort and education"
part.  
> The IETF has been paying more attention to relationships with governments
and regulators lately, and I hope we will be able to leverage that effort.
>> b) contrary to technology deployment, incremental/gradual 
>> introduction of such a framework under a given CC doesn't really make 
>> sense, it's pretty much on/off and
>> And it's not a "couple years".  It will take us longer than that just to
get an out-of-band solution published as an RFC, let alone the timeframe
needed for it to be deployed and a Tier-2 CLEC or its customers to use it.
>> _____________________________________________________________________
>> ____________________________________________________
>> 
>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que
les pieces jointes. Les messages electroniques etant susceptibles
d'alteration, Orange decline toute responsabilite si ce message a ete
altere, deforme ou falsifie. Merci.
>> privileged information that may be protected by law; they should not be
distributed, used or copied without authorisation.

---

From: Michael Hammer <[email-masked]>
Date: Tue, 16 Jul 2013 15:14:11 +0000

Phillippe,

I agree wholeheartedly with your concerns.
I just don't want to re-invent that wheel again.  :)

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, July 16, 2013 10:12 AM
To: Michael Hammer; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [stir] Rollout timeframe (was: RE: Draft STIR Charter)

Mike,

Regards,

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]] 
Sent: Tuesday, July 16, 2013 3:12 PM
To: FOUQUART Philippe OLNC/OLN; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [stir] Rollout timeframe (was: RE: Draft STIR Charter)

Philippe,

Thanks,
Mike

-----Original Message-----

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----

[snip]

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 16 Jul 2013 11:22:53 -0400

> If INSIPID's session ID won't survive end to end, what do you suggest we use here to avoid replay?

We just need to put something into the new header we create for the signature and other stuff.  That's what both draft-kaplan-sip-asserter-identity and draft-kaplan-stir-ikes-out-00 do.  RFC4474 used the Call-ID and Cseq number to prevent replay because they were conveniently available, and because at a SIP layer getting the same values would reject the message even due to normal SIP processing rules.  But we won't have the latter benefit even with Session-ID, and we basically have to rely on only the verifier being the one to detect/prevent replays.

BTW, it doesn't have to be a random value, either - it could be a sequential number.  It just has to provide enough uniqueness within one second of time, for the same source-dest E.164 pair, so that the signer can successfully generate another message for the same source-dest pair within the same second without the signer itself being detected as a replay.  As long as the verifier remembers there was a message from the source-dest pair and its timestamp and its sequence number, for the ~15 minutes a timestamp is valid for, then the verifier can prevent replays.  So I do that in the IKES mechanism, by requiring the verifier to remember the IKES-IF string value for 20 minutes, and comparing future request IKES-IF strings against it.  (it doesn't need to be for a full 20 minutes though - the draft needs to be tightened up some)

-hadriel

---

From: Stephen Kent <[email-masked]>
Date: Tue, 16 Jul 2013 11:24:18 -0400

Mike,

> For example, if ultimately what is needed is a cert that binds aPUBLIC  key
> the chain of service providers through which the key is delegated (probably not the right term), but that
> conflation of delegation complexity with the act of knowing aPUBLIC  key
Consistent with my earlier comment re who makes for a good CA, a called
party need to be able to verify that the entity who asserts the binding
between the public key and an E.164 number is authorized to do so. In the
best case, that would call for the cert path (which is not "key 
delegation" per se)
to match the phone number assignment/delegation path.

Steve

---

From: Michael Hammer <[email-masked]>
Date: Tue, 16 Jul 2013 15:43:51 +0000

Why?  

The cert path can be very short and orthogonal to the delegation path.

The authoritative cert signer can get the base cert passed up to it via
secure means or it can create and sign the cert at the top.

The only important aspect there is that the cert creator know definitively
who to send the private key to.

That does not need to be shared across the delegation path.

Either way, the delegation path does not *need* to be in the cert.

BTW, I would also not pollute the original caller ID with delegated caller
assertions.  

There is no reason there could not be a secondary assertion that binds the
"display number" with the "calling party number":

-          Verify the calling party ID:  Authoritative cert

-          Verify the association of calling party ID with Display ID:
Delegation signed by private key of authoritative cert for the "borrowed
number" (e.g. office number)

-          Display the Display ID

Mike

From: Stephen Kent [mailto:[email-masked]] 
Sent: Tuesday, July 16, 2013 11:24 AM
To: Michael Hammer
Cc: [email-masked]
Subject: Re: [stir] Rollout timeframe

Mike,

 
For example, if ultimately what is needed is a cert that binds a PUBLIC key

with an E.164 number, it could be made more complicated by also including
the chain of service providers through which the key is delegated (probably
not the right term), but that
conflation of delegation complexity with the act of knowing a PUBLIC key
matches with an E.164 number may be an act of shooting oneself in the foot.

best case, that would call for the cert path (which is not "key delegation"
per se) 

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 16 Jul 2013 11:56:28 -0400

Mike,

> system.  So, may be good to learnt he right lessons there.
DigiNotar was a disaster largely because _all_ of the TAs in the browser
environment are able to issue certs for _any_ DNS name. So, yes, the failure
to constrain the scope of "delegation" in that context is the really big 
problem.
Also, technology was commercially available for many years that would 
have allowed
DigiNotar to detect the covert issuance of certs and to allow them to 
revoke those
certs. DigiNotar just didn't make use of such technology.
> other complex routing trappings that NP already covers for routing, which is
I'm not sure I agree with your notion of no need for a hierarchy. Numbering
plans appear to be administered in a hierarchic fashion  (said the 
telephony outsider),
and so aligning a PKI with that hierarchy would be a natural fit, one 
that would
counter the large scale failure that accompanied the DigiNotar security 
failure.
DNSSEC and the RPKI are both examples where the certification system 
aligns with
an extant, hierarchic system.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 16 Jul 2013 12:04:14 -0400

Mike,
> The cert path can be very short and orthogonal to the delegation path.
it could be, but alignment makes the system simpler and easier to 
understand,
and is supportive of the security principle of "least privilege".
>
> The authoritative cert signer can get the base cert passed up to it 
> via secure means or it can create and sign the cert at the top.
>
> The only important aspect there is that the cert creator know 
> definitively who to send the private key to.
>
In the vast majority of PKIs, cert subjects do not send private keys to cert
issuers , so I am confused by the statement above.
> Either way, the delegation path does not **need** to be in the cert.
>
agreed, and in standard cert formats there is not way to represent the 
path anyway.

Steve

---

From: Brian Rosen <[email-masked]>
Date: Tue, 16 Jul 2013 12:11:37 -0400

I think the credential path follows the delegation path, but I hope that in most deployments, we're not chasing a chain of credentials to validate.

Ultimately, remember the math Henning did - even with cert per TN, it's still not a whole lot of data.

Brian

On Jul 16, 2013, at 12:04 PM, Stephen Kent <[email-masked]> wrote:

> it could be, but alignment makes the system simpler and easier to understand,
>> The authoritative cert signer can get the base cert passed up to it via secure means or it can create and sign the cert at the top.
>> The only important aspect there is that the cert creator know definitively who to send the private key to.
> agreed, and in standard cert formats there is not way to represent the path anyway.
> 
> Steve

---

From: Michael Hammer <[email-masked]>
Date: Tue, 16 Jul 2013 16:12:18 +0000

Steve,

I am not saying that the existing delegation system cannot be leveraged,
just don't co-mingle the administrative with the operational.

There are a lot of privacy concerns identified by SPs about revealing what
numbers they are assigned.

By not co-mingling, you can avoid those concerns, and thus freely distribute
certs.

As long as the PKI has a secure automated means by which they can verify
that an SP has "ownership" of the number for which they request a cert, 

there is no reason a cert could not be signed for them or be issued directly
to them.

Every additional link you put into that validation chain is one more
possibility of failure.

It's about minimizing failure with simple operation and strong oversight.

Mike

From: Stephen Kent [mailto:[email-masked]] 
Sent: Tuesday, July 16, 2013 11:56 AM
To: Michael Hammer
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Rollout timeframe

Mike,

Brian,

DigiNotar was a disaster largely because all of the TAs in the browser 
environment are able to issue certs for any DNS name. So, yes, the failure
to constrain the scope of "delegation" in that context is the really big
problem.
Also, technology was commercially available for many years that would have
allowed
DigiNotar to detect the covert issuance of certs and to allow them to revoke
those
certs. DigiNotar just didn't make use of such technology.

I'm not sure I agree with your notion of no need for a hierarchy. Numbering
plans appear to be administered in a hierarchic fashion  (said the telephony
outsider),
and so aligning a PKI with that hierarchy would be a natural fit, one that
would
counter the large scale failure that accompanied the DigiNotar security
failure. 
DNSSEC and the RPKI are both examples where the certification system aligns
with
an extant, hierarchic system.

Steve

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 16 Jul 2013 12:27:44 -0400

> portability rather than reinvent them.

I certainly see benefits to re-using the number portability systems for this, BUT there are some issues that need to be addressed with that too:
1) Number portability doesn't work the same in all countries.  The UK, for example, has a very different number portability model I think.  I don't believe it even requires a central/common database admin, for example (though I could be wrong on that).  Furthermore, some countries don't even have number portability.

2) Number portability never crosses country-codes - there's no international number porting as far as I know.  The NP database only knows about numbers within their given country, and are only accessible by their country's carriers.  Even within +1 NANP, there is a different number portability database and provider/admin for USA vs. Canada.  So to get international calls to work for STIR, the NP would have to tie into others.  I'm not saying that can't be made to work - it can - just that it's not as simple as "use the NPAC".  Someone would have to crate specs for how the international thing would work, and vendors or NP admins would have to implement it.

3) At least in the USA, the NP database is run by a company awarded the contract by a federal agency.  Same goes for Canada.  That means the NP admin is a monopoly. If we want them to handle the caller-id verification data, but we don't want them to charge whatever they wish to because they're in a monopoly position, it will have to be part of the contract too and overseen by the federal agency.  That will take a long time, and involve a lot more people.

4) Today, the NP database is queried by the originator or transit carrier, to route the call.  It is not queried by the terminating carrier when receiving a call.  While this may not seem like a big deal, it has implications on cost/pricing as well as for who can be the verifier.  Because in the USA at least, there are hundreds of "service providers" who don't have access to the NP database and instead rely on a downstream carrier to query it for routing their calls.  That means they would have to rely on their upstream carriers to do the verification too.  I think that's ok, but it's an extra constraint.

5) We'd still have to define one or more protocol means of accessing the NP database.  Today for NP database access it appears to be various SS7-based and IP-based protocols, at different points/places.  But we'd have to at least define how it would work, and how the NP database would know about stuff, to figure out what we need to transport in the SIP signaling.

-hadriel

---

From: Michael Hammer <[email-masked]>
Date: Tue, 16 Jul 2013 16:29:13 +0000

Inline.

From: Stephen Kent [mailto:[email-masked]] 
Sent: Tuesday, July 16, 2013 12:04 PM
To: Michael Hammer
Cc: [email-masked]
Subject: Re: [stir] Rollout timeframe

Mike,

Why?  

I disagree about simpler.  The current system is my proof point.  (But, we
can leverage that.)

Least privilege is about multiple levels (S, TS, TS/SCI etc.) of what the
asserter has authority to assert or view.  

There is only one level of assertion that needs authority here. And the
assertion must be universally readable.

I was not clear.  When a certificate is created the public key is in the
cert, while the associated private key is not.

The public/private key pair creator needs to securely delivery the private
key to the intended "owner" of the cert.  

In this case, the SP is that owner, most likely.

But, it would not be hard to use a mechanism to secure the passing of the
private key to the owner when that owner is remote.

I was pointing to 2 possibilities, 

one is where the signing authority creates the public/private key pair, 

then structures the cert, signs it and then publicly distributes the cert, 

while securely passing the private key to the number holder.

The second option is that the local SP generates the public/private key
pair, then structures the cert, 

then only sends the proto-cert data to the signing authority to sign
creating the signed cert.

Those description are rough, but hopefully get the general idea across.

Mike

agreed, and in standard cert formats there is not way to represent the path
anyway.

Steve

---

From: Michael Hammer <[email-masked]>
Date: Tue, 16 Jul 2013 16:32:57 +0000

I would contend that you only need the current number holder and a central
authority (or their CA) involved.

How the number got there is irrelevant (orthogonal).

Agree, the data volume and transaction speed is doable.

Mike

From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, July 16, 2013 12:12 PM
To: Stephen Kent
Cc: Michael Hammer; [email-masked]
Subject: Re: [stir] Rollout timeframe

I think the credential path follows the delegation path, but I hope that in
most deployments, we're not chasing a chain of credentials to validate.

Ultimately, remember the math Henning did - even with cert per TN, it's
still not a whole lot of data.

Brian

Mike,

Why?  

Steve

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 16 Jul 2013 16:39:09 +0000

Though for obvious reasons my comments on this won't be too extensive, I
will repeat what I've said before: that the IETF shouldn't be designating
trust anchors for this solution. We should be defining protocols and
interfaces that will work with the trust anchors that the industry adopts.
Those protocols and interfaces should assume a trust model that supports
delegation, while being wary of the sort of pluralism that has caused
ambiguity about authority for domain names certs in the past.

Jon Peterson
Neustar, Inc.

On 7/16/13 9:27 AM, "Hadriel Kaplan" <[email-masked]> wrote:

>I certainly see benefits to re-using the number portability systems for
>this, BUT there are some issues that need to be addressed with that too:
>1) Number portability doesn't work the same in all countries.  The UK,
>for example, has a very different number portability model I think.  I
>don't believe it even requires a central/common database admin, for
>example (though I could be wrong on that).  Furthermore, some countries
>don't even have number portability.
>
>2) Number portability never crosses country-codes - there's no
>international number porting as far as I know.  The NP database only
>knows about numbers within their given country, and are only accessible
>by their country's carriers.  Even within +1 NANP, there is a different
>number portability database and provider/admin for USA vs. Canada.  So to
>get international calls to work for STIR, the NP would have to tie into
>others.  I'm not saying that can't be made to work - it can - just that
>it's not as simple as "use the NPAC".  Someone would have to crate specs
>for how the international thing would work, and vendors or NP admins
>would have to implement it.
>
>3) At least in the USA, the NP database is run by a company awarded the
>contract by a federal agency.  Same goes for Canada.  That means the NP
>admin is a monopoly. If we want them to handle the caller-id verification
>data, but we don't want them to charge whatever they wish to because
>they're in a monopoly position, it will have to be part of the contract
>too and overseen by the federal agency.  That will take a long time, and
>involve a lot more people.
>
>4) Today, the NP database is queried by the originator or transit
>carrier, to route the call.  It is not queried by the terminating carrier
>when receiving a call.  While this may not seem like a big deal, it has
>implications on cost/pricing as well as for who can be the verifier.
>Because in the USA at least, there are hundreds of "service providers"
>who don't have access to the NP database and instead rely on a downstream
>carrier to query it for routing their calls.  That means they would have
>to rely on their upstream carriers to do the verification too.  I think
>that's ok, but it's an extra constraint.
>
>5) We'd still have to define one or more protocol means of accessing the
>NP database.  Today for NP database access it appears to be various
>SS7-based and IP-based protocols, at different points/places.  But we'd
>have to at least define how it would work, and how the NP database would
>know about stuff, to figure out what we need to transport in the SIP
>signaling.
>
>-hadriel
>

---

From: Stephen Kent <[email-masked]>
Date: Tue, 16 Jul 2013 12:42:59 -0400

Mike,

> Steve,
>
> I am not saying that the existing delegation system cannot be 
> leveraged, just don't co-mingle the administrative with the operational.
>
> There are a lot of privacy concerns identified by SPs about revealing 
> what numbers they are assigned.
>
> By not co-mingling, you can avoid those concerns, and thus freely 
> distribute certs.
>
"freely distributing" certs ought not be the primary focus for a system that
purports to provide a security service :-) . Ensuring that the certs are 
appropriately
bound to the data that they purport to certify, and that the certs are 
issued to
the right entities, ought to be the primary concerns.
>
> As long as the PKI has a secure automated means by which they can 
> verify that an SP has "ownership" of the number for which they request 
> a cert,
>
> there is no reason a cert could not be signed for them or be issued 
> directly to them.
>
Anytime a third party is "trusted" to validate data supplied by a 
subject and issue
a cert on that basis, we have a problem. That is why the browser PKI 
model is so
badly broken. I hope you are not suggesting using it as a model.
> It's about minimizing failure with simple operation and strong oversight.
I probably disagree, on both counts. Additional nodes in a cert path, if 
constrained
via technical means, do not necessarily create additional security concerns.

"Strong oversight" is not a substitute for using authoritative CAs. 
Again, a lesson
to be learned from the DigiNotar incident. (All TAs in browsers are 
supposed to be
audited, but ...)

Steve

---

From: Michael Hammer <[email-masked]>
Date: Tue, 16 Jul 2013 16:50:16 +0000

You are missing my point.  And I did say "such as" meaning by way of
example, but not definitive.

The called party needs to only be able to reach the freely available cached
data that every SP would likely have.
That could be in DNS.  The validator trusts it because it can validate a
cert, a common action today.
Let us not confuse number holder validation with routing.

The leveraging occurs when needing during the cert creation process.  (the
administrative part)
And that would likely be between the national authority and the existing
registries of who owns what number.
I assume that the national authority has the power to get to that
information, likely without charge, 
or maybe at cost as part of whatever contract they negotiated when they
created that monopoly.

That knowledge is needed solely to ensure that the private key is held by or
given to the number holder.

Mike

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Tuesday, July 16, 2013 12:28 PM
To: Michael Hammer
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Using the NPAC (was: Re: [stir] Rollout timeframe)

I certainly see benefits to re-using the number portability systems for
this, BUT there are some issues that need to be addressed with that too:
1) Number portability doesn't work the same in all countries.  The UK, for
example, has a very different number portability model I think.  I don't
believe it even requires a central/common database admin, for example
(though I could be wrong on that).  Furthermore, some countries don't even
have number portability.

2) Number portability never crosses country-codes - there's no international
number porting as far as I know.  The NP database only knows about numbers
within their given country, and are only accessible by their country's
carriers.  Even within +1 NANP, there is a different number portability
database and provider/admin for USA vs. Canada.  So to get international
calls to work for STIR, the NP would have to tie into others.  I'm not
saying that can't be made to work - it can - just that it's not as simple as
"use the NPAC".  Someone would have to crate specs for how the international
thing would work, and vendors or NP admins would have to implement it.

3) At least in the USA, the NP database is run by a company awarded the
contract by a federal agency.  Same goes for Canada.  That means the NP
admin is a monopoly. If we want them to handle the caller-id verification
data, but we don't want them to charge whatever they wish to because they're
in a monopoly position, it will have to be part of the contract too and
overseen by the federal agency.  That will take a long time, and involve a
lot more people.

4) Today, the NP database is queried by the originator or transit carrier,
to route the call.  It is not queried by the terminating carrier when
receiving a call.  While this may not seem like a big deal, it has
implications on cost/pricing as well as for who can be the verifier.
Because in the USA at least, there are hundreds of "service providers" who
don't have access to the NP database and instead rely on a downstream
carrier to query it for routing their calls.  That means they would have to
rely on their upstream carriers to do the verification too.  I think that's
ok, but it's an extra constraint.

5) We'd still have to define one or more protocol means of accessing the NP
database.  Today for NP database access it appears to be various SS7-based
and IP-based protocols, at different points/places.  But we'd have to at
least define how it would work, and how the NP database would know about
stuff, to figure out what we need to transport in the SIP signaling.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 16 Jul 2013 12:52:09 -0400

> ambiguity about authority for domain names certs in the past.

We're not "designating" trust anchors.  We're merely discussing how, in practice, a STIR solution could be deployed and what its limitations or issues would be.  I think it only makes sense that such a discussion happen, and email is hardly authoritative "designation" - I mean it's not like we're planning an RFC to say "and the NPAC shall be used for this".  

I appreciate that you and Brian have to be careful in what you say on this topic, but I don't see a way around that.  We can't all be expected to agree on a solution we believe will succeed, if we're creating one in a vacuum with no idea how it would actually be used, administered, and deployed.

-hadriel

---

From: Stephen Kent <[email-masked]>
Date: Tue, 16 Jul 2013 12:52:53 -0400

Mike,

> I disagree about simpler.  The current system is my proof point.  
> (But, we can leverage that.)
>
> Least privilege is about multiple levels (S, TS, TS/SCI etc.) of what 
> the asserter has authority to assert or view.
>
> There is only one level of assertion that needs authority here. And 
> the assertion must be universally readable.
>
To which "current system" do you refer?

Your response tells me that you are not familiar with the term "least 
privilege." See
the definition of the term in the paper by Jerry Saltzer, ca 1975. The 
term refers to
the notion that a system should be structured to limit the authority 
(and thus the
amount of damage) associated with each system element, based on what the 
element requires
to do its job.

> I was not clear.  When a certificate is created the public key is in 
> the cert, while the associated private key is not.
>
> The public/private key pair creator needs to securely delivery the 
> private key to the intended "owner" of the cert.
>
Again, not usually the case. In the typical PKI context, the cert 
subject creates the key pair
and transmits a cert request to a CA or RA.
> But, it would not be hard to use a mechanism to secure the passing of 
> the private key to the owner when that owner is remote.
>
yes, that can be done, and there are some significant systems that 
operate that way, but
that approach creates additional security concerns.
> while securely passing the private key to the number holder.
yes, but not the default model, and not a good idea in most cases. (It 
is used when the
cert issuer wants to retain the private key for key escrow purposes, but 
that's not
relevant here.)
>
> The second option is that the local SP generates the public/private 
> key pair, then structures the cert,
>
that is the common model, which was not represented in your previous 
message.

Steve

---

From: Michael Hammer <[email-masked]>
Date: Tue, 16 Jul 2013 17:03:39 +0000

Steve,

We can argue about whether freely distributable is valid or not, 

but do you disagree that some operators would not want the number delegation
revealed?

The number portability DB in US is a trusted third party.

And you argue both sides, since any delegation from central authority is a
third party, even an SP.

You would argue that having many more of them makes it more secure?

Experience also argues the more there are the harder to police.

I see no difference in the DigiNotar case.  That appeared to be an
organizational failure.

That breach could have occurred with an SP as easily.

What "technical constraints" are you saying were not implemented?

Keep in mind that we need a solution that works when there are on the order
of thousands of operators, as there are in the U.S.

Mike

From: Stephen Kent [mailto:[email-masked]] 
Sent: Tuesday, July 16, 2013 12:43 PM
To: Michael Hammer
Cc: [email-masked]
Subject: Re: [stir] Rollout timeframe

Mike,

Steve,

Anytime a third party is "trusted" to validate data supplied by a subject
and issue 
a cert on that basis, we have a problem. That is why the browser PKI model
is so
badly broken. I hope you are not suggesting using it as a model.

"Strong oversight" is not a substitute for using authoritative CAs. Again, a
lesson
to be learned from the DigiNotar incident. (All TAs in browsers are supposed
to be
audited, but ...)

Steve

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 16 Jul 2013 13:26:03 -0400

On Jul 16, 2013, at 1:03 PM, Michael Hammer <[email-masked]> wrote:

> but do you disagree that some operators would not want the number delegation revealed?

There is no debate that some operators would not want their numbers revealed publicly.  They're ok with you learning they're the operator when you a receive a call from them, but they'd not be ok with a script-kiddie being able to learn every phone number they have.

I can think of a reason why it would be a problem: if everyone could learn how many numbers an operator has, people could figure out how many subscribers an operator has gained/lost in a time period.  You can game the stock market using that type of information.

-hadriel

---

From: Michael Hammer <[email-masked]>
Date: Tue, 16 Jul 2013 17:40:52 +0000

Inline. 

From: Stephen Kent [mailto:[email-masked]] 
Sent: Tuesday, July 16, 2013 12:53 PM
To: Michael Hammer
Cc: [email-masked]
Subject: Re: [stir] Rollout timeframe

Mike,

Mike,

Why?  

The fact that there are multiple again proves my point.  

Ask yourself how anyone knows who the current number belongs to and then
tell me if that is simple or not.

I think we both agree it should be simple, but differ only in whether
following existing regimes is simpler or not.

Your response tells me that you are not familiar with the term "least
privilege." See
the definition of the term in the paper by Jerry Saltzer, ca 1975. The term
refers to
the notion that a system should be structured to limit the authority (and
thus the 
amount of damage) associated with each system element, based on what the
element requires
to do its job.

I may be confusing my terms, but when the authority is distributed across
more entities, how is that least privilege?

You have given more actors control not fewer?  Yes, each actor theoretically
controls less data, but how is that enforced?

You have only squeezed the balloon and created a bigger auditing problem
elsewhere.

I was thinking of limiting the authority to the least number of entities
necessary to accomplish the function.

Or, in your terms "limiting the authority associated with each system
element based on  what the element requires to do its job."

It is the job of the "national authority element" and does not need to be
shared more than necessary.

Again, not usually the case. In the typical PKI context, the cert subject
creates the key pair
and transmits a cert request to a CA or RA.

yes, that can be done, and there are some significant systems that operate
that way, but
that approach creates additional security concerns.

yes, but not the default model, and not a good idea in most cases. (It is
used when the
cert issuer wants to retain the private key for key escrow purposes, but
that's not
relevant here.)

Steve

With cryptography, one needs to get down to specific mathematically
notations to fully specify.

I was just trying to outline the general ideas across.  Obviously more
precise wording was needed.

But I hope the idea that limiting the process to 2 actors who can
authenticate each other, 

and relying on strong certificates rather than chains of organizations and
networks could lead 

to better security and privacy.

Mike

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 16 Jul 2013 13:57:13 -0400

On Jul 16, 2013, at 11:56 AM, Stephen Kent <[email-masked]> wrote:

> plans appear to be administered in a hierarchic fashion  (said the telephony outsider),
> and so aligning a PKI with that hierarchy would be a natural fit, one that would
> counter the large scale failure that accompanied the DigiNotar security failure. 
> DNSSEC and the RPKI are both examples where the certification system aligns with

Numbering administration doesn't necessarily align with a clean hierarchy for all countries, depending on how you mean that.  The country-code number portion itself does, and in the North American Numbering Plan (NANP) the area-code level does but only with regard to defining which nation has that whole area-code of numbers.  In other words, all numbers within an area-code belong to the USA, vs. another area-code to Canada, vs. Jamaica, etc.  But within that area-code's tree branches, any specific full number can belong to a different carrier.  For example, the entire +1-603 area-code is a USA NANPA-based one, but +1-603-555-1000 can belong to AT&T, while +1-603-555-1001 can be VZ, and +1-603-555-1002 can be Comcast, etc.  They're initially allocated as blocks (of 1000 numbers I think), but once numbers are ported out they become fragmented.

So if you did this thing with actual certificates, it would be tricky.  Having an authoritative root CA for each country-code wouldn't be too hard, but below that you'd have to define an encoding schema for indicating a range-list of E.164 numbers a cert is good for, and then revoke the cert and replace once a number gets ported.[1]  Or you'd have a separate cert for each E.164 number.  Either way, the cert signing process has to be automated/automatable, because numbers get ported and the new assignee has to be able to claim that ported number in ~15 minutes or so.

The CIDER proposal avoids certificates, and just uses DNS instead.  For SIP email-style names it would be nearly identical to DKIM.  For E.164 numbers it uses a DNS anchor for each country-code, but leaves it up to each country to decide how actual DNS delegation works.  The important aspect is it separates the DNS zone delegation from the E.164 number delegation.  Basically, the DNS admin decides who can populate the public-keys in the DNS nodes representing the E.164 numbers, and gives them provisioning access to do so, but the DNS admin is authoritative for the node in DNS.  In other words, when a carrier is assigned an E.164 number, they're given access rights to populate the public-key for that number in the DNS admin's database, but they're not delegated the DNS node itself and are not authoritative for it.  But of course if the DNS admin wants to delegate it to them, they can (it's still DNS after all).  The ability to not do so is useful, though, to hide who the carrier is and to let it be centrally managed if one so wishes.

-hadriel
[1] One could argue true cert revocation isn't necessary for numbers being ported out, as we could just accept that the cert holder for a ported-out number could illegitimately claim the number until that cert times out.  From a practical threat perspective, that's not a big weakness. (you'd still have revocation for the other usual reasons of course - but for number porting situations it wouldn't be necessary to revoke)

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 16 Jul 2013 18:12:45 +0000

>authentication information for every call, using both mechanisms.

I saw little value in arguing over the meaning of "fully redundant," but
some value in us getting a mutual understanding of how STIR should work.

The characterization you provided repeatedly doesn't capture the model I
have given, anyway. Start by dividing your "caller" into a set of network
devices that may act on a caller's behalf. Some might be end-user
terminals, some network intermediaries. In some cases, neither the
terminal nor any intermediary creates any form of authentication
information. In some cases only one does. In some cases, both do. In some
cases, one entity creates two forms of authentication information itself.

We could do the same exercise for the terminating side, splitting it into
various entities that sometimes support these mechanisms or don't. Then at
the end of the line, there is an end-to-end case where one calling entity
creates two forms of authentication information itself, and one
terminating entity has the capability to verify both forms of
authentication information. You sometimes seem to have latched on to this
last case and treated it as if this were the only case in which the
proposed STIR mechanisms operate. Were that true, I would find a concern
about redundancy more compelling. But it is in fact all of the other cases
that motivate having both an in-band and out-of-band approach to STIR.

[snip]
>when you earlier attempted to call DKIM and PGP 'redundant'.

I didn't miss it, though I must admit I wasn't entirely persuaded by it. I
think the situations are  analogous enough here that this applies. And I
didn't raise this point to highlight that DKIM and PGP were redundant,
merely that their simultaneous use did not (as far as I could tell) lead
to some sort of interoperability failure. That's the point of yours I was
replying to above.

>semantics.  In other words: they have nothing to do with each other.

Again, I think this is a bit too strong of a claim.

>again, the reality is that it's irrelevant to the current discussion.

I intended that to demonstrate that when they get used together, it
doesn't cause an interoperability failure.

>responsive to my own reference?

That was the original point above, actually. The sentences are meant to go
together.

>entities that are seeking to interoperate using the same protocols fail

Sounds reasonable.

>one, thereby ensuring that they fail to achieve the validation they both

So you're worried about a case where the originating side uses only
in-band, say, and the terminating side supports only out-of-band? A bit of
dissonance for me, since above you seem to insist that I propose the
caller must use both in-band and out-of-band for every call, in which case
this could never arise.

But no, you're quite correct here that there is a possible case where the
calling side uses only one of the two mechanisms, and the terminating side
has no entities that support that mechanism. Just like there's a possible
case where I send an INVITE with one codec (or multipart body, if that
floats your boat) and the terminating side doesn't support it.

These cases arise because there are environments that are more conducive
to one codec, or to one STIR mechanism, than others. As this incrementally
rolls out, there will be some calls placed from black phones, say, that
will never support out-of-band. There will also be some smart phones that
can support out-of-band which are attached to networks that won't support
in-band for the foreseeable future. It's not an ideal situation, don't get
me wrong. It'd be better if one size fit all. But it's this assessment of
the deployment realities that lead us to propose a two-prong approached to
STIR.

We further believed that, if, out of necessity, we were going to design
two approaches, that we should design them in concert and try to reuse as
many components as we could between them.

>authentication functions?

I didn't suggest it was a comparable amount of work, just that it was a
comparable amount of redundancy, or intolerability concern.

>more interesting, but you didn't, so it isn't...)

Very generous of you to find an argument that persuades you of this more
than mine did.

>approach dealing with a very complex operational environment.

The complexities of the operational environment are precisely what
motivated us to adopt two approaches.

>developing the smallest useful solution that can be deployed, and then

I discuss above a bit why we didn't propose to "divide and conquer" here,
though, the original charter did propose we do one first and then the
other.

>done, consider enhancements that extend its utility.

It's like like we're so far apart on this point, right. The original
charter did suggest we deliver in-band first. The difference here is that
the original charter then stipulates that we do out-of-band, where here
you say the charter should limit us just to considering it. For the
purposes of creating reusable components, and to some degree having a
crisp scope for each mechanism that recognizes the applicability of the
other, I think they should both be on the plate from the start.

Jon Peterson
Neustar, Inc.

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 16 Jul 2013 14:17:27 -0400

On Jul 16, 2013, at 10:57 AM, Dave Crocker <[email-masked]> wrote:

> Folks,
> Question to the group:
> There are a number of different styles of replay attack, with different likelihoods and different effects (nature/degree of damage).
> What specific replay scenarios does the group deem it essential to prevent and why?
> I've seen situations in which it was deemed acceptable to allow some types of potential replay attacks, because the potential for its occurrence and/or damage it would do were not a serious concern.

It depends on how you define "replay".  In my personal opinion, the threat of someone replaying the same SIP message against the same target is virtually nil.  It's not hard to prevent it I think, so I don't see a reason not to prevent it.

We've already assumed the odds of a malicious MITM are very low.  Or to be more precise, we acknowledge there already are a ton of benign MITM, and that if they wanted to be bad, caller-id authentication isn't gonna prevent much.  It's just closing a stateroom door on the Titanic.

We've acknowledged there are bad senders, but if they can get their messages signed, they hardly need to replay the message with the same signature.

We've acknowledged there are weak signers, but if they have the key to sign messages, then they don't need to replay.

We've acknowledged (I think) that there are bad receivers.  So we have to prevent them from replaying a received message against a *different* target.  I think of that as more of a cut-and-paste attack than replay, but I don't care what it's called.  The point is that I can easily get a bank to call me, and I should not be able to use their call request's STIR info to call someone else and have that someone else believe the bank is calling them.

Unfortunately, preventing that cut-and-paste attack is quite hard.  Mostly because it's hard to distinguish from a completely legitimate call-forwarding case, and we have to support legitimate call-forwarding.

-hadriel

---

From: Stephen Kent <[email-masked]>
Date: Tue, 16 Jul 2013 14:34:31 -0400

Mike,

> but do you disagree that some operators would not want the number 
I don't claim to know what operators want. I know that what folks may 
want may not
align well with security concerns. I'd rather not see us devise a system 
based on known,
bad approaches, e.g., the web browser PKI model.
> The number portability DB in US is a trusted third party.
are we constrained by current models for number portability management 
when we devise a solution for this problem? Just asking, as I didn't 
think that was an explicit part
of the WG charter, but I could be mistaken.

> And you argue both sides, since any delegation from central authority 
> is a third party, even an SP.
>
no, its not, in the PKI sense that we are discussing.
> You would argue that having many more of them makes it more secure?
That's not what I said. I said that the preferred model would use exiting,
authoritative entities to issue certs. Whenever a CA relies on a 
database from
some other entity, problems are likely to arise, based on experience.
> Experience also argues the more there are the harder to police.
Fewer might be better, but not necessarily, as you seem to suggest. External
auditing (policing?) of CA operation has proven to be inadequate in the 
browser context.
> I see no difference in the DigiNotar case.  That appeared to be an 
it was a failure in multiple ways, ways that could have been avoided 
through technical means.
> That breach could have occurred with an SP as easily.
yes, but if the SP were (technically) constrained to issue certs that 
attested only
to phone numbers that have been assigned to it under a numbering plan, 
the fallout
would have been mitigated. I assume you are familiar with the DigiNotar 
details, and
thus realize that the biggest problem was the fact that the attackers 
used DigiNotar
to issue certs for web sites that were not DigiNotar clients.
> What "technical constraints" are you saying were not implemented?
One can use HSMs that assign cert serial numbers and log such assignments in
a secure fashion. That way if an attacker compromises the computer used 
to mint
certs, the attacker cannot control the serial numbers that are assigned 
and cannot delete
the logs showing that certs were issued fraudulently. The CA, with knowledge
of the "bad" cert serial numbers, can revoke them. None of those 
capabilities were
present in the DigiNotar system.
>
> Keep in mind that we need a solution that works when there are on the 
> order of thousands of operators, as there are in the U.S.
>

The RPKI system might provide a useful example. It is being deployed on 
a global basis (slowly) and it must accommodate tens of thousands of 
ISPs. It incorporates the sort of
delegation restrictions that I mentioned, and is aligned with the IP 
address and ASN allocation-delegation hierarchy.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 16 Jul 2013 15:03:45 -0400

Mike,

>     Least privilege is about multiple levels (S, TS, TS/SCI etc.) of
>     what the asserter has authority to assert or view.
>
>     There is only one level of assertion that needs authority here.
>     And the assertion must be universally readable.
>
> /The fact that there are multiple again proves my point. /
>
My question re your term "current system" was intended to elicit a 
response citing
a specific system, so that I might understand your comments in that 
context. Your
reply help me (or other readers) understand the context of your assertion.
>
> //
>
> /Ask yourself how anyone knows who the current number belongs to and 
> then tell me if that is simple or not./
>
> //
>
> /I think we both agree it should be simple, but differ only in whether 
> following existing regimes is simpler or not./
>
Until we have a concrete, detailed proposals, debates about what is and 
is not simple
will probably be futile.
> //
> amount of damage) associated with each system element, based on what 
> the element requires
> to do its job.
>
> /I may be confusing my terms, but when the authority is distributed 
> across more entities, how is that least privilege?/
>
yes, you are confusing the terms. Look at RFC 4949's definition of the 
phrase:

The principle that a security architecture should be designed
so that each system entity is granted the minimum system resources
and authorizations that the entity needs to do its work.

This principle is applied to each entity. If authorization is 
_distributed_ across
multiple entities, then each of those should be constrained accordingly.
>
> //
>
> /You have given more actors control not fewer?  Yes, each actor 
> theoretically controls less data, but how is that enforced?/
>
see the RPKI design, for example.
>
> //
>
> /You have only squeezed the balloon and created a bigger auditing 
> problem elsewhere./
>
Auditing is probably a necessary, but certainly not a sufficient, 
mechanism here.
>
> //
>
> /I was thinking of limiting the authority to the least number of 
> entities necessary to accomplish the function./
>
The term "necessary" is unqualified here. 1 is a possible answer (but 
probably a very bad
one).

> //
>
> /Or, in your terms "limiting the authority associated with each system 
> element based on  what the element requires to do its job."/
>
> /It is the job of the "national authority element" and does not need 
> to be shared more than necessary./
>
Well, at least you provided a concrete example this time. So you're 
suggesting one
entity per country to manage cert issuance for all SPs?

> //
>
> ...
>
> /With cryptography, one needs to get down to specific mathematically 
> notations to fully specify./
>
> /I was just trying to outline the general ideas across. Obviously more 
> precise wording was needed./
>
> /But I hope the idea that limiting the process to 2 actors who can 
> authenticate each other, /
>
> /and relying on strong certificates rather than chains of 
> organizations and networks could lead /
>
> /to better security and privacy./
>
The points on which we disagree above don't require any math (unless 
you're proposing
IBE, which would not be algorithm agile, and which has a lot of IP 
issues). They're
common PKI technology/terminology issues.

Steve

---

From: Michael Hammer <[email-masked]>
Date: Tue, 16 Jul 2013 19:10:40 +0000

Steve,

My pointing to NP was only to indicate that there are trusted third parties
that are reliable.

I also did not want to reinvent the number delegation system for the
operational aspects.

My focus is on how the called party can validate in near-real-time (few
seconds) the authenticity of the number.

That in turn needs administrative side that can update in only slightly
longer time (minutes) due to number portability.

Given that calls can come from anywhere globally, I didn't think crawling
the internet to discover some locally peculiar regime would help.

Anyway, I am going to give this a rest for now.

Mike

From: Stephen Kent [mailto:[email-masked]] 
Sent: Tuesday, July 16, 2013 2:35 PM
To: Michael Hammer
Cc: [email-masked]
Subject: Re: [stir] Rollout timeframe

Mike,

Steve,

I don't claim to know what operators want. I know that what folks may want
may not
align well with security concerns. I'd rather not see us devise a system
based on known,
bad approaches, e.g., the web browser PKI model.

are we constrained by current models for number portability management when
we devise a solution for this problem? Just asking, as I didn't think that
was an explicit part
of the WG charter, but I could be mistaken.

That's not what I said. I said that the preferred model would use exiting,
authoritative entities to issue certs. Whenever a CA relies on a database
from
some other entity, problems are likely to arise, based on experience.

it was a failure in multiple ways, ways that could have been avoided through
technical means.

yes, but if the SP were (technically) constrained to issue certs that
attested only
to phone numbers that have been assigned to it under a numbering plan, the
fallout
would have been mitigated. I assume you are familiar with the DigiNotar
details, and
thus realize that the biggest problem was the fact that the attackers used
DigiNotar
to issue certs for web sites that were not DigiNotar clients.

One can use HSMs that assign cert serial numbers and log such assignments in
a secure fashion. That way if an attacker compromises the computer used to
mint
certs, the attacker cannot control the serial numbers that are assigned and
cannot delete
the logs showing that certs were issued fraudulently. The CA, with knowledge
of the "bad" cert serial numbers, can revoke them. None of those
capabilities were
present in the DigiNotar system.

The RPKI system might provide a useful example. It is being deployed on a
global basis (slowly) and it must accommodate tens of thousands of ISPs. It
incorporates the sort of
delegation restrictions that I mentioned, and is aligned with the IP address
and ASN allocation-delegation hierarchy. 

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 16 Jul 2013 15:14:40 -0400

Hadriel,
> Numbering administration doesn't necessarily align with a clean hierarchy for all countries, depending on how you mean that.  The country-code number portion itself does, and in the North American…
yep, this matches what I understood to be true.
> So if you did this thing with actual certificates, it would be tricky.  Having an authoritative root CA for each country-code wouldn't be too hard, but below that you'd have to define an encoding s…
An efficient encoding and suitable distribution of ranges of numbers 
across multiple certs
is a challenge, but we ought not assume it is impossible. I concur with 
the need to automate
cert signing. I would not suggest a per-number cert unless there was a 
real need for that
granularity of authentication. I admit that 15 minutes is pretty fast to 
make this info
available. That may be biggest challenge for any solution.
> The CIDER proposal avoids certificates, and just uses DNS instead.  For SIP email-style names it would be nearly identical to DKIM.  For E.164 numbers it uses a DNS anchor for each country-code, bu…
I'm not enough of a DNS expert to fully understand the outline of the 
design you
provided above. I'll look forward to seeing others (more DNS 
knowledgeable than I)
comment on it.
> [1] One could argue true cert revocation isn't necessary for numbers being ported out, as we could just accept that the cert holder for a ported-out number could illegitimately claim the number unt…
When designing a PKI one should always make decisions about cert 
lifetimes and CRL
size and issuance frequency based on some model of expected operation. 
It is appalling
that some very big PKIs fail this test, e.g., the U.S. DoD PKI! It isn't 
yet clear *at
least to me) how big the vulnerability is if revocation info is slow, 
relative to new cert issuance. We might want to err on the side of being 
unable to verify calling number info
(and providing an indication to the called parry) vs. denying service.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 16 Jul 2013 15:17:15 -0400

Brian,

> I think the credential path follows the delegation path, but I hope 
> that in most deployments, we're not chasing a chain of credentials to 
> validate.
I don't know what you mean by the statement above. Do you mean that you 
hope cert paths
(or a DNSSEC equivalent) will be short, that most of tbe data will 
change slowly enough that
caching will be a big win, or what?
> it's still not a whole lot of data.
These days very few things that I imagine dealing with amount to a 
"whole lot of data" :-) .

Steve

---

From: Michael Hammer <[email-masked]>
Date: Tue, 16 Jul 2013 19:23:07 +0000

One last reply.  (famous last words)

s/current system/current state of affairs/

It's balkanized.  There is no one system we can align with.

If we need to reflect the delegation systems of every nation globally into
our solution, the BOF time frame goals won't be met.

Mike

From: Stephen Kent [mailto:[email-masked]] 
Sent: Tuesday, July 16, 2013 3:04 PM
To: Michael Hammer
Cc: [email-masked]
Subject: Re: [stir] Rollout timeframe

Mike,

Why?  

My question re your term "current system" was intended to elicit a response
citing
a specific system, so that I might understand your comments in that context.
Your
reply help me (or other readers) understand the context of your assertion.

Until we have a concrete, detailed proposals, debates about what is and is
not simple
will probably be futile.

This principle is applied to each entity. If authorization is distributed
across
multiple entities, then each of those should be constrained accordingly.

Auditing is probably a necessary, but certainly not a sufficient, mechanism
here. 

 ...

The points on which we disagree above don't require any math (unless you're
proposing
IBE, which would not be algorithm agile, and which has a lot of IP issues).
They're
common PKI technology/terminology issues.

Steve

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 16 Jul 2013 15:25:46 -0400

On Jul 16, 2013, at 1:03 PM, Michael Hammer <[email-masked]> wrote:

> And you argue both sides, since any delegation from central authority is a third party, even an SP.
> I see no difference in the DigiNotar case.  That appeared to be an organizational failure.
> What “technical constraints” are you saying were not implemented?
> 

I think Steven's point is that the web-pki model basically allows any trusted CA to claim any domain name, even though none of them are actually authoritative for domain name assignments.  You can think of it as basically creating an alternate-root to DNS - an alternate authority of names - from an SSL/TLS-usage perspective.

Since browsers trust ~160 CAs, the odds of a trusted CA screwing up not only became high, but once it happened it affected all domain names.  It didn't just screw up the validity of domain names DigiNotar happens to certify, but it screwed up ALL of them, because no one knows what domain names DigitNotar could legitimately certify.  With DNSSEC, however, the actual authority of domain name assignments is the same entity who actually signs stuff; they are not an alternate authority of names, they *are* the one-and-only authority of the name.  If they screw up, they affect only the names signed by them (i.e., the names under their DNS tree branch).  And if they screw up, "revocation" is fairly simple for them to perform and have take effect: they just change their DNSSEC entries.

When it comes to STIR stuff, the point is we can't just trust third-party CAs to certify any E.164 number it cares to; because if they scrwe up, it affectes all E.164 numbers.  We have to have some means of tying the certification to the authority that actually authoritatively assigns the numbers.  So we need to know that a cert from carrier-X for number +1-603-555-1000 is signed by a CA that actually assigned carrier-X that E.164 number; which means we need to know what numbers the CA can assign - that it's authoritative for that role/decision.

So... assuming we define some encoding scheme and mechanics for this E.164 stuff to be done in certs... we could have the ITU sign certs of country-code admins indicating the country-code number, and the country-code admins sign certs of carriers indicating the full number, and the carriers sign certs of their customer service providers, and them signing certs of enterprises or end-users.  (or more likely we'd skip the ITU level one, and start with country-code level admins)

But that would require a means of actually retrieving the correct cert, walking the chain of signers, retrieving each of their certs, and checking revocation lists.  Meanwhile the caller has hung up the phone because it didn't ring. :)

-hadriel

---

From: Brian Rosen <[email-masked]>
Date: Tue, 16 Jul 2013 15:39:32 -0400

In the U.S., there may be many delegations in a path from the North American Number Plan Administrator to the user that has the number.  Only the first two of these are captured in the formal delegation databases - NANPA allocates a NPA (area code) to the Pooling Administrator, which delegates a 1000 number block to a carrier.

That carrier may resell 100 numbers to a SIP provider, who resells 20 of them to another SIP provider who sells 10 of them to an enterprise, who allocates one of those to an employee.

At each step in the delegation (possibly save the last one), there could theoretically be a credential issued.

I would not want to verify the validity of all of these individually to check a source identity.

Ideally, I'd like to go one place and be able to get one credential that is authoritative for the number.

That seems possible, even when we have the credential path follow the delegation path.

I hear you on data size.  But remember, an exabyte hear and an exabyte there, and pretty soon, we're talking real big data stores.

Brian

On Jul 16, 2013, at 3:17 PM, Stephen Kent <[email-masked]> wrote:

> I don't know what you mean by the statement above. Do you mean that you hope cert paths
> (or a DNSSEC equivalent) will be short, that most of tbe data will change slowly enough that
> These days very few things that I imagine dealing with amount to a "whole lot of data" :-) .
> 
> Steve
>

---

From: Michael Hammer <[email-masked]>
Date: Tue, 16 Jul 2013 20:14:41 +0000

Agree, but I was suggesting one CA operating for the national authority 
who knows via feedback from the delegation system what SP has each number.
One CA
One cert per number
No chains.
One place to look to validate.

Your DNSSEC solution just defines how the central authority maintains its
knowing of what SP owns what number.
There are other technologies to store/maintain the {Tel#, SP name, SP public
key | cert, User public key | cert} tuple.
Delegation updates SP values, Assignment uses SP values to update User
values.

15 digits:
1,000,000,000,000,000 = Peta numbers
P     T      G     M    K

And that is the whole E.164 number space, so at national level orders of
magnitude less.

Mike

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Tuesday, July 16, 2013 3:26 PM
To: Michael Hammer
Cc: [email-masked]; [email-masked]
Subject: Re: [stir] Rollout timeframe

third party, even an SP.
organizational failure.
> What "technical constraints" are you saying were not implemented?

I think Steven's point is that the web-pki model basically allows any
trusted CA to claim any domain name, even though none of them are actually
authoritative for domain name assignments.  You can think of it as basically
creating an alternate-root to DNS - an alternate authority of names - from
an SSL/TLS-usage perspective.

Since browsers trust ~160 CAs, the odds of a trusted CA screwing up not only
became high, but once it happened it affected all domain names.  It didn't
just screw up the validity of domain names DigiNotar happens to certify, but
it screwed up ALL of them, because no one knows what domain names DigitNotar
could legitimately certify.  With DNSSEC, however, the actual authority of
domain name assignments is the same entity who actually signs stuff; they
are not an alternate authority of names, they *are* the one-and-only
authority of the name.  If they screw up, they affect only the names signed
by them (i.e., the names under their DNS tree branch).  And if they screw
up, "revocation" is fairly simple for them to perform and have take effect:
they just change their DNSSEC entries.

When it comes to STIR stuff, the point is we can't just trust third-party
CAs to certify any E.164 number it cares to; because if they scrwe up, it
affectes all E.164 numbers.  We have to have some means of tying the
certification to the authority that actually authoritatively assigns the
numbers.  So we need to know that a cert from carrier-X for number
+1-603-555-1000 is signed by a CA that actually assigned carrier-X that
E.164 number; which means we need to know what numbers the CA can assign -
that it's authoritative for that role/decision.

So... assuming we define some encoding scheme and mechanics for this E.164
stuff to be done in certs... we could have the ITU sign certs of
country-code admins indicating the country-code number, and the country-code
admins sign certs of carriers indicating the full number, and the carriers
sign certs of their customer service providers, and them signing certs of
enterprises or end-users.  (or more likely we'd skip the ITU level one, and
start with country-code level admins)

But that would require a means of actually retrieving the correct cert,
walking the chain of signers, retrieving each of their certs, and checking
revocation lists.  Meanwhile the caller has hung up the phone because it
didn't ring. :)

-hadriel

---

From: Russ Housley <[email-masked]>
Date: Tue, 16 Jul 2013 16:21:41 -0400

>     If no one cares about this distinction and everyone feels that "authenticate the originator" is sufficiently precise and accurate, fine, but I thought it worth making sure.

You are correct, and several people agreed with you.  However, none of you offered text.  So, I have made a stab at updating the charter text to address this point.  I'll post it in a minute.

> 'Considered...but main focus' essentially calls for solving the issue in the current effort.
> 
> Instead:
> 
>     Expansion of the authentication mechanism to identifiers using the user@domain form is deferred.
> 
> This creates awareness of the issue and implies an intent to deal with it (later).

Okay, but if someone comes up with a clean way to tackle telephone numbers and user@domain in a consistent fashion, I believe that would be highly desirable.

> These two draft sentence essentially require defining an out-of-band mechanism; if they don't they are meaningless or a distraction.
> 
> Instead:
> 
>     Consideration of out-of-band mechanisms, to deal with transit across non-SIP hops, is deferred.

I do not see consensus for this position.  It is agree that an end-to-end SIP session is the first priority.  However, others have said that an out-of-band solution is also needed to address the whole problem.  This is the second priority, and the charter text that I will propose says:

   After completing the in-band mechanism, the working group will consider
   session establishment where there are one or more non-SIP hops, most
   likely using an out-of-band authorization mechanism.  However, the
   in-band and the out-of-band mechanisms should share as much in common as
   possible, especially the credentials.

> I thought there was agreement to drop this deliverable.  It seems to have crept back in.

No.  This is tied to the above.

Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 16 Jul 2013 16:33:55 -0400

Russ

= = = = = = = = = =

Chairs: TBD

mechanism that verifies the authorization of the calling party to use
a particular telephone number.

SIP is one of the main VoIP technologies used by parties that want to
present an incorrect origin, in this context an origin telephone number.
Several previous efforts have tried to secure the origins of SIP
communications, including RFC 3325, RFC 4474, and the VIPR working group.
To date, however, true validation of the source of SIP calls has not seen
any appreciable deployment.  Several factors contributed to this lack of
success, including: failure of the problem to be seen as critical at the
time; lack of any technical means of producing a proof of authority over
telephone numbers; misalignment of the mechanisms proposed by RFC 4474
with the complex deployment environment that has emerged for SIP; lack of
end-to-end SIP session establishment; and inherent operational problems
with a transitive trust model.  To make deployment of this solution more
likely, consideration must be given to latency, real-time performance,
computational overhead, and administrative overhead for the legitimate
call source and all verifiers.

As its first work item, the working group will specify a SIP header-based
authorization mechanism to verify 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.  This is called an in-band mechanism.
The mechanism will use a canonical telephone number representation
specified by the working group, including any mappings that might be
needed between the SIP header fields and the canonical telephone number
representation.  The working group will consider choices for protecting
identity information and credentials used, but will likely be based on a
digital signature mechanism that covers a set of information in the SIP
header fields, and verification will employ a credential that contains
the public key and is associated with the one or more telephone numbers.
In order to be authoritative, credentials used with this mechanism will
be derived from existing telephone number assignment and delegation
models.  That is, when a telephone number or range of telephone numbers
is delegated to an entity, relevant credentials will be generated (or
modified) to reflect such delegation.  The mechanism must allow parties
who are not delegated a telephone number, but are authorized by the
entity who is delegated the number, to place calls using the identity.

Expansion of the authorization mechanism to identities using the
user@domain form deferred since the main focus of the working group is to
develop a solution for telephone numbers.

Authentication and authorization of identity is closely linked to
privacy, and these security features frequently come at the cost of
privacy.  This working group is not chartered to mandate the presence of
identity in SIP requests, and to the extent feasible it will find
privacy-friendly solutions that leak minimal information about calls to
third parties.

  - A document describing the credentials required to support
    telephone number identity authentication

Milestones

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 16 Jul 2013 20:52:53 +0000

I'm not sure this is what you have in mind, but to elaborate a bit:

I suspect that for both the DNS and other database solutions, as well as certs, you can do something like the following:

* The carrier of record for a number block has credentials with the national DB operator, whether a cert or simply a password. (For simplicity, I assume one such operator, which appears to be common in most jurisdictions. If multiple, add a level of indirection.)

* The carrier of record takes a request from their customer containing a public key and says to the DB operator: "Hi, DB operator, please issue a cert for the public key for this number out of my block". DB operator complies and signs public key. No need to reveal who the public key belongs to.

* Signing requests get chained up, i.e., the end user sends a request to their provider, who turns around and contacts theirs, etc. Add OAuth to taste.

There is no need to trace the delegation chain in real time for validation - every cert is signed by the DB operator.

There is no need for a single protocol to do the requests, although that's obviously a good thing to have for automated provisioning. Fax and ftp will do, if needed, since the interoperability is local to the carrier and its customers.

If somebody screws up, they can only screw up their own number range. A customer down the chain needs to trust everybody up the chain, but that's true today - if the carrier re-assigns your number to somebody else or two parties, you will have at least a few miserable days getting it straightened out. We do get those types of complaints, apparently more so recently.

Henning
________________________________________
From: [email-masked] [[email-masked]] on behalf of Michael Hammer [[email-masked]]
Sent: Tuesday, July 16, 2013 4:14 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [stir] Rollout timeframe

15 digits:

Mike

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]]
Sent: Tuesday, July 16, 2013 3:26 PM
To: Michael Hammer
Cc: [email-masked]; [email-masked]
Subject: Re: [stir] Rollout timeframe

third party, even an SP.
organizational failure.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 16 Jul 2013 16:53:07 -0400

> I do not see consensus for this position.  It is agree that an end-to-end SIP session is the first priority.  However, others have said that an out-of-band solution is also needed to address the wh…

If the chairs are going to be fair, I don't think there's a consensus for the opposite case *either*.  We are not a Working Group yet, and there is no existing charter of a Working Group yet.  The current charter is an empty page.  Thus we need consensus to put something *in* a new charter, as much as we need to remove something from one.  In fact, I'd argue you need far stronger consensus to put something *in* a new charter, than you do to keep something out.

Be that as it may, I think it's clear we'll be debating this issue in the BOF.  I don't see enough time for doing that - 30 minutes for charter debate isn't long when you know in advance there'll be heated debate.

I'm happy to give up my presentation time slot, to give more time for the debate.

Maybe the chairs could also write up a script of what we're each going to say in advance.  You only need to copy from the emails we've already sent.  That way we'd save on time, and even have the minutes already documented. :)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 16 Jul 2013 17:07:59 -0400

Yup, that's basically what CIDER proposes happens.  Except it skips the part about needing to get back a cert, or even having certs, because they're useless and unnecessary overhead and just something more that can go wrong.  Many people in the IETF love them - most developers and especially admins trying to use them hate them, afaict.

-hadriel
p.s. And the CIDER draft does have an appendix on requirements for the public-key provisioning protocol part, even though you could obviously do it with email or fax or a web-portal or whatever.

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 16 Jul 2013 17:38:19 -0400

After my 2nd cocktail.

Why don't we in +1  just call up the NSA and the Communications Security
Establishment Canada and suggests they take over joint CA responsibility for
the NANP. 

The have the money a certain "technical expertise".  They already have our
call detail records. <g>  If they could stop Call Spoofing they would be
extremely popular with the public.  <g> 

It's a joke ..sort of .. <g> 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian Rosen
Sent: Tuesday, July 16, 2013 3:40 PM
To: Stephen Kent
Cc: [email-masked]; Michael Hammer
Subject: Re: [stir] Rollout timeframe

In the U.S., there may be many delegations in a path from the North American
Number Plan Administrator to the user that has the number.  Only the first
two of these are captured in the formal delegation databases - NANPA
allocates a NPA (area code) to the Pooling Administrator, which delegates a
1000 number block to a carrier.

That carrier may resell 100 numbers to a SIP provider, who resells 20 of
them to another SIP provider who sells 10 of them to an enterprise, who
allocates one of those to an employee.

At each step in the delegation (possibly save the last one), there could
theoretically be a credential issued.

I would not want to verify the validity of all of these individually to
check a source identity.

Ideally, I'd like to go one place and be able to get one credential that is
authoritative for the number.

That seems possible, even when we have the credential path follow the
delegation path.

I hear you on data size.  But remember, an exabyte hear and an exabyte
there, and pretty soon, we're talking real big data stores.

Brian

On Jul 16, 2013, at 3:17 PM, Stephen Kent <[email-masked]> wrote:

> Brian,
> 
>> I think the credential path follows the delegation path, but I hope that
in most deployments, we're not chasing a chain of credentials to validate.
> I don't know what you mean by the statement above. Do you mean that 
> you hope cert paths (or a DNSSEC equivalent) will be short, that most 
> of tbe data will change slowly enough that caching will be a big win, or
what?

---

From: Brian Rosen <[email-masked]>
Date: Tue, 16 Jul 2013 17:41:39 -0400

Sure, why not?

They would jump on it, because it gives them real time call set up time data, not after-the-fact billing data.

Brian

---

From: Michael Hammer <[email-masked]>
Date: Tue, 16 Jul 2013 21:51:45 +0000

Yes, much along those lines.

However, unlike CIDER, you don't need secret trees that have limited access,
and no privacy concerns.
The certificates can be promiscuously distributed, and can be validated by
also having the well-known DB cert.
You can even have the cert send in-band, with no query to the DNS.
And how to validate a cert is well known.

The DB operator has credentials for all the carriers of record.  
That can be many if the delegation cuts out some levels of middlemen and CoR
is more granular, but still doable.

A standard process to register a Tel#/public key pair and get a cert between
carrier of record and DB should not be hard.

How the carrier of record manages the creation of public keys and pairing
with telephone numbers 
and manages that with their customers does not need to be standardized.

(Note, the carrier could even create those pairings in advance and register
them with the DB in advance, 
and distribute only to users when assigning to users.  If you trust the
carrier to administer the number, 
no reason not to trust them to administer the private key/cert
distribution.)

If one wanted the end-user to generate the Tel#/private key pair, the CoR
could ask them to generate that and 
submit the public key up hop-by-hop through the SP chain to the CoR that
registers it and returns a cert.

What gets signed and what passes E2E in-band is still an issue, but at least
a trust basis would be in place.
And presumable, the SPs that support it won't turn around and circumvent it
by stripping out supporting E2E headers.

Mike

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Tuesday, July 16, 2013 5:08 PM
To: Henning Schulzrinne
Cc: Michael Hammer; [email-masked]
Subject: Re: [stir] Rollout timeframe

Yup, that's basically what CIDER proposes happens.  Except it skips the part
about needing to get back a cert, or even having certs, because they're
useless and unnecessary overhead and just something more that can go wrong.
Many people in the IETF love them - most developers and especially admins
trying to use them hate them, afaict.

-hadriel
p.s. And the CIDER draft does have an appendix on requirements for the
public-key provisioning protocol part, even though you could obviously do it
with email or fax or a web-portal or whatever.

On Jul 16, 2013, at 4:52 PM, Henning Schulzrinne
<[email-masked]> wrote:

> I suspect that for both the DNS and other database solutions, as well as
certs, you can do something like the following:
> 
> * The carrier of record for a number block has credentials with the 
> national DB operator, whether a cert or simply a password. (For 
> simplicity, I assume one such operator, which appears to be common in 
> most jurisdictions. If multiple, add a level of indirection.)
> 
> * The carrier of record takes a request from their customer containing a
public key and says to the DB operator: "Hi, DB operator, please issue a
cert for the public key for this number out of my block". DB operator
complies and signs public key. No need to reveal who the public key belongs
to.
> 
> * Signing requests get chained up, i.e., the end user sends a request to
their provider, who turns around and contacts theirs, etc. Add OAuth to
taste.
> 
> There is no need to trace the delegation chain in real time for validation
- every cert is signed by the DB operator.
> 
> There is no need for a single protocol to do the requests, although that's
obviously a good thing to have for automated provisioning. Fax and ftp will
do, if needed, since the interoperability is local to the carrier and its
customers.
> 
> If somebody screws up, they can only screw up their own number range. A
customer down the chain needs to trust everybody up the chain, but that's
true today - if the carrier re-assigns your number to somebody else or two
parties, you will have at least a few miserable days getting it straightened
out. We do get those types of complaints, apparently more so recently.
> From: [email-masked] [[email-masked]] on behalf of 
> Michael Hammer [[email-masked]]
> Agree, but I was suggesting one CA operating for the national 
> authority who knows via feedback from the delegation system what SP has
each number.
> Your DNSSEC solution just defines how the central authority maintains 
> its knowing of what SP owns what number.
> There are other technologies to store/maintain the {Tel#, SP name, SP 
> public key | cert, User public key | cert} tuple.
> And that is the whole E.164 number space, so at national level orders 
> of magnitude less.
> 
> Mike
> 
> 
> trusted CA to claim any domain name, even though none of them are 
> actually authoritative for domain name assignments.  You can think of 
> it as basically creating an alternate-root to DNS - an alternate 
> authority of names - from an SSL/TLS-usage perspective.
> 
> Since browsers trust ~160 CAs, the odds of a trusted CA screwing up 
> not only became high, but once it happened it affected all domain 
> names.  It didn't just screw up the validity of domain names DigiNotar 
> happens to certify, but it screwed up ALL of them, because no one 
> knows what domain names DigitNotar could legitimately certify.  With 
> DNSSEC, however, the actual authority of domain name assignments is 
> the same entity who actually signs stuff; they are not an alternate 
> authority of names, they *are* the one-and-only authority of the name.  
> If they screw up, they affect only the names signed by them (i.e., the 
> names under their DNS tree branch).  And if they screw up, "revocation" is
fairly simple for them to perform and have take effect:
> When it comes to STIR stuff, the point is we can't just trust 
> third-party CAs to certify any E.164 number it cares to; because if 
> they scrwe up, it affectes all E.164 numbers.  We have to have some 
> means of tying the certification to the authority that actually 
> authoritatively assigns the numbers.  So we need to know that a cert 
> from carrier-X for number
> +1-603-555-1000 is signed by a CA that actually assigned carrier-X 
> +that
> E.164 number; which means we need to know what numbers the CA can 
> assign - that it's authoritative for that role/decision.
> 
> So... assuming we define some encoding scheme and mechanics for this 
> E.164 stuff to be done in certs... we could have the ITU sign certs of 
> country-code admins indicating the country-code number, and the 
> country-code admins sign certs of carriers indicating the full number, 
> and the carriers sign certs of their customer service providers, and 
> them signing certs of enterprises or end-users.  (or more likely we'd 
> skip the ITU level one, and start with country-code level admins)
> 
> But that would require a means of actually retrieving the correct 
> cert, walking the chain of signers, retrieving each of their certs, 
> and checking revocation lists.  Meanwhile the caller has hung up the 
> phone because it didn't ring. :)
> 
> -hadriel
>

---

From: Michael Hammer <[email-masked]>
Date: Tue, 16 Jul 2013 22:34:01 +0000

Not an easy task to do.

I have perhaps one area of concern:
"The mechanism must allow parties who are not delegated a telephone number, 
but are authorized by the entity who is delegated the number, to place calls
using the identity."

I think that this is an ancillary mechanism, versus "the" mechanism, but
that aside how about:

"The mechanism(s) must allow a delegated telephone number holder to locally
sub-delegate and revoke its use 
by another delegated telephone number holder without compromising the global
delegation scheme."

I suggested earlier how this could be done.

My concern is that such local issues should not impact the SPs or the
central authority, nor should it weaken the overall delegation process.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Russ
Housley
Sent: Tuesday, July 16, 2013 4:34 PM
To: IETF STIR Mail List
Subject: Re: [stir] Draft STIR Charter

I have tried to pull all of the discussion into an updated charter.  I have
also attached a diff to make it easier to review.

Russ

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 16 Jul 2013 20:57:07 -0400

> who knows via feedback from the delegation system what SP has each number.

OK, I think I grok the part above so far - you're just saying use one trusted CA per country, and have it sign all certs, and there's a separate cert per E.164.  I'm with you so far...

> One place to look to validate.

Where?  Where does the call verifier system get the cert from, when it receives a call request?  Where does it check that both the root CA's cert and the carrier's cert have not been revoked?

> knowing of what SP owns what number.

Sure it does that, but it doesn't "just" do that - that's not even its main purpose/benefit.  It lets the verifier systems retrieve the public keys, in a highly-efficient, scalable manner; and in such a way that they don't have to do any additional CRL/OCSP validation.  It stores the keys in the same place that defines the number assignments, and when number assignment changes, both the database entry of the assignment and the database of the keys changes at the same time.  There aren't a bunch of certs floating around in the ether to worry about.

[as an aside, CIDER is not a "DNSSEC" solution per se - the DNS tree should be DNSSEC signed, but whether the verifier checks the DNSSEC parts or not is up to them, and my guess is most won't for calls within their country, because the threat model of bogus DNS injection is likely pretty small for STIR in practice]

> key | cert, User public key | cert} tuple.

Yup, of course there are.

> Delegation updates SP values, Assignment uses SP values to update User

I'm not sure I grok that.  What do you mean?

-hadriel

---

From: Michael Hammer <[email-masked]>
Date: Wed, 17 Jul 2013 02:36:37 +0000

Inline...

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Tuesday, July 16, 2013 8:57 PM
To: Michael Hammer
Cc: [email-masked] Mail List
Subject: CA Certs (was: Re: [stir] Rollout timeframe)

each number.
> No chains.

OK, I think I grok the part above so far - you're just saying use one
trusted CA per country, and have it sign all certs, and there's a separate
cert per E.164.  I'm with you so far...

> One place to look to validate.

Where?  Where does the call verifier system get the cert from, when it
receives a call request?  Where does it check that both the root CA's cert
and the carrier's cert have not been revoked?

>> The cert can be provided in-band with the call.  

>> If need be, the certs can be fetched from a known location.  Each carrier
can also cache any cert.  The central administrator's cert can also be
published and cached widely so that any Tel# cert can be directly verified.

>>  This does not involve the carrier's cert other than that the central
administrator needs to validate that the carrier's cert used in updating the
DB is up to date and not revoked.  Those certs are a separate matter.  If
the DB wants, they can use passwords if they want.

>>  Revocations are done via Certificate Revocation Lists.

> its knowing of what SP owns what number.

Sure it does that, but it doesn't "just" do that - that's not even its main
purpose/benefit.  It lets the verifier systems retrieve the public keys, in
a highly-efficient, scalable manner; and in such a way that they don't have
to do any additional CRL/OCSP validation.  

>> How many RTTs does your system require versus none?

It stores the keys in the same place that defines the number assignments,
and when number assignment changes, both the database entry of the
assignment and the database of the keys changes at the same time.  There
aren't a bunch of certs floating around in the ether to worry about.

>> For normal operation they don't float in the ether, they are included in
the signaling between caller and called.  No different than the validation
that would be required to be sure that access to your solution is not
spoofed.

[as an aside, CIDER is not a "DNSSEC" solution per se - the DNS tree should
be DNSSEC signed, but whether the verifier checks the DNSSEC parts or not is
up to them, and my guess is most won't for calls within their country,
because the threat model of bogus DNS injection is likely pretty small for
STIR in practice]

>> So, you basically propose a solution that is either unsecure or requires
an equivalent strong security?  Need to compare apples to apples here.

>> Just that it is inherent that the central authority keep track of who
"owns" the number to determine who is allowed to update.  You have the same
in your solution.  Once, the carrier of record is authenticated, then the
information they provide for that number (public key) can be used to
create/store/return a cert.  You have same storage of public key and
association to a number in your solution.

>> I am also hoping that the cert-based solution exhibits a higher degree of
shared fate, since it coincides with the signaling, versus dependency on
5-9's operation for the repository you propose.

Hopes that helps,
Mike

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 16 Jul 2013 23:34:00 -0400

> However, unlike CIDER, you don't need secret trees that have limited access,

What "secret trees"?  You mean that CIDER could be deployed as a private DNS?

CIDER could be deployed in a private/federated manner, for sure, but it doesn't *have* to be.  Each country/anchor can make that decision for themselves.

Obviously if a country chooses to keep it private, then they'd have to either figure out how to let other countries validate the numbers, or not have their numbers be validated by other countries.  It's not actually impossible to keep your country's CIDER tree private while still letting other countries validate your numbers - because international calls in most countries happen to come in through very specific peering points/carriers, and we could figure out how to make it work.  For example, the private country could let just the specific international carriers access its CIDER servers; or it could let just specific DNS resolvers do so under controlled conditions.  There are only ~160 country-code admins to have to deal with, so it's not totally crazy.

Then again, using HTTP or LDAP or anything else has the same problem - if you don't provide unrestricted access to the certs, then you have to live with the complexities of access control to them from everywhere, including all other countries; or not make them accessible to other countries; or use the same sort of hacks.

> The certificates can be promiscuously distributed,

How?

> You can even have the cert send in-band, with no query to the DNS.

Sadly, that we can't do.  Or at least the premise has been that we can't expect to do that successfully, and I believe the premise is likely true.

> is more granular, but still doable.

Sure - it has to have that in CIDER too, to grant access rights for publishing public keys.  No matter what, the common root/anchor/whatever has to know about the CoRs, and it's scalable because they know about them already today.

> carrier of record and DB should not be hard.

Agreed.

> and manages that with their customers does not need to be standardized.

Right it doesn't *have* to be standardized, but as it turns out, it could be the exact same protocol as used between the CoR and the DB.  Creating a standard protocol for it doesn't mean people must or will use it - it just simplifies things for some people if there is a standard protocol for it.

> no reason not to trust them to administer the private key/cert

I don't disagree that could happen, but we'd never say so in any IETF documents.  It's bad mojo to have private keys passed around.  Kinda ruins the non-repudiation aspects.  There's "trust" and then there's "Legally-binding Trust".  I think even the carriers might prefer you use a private key they can't know about, for example so that if you screw up later they could prove you screwed up and not them.

> registers it and returns a cert.

Yup, like CIDER too.  Except CIDER skips the "returns a cert" portion.

> a trust basis would be in place.

Right, much of the debate has been around how the trust basis would happen, not about what passes E2E.  So far there are two proposals for what passes E2E, but no debate about that yet.

> by stripping out supporting E2E headers.

Right, which means we need to make the info in the headers as benign/uncontroversial as possible.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 17 Jul 2013 00:37:42 -0400

>>> The cert can be provided in-band with the call.  

It can't. Not if we want to get the stuff through E2E. :(

>>> If need be, the certs can be fetched from a known location.  

What known location?
An HTTP server in the cloud?  Run by whom?

>>> Each carrier
> can also cache any cert.  

How?  You mean cache them after they've retrieved them from a previous call?
How long do they cache them for, so as not to screw up the ability for the originator/DB to change certs?

> The central administrator's cert can also be

Yup.

> the DB wants, they can use passwords if they want.

Sorry, I should have been clearer: I mean the end-entity E.164 cert not the carrier cert.  I meant when a call arrives, the verifier goes and gets a cert for the E.164.  That cert is signed by a root CA (the central admin cert).  The verifier needs to check the root CA cert hasn't been revoked, but let's ignore that part because it's not a check it has to do on every call really.  But the verifier has to check the root CA hasn't revoked the end-entity E.164 cert.  That's painful.

We could ignore that end-entity revocation check too if we decide it's ok for it to be wrong until the cert expiry time.  For example if we make those E.164 certs only last a few months or something, we could just take the risk that the cert has been revoked and if we're wrong it would only be a problem for a few months in the worst case.  But it wouldn't look good in the press if that E.164 happened to be Citibank's number.  And refreshing certs every few months isn't fun either.

>>> Revocations are done via Certificate Revocation Lists.

Ouch.  Those really suck.
Although it would be a fascinating case-study to see how CRLs scale when one carrier has its private keys compromised.
:)

>>> How many RTTs does your system require versus none?

In actual practice?  I would expect CIDER to take about one RTT on average, for domestic calls.  More for international, but users expect longer PDD for international calls.

There is no "none".  HTTP takes 2 RTTs best-case for just the TCP+HTTP portion - but you need to do DNS before that to resolve the URL.  CIDER gives you the key during that DNS portion.  No need to go further.

If by "none" you mean put the cert in the signaling, see above/below on that.

> that would be required to be sure that access to your solution is not

See above.  The premise has so far been that we can't include the certs in the signaling and expect them to get E2E.  I agree with that premise, unfortunately.

> an equivalent strong security?  Need to compare apples to apples here.

For sure, but I was just commenting on your using the phrase "Your DNSSEC solution..." above.  So I was just commenting on that "DNSSEC" label.

But since we're on this topic, the threat model for bogus DNS responses in STIR is far different from the threat model of using bogus certs in STIR.  The latter is trivial to accomplish.  The former is really hard.

> association to a number in your solution.

Ahh, got it.

> 5-9's operation for the repository you propose.

Right, if we could put the certs in the signaling we'd have fewer things to fail.  The bad news is we can't put the certs in the signaling.  The good news is DNS is pretty stable and redundantly deployable; and in practice I expect many carriers to have either highly managed connections to the DB, or actual local copies of the thing; and if it can't be reached temporarily, I don't expect calls to fail.

-hadriel

---

From: Michael Hammer <[email-masked]>
Date: Wed, 17 Jul 2013 13:30:00 +0000

Points to answer:

Having to go through a (existing PSTN?) international peering point carrier
just prolongs the PSTN hop-by-hop model and not the Internet E2E model.

Promiscuous distribution:  There can be an app for that.  HTTP works really
well.  :)

I realize that passing the certs through a PSTN hop represents a challenge.
The narrowly defined PSTN alt-route for "fat stuff that doesn't fit in
existing SS7" between PSTN GW proposed earlier could address that, and could
even be done without standardization.

Mike

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Tuesday, July 16, 2013 11:34 PM
To: Michael Hammer
Cc: [email-masked]; [email-masked]
Subject: CA certs (was Re: [stir] Rollout timeframe)

On Jul 16, 2013, at 5:51 PM, Michael Hammer <[email-masked]>
wrote:

> However, unlike CIDER, you don't need secret trees that have limited 
> access, and no privacy concerns.

What "secret trees"?  You mean that CIDER could be deployed as a private
DNS?

CIDER could be deployed in a private/federated manner, for sure, but it
doesn't *have* to be.  Each country/anchor can make that decision for
themselves.

Obviously if a country chooses to keep it private, then they'd have to
either figure out how to let other countries validate the numbers, or not
have their numbers be validated by other countries.  It's not actually
impossible to keep your country's CIDER tree private while still letting
other countries validate your numbers - because international calls in most
countries happen to come in through very specific peering points/carriers,
and we could figure out how to make it work.  For example, the private
country could let just the specific international carriers access its CIDER
servers; or it could let just specific DNS resolvers do so under controlled
conditions.  There are only ~160 country-code admins to have to deal with,
so it's not totally crazy.

Then again, using HTTP or LDAP or anything else has the same problem - if
you don't provide unrestricted access to the certs, then you have to live
with the complexities of access control to them from everywhere, including
all other countries; or not make them accessible to other countries; or use
the same sort of hacks.

How?

> You can even have the cert send in-band, with no query to the DNS.

Sadly, that we can't do.  Or at least the premise has been that we can't
expect to do that successfully, and I believe the premise is likely true.

> That can be many if the delegation cuts out some levels of middlemen 
> and CoR is more granular, but still doable.

Sure - it has to have that in CIDER too, to grant access rights for
publishing public keys.  No matter what, the common root/anchor/whatever has
to know about the CoRs, and it's scalable because they know about them
already today.

> A standard process to register a Tel#/public key pair and get a cert 
> between carrier of record and DB should not be hard.

Agreed.

> How the carrier of record manages the creation of public keys and 
> pairing with telephone numbers and manages that with their customers 
> does not need to be standardized.

Right it doesn't *have* to be standardized, but as it turns out, it could be
the exact same protocol as used between the CoR and the DB.  Creating a
standard protocol for it doesn't mean people must or will use it - it just
simplifies things for some people if there is a standard protocol for it.

> (Note, the carrier could even create those pairings in advance and 
> register them with the DB in advance, and distribute only to users 
> when assigning to users.  If you trust the carrier to administer the 
> number, no reason not to trust them to administer the private key/cert
> distribution.)

I don't disagree that could happen, but we'd never say so in any IETF
documents.  It's bad mojo to have private keys passed around.  Kinda ruins
the non-repudiation aspects.  There's "trust" and then there's
"Legally-binding Trust".  I think even the carriers might prefer you use a
private key they can't know about, for example so that if you screw up later
they could prove you screwed up and not them.

> If one wanted the end-user to generate the Tel#/private key pair, the 
> CoR could ask them to generate that and submit the public key up 
> hop-by-hop through the SP chain to the CoR that registers it and 
> returns a cert.

> What gets signed and what passes E2E in-band is still an issue, but at 
> least a trust basis would be in place.

Right, much of the debate has been around how the trust basis would happen,
not about what passes E2E.  So far there are two proposals for what passes
E2E, but no debate about that yet.

> And presumable, the SPs that support it won't turn around and 
> circumvent it by stripping out supporting E2E headers.

Right, which means we need to make the info in the headers as
benign/uncontroversial as possible.

-hadriel

---

From: Michael Hammer <[email-masked]>
Date: Wed, 17 Jul 2013 13:49:45 +0000

Points:

The beauty of the cert is that you don't have to get it from a specific
location, so no single point of attack to block it.

CRLs wouldn't be checked during a call, that can be done periodically when
the user is inactive.

A revocation period would be no different that the period of time that an
entry in your DNS would be bad.  Same issue.

Your E2E issue is valid.  But, do we design for the past or for the future
when most calls will be Internet E2E?
(That is, do we do work-arounds for the past or constrain the future signal
routing patterns?)

Mike

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Wednesday, July 17, 2013 12:38 AM
To: Michael Hammer
Cc: [email-masked]
Subject: Re: CA Certs (was: Re: [stir] Rollout timeframe)

On Jul 16, 2013, at 10:36 PM, Michael Hammer <[email-masked]>
wrote:

> receives a call request?  Where does it check that both the root CA's 
> cert and the carrier's cert have not been revoked?
> 

What known location?

How?  You mean cache them after they've retrieved them from a previous call?
How long do they cache them for, so as not to screw up the ability for the
originator/DB to change certs?

> The central administrator's cert can also be published and cached 
> widely so that any Tel# cert can be directly verified.

Yup.

> administrator needs to validate that the carrier's cert used in 
> updating the DB is up to date and not revoked.  Those certs are a 
> separate matter.  If the DB wants, they can use passwords if they want.

Sorry, I should have been clearer: I mean the end-entity E.164 cert not the
carrier cert.  I meant when a call arrives, the verifier goes and gets a
cert for the E.164.  That cert is signed by a root CA (the central admin
cert).  The verifier needs to check the root CA cert hasn't been revoked,
but let's ignore that part because it's not a check it has to do on every
call really.  But the verifier has to check the root CA hasn't revoked the
end-entity E.164 cert.  That's painful.

We could ignore that end-entity revocation check too if we decide it's ok
for it to be wrong until the cert expiry time.  For example if we make those
E.164 certs only last a few months or something, we could just take the risk
that the cert has been revoked and if we're wrong it would only be a problem
for a few months in the worst case.  But it wouldn't look good in the press
if that E.164 happened to be Citibank's number.  And refreshing certs every
few months isn't fun either.

>>> Revocations are done via Certificate Revocation Lists.

Ouch.  Those really suck.
Although it would be a fascinating case-study to see how CRLs scale when one
carrier has its private keys compromised.
:)

> Sure it does that, but it doesn't "just" do that - that's not even its 
> main purpose/benefit.  It lets the verifier systems retrieve the 
> public keys, in a highly-efficient, scalable manner; and in such a way 
> that they don't have to do any additional CRL/OCSP validation.
> 

In actual practice?  I would expect CIDER to take about one RTT on average,
for domestic calls.  More for international, but users expect longer PDD for
international calls.

There is no "none".  HTTP takes 2 RTTs best-case for just the TCP+HTTP
portion - but you need to do DNS before that to resolve the URL.  CIDER
gives you the key during that DNS portion.  No need to go further.

If by "none" you mean put the cert in the signaling, see above/below on
that.

> It stores the keys in the same place that defines the number 
> assignments, and when number assignment changes, both the database 
> entry of the assignment and the database of the keys changes at the 
> same time.  There aren't a bunch of certs floating around in the ether to
worry about.
> the signaling between caller and called.  No different than the 
> validation that would be required to be sure that access to your 
> solution is not spoofed.

See above.  The premise has so far been that we can't include the certs in
the signaling and expect them to get E2E.  I agree with that premise,
unfortunately.

> [as an aside, CIDER is not a "DNSSEC" solution per se - the DNS tree 
> should be DNSSEC signed, but whether the verifier checks the DNSSEC 
> parts or not is up to them, and my guess is most won't for calls 
> within their country, because the threat model of bogus DNS injection 
> is likely pretty small for STIR in practice]
> 

For sure, but I was just commenting on your using the phrase "Your DNSSEC
solution..." above.  So I was just commenting on that "DNSSEC" label.

But since we're on this topic, the threat model for bogus DNS responses in
STIR is far different from the threat model of using bogus certs in STIR.
The latter is trivial to accomplish.  The former is really hard.

>> Delegation updates SP values, Assignment uses SP values to update 
>> User values.
> 
> "owns" the number to determine who is allowed to update.  You have the 
> same in your solution.  Once, the carrier of record is authenticated, 
> then the information they provide for that number (public key) can be 
> used to create/store/return a cert.  You have same storage of public 
> key and association to a number in your solution.

Ahh, got it.

> shared fate, since it coincides with the signaling, versus dependency 
> on 5-9's operation for the repository you propose.

Right, if we could put the certs in the signaling we'd have fewer things to
fail.  The bad news is we can't put the certs in the signaling.  The good
news is DNS is pretty stable and redundantly deployable; and in practice I
expect many carriers to have either highly managed connections to the DB, or
actual local copies of the thing; and if it can't be reached temporarily, I
don't expect calls to fail.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 17 Jul 2013 10:14:22 -0400

> just prolongs the PSTN hop-by-hop model and not the Internet E2E model.

OK, but STIR is supposed to be about fixing robocalling in the real world, not the world we might want to exist.

> Promiscuous distribution:  There can be an app for that.  HTTP works really

Sure, that's the out-of-band proposal.

> even be done without standardization.

How could it be done without standardization?

-hadriel

---

From: Michael Hammer <[email-masked]>
Date: Wed, 17 Jul 2013 14:23:30 +0000

Note, I pointed out both in-band and out-of-band was possible.

As a former PSTN GW vendor, I can say we did lots of things that were
standardized.
If the two GWs are from the same vendor and if the two carriers have a
bilateral agreement, it can be done.
I am not saying that having a standard method wouldn't help.

Mike

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Wednesday, July 17, 2013 10:14 AM
To: Michael Hammer
Cc: [email-masked] List
Subject: Re: [stir] CA certs (was Re: Rollout timeframe)

On Jul 17, 2013, at 9:30 AM, Michael Hammer <[email-masked]>
wrote:

> Having to go through a (existing PSTN?) international peering point 
> carrier just prolongs the PSTN hop-by-hop model and not the Internet E2E
model.

OK, but STIR is supposed to be about fixing robocalling in the real world,
not the world we might want to exist.

> Promiscuous distribution:  There can be an app for that.  HTTP works 
> really well.  :)

> existing SS7" between PSTN GW proposed earlier could address that, and 
> could even be done without standardization.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 17 Jul 2013 10:48:55 -0400

> location, so no single point of attack to block it.

Yup, agreed.  But you still need a location/URL to get it from.  
Unless you just mean that multiple physical servers can hold the cert - but that's true for DNS as well, obviously.

> CRLs wouldn't be checked during a call, that can be done periodically when

OK, but when I said "it would be an interesting case-study" I meant more that if a large carrier had its private keys compromised, that's a crap-load of certs to revoke.  The model you had was each E.164 has its own cert, and that end-entity E.164 cert was signed by the one DB numbering authority for the entire country-code. So if a carrier with 50 million numbers had its private keys compromised, 50 million certs would have to be revoked, and added to the CRL. (and 50 million isn't an exaggerated number, many carriers have more than that already today)

> entry in your DNS would be bad.  Same issue.

How so?  The instant an E.164's key is compromised you switch out the DNS entry.  There may be some DNS caches with the old keys, but only for hours not months.  It's a TTL value, not cert validity time.

From a DNSSEC perspective, yes you would still be susceptible to bogus DNS injections/poisoning using the old entry, because the RRSIG RR for the old entry would be valid still - but it's a lot harder to accomplish bogus DNS injections/poisoning for a given E.164 number in STIR, than it is to simply make a phone call claiming the E.164 and using the compromised cert.

> (That is, do we do work-arounds for the past or constrain the future signal

I know it's tempting to design for a future you might want to have, but as far as I know the STIR thing is supposed to be about making it work and deployable in the world we really have.  Personally, that's the reason I'm spending any time on it - I think RFC 4474 is perfectly fine for some future E2E world, and doesn't need fixing for that world.  If we want to design for some future thing that might happen someday, that's cool, but I think we should be up-front about it.  We create working groups for that sort of thing too, but it attracts different people and has different constraints/timeframes/etc.

-hadriel

---

From: Brian Rosen <[email-masked]>
Date: Wed, 17 Jul 2013 10:58:32 -0400

Small note:

You would have to keep TTLs for at least U.S. zones under a few minutes to allow the 15 minute port.

I'd actually probably set it at a minute or two.

Enough that retries work, not enough for any effective load reduction on the authoritative servers.

Note that you are sure to get a bunch of trawlers looking for TNs that ported recently.  That may be a big problem, both for the server and for the idea.

Brian

---

From: Stephen Kent <[email-masked]>
Date: Wed, 17 Jul 2013 11:21:58 -0400

Brian,

Thanks for the clarification wrt number delegation.

> That carrier may resell 100 numbers to a SIP provider, who resells 20 of them to another SIP provider who sells 10 of them to an enterprise, who allocates one of those to an employee.
Are the delegations at the lower tiers in your example reported to 
higher tiers?
If not, then higher tiers cannot certify the lowest tier number holders, 
right?
> At each step in the delegation (possibly save the last one), there could theoretically be a credential issued.
yep.
> Ideally, I'd like to go one place and be able to get one credential that is authoritative for the number.
and who would issue that credential, in your example?
> That seems possible, even when we have the credential path follow the delegation path.
how?
> I hear you on data size.  But remember, an exabyte hear and an exabyte there, and pretty soon, we're talking real big data stores.
I agree that we have to not go overboard, but I also have not heard a 
description of
a consistent, secure approach to this problem. Some folks have said that 
MITM attacks are
not a concern, which runs counter to the model we almost always employ 
when evaluating protocol security in the IETF.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 17 Jul 2013 11:32:41 -0400

Henning,

The model you describe is simple and avoids the cert chaining concerns 
folks have cited.
it does yield a cert-per-number DB, I believe, as you have described it.

In Brian's example, the carrier of record may have sold numbers to folks who
have sold numbers to other folks, ... In this case, where the carrier of 
record
no longer knows to whom some of these number have been sold. When 
numbers are sold
does the carrier of record had over the private keys for those numbers, 
or does it
revoke the old certs and transitively pass on new cert requests from the 
lower tier
operators, so that only they have the private keys, or something else. 
Is this
process repeated through multiple tiers of operators as numbers are sold 
or ported?

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 17 Jul 2013 11:44:23 -0400

By "give this a rest for now" I think you mean having the last word :-) 
. Nice try.

> Steve,
>
> My pointing to NP was only to indicate that there are trusted third 
> parties that are reliable.
>
My suggestion was precisely to recommend aligning a certification system 
with the
existing number delegation system.
>
> My focus is on how the called party can validate in near-real-time 
> (few seconds) the authenticity of the number.
>
> That in turn needs administrative side that can update in only 
> slightly longer time (minutes) due to number portability.
>
> Given that calls can come from anywhere globally, I didn't think 
> crawling the internet to discover some locally peculiar regime would help.
>
If number delegation system details vary from one country to the next, 
and if certification
were to parallel that system, some discovery might be needed.

The example you cited here is just one case. As a consumer I might be 
happy if my SP verifies the calling number info and passes it  to me, 
rather than me having to do it myself. I realize that the current 
charter does not emphasize this model, but it's still just a draft ...

You have repeatedly referred to "the central authority" without 
qualifying the term.
presumably you don't envision one central authority for all numbers in 
the world, right?
If you mean a per-country central authority, and if countries manage 
delegation in a
fashion that views such an entity as authoritative for all number 
assignments (and
sub-delegations) in the country, then that makes sense, and is 
consistent with what I
suggested.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 17 Jul 2013 11:55:30 -0400

Hadriel,

> When it comes to STIR stuff, the point is we can't just trust third-party CAs to certify any E.164 number it cares to; because if they scrwe up, it affectes all E.164 numbers.  We have to have some…
Aside from misspelling  my name, your characterization of what I said is 
right!
> But that would require a means of actually retrieving the correct cert, walking the chain of signers, retrieving each of their certs, and checking revocation lists.  Meanwhile the caller has hung u…
gee, and just when I had become fond of your concise, accurate 
description of what I was saying :-) ! Several things could make this 
potentially time consuming process less onerous.
First, if carriers performed this checking for their called-party 
clients, they could cache the cert and CRL data and perform the checks 
very quickly, during call setup, vouching for
the caller ID info. Also, if the delegation chain is short, because it 
extends only to carriers of record and all certs are issued by them, or 
by national level authorities (as Henning suggested) then, this need not 
be a slow process. When the cert path is short, one could send it via 
SIP, so no need to search for the certs. If revocation status checking 
is not a critical, realtime requirement, as some others have suggested, 
then all the certs the called party needs would be in the header. (One 
could also consider sending OCSP responses to avoid the need for CRL 
checking.)

Anyway, thanks for the very clear message.

Steve

---

From: Michael Hammer <[email-masked]>
Date: Wed, 17 Jul 2013 16:20:39 +0000

Carrier certs:  first this only affects the administrative process.  Second,
there is no limitation of the carrier to one set of credentials.  How is
that different that if the credentials used to update DNS somehow were
determined to be compromised?  The net effect is the same.  The public keys
for users put in DNS by that carrier using that credential might be suspect
also.  The only difference is the nature of the credential and validation.

Cert validity time versus cache age-out time:  The two are different.  A
store can periodically remove and get new credentials for a user from the DB
source or a reflection site.  This is done all the time and is typical of
mobile networks.

Mike

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Wednesday, July 17, 2013 10:49 AM
To: Michael Hammer
Cc: [email-masked]
Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe)

On Jul 17, 2013, at 9:49 AM, Michael Hammer <[email-masked]>
wrote:

> Points:
> The beauty of the cert is that you don't have to get it from a 
> specific location, so no single point of attack to block it.

Yup, agreed.  But you still need a location/URL to get it from.  
Unless you just mean that multiple physical servers can hold the cert - but
that's true for DNS as well, obviously.

> CRLs wouldn't be checked during a call, that can be done periodically 
> when the user is inactive.

OK, but when I said "it would be an interesting case-study" I meant more
that if a large carrier had its private keys compromised, that's a crap-load
of certs to revoke.  The model you had was each E.164 has its own cert, and
that end-entity E.164 cert was signed by the one DB numbering authority for
the entire country-code. So if a carrier with 50 million numbers had its
private keys compromised, 50 million certs would have to be revoked, and
added to the CRL. (and 50 million isn't an exaggerated number, many carriers
have more than that already today)

> A revocation period would be no different that the period of time that 
> an entry in your DNS would be bad.  Same issue.

How so?  The instant an E.164's key is compromised you switch out the DNS
entry.  There may be some DNS caches with the old keys, but only for hours
not months.  It's a TTL value, not cert validity time.

>From a DNSSEC perspective, yes you would still be susceptible to bogus DNS
injections/poisoning using the old entry, because the RRSIG RR for the old
entry would be valid still - but it's a lot harder to accomplish bogus DNS
injections/poisoning for a given E.164 number in STIR, than it is to simply
make a phone call claiming the E.164 and using the compromised cert.

> Your E2E issue is valid.  But, do we design for the past or for the 
> future when most calls will be Internet E2E?
> (That is, do we do work-arounds for the past or constrain the future 
> signal routing patterns?)

I know it's tempting to design for a future you might want to have, but as
far as I know the STIR thing is supposed to be about making it work and
deployable in the world we really have.  Personally, that's the reason I'm
spending any time on it - I think RFC 4474 is perfectly fine for some future
E2E world, and doesn't need fixing for that world.  If we want to design for
some future thing that might happen someday, that's cool, but I think we
should be up-front about it.  We create working groups for that sort of
thing too, but it attracts different people and has different
constraints/timeframes/etc.

-hadriel

---

From: Michael Hammer <[email-masked]>
Date: Wed, 17 Jul 2013 16:25:13 +0000

I was trying to get back to other work.  J

But, it is hard not to answer questions when asked.

No single world authority.  Likely on a per-national basis.

Mike

From: Stephen Kent [mailto:[email-masked]] 
Sent: Wednesday, July 17, 2013 11:44 AM
To: Michael Hammer
Cc: [email-masked]
Subject: Re: [stir] Rollout timeframe

By "give this a rest for now" I think you mean having the last word :-) .
Nice try.

Steve,

If number delegation system details vary from one country to the next, and
if certification
were to parallel that system, some discovery might be needed. 

The example you cited here is just one case. As a consumer I might be happy
if my SP verifies the calling number info and passes it  to me, rather than
me having to do it myself. I realize that the current charter does not
emphasize this model, but it's still just a draft ...

You have repeatedly referred to "the central authority" without qualifying
the term.
presumably you don't envision one central authority for all numbers in the
world, right?
If you mean a per-country central authority, and if countries manage
delegation in a
fashion that views such an entity as authoritative for all number
assignments (and
sub-delegations) in the country, then that makes sense, and is consistent
with what I
suggested.

Mike

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 17 Jul 2013 12:43:10 -0400

Sorry about the name misspelling. :(
Other comments inline...

On Jul 17, 2013, at 11:55 AM, Stephen Kent <[email-masked]> wrote:

> gee, and just when I had become fond of your concise, accurate description of what I was saying :-) ! Several things could make this potentially time consuming process less onerous.
> First, if carriers performed this checking for their called-party clients, they could cache the cert and CRL data and perform the checks very quickly, during call setup, vouching for

Maybe, maybe not - they can certainly cache the country-code one, and even ones for the bigger/real carriers.  It might or might not be practical to cache ones for all service providers, both the real ones and the unregulated ones (last time I checked, there are on the order of ~1000 of them in total so far in the US, but its growing).

But I'm pretty sure it's impractical to cache them all if we really think Enterprises would have their own cert as well.  I'm not sure if it's realistic to expect Enterprises to have certs, but the desire to support that has been raised for STIR, mostly so the Enterprise could then sign certs of outsourced call-centers and remote branch offices I think.

> the caller ID info. Also, if the delegation chain is short, because it extends only to carriers of record and all certs are issued by them, or by national level authorities (as Henning suggested) then, this need not be a slow process.

Agreed, if there's only one CA signing everything, by definition it's not a long chain. :)
I was more responding to the idea of having a cert signing chain, which I thought was what people were talking about - that is what they were talking about at some point.

> When the cert path is short, one could send it via SIP, so no need to search for the certs.

Sadly we can't - doubling or tripling the SIP message size will make deploying it in the current infrastructure essentially untenable, from a practical perspective. Or at least that's the premise folks stipulated when the STIR discussion began, and I agree with it.

> If revocation status checking is not a critical, realtime requirement, as some others have suggested, then all the certs the called party needs would be in the header. (One could also consider sending OCSP responses to avoid the need for CRL checking.)

Yeah, I'm not sure whether revocation is important or not.  I think it depends on how long a compromised key would be usable for.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 17 Jul 2013 13:21:50 -0400

> I'd actually probably set it at a minute or two.

I'm not sure if it really matters if the TTL is short, but it doesn't have to be short - at least not with CIDER.  The DNS name uses a "key index", which identifies which specific public key was used for signing the call - i.e., a single E.164 can have multiple public keys in DNS. (it's like a DKIM "selector", but an integer instead of string)  That key index value is sent in the SIP header.  It then becomes part of the generated DNS name used for the lookup.  So when a key changes, the DNS full name changes, and there's no cache collision.

You have to do something like that no matter what solution we end up with (even HTTP), because the carriers have to be able to change their key whenever they want without affecting in-flight call requests, and give time for the new key to propagate to the local copies carriers might have of the whole DB.  Plus it lets two or more agents claim the same phone number, for example the outsourced call-center or medical doctor scenarios.

So when a number gets ported, the new carrier uploads a public key into a new/unused key index value, and thus there's no collision when verifiers query for it, and no problem if they have an older key cached locally.  The TTL won't affect it.

For example, suppose my number is +1-603-555-1000.  My carrier has a private key for that, and it had uploaded the public key into the CIDER DB for index "2".  When it signs the message, that number "2" gets put into the STIR header info somewhere (draft-kaplan-stir-ikes-out-00 describes where it could be encoded, for SIP/SS7/XMPP).  When some verifier receives that message, it sees the "2" and the caller-id of +1-603-555-1000, and creates a DNS query for the name "2._cidkey.0.0.0.1.5.5.5.3.0.6.1.cid.example.org".  It gets back a TXT RR with the base64-encoded public key, verifies the message, etc.

So suppose I port the number to a new carrier.  The porting process happens, and the new carrier now uploads a new public key into the CIDER DB, but will now use/get index "3" or "12" or whatever.  It then uses that "3" in its SIP messages.  So a verifier will generate a DNS query for name "3._cidkey.0.0.0.1.5.5.5.3.0.6.1.cid.example.org".  Thus there's no DNS cache hit to worry about.

> Note that you are sure to get a bunch of trawlers looking for TNs that ported recently.  That may be a big problem, both for the server and for the idea.

It may be a problem, but it's not a problem for the server or the idea.  For one thing, CIDER can be deployed in a purely private/controlled manner.  That's up to the specific admin of each branch to decide (i.e., each national authority, or national admin, or whatever).  There's plenty of evidence of private DNS in use, including in the SIP provider world.

But anyway, *any* database-based solution which is deployed as open/unrestricted query access would have that problem.  Using HTTP doesn't mean people can't write scripts to generate HTTP queries, and putting certs in HTTP servers certainly doesn't prevent learning when the cert contents change.  It's not the protocol that causes the issue... it's how it's administered, deployed, and controlled.

-hadriel

---

From: Brian Rosen <[email-masked]>
Date: Wed, 17 Jul 2013 13:43:42 -0400

On Jul 17, 2013, at 11:21 AM, Stephen Kent <[email-masked]> wrote:

> Are the delegations at the lower tiers in your example reported to higher tiers?
No, not in most cases

> If not, then higher tiers cannot certify the lowest tier number holders, right?
Presently, that's correct

> and who would issue that credential, in your example?
Well, of course, that's the big issue here.  I think we are mostly talking about some kind of per-country DB that issues credentials.
At every point, the delegator has to tell the DB about the delegation. 

It's not clear to me how far we should or need to go in that direction yet.  It certainly makes a whole lot of things easier and more practical if we do.  

> I agree that we have to not go overboard, but I also have not heard a description of
> a consistent, secure approach to this problem. Some folks have said that MITM attacks are
> not a concern, which runs counter to the model we almost always employ when evaluating protocol security in the IETF.
Yeah, and we're not of one mind about that.

If we stick to the problem we're trying to solve = robocalling, vishing and swatting, there is no MITM to worry about.

But, some of us want our solutions to prevent, or at least mitigate MITM.  How far you go gets into trouble with other aspects.

An example is the media hijack - alter the SDP and hijack the media.  That's an MITM problem, and the original 4474 work protected against that.  The problem is that in the real world, the SDP is altered most of the time by various middle boxes for reasons deemed important to the service providers.  That doesn't seem like it's going to change.  Jon has proposed including in the signature a way to know if the SDP has been altered, but not fail the signature if it had.  Given that nearly all SDP is altered, several folks on the list say that is a waste of effort.

---

From: Russ Housley <[email-masked]>
Date: Wed, 17 Jul 2013 15:08:38 -0400

Mike:

Included the previous sentence for context, I think we can convey the same meaning with many fewer words.

   That is, when a telephone number or range of telephone numbers
   is delegated to an entity, relevant credentials will be generated (or
   modified) to reflect such delegation.  The mechanism must allow a
   telephone number holder to further delegate and revoke use of
   a telephone number without compromising the global delegation
   scheme.

Russ

---

From: Michael Hammer <[email-masked]>
Date: Wed, 17 Jul 2013 19:17:29 +0000

Thanks, that works for me.

Wanted to de-couple local feature changes which could be frequent and
numerous.

Mike

-----Original Message-----
From: Russ Housley [mailto:[email-masked]] 
Sent: Wednesday, July 17, 2013 3:09 PM
To: Michael Hammer
Cc: [email-masked]
Subject: Re: [stir] Draft STIR Charter

Mike:

Included the previous sentence for context, I think we can convey the same
meaning with many fewer words.

Russ

On Jul 16, 2013, at 6:34 PM, Michael Hammer wrote:

> "The mechanism(s) must allow a delegated telephone number holder to 
> locally sub-delegate and revoke its use by another delegated telephone 
> number holder without compromising the global delegation scheme."

---

From: Stephen Kent <[email-masked]>
Date: Wed, 17 Jul 2013 16:28:37 -0400

Hadriel,
> But I'm pretty sure it's impractical to cache them all if we really think Enterprises would have their own cert as well.  I'm not sure if it's realistic to expect Enterprises to have certs, but the…
In the RPKI context the plan is for every AS operator to acquire and 
cache all certs
CRLs, ROAs, etc. for every other other operator, and to check for 
changes a few times per day.
There are about 35K network operators, world wide. Analysis of the time 
it takes to do this,
using servers in the Amazon cloud (in Tokyo and the US) to represent 
servers and clients,
shows that this is really not a big deal in terms of bandwidth, time, 
storage, etc. So, it would be useful to have some number to play with to 
get a sense of how much bigger this system might be.
> I was more responding to the idea of having a cert signing chain, which I thought was what people were talking about - that is what they were talking about at some point.
It's not one CA, but maybe one per country, or two tiers of CA per 
country, as per
Henning's model. But, that still makes of a very short chain.
> Sadly we can't - doubling or tripling the SIP message size will make deploying it in the current infrastructure essentially untenable, from a practical perspective. Or at least that's the premise f…
OK, I didn't see that assumption/assertion in the charter.
> Yeah, I'm not sure whether revocation is important or not.  I think it depends on how long a compromised key would be usable for.
As I mentioned in a previous message, when designing a PKI it's 
important to have a
model of the expected revocation rate when deciding on cert lifetimes. 
If one has
good data on churn for a system prior to engineering a PKI, one can 
avoid serious
mistakes.

Steve

---

From: Brian Rosen <[email-masked]>
Date: Wed, 17 Jul 2013 16:53:13 -0400

We haven't agreed on a model for credentials yet, but some statistics:

There are several billion telephone numbers.  I think most experts believe there are more assigned numbers than people.  
There are 300-odd country codes
There are a few tens of thousands of service providers.  If enterprises get some form of credential, there are potentially high tens of millions

In the US, there are 500 million or so records in the portability database.  15 minute ports for wireless numbers is the norm, and that includes distribution of the update to the high hundreds or low thousands of copies of the database.  It handles up to about a million transactions a day, not all of which are ports.  Numbers that are assigned but not in the portability database are in ranges assigned to carriers.

Brian

On Jul 17, 2013, at 4:28 PM, Stephen Kent <[email-masked]> wrote:

> In the RPKI context the plan is for every AS operator to acquire and cache all certs
> CRLs, ROAs, etc. for every other other operator, and to check for changes a few times per day.
> There are about 35K network operators, world wide. Analysis of the time it takes to do this,
> using servers in the Amazon cloud (in Tokyo and the US) to represent servers and clients,
> shows that this is really not a big deal in terms of bandwidth, time, storage, etc. So, it would be useful to have some number to play with to get a sense of how much bigger this system might be.
> It's not one CA, but maybe one per country, or two tiers of CA per country, as per
> As I mentioned in a previous message, when designing a PKI it's important to have a
> model of the expected revocation rate when deciding on cert lifetimes. If one has
> good data on churn for a system prior to engineering a PKI, one can avoid serious
> mistakes.
> 
> Steve

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 17 Jul 2013 21:53:47 +0100

Hi Steve,

> good data on churn for a system prior to engineering a PKI, one can

That's certainly correct. And I do hope that some WG participants
(assuming this BoF succeeds as I hope it will) do that modelling.

One maybe-relevant quibble though: I don't think the goal here
is to engineer an X.509 based PKI - that might be the best answer,
(and is certainly a possible answer) but then again it might not,
esp if something far more easily deployable that can meet the main
requirements suffices. I don't know if there's a real possibility
for the latter case (still have to read Hadriel's draft), but I
very much do think the putative WG needs to spend time early on
examining that question with as much interest as is applied to
checking out what kind of PKI might work best.

Put another way, I'm fairly sure that a PKI can be designed to meet
the requirements here but I'm not at all sure that that PKI would
be sufficiently easy to develop and deploy for STIR to succeed.

My guess is that a DKIM-like thing (which I guess is what Hadriel
is proposing) seems like the main non-PKI based approach worth
investigating as an alternative. As of now, I'm not at all sure
which approach might turn out better.

Sorry if that's all obvious,
S.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 17 Jul 2013 17:12:29 -0400

Brian,

Thanks for the stats. They help frame some of the discussion of scaling.
Are the U.S. numbers re wireless portability representative of what
one sees on other countries where portability has been available for
a few years?

In addition to size, there is the rate of churn issue, e.g., what percentage
of numbers are "ported" every day, how long does a ported number stay with a
new carrier, on average, etc. Also how many countries allow number 
portability
today?

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 17 Jul 2013 17:17:45 -0400

Stephen,

Since you were a major contributor to and proponent of DKIM and since
I chaired PKIX for >16 years folks should expect each of us to favor 
technologies
with which we have extensive experience.

Since others on the list talked explicitly in terms of certs, I think it 
fair
that we discuss that technology along with other options, right?

Steve

---

From: Brian Rosen <[email-masked]>
Date: Wed, 17 Jul 2013 17:24:16 -0400

You can get a number ported in New Zealand in seconds I am told. http://en.wikipedia.org/wiki/Mobile_number_portability has some more data.
It's pretty typical for ports to take days, not minutes in most places, but that is changing.

I don't know what the churn stats are, but I could look them up if it's important.  Seems like the million transactions a day on 500 million records is an upper bound.

Dozens of countries have portability running, I don't think it's a hundred yet.  See above reference.  That is also changing fairly fast.  

Brian

On Jul 17, 2013, at 5:12 PM, Stephen Kent <[email-masked]> wrote:

> new carrier, on average, etc. Also how many countries allow number portability
> today?
> 
> Steve
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 17 Jul 2013 17:27:14 -0400

> which approach might turn out better.

Yup, basically CIDER uses a DKIM-style model - for email-style names, E.164 numbers, and nationally-specific short codes.

-hadriel

---

From: Dave Crocker <[email-masked]>
Date: Wed, 17 Jul 2013 14:31:02 -0700

> that we discuss that technology along with other options, right?

One should even look forward to a merit-oriented debate about the choices.

Something that might help would be a *non-technical* description of the 
trust model and functional services that are needed, independent of how 
they are instantiated. No reference to technology beyond, perhaps, 
saying "storage" or "transfer".

This thread has already touched on a number of these sorts of statements 
(requirements, ideas, whatever).

What I'm suggesting is formulating a complete set into a document -- for 
now I don't care whether it gets published -- so that everyone can point 
at it and agree that that is what must be done, whether by a classic 
credential mechanism, DNS-based KDS, word-of-mouth rumor mill, or the like.

d/

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 17 Jul 2013 22:59:03 +0100

> with which we have extensive experience.

Well, I've actually more real experience with X.509 stuff, but sure.
(And it is absolutely fair to say that I'm a fan of more easily
deployable things these days, much more than I used be anyway, and
that's partly down to chairing DKIM.)

> that we discuss that technology along with other options, right?

Oh absolutely. Like I said, certs can certainly do the functional
and security job here. IMO, the doubt only relates to whether that
ends up more complex than will be deployed. So I'd love to see
some early work on both approaches and then for the the WG to pick
one. (Assuming both survive and one doesn't wither on the vine.)

S.

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 17 Jul 2013 18:09:26 -0400

Brian,
thanks for the numbers.

One question regarding the 300-odd country-codes: how many distinct numbering plan administrations are there?  It's not 300 is it?  I mean there are ~200 countries in the world, and 24 countries/territories fall under the +1 country-code.[1]  I realize there are a dozen or so non-country-things with country-codes, and another ~30 or so organizations in the 882 and 883 country-code, but I'm kinda ignoring them.

I'm just trying to figure out how many national voice-service numbering plan admins there are, which I thought was ~200.  No?

-hadriel
[1] Though of course +1 is split up into separate number admins, but not 24 of them afaik.

---

From: Brian Rosen <[email-masked]>
Date: Wed, 17 Jul 2013 18:19:15 -0400

http://www.wtng.info/wtng-cod.html

I didn't add up how many there were.  I was told 320 or something like it, but that looks wrong.

Don't think the difference between 200 and 300 is significant.

Brian

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 17 Jul 2013 18:25:40 -0400

> I didn't add up how many there were.  I was told 320 or something like it, but that looks wrong.

Ah ok - yeah I think it's ~210.

> Don't think the difference between 200 and 300 is significant.

Nope, me neither - I was just surprised it was so much more than I remembered.
:)

-hadriel

---

From: Stephen Kent <[email-masked]>
Date: Thu, 18 Jul 2013 10:16:52 -0400

Stephen,
> that's partly down to chairing DKIM.)
I didn't say "more easily deployable" :-) .

Steve

---

From: Dave Crocker <[email-masked]>
Date: Thu, 18 Jul 2013 07:20:59 -0700

On 7/17/2013 2:17 PM, Stephen Kent wrote:
> technologies with which we have extensive experience.

Stephen's dramatically shorter tenure with the DKIM wg might have been 
because it only needed a few years to get specified and then deployed 
widely in the global email infrastructure, unlike PKI-based mechanisms, 
which continue to have challenging administration and very constrained 
global use...

d/

---

From: Stephen Kent <[email-masked]>
Date: Thu, 18 Jul 2013 11:28:22 -0400

Dave,

> widely in the global email infrastructure, unlike PKI-based 
> mechanisms, which continue to have challenging administration and very 
> constrained global use...
>
> d/
since DKIM's goals were much more modest with regard to email security 
vs. S/MIME's use
of PKI, this is a largely irrelevant comparison. But if you really want 
to start a food
fight about security technologies I'm ready.

Steve

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 18 Jul 2013 16:33:49 +0100

On 07/18/2013 04:28 PM, Stephen Kent wrote:
> start a food
> fight about security technologies

I suggest we don't.

S.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 18 Jul 2013 12:44:41 -0700

...

Steve,

Thanks for up-leveling to a point of significant substance, namely the 
importance of the functional goal in choosing among alternative designs.

In the current context, it exactly targets the core question of the 
functional goal for Caller-ID validation, with eye towards carefully 
considering the pragmatics of a very constrained mechanism for this very 
constrained goal.

At a significantly more 'meta' level -- which will probably cause 
Stephen F to roll his eyes now as he always did when I attempted this 
during the DKIM effort -- it suggests the benefit of formulating and 
attacking narrower goals with narrower solutions and the detriment of 
trying, instead, to create broader and more general solutions.

Divide and conquer on complex problems is good for humans, as well as 
computers...

d/

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 18 Jul 2013 22:49:20 +0000

As long as you allow multiple public-private key pairs for one number (which we need for the legitimate spoofing cases anyway), porting isn't a big deal. The likelihood that the entity that got their number ported away will suddenly start spoofing that number seems pretty remote, particularly since it would be trivial to detect who did it. Thus, rapid key expiration does not appear to be a major issue - nice to have, but we don't have to expire every record every 10 minutes. The model we'd want is probably something a bit different than typical: namely, if the cached cert/public key works, done. If there's a mismatch, a new holder may have been added and a query is needed. This would only affect a very small fraction of calls for reasonable expiration times (days to a week).

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 18 Jul 2013 19:02:14 -0400

Yup, agreed - I was just responding to Brian's concern that using a DNS-based approach would require low TTL values, in order to support porting.  It doesn't require that.

With regards to using certs: I don't think porting a number would require a cert revocation, but the verifying systems would have to check revocations, because private keys will get compromised ultimately.

-hadriel

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 19 Jul 2013 15:57:56 +0000

Since both revocations and ports are relatively rare and the number of validators is relatively small (thousands, not millions), I suspect that a pub-sub approach may well be better suited than querying the origin server or DNS authoritative server for each validation.

________________________________________
From: Hadriel Kaplan [[email-masked]]
Sent: Thursday, July 18, 2013 7:02 PM
To: Henning Schulzrinne
Cc: [email-masked] List
Subject: Re: [stir] CA Certs (was: Re:  Rollout timeframe)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 19 Jul 2013 13:29:03 -0400

> Since both revocations and ports are relatively rare and the number of validators is relatively small (thousands, not millions), I suspect that a pub-sub approach may well be better suited than que…

<Sigh>  You don't have to query the DNS authoritative server for each validation.  One of the benefits of DNS is it cleans itself up, and the threat model for bogus DNS injections for a STIR use-case is really really small.  More importantly, using CIDER with DNSSEC there would be far fewer root-signing private-key holders to be compromised, and if they get compromised they don't need to issue new E.164 certs to everyone they had previously signed certs for, and they can actually set their signature validity times really short because of that (i.e., they can re-sign frequently).  That means there's no actual need for certificate revocation, no need for CRLs/OCSP, and the thing actually *scales*.

I appreciate that it's useful if we focus on how to solve the problem for just one or a couple countries, but deploying whatever STIR ends up being is going to be a massive undertaking.  It may not be much work for us in the IETF to define in specs, and for 3GPP and others to adopt in specs... but the work required to evangelize/educate, implement, test, deploy, troubleshoot, and manage from an ops perspective is going to be A BIG DEAL.

So whatever the STIR thing is, it must be able to scale and be truly usable on a world-wide international basis.  Because other countries will eventually adopt it and we will want to validate incoming international calls.  International calls already pose problems today, and for all the work and time STIR will take it would be insane not to provide a tool which can work internationally.

So I think we really do have to consider things from that perspective, to make sure whatever we do would be usable as well internationally in the future.

I agree that porting isn't a reason to revoke certs.  But private key compromise would be.  Private keys are compromised in the real world, and it's not hard to imagine some carrier somewhere having its E164 cert keys be compromised by a rogue employee or remote hacker or whatever.  In the worst-case, the largest mobile service provider in the world has ~700 Million phone subscribers, and it's growing.  Hopefully they wouldn't store all their private keys/certs in any one server anywhere, but it's not hard to imagine that we could still be talking about tens of millions of certs needing to be revoked at some point in the future.

If STIR uses certs for E.164 numbers, we will have to actually implement revocation, even just in the US.  I simply don't believe we could get away with not revoking them, if a carrier's keys were compromised and published on the web, and they included E.164 numbers for Citibank, Fidelity, American Airlines, etc.  It doesn't matter if it causes real fraud or not - the perception/marketing problem alone would be too damning.

Regardless of the solution we end up with, we have to have some reasonably believable story for how private keys could be changed and revoked in a reasonable timeframe, for the various key holders, on a world-wide basis.

-hadriel

---

From: Michael Hammer <[email-masked]>
Date: Fri, 19 Jul 2013 17:48:18 +0000

Both solutions have the characteristics that you outline.

If the carrier credentials get compromised, then likely all the public keys
in the DNS associated with that carrier are also compromised and hence must
be updated, since you don't know what might have been "planted" or not.
That could also mean getting new public/private key pairs for every customer
that had a public key in the DNS for that carrier.

The same liability issues exist.

To do this analysis you need to ask how often would the carrier credentials
be compromised?  Any data to quantify that?

You also make assumptions that the carrier has only one set of credentials.

If the carrier uses multiple, then divide by that number to get a newer
exposure number.
Also, those credentials can be rotated and aged out by time.
Thus, a compromise would mean restoring the associated DNS entries, or
credentials affected by that time frame.

Weak strawmen don't help the comparison and discussion.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hadriel Kaplan
Sent: Friday, July 19, 2013 1:29 PM
To: Henning Schulzrinne
Cc: [email-masked] List
Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe)

On Jul 19, 2013, at 11:57 AM, Henning Schulzrinne
<[email-masked]> wrote:

> Since both revocations and ports are relatively rare and the number of
validators is relatively small (thousands, not millions), I suspect that a
pub-sub approach may well be better suited than querying the origin server
or DNS authoritative server for each validation.

<Sigh>  You don't have to query the DNS authoritative server for each
validation.  One of the benefits of DNS is it cleans itself up, and the
threat model for bogus DNS injections for a STIR use-case is really really
small.  More importantly, using CIDER with DNSSEC there would be far fewer
root-signing private-key holders to be compromised, and if they get
compromised they don't need to issue new E.164 certs to everyone they had
previously signed certs for, and they can actually set their signature
validity times really short because of that (i.e., they can re-sign
frequently).  That means there's no actual need for certificate revocation,
no need for CRLs/OCSP, and the thing actually *scales*.

I appreciate that it's useful if we focus on how to solve the problem for
just one or a couple countries, but deploying whatever STIR ends up being is
going to be a massive undertaking.  It may not be much work for us in the
IETF to define in specs, and for 3GPP and others to adopt in specs... but
the work required to evangelize/educate, implement, test, deploy,
troubleshoot, and manage from an ops perspective is going to be A BIG DEAL.

So whatever the STIR thing is, it must be able to scale and be truly usable
on a world-wide international basis.  Because other countries will
eventually adopt it and we will want to validate incoming international
calls.  International calls already pose problems today, and for all the
work and time STIR will take it would be insane not to provide a tool which
can work internationally.

So I think we really do have to consider things from that perspective, to
make sure whatever we do would be usable as well internationally in the
future.

I agree that porting isn't a reason to revoke certs.  But private key
compromise would be.  Private keys are compromised in the real world, and
it's not hard to imagine some carrier somewhere having its E164 cert keys be
compromised by a rogue employee or remote hacker or whatever.  In the
worst-case, the largest mobile service provider in the world has ~700
Million phone subscribers, and it's growing.  Hopefully they wouldn't store
all their private keys/certs in any one server anywhere, but it's not hard
to imagine that we could still be talking about tens of millions of certs
needing to be revoked at some point in the future.

If STIR uses certs for E.164 numbers, we will have to actually implement
revocation, even just in the US.  I simply don't believe we could get away
with not revoking them, if a carrier's keys were compromised and published
on the web, and they included E.164 numbers for Citibank, Fidelity, American
Airlines, etc.  It doesn't matter if it causes real fraud or not - the
perception/marketing problem alone would be too damning.

Regardless of the solution we end up with, we have to have some reasonably
believable story for how private keys could be changed and revoked in a
reasonable timeframe, for the various key holders, on a world-wide basis.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 19 Jul 2013 14:47:16 -0400

> Both solutions have the characteristics that you outline.

Nope.  I really think you need to read the CIDER draft, and read how DNSSEC works, and think about it from the perspective of STIR usage.  Or better-yet wait until we get some face-time and powerpoint time to let me explain the CIDER concept.  I know email is a lousy way to communicate some of these things.
:(

> be updated, since you don't know what might have been "planted" or not.

Of course.  The private/public key pairs for the E.164 entries need to be changed, if they're compromised.  That's true regardless of whether they're entries in a DNS or certs.

So imagine that happening.  With CIDER, the carrier communicates with the Registry to change its pub-keys.  That could happen through a protocol (the CIDER draft proposes requirements for such a protocol), or via email or whatever.  That part has to happen regardless of DNS entries or certs.  With CIDER, however, there's no need to respond with new certs, and more importantly the old entries don't need to be revoked.  The old ones will time out, very quickly.  It's impractical to have short expiry for certs.

Or by "credentials get compromised" do you mean the credentials used by the carrier to access its entries in the Registry?  That's still the same problem for both, with a similar result.

> that had a public key in the DNS for that carrier.

Yes, that could happen for any/either solution.  Again, in one solution it requires revocation - in the other it doesn't.  The "revocation" is implicit.

> be compromised?  Any data to quantify that?

I don't understand why that matters.  If we're using certs and it happens once, to a large carrier, hilarity ensues.

> You also make assumptions that the carrier has only one set of credentials.

Which "credentials" are you referring to?  (sorry, we keep using that word for different things in this mailing list, so I'm not sure which ones you mean)

> Weak strawmen don't help the comparison and discussion.

On the contrary - the CIDER proposal is written down in a draft, for all to see and read and argue over... and its essentially based on a DKIM model.  I have yet to see a draft that actually describes how a certificate-based model would actually work, be deployed, scale, and handle things for E.164.  Instead, there appear to be at least two different proposals for how certificates could be used, across various emails, with no concrete proposal to compare CIDER against.  Which one of these is the "strawman" exactly?

It's very easy to argue against a concrete proposal, when any counter-proposal is undefined. 

-hadriel

---

From: Michael Hammer <[email-masked]>
Date: Fri, 19 Jul 2013 21:33:17 +0000

Inline...

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Friday, July 19, 2013 2:47 PM
To: Michael Hammer
Cc: [email-masked] List
Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe)

> Both solutions have the characteristics that you outline.

Nope.  I really think you need to read the CIDER draft, and read how DNSSEC
works, and think about it from the perspective of STIR usage.  Or better-yet
wait until we get some face-time and powerpoint time to let me explain the
CIDER concept.  I know email is a lousy way to communicate some of these
things.
:(

>> I read your CIDER draft, but am trying to draw out the salient points on
where the chain of trust lies and what is really different.  Maybe I am
missing some key point about what is securing the DNS entry and what is in
that entry that needs to be secured and how that relates to the key used to
sign the SIP header element.

> If the carrier credentials get compromised, then likely all the public 
> keys in the DNS associated with that carrier are also compromised and 
> hence must be updated, since you don't know what might have been "planted"
or not.

Of course.  The private/public key pairs for the E.164 entries need to be
changed, if they're compromised.  That's true regardless of whether they're
entries in a DNS or certs.

So imagine that happening.  With CIDER, the carrier communicates with the
Registry to change its pub-keys.  That could happen through a protocol (the
CIDER draft proposes requirements for such a protocol), or via email or
whatever.  That part has to happen regardless of DNS entries or certs.  With
CIDER, however, there's no need to respond with new certs, and more
importantly the old entries don't need to be revoked.  The old ones will
time out, very quickly.  It's impractical to have short expiry for certs.

>> Maybe you could elaborate more here.  The carrier has a public keys used
to sign submissions of public key values associated with private keys used
by the number holder to sign the number field in the SIP invite.  If that
carrier private key was compromised, then all the related DNS entries are
also thrown into question.  So, just updating the carrier public key in the
DNS doesn't fix the question of validity of the number-holder data in DNS
which could be bogus.  So, how do you say that the old entries don't need to
be revoked.

>> OK, so if they time out you have to generate new public-private key pairs
for each number holder, and update both the DNS and the end-user with those
values, no?

Or by "credentials get compromised" do you mean the credentials used by the
carrier to access its entries in the Registry?  That's still the same
problem for both, with a similar result.
>> Yes.

> That could also mean getting new public/private key pairs for every 
> customer that had a public key in the DNS for that carrier.

Yes, that could happen for any/either solution.  Again, in one solution it
requires revocation - in the other it doesn't.  The "revocation" is
implicit.
>> Revocation is revocation.  The question is whether there is any
difference in how long it takes to get number-holder and the validation
point updated.  In one case, the new key binding is wrapped in a cert and
signed and the CRL list updated.  In the other, the key binding is wrapped
in a secure DNS setting.  Caches of DNS entries or cert DB can then be
updated in timely fashion as you mention.

> To do this analysis you need to ask how often would the carrier 
> credentials be compromised?  Any data to quantify that?

I don't understand why that matters.  If we're using certs and it happens
once, to a large carrier, hilarity ensues.
>> Likewise, once the key securing DNS is compromised, ditto.  Note that
"large" is related to the number of entries signed, so with smart planning,
all "carriers" are small.

> You also make assumptions that the carrier has only one set of
credentials.
Which "credentials" are you referring to?  (sorry, we keep using that word
for different things in this mailing list, so I'm not sure which ones you
mean)
>> I was trying to follow your argument about the scope of someone's
credentials being compromised.  You tell me.

> Weak strawmen don't help the comparison and discussion.

On the contrary - the CIDER proposal is written down in a draft, for all to
see and read and argue over... and its essentially based on a DKIM model.  I
have yet to see a draft that actually describes how a certificate-based
model would actually work, be deployed, scale, and handle things for E.164.
Instead, there appear to be at least two different proposals for how
certificates could be used, across various emails, with no concrete proposal
to compare CIDER against.  Which one of these is the "strawman" exactly?

It's very easy to argue against a concrete proposal, when any
counter-proposal is undefined. 

>> You missed the point about what is a strawman.  My point was that you
were making assertions about how the cert model would work, then attacking
your portrayal of that model.  I wasn't referring to your CIDER approach as
a strawman.

>> As for having a draft of not, it is obvious that you had been working on
this prior to the STIR mail list being formed.  So, dumping a fait accompli
on the group and suggesting that being first to get a draft out is reason
not to consider other possibilities prior to the WG even being formed just
doesn't seem very sporting of you.  I had hoped that responding to your
questions across the various emails had helped clarify some ideas versus
confuse you.  I guess "concrete" is in the eye of the beholder.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 19 Jul 2013 18:15:44 -0400

I'll respond to the other points separately tonight when I have more time, but this one is different so I'll just respond quick..

On Jul 19, 2013, at 5:33 PM, Michael Hammer <[email-masked]> wrote:

> this prior to the STIR mail list being formed.  

Actually, I wasn't working on it at all before STIR was formed, nor even when STIR was formed.  Some of us had discussed at a very high level, several years ago, about using DNS/ENUM for caller-id verification.  This was back when we were debating rfc4474's uselessness and trying to fix it.  But it never got into the details or more than just a few sentences in email on one of the SIP-related mailing lists, at least as far as I can recall or was involved in.

Even at the STIR kickoff meeting in Wash DC a couple months ago, we had jokingly mentioned it in the meeting, but I had mentally dismissed it as untenable due to privacy concerns.  It was only about a month ago during the discussions on this list that I realized (or someone else pointed out) that (1) the contents of the DNS entries don't need to reveal anything private other than a public key value, and (2) that since we do use ENUM today in a private-access manner, we could still do that if it turned out we wanted to keep the databases private in the end.

So I wrote up the draft in spurts over the past couple weeks, and only really got it done the day before submission was due. 
:)

> So, dumping a fait accompli
> doesn't seem very sporting of you.  

If anything, it is the opposite situation: the running assumption when the STIR list was created was we'd be using X.509 certs and HTTP, with some tweak of RFC 4474.  There are also several people on the list who have allergic reactions to the word "DNS".

Trust me, what I'm proposing is NOT a fait accompli, and I'm not claiming it should be.  I'm not at all claiming because I got a draft submitted that somehow its superior.  I'm just saying we can't really argue much in detail until we see what the alternatives are.  We will really need to spend a long time in meetings going over any proposed solutions, and chew on them for a while.

> I had hoped that responding to your

I appreciate the emails - I'm just having a hard time understanding and keeping track of the various proposals - there's not just one cert-based or even HTTP-based proposal.  So without having something written down, it's hard to know what the alternatives are.
:)

-hadriel

---

From: Dave Crocker <[email-masked]>
Date: Fri, 19 Jul 2013 16:19:11 -0700

On 7/19/2013 8:57 AM, Henning Schulzrinne wrote:
> Since both revocations and ports are relatively rare and the number of validators is relatively small (thousands, not millions),

Henning,

I thought that the operational goal was to permit validation by 
enterprises and even end-user-systems, and, I guess, even permit 
/signing/ by such systems.

That's not a small total number and the combinatorials -- every pair 
that might do a SIP call is not a small working set.

d/

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sat, 20 Jul 2013 00:12:21 +0000

> I'd actually probably set it at a minute or two.

Originally I was thinking this way but I slowly came to think this may not be the case depending on you attack model. 

Lets say my number was with Verizon then I move it to Sprint. Sure the ports needs to happen fast but how fast does Verizon need to loose the ability to impersonate me? That might not have to happen as fast - for example, if Verizon could continue signing records on my behalf for another 30 days after the port, would that really matter? Sure people have to recognize the new signatures from Sprint very quickly ( like minutes ), but I'm not sure the old entities need to loose my trust right away. 

This is more a question about the attack model and what the requirement is for how quickly someone that used to be able to assert my identity looses that ability. Perhaps the time is the same as the port time but it seem worth thinking about what a model would look like where that time was much higher.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sat, 20 Jul 2013 00:12:23 +0000

On Jul 16, 2013, at 6:18 AM, Hadriel Kaplan <[email-masked]> wrote:

> I would like to talk to them. 

>From a Cisco point of view, I'm glad to arrange a call with anyone that the STIR group might want to talk to at Cisco to collect information about PBXs. (We are #1 market share in this space and I imagine the other large vendors might answer any questions folks have too). I imagine that most people at Cisco will point out that ultimately, I will end up being the main person that needs to decide what Cisco will do here but if anyone would prefer an email from the CTO or something, glad to arrange that too. 

The Cisco Unified Communication Groups is very clear that we would like to see the industry solve the robo calling problem if at all possible. We are concerned that the problem will get worse if we don't do something.

Note my emails to this list normally represent my opinion but since there was a request around the PBX vendors, I thought I would make this offer from Cisco.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sat, 20 Jul 2013 00:12:24 +0000

The number one problem with VIPR is a privacy issue where one person can learn about if Alice is calling Bob.   I want to make sure we are thinking about the privacy issues form the start. 

So consider the text from the charter of 

On Jul 16, 2013, at 1:33 PM, Russ Housley <[email-masked]> wrote:

>  This working group will define a deployable

I think we need to add a bit more to the text above. I would suggest something along the lines of saying who can do this verification.  I think it needs to be some network device or endpoint authorized by the called party. Perhaps there is some other way to phrase the privacy issues. 

To provide a very specific use case, I don't want EKR or some random transit provider to be be able to figure out if I am calling EKR's wife or not. If we fail to have this property, I don't believe this work will be deployed - particularly in the EU.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sat, 20 Jul 2013 00:12:24 +0000

I'm listening to the arguments for in band or out of band but right now I am pretty skeptical that doing in-band before out-of-band is the right order. I suspect we need them both. Let me say a bit more 

Mobile phones could have done wideband audio long ago, but they did not. There was no incentive for them to do it since there was no alternative that could do do wideband and had the same mobility properties. Then along came smart phones and started providing much better audio quality using things like Skype. Suddenly there was an incentive to do wideband audio on mobile phones and you are starting to see that deploy. 

So lets talk about carrier to carrier SIP interconnects. Unless there is an real incentive, I sort of doubt that they will initially do a lot more than the SS7 interconnects they replace. No incentive and complicated to change the business agreements in place. Particularly for interconnects between say Nigeria and US. 

However, there is a great incentive for smartphones to implement an out of band solutions even it only works to other smartphones. Once that existed, there would be an incentive for non smart phones to get an equivalent level of service and that would most likely be done with a in band solution but at that point there is an incentive to deploy in band. 

A solution that only worked for smart phones is clearly not as useful as one that works for all phones, but doing both at the same time seems the most likely way to me to get either of them to deploy. 

Sure it would be better for the non over the top service providers if there was only a solution that worked for the carrier a telephone numbers was delegated down to form a nation level, but as apple showed with iMessage, it can be better for the users to have two ways to send a SMS messages to another user. One way that goes thought the provider that the phone number was delegated to, and one way that goes around the the carrier the phone number was delegated to. 

So, I'd like to see the charter changed to work on both in-band and out-of-band at the same time. 

On Jul 16, 2013, at 1:33 PM, Russ Housley <[email-masked]> wrote:

> <charter-stir-00-00bc.wdiff.html>

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Sat, 20 Jul 2013 00:51:36 +0000

What? Out of band before In band.  What air are you breathing..... sorry fluf... you are off base on this... let's think economic deployable...

To date I have been nice but you bring out the best, this has been a USA synergic discussion, no consideration to international, so IETF is going yield to the ITU.....a(xx)

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 19 Jul 2013 22:46:23 -0400

> The number one problem with VIPR is a privacy issue where one person can learn about if Alice is calling Bob.   I want to make sure we are thinking about the privacy issues form the start. 

Wow.  If you think that was what doomed VIPR then we are in very different worlds.  Or do you just mean that was the concern you guys focused on solving for it?  Obviously we do have to seriously consider privacy for STIR, but we don't have to go beyond what privacy you have now.  We're not here to solve other problems, and trying to solve other problems is what gets us in trouble with getting things defined in such a way that people can and want to use it (e.g., rfc4474).  We can't introduce new problems, but the problem we're trying to solve is source number validation.

> To provide a very specific use case, I don't want EKR or some random transit provider to be be able to figure out if I am calling EKR's wife or not. If we fail to have this property, I don't believ…

Umm... they can figure that out *today*.  That's not a problem we've been tasked to solve, nor is it one we should try to solve.  Not only is that data clearly available to them, there's an entire industry around storing and analyzing that data, usually for things related to billing.  It's called "Call Detail Records".  Perhaps you've heard of it?  ;)

Or do you mean you don't want providers that are themselves not in the call signaling path to figure it out?  I'm cool with that.  I think that would certainly be something for the out-of-band to worry about, but I don't see how the in-band would have such a problem.

-hadriel

---

From: Michael Hammer <[email-masked]>
Date: Sat, 20 Jul 2013 04:16:25 +0000

Fair enough.  I need to stop writing emails and write a draft.  :)

Have a good weekend.

Mike

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Friday, July 19, 2013 6:16 PM
To: Michael Hammer
Cc: [email-masked]
Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe)

I'll respond to the other points separately tonight when I have more time,
but this one is different so I'll just respond quick..

> this prior to the STIR mail list being formed.  

Actually, I wasn't working on it at all before STIR was formed, nor even
when STIR was formed.  Some of us had discussed at a very high level,
several years ago, about using DNS/ENUM for caller-id verification.  This
was back when we were debating rfc4474's uselessness and trying to fix it.
But it never got into the details or more than just a few sentences in email
on one of the SIP-related mailing lists, at least as far as I can recall or
was involved in.

Even at the STIR kickoff meeting in Wash DC a couple months ago, we had
jokingly mentioned it in the meeting, but I had mentally dismissed it as
untenable due to privacy concerns.  It was only about a month ago during the
discussions on this list that I realized (or someone else pointed out) that
(1) the contents of the DNS entries don't need to reveal anything private
other than a public key value, and (2) that since we do use ENUM today in a
private-access manner, we could still do that if it turned out we wanted to
keep the databases private in the end.

So I wrote up the draft in spurts over the past couple weeks, and only
really got it done the day before submission was due. 
:)

> on the group and suggesting that being first to get a draft out is 
> reason not to consider other possibilities prior to the WG even being 
> formed just doesn't seem very sporting of you.

If anything, it is the opposite situation: the running assumption when the
STIR list was created was we'd be using X.509 certs and HTTP, with some
tweak of RFC 4474.  There are also several people on the list who have
allergic reactions to the word "DNS".

Trust me, what I'm proposing is NOT a fait accompli, and I'm not claiming it
should be.  I'm not at all claiming because I got a draft submitted that
somehow its superior.  I'm just saying we can't really argue much in detail
until we see what the alternatives are.  We will really need to spend a long
time in meetings going over any proposed solutions, and chew on them for a
while.

> questions across the various emails had helped clarify some ideas 
> versus confuse you.  I guess "concrete" is in the eye of the beholder.

I appreciate the emails - I'm just having a hard time understanding and
keeping track of the various proposals - there's not just one cert-based or
even HTTP-based proposal.  So without having something written down, it's
hard to know what the alternatives are.
:)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 20 Jul 2013 00:54:57 -0400

> sign the SIP header element.

Right, so the basic gist is the private key used to sign SIP request caller-ids with, has its public key counterpart in a DNS TXT RR.  It may be The Public DNS, or it may be a controlled-access private or federated one.  Regardless, the public key remains in a DNS, and it's retrieved by the verifier using the DNS protocol.  Let's call that public key the "CID Key", for Caller-ID key.  Let's call the entity who uploaded the CID Key into DNS the "Assignee".

The DNS TTL for the entry is likely quite short... say 30 minutes or even less.  Thus DNS caches will time it out in 30 minutes.  There's not much point in caching them longer, because it's rare for source call numbers to be used frequently enough to make it worth caching for longer.  Even for those that are "worth it", a DNS query every 30 minutes for the frequent ones isn't a big deal.  It might be a lot shorter TTL even, but that's all up to the admin to decide anyway.  That TTL actually has nothing to do with how long a DNSSEC signature is valid for, but it's useful to keep the TTL short purely to force DNS caches to flush and check DNS again.

From a DNSSEC perspective, what's securing the DNS entry is a signature, using a private key of the admin, with the public key also being available in DNS.  There's actually a chained signing model for DNS subdomain hierarchies, but in our case you can skip it so long as the public key value matches the country-code's, so I'll ignore it for now.  Fundamentally, it's essentially the same concept as what you described: having all certs signed by the country-code admin.  In this case, all the TXT RRs are signed by the country-code admin.  Let's call the DNS admin's public key the "DNS Key", and call the signature of the TXT RR (containing the CID Key) a "RR Signature".  The RR Signature is sent back in a resource record along with the TXT RR, in the same DNS answer packet, when you query DNS for the TXT RR.

So it's similar to a cert when DNS is queried/answered, but there's no point in giving a "cert" back to the Assignee, because it serves no purpose.  No one gets a "cert" from the Assignee - they get it from DNS.  Because they can get it from DNS, the DNS admin can actually set the RR Signature expiry time to be relatively short.  Let's say one week.  They can do that because they can re-sign the TXT RR (generate a new RR Signature) without communicating that change to the Assignee at all.  The Assignee never has to upload a fresh CID key again, until their key is compromised or their E.164 number ports out.  Meanwhile the DNS admin can re-sign again and again.  Even if the DNS admin's DNS Key is compromised, they can change it and re-sign without having to have the Assignees do anything.

If the Assignee's CID key is compromised, the Assignee uploads a new CID Key to the DNS admin, replacing the old one.  TTL expiry cleans out the old caches, triggering a fresh query to the DNS.  Thus we don't need revocations.  For those concerned with DNS injection attacks using a compromised key, or broken caches holding on to old DNS answers using a compromised DNS Key, the RR Signature itself only lasts a week.

I should mention that the CIDER draft currently expects the STIR verifier systems to be client stub resolvers.  In other words, the SIP system performing STIR verification wouldn't actually do the DNS tree walking or DNSSEC validation; their local DNS servers would do it on their behalf.  From a security perspective it means the verifier needs to trust its local DNS resolvers, but for the STIR use-case that seems reasonable.  The benefit being that you can basically off-load the work, use a private or federated DNS model, and so that a carrier can use specialized systems or rules to do that stuff if they want to. (such systems already exist for private ENUM use today, for similar call-signaling purposes, though they don't use DNSSEC)

I also expect there to be local actual copies of the entire DNS tree for a country-code; for example large US carriers would likely have a local copy for all US numbers; Canadian carriers for Canada numbers; etc.  Their local copy is not authoritative, but it's a slave synchronizing stuff from the master run by the country-code admin or a commonly-agreed-upon admin.  That's what happens today in NPAC, for example.  Smaller carriers, or non-regulated providers, or Enterprises, or whatever - they can just access the master using DNS, or through their upstream carrier, or a third party middleman.  The reason I mention this is that these local copies don't need to deal with DNSSEC at all - they have a synchronized copy of the master over some secure channel, so the DNSSEC stuff isn't necessary for their local copy.

The reason that the last part is different for certs, is that so far the proposals for using certs has been based on rfc4474: that the caller identifies the HTTP URL to go get the cert from, by putting the URL in the SIP message in the Identity-Info header field.  That means if an E.164 cert private key is compromised, it's trivial to abuse it - just generate a SIP INVITE with your own HTTP URL to your site holding the original cert, and use the compromised private kay to sign the INVITE.  That's why we'd need cert revocations.  We couldn't even have short expiries for the certs, of anything like a week long for example, because it would require getting a new cert up to the country-code admin to be re-signed every week.  But with DNS, it's not trivial to use a compromised CID Key: the DNS entry would be changed, and quickly take effect.  So we wouldn't need actual revocations.

-hadriel
p.s. I didn't mean to spend so much time or focus on the cert revocation aspect for using CIDER - avoiding revocations isn't really the major benefit of using CIDER.  There are many more benefits to using CIDER.  Right now I'm just trying to figure out what the drawbacks/downsides to it are, and where/if it would break or be less practical than alternatives. (for me, the STIR thing is more about practicality for the target use-cases than anything else)

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 20 Jul 2013 01:04:00 -0400

Nope, I don't think porting numbers requires a cert revocation or anything logically equivalent.  As long as it ages out within a few months, I think it would be fine. (though as an aside, I still think CIDER DNS TTLs should be short, but not for this reason)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 20 Jul 2013 02:34:58 -0400

> Mobile phones could have done wideband audio long ago, but they did not. There was no incentive for them to do it since there was no alternative that could do do wideband and had the same mobility…

OK, you think Skype is the incentive for providing wideband audio.  Might I suggest that if that were the case, that the reason it was an incentive is because Skype represented a threat to carrier's business models?  How is Apple/Android/whatever providing out-of-band caller-id validation a threat to a carrier's business model?  If anything, it would relieve some pressure on the carriers.

The "threat" right now is an FCC mandate, or even just a general loss of trust in the PSTN system.  The last thing they want is for voice service to become like email, with constant spam and phishing attacks.  Carrier's aren't idiots.  It takes time for things to reach a level that can overcome the inertia, but I think we're reaching that point.

> However, there is a great incentive for smartphones to implement an out of band solutions even it only works to other smartphones. Once that existed, there would be an incentive for non smart phone…

That's an interesting psychological motivator.  I'm sure Nigeria will be strongly motivated to deploy secure caller-id because of a smartphone app proving it can be done.[1]
;)

> A solution that only worked for smart phones is clearly not as useful as one that works for all phones, but doing both at the same time seems the most likely way to me to get either of them to depl…

Actually, I think it would make deploying an in-band one more challenging, for various reasons.  But I have no crystal ball.

> Sure it would be better for the non over the top service providers if there was only a solution that worked for the carrier a telephone numbers was delegated down to form a nation level, but as app…

And next you'll be telling us: "oh, and now that we have this way around them, lets just send SIP over that channel and bypass the carriers".  I understand the personal desire for that.  I believe the solution for it is called VIPR.  But I don't think it's helpful in getting an in-band solution deployed.  We don't need to threaten the carriers.

Furthermore, I think you're dead wrong about the motivated actors here.  The over-the-top service providers are actually the *cause* of the problem, as far as I can tell.  The "traditional" and regulated carriers, MSOs, etc., are the ones who want to stop it.

> So, I'd like to see the charter changed to work on both in-band and out-of-band at the same time. 

Then charter a separate working group for out-of-band, or charter a separate working group for in-band.

At the end of the day, charter items reflect what the working group spends its time doing - the time in physical meetings, conference calls, mailing lists, document reviews, etc.  It also identifies the target audience for participation, scope, and work outcome.

We've been told we need to get a source identity solution quickly.  That means those of us interested in in-band need to focus on in-band, and those of us interested in out-of-band need to focus on out-of-band.  We need real face-time/mic-time in meetings, without being rushed by chairs to move on to next topics/presentations.  We need to cut down on email traffic, so those of us who have other day-jobs can focus on just what we care about.  We need to schedule interims and conference calls, without worrying about accommodating more people's schedules.  In short: we need focus.

I know there's some people overlap, but *every* RAI working group has people overlap.

It's kinda like RTCWEB and CLUE - both have to do with audio and video multi-stream communication scenarios, but for very different deployment models/agents/endpoints.  It's been challenging for when they intersect in SDP usage, but I don't think anyone would combine them into one RTCWEB-CLUE WG and expect to get anything done.

-hadriel
[1] As it happens, I've been told Nigeria may well be motivated to provide secure caller-ids... but it's not due to smartphone apps.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 20 Jul 2013 14:51:16 +0100

> You are correct, and several people agreed with you.  However, none of you offered text.  So, I have made a stab at updating the charter text to address this point.  I'll post it in a minute.

Russ,

to close the loop on this:

1. The latest draft's vocabulary changes about this look good to me. 
Thanks for doing that.

2. I didn't offer wording changes because I felt tenuous enough about 
the issue that I wanted to ask about the issue in the abstract, before 
worrying about the wording.

It's clear to me that there is a legitimate debate one might have 
between the two vocabulary choices of authentication vs. authorization, 
apparently even among folks with long-standing security backgrounds 
(thereby excluding me).  (I was impressed to discover that RFC 4949 does 
list authorization as a vocabulary term!  Does that mean the AAA folks 
have to become only AA?)

> I do not see consensus for this position.  It is agree that an end-to-end SIP session is the first priority.  However, others have said that an out-of-band solution is also needed to address the wh…

The latest language about this in the draft charter, and schedule you 
show in it, is workable I think.

That said, I think Hadriel has reminded us of an important point:  A 
draft charter beings as a blank sheet of paper.  There are no rights 
that accrue to whatever the first draft contained.  Everything in the 
charter needs to represent a reasonable consensus amongst those who will 
do the work (as well as the IESG), even though there's no working group 
to do a formal consensus process.

My own reading of the list, about out-of-band, is that while it might 
not have clear rough consensus to take it out of the charter, I don't 
see anything close to a clear consensus to keep it in, either...

d/

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 20 Jul 2013 21:35:29 +0000

I thought the general consensus was that carriers would do (most) of the validating. If you include the Fortune 500 as other likely validators, that adds roughly 500 to the list. 

If we do get larger numbers, hierarchical subscription would work easily, i.e., the carrier sends an event notification to the business, possibly using the same SIP trunk they already have set up for call signaling.

I don't see the combinatorial - you have one source of revocation notifications (the database operator), and a smallish number of recipients (the validators).

Henning

________________________________________
From: Dave Crocker [[email-masked]]
Sent: Friday, July 19, 2013 7:19 PM
To: Henning Schulzrinne
Cc: [email-masked] List
Subject: Re: [stir] CA Certs

Henning,

d/

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 20 Jul 2013 22:14:34 +0000

If TTLs are short (below a few hours), essentially every query will be answered by the authoritative server in the DNS model, since legitimate calls don't have much locality, from what I can tell.

________________________________________
From: [email-masked] [[email-masked]] on behalf of Hadriel Kaplan [[email-masked]]
Sent: Saturday, July 20, 2013 1:04 AM
To: Cullen Jennings
Cc: [email-masked] Mail List
Subject: Re: [stir] CA Certs (was: Re:  Rollout timeframe) - attack model

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 20 Jul 2013 19:12:44 -0400

By "authoritative" servers if you mean the CIDER Registry's DNS servers, sure that could be the case.  It's just not that useful to cache specific E.164 number records (ie, DNS leaf nodes) for very long in the general case, because the odds of another call from the same number aren't high enough to make it worth it.  And DNS querying is fairly light-weight and fast, so timing out a cache and re-querying isn't a big deal.  The nice thing is the TTLs for the parent nodes (i.e., the branches of the tree representing the prefixes) can be longer TTLs, and even when the TTL expires then one lookup caches it for the next time period - and since those parents represent ranges of numbers, the odds get better for cache-hit "locality".  There's some further optimization one could make, but I don't think it's necessary to go into that level of detail yet.

Note that the above is about a public Internet access model; or even a private/carrier model but for the providers/Enterprises/whatever that don't have local copies and instead query the CIDER Registry and rely on simple DNS caches.

For the regulated carrier scenarios, regardless of whether it's in The Public DNS or only available in a private manner, the carriers would get local synchronized copies of the whole thing - at least for their country-code branch, for example.  For that scenario, their synch connection to the master would be secure so not need DNSSEC, and it would use some synch protocol (sub/pub or whatever) so the TTLs we're talking about don't apply to their copy.

For international caller-id validation - which probably wouldn't be in the carrier's local DB copies for various reasons - if the foreign country has a restricted-access model then the carriers' local DBs would either recursively resolve through pre-agreed connections, or use the master CIDER Registry and it would do it with pre-agreed connections.  That stuff is flexible and based on how other countries want to deploy, and how the local country handles it. 

In none of those cases do you need CRL lists or OCSP.  The protocol's mechanics clears the old ones out, either through TTLs or sub/pub; and the CIDER Registry (the logical equivalent of the root CA for certs) can keep its signature expiry short and keep re-signing without involving anyone else.

BTW, I'm not saying this is a huge deal - it's just one of the benefits of DNS is all.
(well... I guess it could be a big deal, if the alternative is putting the HTTP URL in the SIP message a la rfc4474)

-hadriel

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 20 Jul 2013 23:20:09 +0000

I don't see the "benefit" of DNS here. There are two cases, either way:

(1) A standard DNS hierarchy, with caching, but no synchronization. In that case, you need short TTLs if you care about revocation. With short TTLs, you get one country-level RTT for every query, even assuming no packet loss.

(2) A locally-cached synchronized DNS hierarchy, using some kind of rsync-like mechanism.

You can get the same two versions for HTTP and certs.

The locally-cached synchronized DNS has essentially the same overhead as the locally-cached HTTP version, since the connection is nailed down.

Henning

________________________________________
From: Hadriel Kaplan [[email-masked]]
Sent: Saturday, July 20, 2013 7:12 PM
To: Henning Schulzrinne
Cc: Cullen Jennings; [email-masked] Mail List
Subject: Re: [stir] CA Certs (was: Re:  Rollout timeframe) - attack model

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 20 Jul 2013 20:13:19 -0400

> (1) A standard DNS hierarchy, with caching, but no synchronization. In that case, you need short TTLs if you care about revocation. With short TTLs, you get one country-level RTT for every query, e…

By "one country-level RTT for every query", do you mean you get one RTT on average for every call, and the RTT is likely not long on average because it's to a server in your geographic country?  If so, sure that would likely be the case for public internet access queriers.  One RTT on average, for a public Internet access model is pretty good, BTW.  HTTP really won't have one RTT for such public Internet access, not in actual practice if this Identity-Info URL model is used.  Again, this is not CIDER's raison d'etre, but just another plus.

> You can get the same two versions for HTTP and certs.

No, I really don't believe you can.  You can get them if we give up on the Identity-Info URL thing, and define how HTTP would work without it, how the international call thing works, and so on.  But not if the cert is served on some random server indicated by the Identity-Info header.

> The locally-cached synchronized DNS has essentially the same overhead as the locally-cached HTTP version, since the connection is nailed down.

Define "overhead".  Overhead for whom?  For the verifier systems HTTP is more overhead - a trivial amount if the stars align, and more if reality is included in the equation; but not a massive amount regardless.  For the carriers, HTTP is more cost and operational overhead from a deployment perspective if reality is included, but again if we ignore practical realties then it's all equal.  So sure, if all carriers in all nations deploy Google or Facebook style infrastructures and tweak their verifiers' TCP and HTTP implementations - all for the benefit of verifying a caller-id - then we're all good-to-go. ;)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 21 Jul 2013 11:50:15 -0400

I've been thinking about your questions and it occurred to me we may be talking past each other, or I'm not being clear enough.  It's hard to discuss some of this stuff in email, but anyway let me try a different tack...

So far, there is one relatively concrete proposal for how HTTP would be used: RFC4474 or 4474bis, which use certs signed by someone, and indicates where to get the cert in an HTTP URL encoded in the SIP message Identity-Info header.  That model has a whole host of issues, and if by "HTTP" you mean that model, then we could drill-down on the practical problems I believe it would have.

There is another way it could work using HTTP, which is essentially to copy the CIDER proposal but replace the DNS query-answer with HTTP query-answer.  The verifier would generate its own HTTP URL to resolve, based on the received identity information in SIP, and we'd define how it does that, what the cert model and encoding would be, how it gets secured redirection, how it times out cached copies, how to get the cert signer's cert, how to time that out, etc.  Let's call such a model "HARD CIDER", for "Http-based Access of Registry Data" or some such.[1]

For a Hard Cider model to be used in a public Internet access model, we'd still be relying on DNS and DNSSEC, to perform resolution of the HTTP URL in a secure manner.  And using a generated HTTP URL implies the national registries are deployed as a Google/Facebook/Amazon type cloudy infrastructure with internal horizontal scaling technologies, etc.  But let's ignore that for now.

The bigger problem is the target user environment: where we expect to be using this stuff, in carriers.  In practice, HTTP isn't frequently used by real-time call-handling network devices in most carriers.  It is used by the carrier as a corporation of course, in various other areas/groups/functions; and it's used in some call-control cases, usually by application servers providing features for specific users or calls, in specific scenarios.  It's far less common to have it used for every call, and essentially never gets used by SBCs or X-CSCFs on an every-call basis.  There are a variety of practical reasons for that, but it doesn't really matter why.  What matters is it would be a barrier to deployability and adoption, in the real world, if we chose it.

Arguably, DIAMETER is a far more common protocol for many carriers to use for this type of stuff than HTTP or even DNS.  DIAMETER has its own challenges in actual carrier deployments, mostly around scalability and manageability, but we couldn't pick DIAMETER anyway because it's only used in some carriers and not all carriers, and rarely used by anyone else.

As a protocol, DNS happens to be used by everyone - it's only used as private ENUM by some carriers not all obviously, but virtually all of them use DNS for at least hostname resolution, even internally.  And DNS client implementation happens to be available in code in all systems, whether it be SBCs or X-CSCFs or app servers or whatever; and its performance, scalability and manageability characteristics happen to be really good in actual carrier deployments.

Having said all that, another way we could go in STIR is to just hedge our bets and define multiple protocols: DNS, HTTP, and maybe even DIAMETER.  To do that, though, it still has to be deployable as DNS, still have to be based on the verifier generating the URL and not have it sent by the originator, still have to specify the caching and clearing behavior, still have to support both a centralized and distributed model of database deployment for numbers, etc.  We've done that sort of hedging before in the IETF, rarely - it's a LOT more work, obviously, but it lets the market decide for itself what to do.

If we do hedge our bets, however, I believe the most straight-forward way to actually do that would be to define the DNS one *first*, and then figure out the HTTP or DIAMETER mechanics required for doing the same things accessing stuff from a deployed DNS database infrastructure.  That's because DNS as a protocol already defines the semantics, mechanics, and database structure; and if its used in a public Internet access manner then it's The Public DNS.  So a use of HTTP or DIAMETER would need to access it and follow its behavior.  And that has some bizarre deployment expectations for all parties, for example for international call scenarios, or for an email-style identity model.

A more reasonable approach might be to define the DNS model, and then only define how an HTTP or DIAMETER access to the local DNS resolver could also work, where the verifier can only be a stub.  That's still a lot of work, and still involves localhost caching rules and such, but at least it constrains the problem somewhat.

-hadriel
[1] I don't use the term "hard" to mean it will be hard, but rather because "hard cider" happens to be a specific form of the drink known as cider. :)

---

From: <[email-masked]>
Date: Mon, 22 Jul 2013 07:56:43 +0000

> You are correct, and several people agreed with you.  However, none of you offered text.  

(Not wanting to reopen the loop) Actually, Henning proposed some language and I, being one of those who struggled with authorization, was fine with it. But I can live with the latest text on this particular point.

(http://www.ietf.org/mail-archive/web/stir/current/msg00911.html)

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave Crocker
Sent: Saturday, July 20, 2013 3:51 PM
To: Russ Housley
Cc: IETF STIR Mail List
Subject: Re: [stir] Draft STIR Charter

Russ,

d/

---

From: <[email-masked]>
Date: Mon, 22 Jul 2013 08:04:01 +0000

Thanks Steve. As I said, I was more concerned about the use of this term given the context than about its general acception, but the recently proposed text is fine. (and thanks for the pointer. I wasn't aware of that one) 

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Kent
Sent: Tuesday, July 16, 2013 5:01 PM
To: [email-masked]
Subject: Re: [stir] Draft STIR Charter

Phillipe,

authenticate

Steve

---

From: Dave Crocker <[email-masked]>
Date: Mon, 22 Jul 2013 09:10:25 +0100

>> If TTLs are short (below a few hours), essentially every query will
>> be answered by the authoritative server in the DNS model, since
>> legitimate calls don't have much locality, from what I can tell.
>
> By "authoritative" servers if you mean the CIDER Registry's DNS
> servers, sure that could be the case. ...   And DNS querying
> is fairly light-weight and fast, so timing out a cache and
> re-querying isn't a big deal.  The nice thing is the TTLs for the
> parent nodes (i.e., the branches of the tree representing the
> prefixes) can be longer TTLs,...

Right.

So...

The DKIM model is a small enhancement over the original work done by 
Mark Delany, then at Yahoo, for DomainKeys.  It offered the basic 
innovation of putting public keys directly into the DNS, using the 
location in the DNS namespace as the de facto cert.  I asked him what 
drove this design choice.

His thoughtful response:

> There were a number of factors in choosing the DNS model over the CA
> approach.
>
> 1. Control. Key revocation and management is entirely in the control
> of the domain owner. We see the mess with revocation in the CA
> world. The lag and the lookup imposition just to name two issues. At
> high volume this sort of approach is a performance disaster.
>
>
> 2. Cost. DNS records are free. Certs cost money. no news there, but we
> were very keen that adoption be as easy as possible and a zero-cost
> "cert" is pretty attractive. People say certs are cheap, but they
> mostly live in that uncommon place, a first-world country.
>
> Frankly the CA business model is not well aligned with the security
> benefits of certs. It wouldn't surprise me if CAs would want to do the
> same IP/Domain binding and premium pricing for wildcard certs that
> they do in the HTTP space.
>
> Note that it never made it into DKIM, but early DomainKeys specs also
> hinted at advertising per-user keys in DNS. That is a real cost-saver
> and allows cheap peer-to-peer authentication - something I would think
> SIP would like to do.
>
>
> 3. Security. With the now common knowledge that TLS is interceptable
> with participating CAs, one has to question the whole security premise
> of a CA model.
>
>
> 4. Flexibility. You can change your DNS at a whim. Need to change key
> lengths, or algorithms in a hurry? Need to spin up a new domain? Try
> that with a CA.
>
>
> 5. Orthogonality of trust. Dunno whether this is relevant to your SIP
> scenario, but the - always dubious - notion that CAs "assert" who you
> are was removed from the equation so that market forces could provide
> whatever was needed. One example might be DMARC in the email space.
>
> Having done the "assertion" dance for certs for non-US entities, I
> know the process is largely a farce.
>
> 6. Adaptation. We were of the belief that such keys could be trivially
> extended to other protocols, such as jabber and SIP, with little or no
> change (Yahoo Messenger interop with 3rd-parties in particular was a
> hot issue back then). I think the earlier specs had various attempts
> at codifying exactly how that would work, but not a lot of effort went
> into this in the WG.

For STIR, I believe the only interesting design risk in a DNS-based 
approach is whether a DNS namespace can be adequately defined and 
administered, to match the needs of the STIR function.

In terms of any other operational concerns of the approach, DKIM 
provides a large-scale, multi-administration equivalence existence 
proof.  It covers at least 60% of all email traffic on the net.  I 
believe there is no operational equivalent any other technical approach; 
if that's not correct, it would help to hear about a global 
authentication mechanism that supports an equivalent scale of 
/independent/ (multi-administration) identifier authorizations.

The view that creating, deploying and perhaps later modifying the design 
of a CA-based global infrastructure will be straightforward does not 
match anything I have ever heard about CA administration and operation, 
at scale.  Creating any global infrastructure is typically a very high 
risk activity, but CAs have had an especially rocky, long-term history. 
  It would be extremely helpful to see some documentation that 
demonstrates that that path is lower risk than simply adding some more 
names and records to the DNS.

In terms of public-vs-private operation, the notes that are getting 
posted on this list seem to vary between a goal of public access and a 
goal of private access (restricted to a privileged few operators.)  The 
scaling and operational complexity differences between these two 
operating modes is, of course, fundamental.  So it it be helpful to 
stabilize this requirement for STIR and then be consistent about 
referring to it.

d/

---

From: Dan York <[email-masked]>
Date: Mon, 22 Jul 2013 12:34:50 +0000

Dave, 

On Jul 22, 2013, at 4:35 AM, "Dave Crocker" <[email-masked]> wrote:

> The DKIM model is a small enhancement over the original work done by Mark Delany, then at Yahoo, for DomainKeys.  It offered the basic innovation of putting public keys directly into the DNS, using the location in the DNS namespace as the de facto cert.  I asked him what drove this design choice.

Very good responses. Thank you for requesting and sharing this feedback. 

> In terms of public-vs-private operation, the notes that are getting posted on this list seem to vary between a goal of public access and a goal of private access (restricted to a privileged few operators.)  The scaling and operational complexity differences between these two operating modes is, of course, fundamental.  So it it be helpful to stabilize this requirement for STIR and then be consistent about referring to it.

While I agree that stabilizing the requirement could be helpful, I would also note that as Hadriel mentioned, a benefit of a DNS-based approach is that we don't really have to decide on the public-vs-private aspect right now. We can construct a system that can be used publicly - and then later if people want to use it on private networks they an do so. (Although in writing this I realize that I am effectively indicating the initial requirement should be "public".)

Dan

---

From: Michael Hammer <[email-masked]>
Date: Mon, 22 Jul 2013 14:07:09 +0000

Hi.  Thanks for the detailed explanation.

One detail that I think you are overlooking is that most calls are between
individual that know each other.  So, there is advantage in the end system
caching the information that allows it to validate a call.  Whether that is
a cert or a DNS CID key would not be much different, except that, as you
note, the DNS cache will likely be lost often.  We should design for the
majority of cases, not the smaller number of unknown callers.

I was thinking that there could be a SIP 1xx series error code whereby the
called party could tell the sender it needs a new cert.  (That could trigger
a display to the user of "Unknown new caller begin verified".)  That could
also be a point where a DNS cache could be queried as well.  There could be
an UPDATE message then sent to provide the cert for that call ID.

Another detail that you may have some cognitive dissonance on is that the
security of the cert or the DNS entry is not secured by the caching system
that delivered it to the called party, but by the fact that the signature of
a well-known administrator cannot be spoofed.  For DNS, garbage in = garbage
out.  You have proven that a bad CID key can be securely distributed.  My
concern is about the root source of the CID key.

"Even if the DNS admin's DNS Key is compromised, they can change it and
re-sign without having to have the Assignees do anything."  This is false.
You would need to know what Text RRs were signed by that key, invalidate all
those CID keys, reissue new public/private key pairs, then sign a new Text
RR for however many that was.  Problem is there is probably no audit as to
what was signed.  At least with a cert, you know what admin key signed a
cert and can check any that you have to flush out both the admin cert as
well as the certs that it signed.

Your rfc4474 paragraph applies for both solutions as a compromised end-user
private key doesn't even need a URL, just the DNS cache.  But, at least in
those cases, that is the end-user's bad.

Hope that helps,
Mike

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Saturday, July 20, 2013 12:55 AM
To: Michael Hammer
Cc: [email-masked]
Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe)

On Jul 19, 2013, at 5:33 PM, Michael Hammer <[email-masked]>
wrote:

> where the chain of trust lies and what is really different.  Maybe I 
> am missing some key point about what is securing the DNS entry and 
> what is in that entry that needs to be secured and how that relates to 
> the key used to sign the SIP header element.

Right, so the basic gist is the private key used to sign SIP request
caller-ids with, has its public key counterpart in a DNS TXT RR.  It may be
The Public DNS, or it may be a controlled-access private or federated one.
Regardless, the public key remains in a DNS, and it's retrieved by the
verifier using the DNS protocol.  Let's call that public key the "CID Key",
for Caller-ID key.  Let's call the entity who uploaded the CID Key into DNS
the "Assignee".

The DNS TTL for the entry is likely quite short... say 30 minutes or even
less.  Thus DNS caches will time it out in 30 minutes.  There's not much
point in caching them longer, because it's rare for source call numbers to
be used frequently enough to make it worth caching for longer.  Even for
those that are "worth it", a DNS query every 30 minutes for the frequent
ones isn't a big deal.  It might be a lot shorter TTL even, but that's all
up to the admin to decide anyway.  That TTL actually has nothing to do with
how long a DNSSEC signature is valid for, but it's useful to keep the TTL
short purely to force DNS caches to flush and check DNS again.

>From a DNSSEC perspective, what's securing the DNS entry is a signature,
using a private key of the admin, with the public key also being available
in DNS.  There's actually a chained signing model for DNS subdomain
hierarchies, but in our case you can skip it so long as the public key value
matches the country-code's, so I'll ignore it for now.  Fundamentally, it's
essentially the same concept as what you described: having all certs signed
by the country-code admin.  In this case, all the TXT RRs are signed by the
country-code admin.  Let's call the DNS admin's public key the "DNS Key",
and call the signature of the TXT RR (containing the CID Key) a "RR
Signature".  The RR Signature is sent back in a resource record along with
the TXT RR, in the same DNS answer packet, when you query DNS for the TXT
RR.

So it's similar to a cert when DNS is queried/answered, but there's no point
in giving a "cert" back to the Assignee, because it serves no purpose.  No
one gets a "cert" from the Assignee - they get it from DNS.  Because they
can get it from DNS, the DNS admin can actually set the RR Signature expiry
time to be relatively short.  Let's say one week.  They can do that because
they can re-sign the TXT RR (generate a new RR Signature) without
communicating that change to the Assignee at all.  The Assignee never has to
upload a fresh CID key again, until their key is compromised or their E.164
number ports out.  Meanwhile the DNS admin can re-sign again and again.
Even if the DNS admin's DNS Key is compromised, they can change it and
re-sign without having to have the Assignees do anything.

If the Assignee's CID key is compromised, the Assignee uploads a new CID Key
to the DNS admin, replacing the old one.  TTL expiry cleans out the old
caches, triggering a fresh query to the DNS.  Thus we don't need
revocations.  For those concerned with DNS injection attacks using a
compromised key, or broken caches holding on to old DNS answers using a
compromised DNS Key, the RR Signature itself only lasts a week.

I should mention that the CIDER draft currently expects the STIR verifier
systems to be client stub resolvers.  In other words, the SIP system
performing STIR verification wouldn't actually do the DNS tree walking or
DNSSEC validation; their local DNS servers would do it on their behalf.
>From a security perspective it means the verifier needs to trust its local
DNS resolvers, but for the STIR use-case that seems reasonable.  The benefit
being that you can basically off-load the work, use a private or federated
DNS model, and so that a carrier can use specialized systems or rules to do
that stuff if they want to. (such systems already exist for private ENUM use
today, for similar call-signaling purposes, though they don't use DNSSEC)

I also expect there to be local actual copies of the entire DNS tree for a
country-code; for example large US carriers would likely have a local copy
for all US numbers; Canadian carriers for Canada numbers; etc.  Their local
copy is not authoritative, but it's a slave synchronizing stuff from the
master run by the country-code admin or a commonly-agreed-upon admin.
That's what happens today in NPAC, for example.  Smaller carriers, or
non-regulated providers, or Enterprises, or whatever - they can just access
the master using DNS, or through their upstream carrier, or a third party
middleman.  The reason I mention this is that these local copies don't need
to deal with DNSSEC at all - they have a synchronized copy of the master
over some secure channel, so the DNSSEC stuff isn't necessary for their
local copy.

The reason that the last part is different for certs, is that so far the
proposals for using certs has been based on rfc4474: that the caller
identifies the HTTP URL to go get the cert from, by putting the URL in the
SIP message in the Identity-Info header field.  That means if an E.164 cert
private key is compromised, it's trivial to abuse it - just generate a SIP
INVITE with your own HTTP URL to your site holding the original cert, and
use the compromised private kay to sign the INVITE.  That's why we'd need
cert revocations.  We couldn't even have short expiries for the certs, of
anything like a week long for example, because it would require getting a
new cert up to the country-code admin to be re-signed every week.  But with
DNS, it's not trivial to use a compromised CID Key: the DNS entry would be
changed, and quickly take effect.  So we wouldn't need actual revocations.

-hadriel
p.s. I didn't mean to spend so much time or focus on the cert revocation
aspect for using CIDER - avoiding revocations isn't really the major benefit
of using CIDER.  There are many more benefits to using CIDER.  Right now I'm
just trying to figure out what the drawbacks/downsides to it are, and
where/if it would break or be less practical than alternatives. (for me, the
STIR thing is more about practicality for the target use-cases than anything
else)

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 22 Jul 2013 10:15:31 -0400

To Brother Marty's point folks have got to understand what Incumbent
Carriers ILEC AND MSO's are capable of actually deploying given the existing
infrastructure and capital constraints on all parties concerned. The end of
the TDM/SS7 PSTN are upon us ... certainly in North America and the US in
particular.

IMHO any non DNS like in band solution will not deploy within carrier
networks cached or otherwise if you believe, as I do that the carriers are
an important part of the solution.   There is a VAST amount of experience
with cached DNS infrastructure in SIP/IMS networks for multiple applications
LNP routing etc.  

There are LOTS of market binders here. If folks want to parallel out of band
vs in band fine there may be some limited justification and use cases for
this.  I'm skeptical but I've been wrong in the past. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
DOLLY, MARTIN C
Sent: Friday, July 19, 2013 8:52 PM
To: Cullen Jennings (fluffy); IETF STIR Mail List
Cc: Russ Housley
Subject: Re: [stir] Draft STIR Charter - out of band

What? Out of band before In band.  What air are you breathing..... sorry
fluf... you are off base on this... let's think economic deployable...

To date I have been nice but you bring out the best, this has been a USA
synergic discussion, no consideration to international, so IETF is going
yield to the ITU.....a(xx) 

-----Original Message-----
Cullen Jennings (fluffy)

I'm listening to the arguments for in band or out of band but right now I am
pretty skeptical that doing in-band before out-of-band is the right order. I
suspect we need them both. Let me say a bit more 

Mobile phones could have done wideband audio long ago, but they did not.
There was no incentive for them to do it since there was no alternative that
could do do wideband and had the same mobility properties. Then along came
smart phones and started providing much better audio quality using things
like Skype. Suddenly there was an incentive to do wideband audio on mobile
phones and you are starting to see that deploy. 

So lets talk about carrier to carrier SIP interconnects. Unless there is an
real incentive, I sort of doubt that they will initially do a lot more than
the SS7 interconnects they replace. No incentive and complicated to change
the business agreements in place. Particularly for interconnects between say
Nigeria and US. 

However, there is a great incentive for smartphones to implement an out of
band solutions even it only works to other smartphones. Once that existed,
there would be an incentive for non smart phones to get an equivalent level
of service and that would most likely be done with a in band solution but at
that point there is an incentive to deploy in band. 

A solution that only worked for smart phones is clearly not as useful as one
that works for all phones, but doing both at the same time seems the most
likely way to me to get either of them to deploy. 

Sure it would be better for the non over the top service providers if there
was only a solution that worked for the carrier a telephone numbers was
delegated down to form a nation level, but as apple showed with iMessage, it
can be better for the users to have two ways to send a SMS messages to
another user. One way that goes thought the provider that the phone number
was delegated to, and one way that goes around the the carrier the phone
number was delegated to. 

So, I'd like to see the charter changed to work on both in-band and
out-of-band at the same time. 

On Jul 16, 2013, at 1:33 PM, Russ Housley <[email-masked]> wrote:

> I have tried to pull all of the discussion into an updated charter.  I
have also attached a diff to make it easier to review.
> define a deployable mechanism that verifies the authorization of the 
> calling party to use a particular telephone number.
> 
> To date, however, true validation of the source of SIP calls has not 
> seen any appreciable deployment.  Several factors contributed to this 
> lack of success, including: failure of the problem to be seen as 
> critical at the time; lack of any technical means of producing a proof 
> of authority over telephone numbers; misalignment of the mechanisms 
> proposed by RFC 4474 with the complex deployment environment that has 
> emerged for SIP; lack of end-to-end SIP session establishment; and 
> inherent operational problems with a transitive trust model.  To make 
> to latency, real-time performance, computational overhead, and 
> administrative overhead for the legitimate call source and all verifiers.
> 
> header-based authorization mechanism to verify 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.  This is called an
in-band mechanism.
> needed between the SIP header fields and the canonical telephone 
> number representation.  The working group will consider choices for 
> protecting identity information and credentials used, but will likely 
> be based on a digital signature mechanism that covers a set of 
> information in the SIP header fields, and verification will employ a 
> credential that contains the public key and is associated with the one or
more telephone numbers.
> delegation models.  That is, when a telephone number or range of 
> telephone numbers is delegated to an entity, relevant credentials will 
> be generated (or
> modified) to reflect such delegation.  The mechanism must allow 
> parties who are not delegated a telephone number, but are authorized 
> by the entity who is delegated the number, to place calls using the
identity.
> 
> After completing the in-band mechanism, the working group will 
> consider session establishment where there are one or more non-SIP 
> hops, most likely using an out-of-band authorization mechanism.  
> However, the in-band and the out-of-band mechanisms should share as 
> much in common as possible, especially the credentials.
> 
> user@domain form deferred since the main focus of the working group is 
> to develop a solution for telephone numbers.
> 
> privacy.  This working group is not chartered to mandate the presence 
> of identity in SIP requests, and to the extent feasible it will find 
> privacy-friendly solutions that leak minimal information about calls 
> to third parties.
>

---

From: <[email-masked]>
Date: Mon, 22 Jul 2013 16:13:03 +0000

More like 221 assigned E.164 CCs to date I think, plus half a dozen reserved but it obviously covers a large variety of situations in terms of assignment models I'm not sure there's much to infer from that. 

FWIW the figure of 68 countries out of 198 un member states was put forward as having some form of NP (M/L/*) in a seminar last year. Haven't double checked... just repeat it...  

Indeed if there are already about 6 billion mobile phones, each of which has at least one number, just add the landlines and other services on top of this.

For the SP, depends on how you define it.

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Wednesday, July 17, 2013 10:53 PM
To: Stephen Kent
Cc: [email-masked]; Hadriel Kaplan
Subject: Re: [stir] Rollout timeframe

Brian

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 22 Jul 2013 17:18:01 +0000

Personally, I still don't see much value in dragging this mailing list
deep into a certs-versus-DNS debate. When I look at the web security world
today, I see both certificates and the DNS playing a role, and I think
we'd be best off we tried to leave the door open to both and see where the
market takes us. I suspect certs are going to play a part in this, maybe
not the only part, but a part. The "DNS is better than certs" arguments
below, while they may have been persuasive arguments for DKIM, don't make
me feel any less sure that certs are viable here.

>> high volume this sort of approach is a performance disaster.

True when it's clear who a "domain owner" is - in other words, when we're
talking about DNS names that you go get from a DNS registrar. I mean, for
DNS names, in many ways the DANE or DKIM approach is a no-brainer: if you
already have a DNS name, and senders are going to resolve it in the course
of protocol operation already, why not put keys in the DNS? But when we
need to create a new DNS tree just for these newly-created names, and that
tree is for use by the -recipient- of a communication who ordinarily
wouldn't be invoking the DNS in the course of protocol operation, with
very curious semantics for what constitutes a "domain owner", this
argument isn't exactly persuasive.

>> mostly live in that uncommon place, a first-world country.

DNS records are free once you have a DNS name, but DNS names are not free.
If you make it a requirement to use the DNS, then the cost for these names
and records will be paid by someone, somewhere. Again, this is a
persuasive motivating assumption for DANE or DKIM, where you just assume
people already have a domain name, but here we're in a situation where the
whole tree of names must be created in order to provide the function.
There's no free lunch.

>> they do in the HTTP space.

No lesser risk of that for the DNS than for certs, though I often do
shudder when I contemplate how wildcarding-like functions would be
provided in the DNS context.

>> and allows cheap peer-to-peer authentication - something I would think

Peer-to-peer authentication is highly desirable, and some devices may be
able to provide it in either model.

>> with participating CAs, one has to question the whole security premise

Š and for the delegation models of the DNS, there is corollary inceptions
that could be launched by anyone above you in the delegation hierarchy,
right?

>> lengths, or algorithms in a hurry? Need to spin up a new domain? Try

You're surely right that for some implementations of DNS services, and
some implementations of CAs, it would be easier to provision new and
surprising security features through the DNS. I'm not sure I see a lot of
value in that, though. If you publish keys with previously unsupported
lengths or use new algorithms unilaterally in your domain name's records,
I suspect that for authentication/verification services surprise is a bad
thing. When you expect your records to be consumed by just anyone, you
need to be pretty strict in what you publish, so flexibility of this
nature doesn't fulfill any obvious need. That situation won't be any
different for CAs or for the DNS.

>> whatever was needed. One example might be DMARC in the email space.

The idea here is that the trust anchors would only be projecting onto the
Internet the existing authority structures of telephone numbers. In this
respect, the enrollment method of the CA could provide a far tighter
coupling between certs and TN authorities than there is between web certs
and domain owners, say. But yes, necessarily the credentials issued are
"orthogonal" to any existing Internet authority - that is a critical
requirement of this work. I think the ability of CAs to enroll entities
into a trust framework without following DNS-style delegation paths is a
good reason for CAs and certs to play a part in the STIR solution.

>> at codifying exactly how that would work, but not a lot of effort went

I believe CA certs could also be adapted to other protocols with no
greater difficulty than DNS names.

Some of the above are great reasons why, when we secure greenfield SIP
identifiers, we should incorporate DANE or something like it. I'm really
not clear these move the needle for telephone numbers, though.

Jon Peterson
Neustar, Inc.

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 22 Jul 2013 17:34:47 +0000

I don't think Cullen's note is recommending that incumbent carriers forgo
in-band. If anything, he suggested that it will take a while for carriers
to get in-band implemented (something I would have thought Mr. Dolly would
sympathize with), and that out-of-band would help as a interim solution in
the meantime, since it could be implemented on edge devices like
smartphones. That is an argument not to wait to do out-of-band only until
after in-band is done, but it doesn't assume anything about existing
carrier infrastructure or require any changes to same. Nor does this have
anything to do with whether the trust anchors reside in the DNS, in CAs,
in both or in neither.

Jon Peterson
Neustar, Inc.

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 22 Jul 2013 13:54:35 -0400

For the below, I assume you're referring to a public Internet access model...

On Jul 22, 2013, at 10:07 AM, Michael Hammer <[email-masked]> wrote:

> caching the information that allows it to validate a call.  

It doesn't matter whether you personally know the far-end caller or not.  DNS caches (or HTTP caches for that matter) can't know the CID Key hasn't been compromised.  If you personally think it's safe to cache your friends' CID Keys for longer than 30 minutes, then fine cache them all day.  If you're comfortable with just believing the keys forever, then fine cache them forever.  That's an end host *application-layer* local policy decision, because it requires knowledge/risk only a specific user application or human can make. 

But from the perspective of DNS caches in the network, and the DNS cache in the end host operating system, they can't possibly make such a decision.  So if your SIP application asks the operating system's DNS client for an answer, the operating system will check the authoritative source after the TTL expires.  In my opinion, that's a *good* property, not a drawback.  Of course your SIP application might decide to store the CID Keys for longer, even forever, because you/it is willing to take the risk; that's your problem to deal with if it turns out you were wrong.

> Whether that is

End host operating systems do cache DNS responses, but yes they'd be clearing them out based on TTL.  The DNS cache is "lost" because the admin of the DNS decides to use a shorter TTL.  The reason to do that in STIR's case would be to reduce the time between checking the number authority (the root "signer" of the logical "cert" equivalent), for a changed or revoked CID key.  The reason the admin would want to do that would be to have the logical equivalent of "cert revocation" in some reasonable time period.

This makes sense because for a huge quantity of the E.164 number "certs", the Assignee of the CID Keys will be regulated and unregulated carriers around the World - not end users, not Enterprises, etc.  While they likely will not use one common private key for all their E.164 numbers, it's doubtful they'd use separate keys for each and every E.164 number.  Even the CPU time required to generate 100 million unique RSA keys is impressive.  A much more likely scenario is they use the same key for some X number of E.164s, for example one key for every 10k or 100k E.164 numbers.  So one compromised key represents a crap-load of revocations.

Even if they use a separate private key for each and every E.164, some X number of those unique keys will reside on one server in the carrier - the server doing the signing for that X number of E.164 sources' SIP messages.  In other words, even if every E.164 has a unique key, it's not the endpoints doing the signing, but rather some systems in the carrier and those systems would each have a lot of the E.164 private keys.  So again, one compromise represents a crap-load of revocations.

> an UPDATE message then sent to provide the cert for that call ID.

RFC 4474 has such a response code - it fails the request with a 438 response.  But how does that help for your case?  The *called* party doesn't know the *calling* sender needs a new cert.  As far as the called party knows, the original cert is fine.  The threat scenario is a private key is compromised, allowing someone else to claim to be the caller.  If the cert is retrieved by DNS or some auto-generated URL, it's hard for the attacker to accomplish the attack; if the cert is retrieved by a URL sent in the SIP message, then it's trivial to accomplish.

> a well-known administrator cannot be spoofed.  

Of course: the well-known admin's private key(s) can be compromised, and then the DNS answers from the well-known admin can be "spoofed".  Even in that case it's not actually trivial to accomplish spoofing the DNS answers, fwiw.  But more importantly the situation can be fixed quickly in a scalable manner, because the well-known admin's now-spoofable signature was itself signed for only a limited time by a higher domain authority, ultimately leading to ICANN's root keys. (you can read about ICANN's key procedures at https://www.iana.org/dnssec/icann-dps.txt)

Since we're talking about a public Internet access model, if ICANN's keys are compromised the whole Internet is basically exposed anyway, for some time period.  I mean it's not like domain names aren't used for a whole lot of more-important things than caller-id verification already. :)

> For DNS, garbage in = garbage

Ummm... how is that any worse than how certs work?  With end-entity certificates, they're only as authentic as the trust and signature of the root CA, and only as secure as end-entity cert holder of the private key keeps its key *private*.  If the root CA is compromised, hilarity ensues. (i.e., DigiNotar)  If the end-entity private key is compromised, same problem.  The difference is in the aspect of how everyone learns about it and the CA can effectively fix it, quickly and in a scalable manner.

> well as the certs that it signed.

Nope.  The TXT RR (CID Key) only holds the Assignee's *public* key value.  The DNS admin does not hold, nor never knew about, the private key twin the Assignee has for its public CID Key.  So the DNS admin can sign all TXT RRs again, and keep its signature validity period short, because the TXT RR's value doesn't need to change.

It doesn't in certs either, for that matter.  A CA could continuously re-sign certs all day long (ie, generate certs from old CSRs).  The problem is that the old certs are given back to the end entity applicant that made the signing request, to be used in TLS/SSL, S/MIME, etc.  So you'd need to disseminate new signed certs to all the old applicants.  That's why a cert validity period is long, and why we need revocation lists for end-entity certs.  In CIDER's case, the logical equivalent of the "CSR applicant" never needs the signed "cert" back, because the "cert" is retrieved directly from the "CA" by the STIR verifier. 

> those cases, that is the end-user's bad.

I don't understand what you mean.  In CIDER, if Alice's end-user private key is compromised by Charlie, then when Charlie sends a SIP INVITE to Bob pretending to be Alice, Charlie would have to be able to inject a fake answer to Bob's DNS query for Alice's public key.  Charlie would have to know what DNS cache Bob happens to use, and succeed in poisoning that cache.  DNS cache poisoning has occurred, but DNS caches learned from that: they now employ means of making it a lot harder to perform (e.g.: randomized source port, randomized 16-bit ID field value), and ultimately DNSSEC was created with the goal of preventing such poisoning.  That's one of the main reasons why one would even use DNSSEC in a CIDER public Internet access model - to prevent such poisoning.

-hadriel

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 22 Jul 2013 18:28:39 +0000

It seems that either a certificate or DNS-based approach can be public or private. For DNS, you'd presumably need either local DNS (restricted by network access controls of some sort) or a boatload of VPNs (which presumably have to be standardized or profiled if you want interoperability, given the multitude of VPN technologies out there). If you are relying on some local-access-only-DNS, you need a mechanism to distribute the data to those local DNS servers, update individual entries, do revocations, etc. Thus, there are a number of pieces that would need to be specified for the private-DNS option in order to build a real system with thousands of validating participants.

For HTTP-based solution, you'd similarly have to pick from small bag of solutions (basic, digest, client cert, all over TLS, presumably), but most client implementations are likely to support all three out of the box.

Another consideration is who runs what size infrastructure - given the lack of useful resolver caching, the DNS solution would likely have to be able to handle every single validation in the VPN model from the central authority (e.g., the numbering administrator). In the HTTP data synchronization model, the load would be local to the validating carrier, with the central infrastructure pushing only updates as needed. 

Indeed, you could picture a combination of the two approaches - a carrier runs a local, private DNS service that interacts with the call control components, but the local server care and feeding is through an HTTP-style cache management and bulk transfer mechanism.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan York
Sent: Monday, July 22, 2013 8:35 AM
To: <[email-masked]>
Cc: [email-masked] Mail List
Subject: Re: [stir] CA Certs

Dave, 

Dan

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 22 Jul 2013 14:56:05 -0400

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Henning Schulzrinne
Sent: Monday, July 22, 2013 2:29 PM
To: 'Dan York'; <[email-masked]>
Cc: [email-masked] Mail List
Subject: Re: [stir] CA Certs

It seems that either a certificate or DNS-based approach can be public or
private. For DNS, you'd presumably need either local DNS (restricted by
network access controls of some sort) 
[
[RS> ] Which is exactly how boatloads of carriers access LNP and Routing
data via 6116 queries today.  People forget it was local TCAP elimination
that drove Carrier ENUM into the network in the first place. "No more dip
charges." SS7 sucks. 

or a boatload of VPNs (which presumably have to be standardized or profiled
if you want interoperability, given the multitude of VPN technologies out
there). If you are relying on some local-access-only-DNS, you need a
mechanism to distribute the data to those local DNS servers, update
individual entries, do revocations, etc. 

[RS> ] Which is exactly how wireless carriers implemented MMS routing using
6116 before moving to a locally cached DNS ENUM servers and a trusted
registry with a bulk download distribution mode of the portability corrected
NANP>LRN>OCN>MMSC data. 

Thus, there are a number of pieces that would need to be specified for the
private-DNS option in order to build a real system with thousands of
validating participants.

For HTTP-based solution, you'd similarly have to pick from small bag of
solutions (basic, digest, client cert, all over TLS, presumably), but most
client implementations are likely to support all three out of the box.

Another consideration is who runs what size infrastructure - given the lack
of useful resolver caching, the DNS solution would likely have to be able to
handle every single validation in the VPN model from the central authority
(e.g., the numbering administrator). In the HTTP data synchronization model,
the load would be local to the validating carrier, with the central
infrastructure pushing only updates as needed. 

[RS> ]  Which is essentially how the NPAC works today. A massive centralized
registry but distributed local cache, but that has "other" issues of who
operates the registry, why and how much.   Shockey's Law here" Money is the
answer, what is the question?"   

My point is in the modern SIP/IMS model the protocols are in place with the
CSCF to handle locally cached 6116/DNS data and modifications could be
relatively simple. I just don't see the HTTP stack making its way into IMS
before V 26 or so <g> but I'll let 3GPP experts elaborate on that. 

Indeed, you could picture a combination of the two approaches - a carrier
runs a local, private DNS service that interacts with the call control
components, but the local server care and feeding is through an HTTP-style
cache management and bulk transfer mechanism.

[RS> ] There is some rationale for that.  This begs an old problem we had in
Carrier ENUM.  Do you want a "Thick" registry or "Thin". Thick presumes all
the data components are held in the centralized registry, which is useful
for validation purposes etc then distributed out via some bulk
transfer/update method or Thin where the data is presumed to be held by the
"Carrier of Record" for the TN and the first order resolution is nothing
more than some NS like record.  DNS is much much better for Thin models.  

Logically Peterson is somewhat correct here. If you presume that at least
_part_ of the solution involves the CUA or edge PBX systems you might look
at HTTP mechanisms, but then you have reduced the problem to access
methodology.   There are real tradeoff's here are in presuming how the data
is managed and how it would globally scale. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan
York
Sent: Monday, July 22, 2013 8:35 AM
To: <[email-masked]>
Cc: [email-masked] Mail List
Subject: Re: [stir] CA Certs

Dave, 

On Jul 22, 2013, at 4:35 AM, "Dave Crocker" <[email-masked]> wrote:

> The DKIM model is a small enhancement over the original work done by Mark
Delany, then at Yahoo, for DomainKeys.  It offered the basic innovation of
putting public keys directly into the DNS, using the location in the DNS
namespace as the de facto cert.  I asked him what drove this design choice.

> In terms of public-vs-private operation, the notes that are getting posted
on this list seem to vary between a goal of public access and a goal of
private access (restricted to a privileged few operators.)  The scaling and
operational complexity differences between these two operating modes is, of
course, fundamental.  So it it be helpful to stabilize this requirement for
STIR and then be consistent about referring to it.

While I agree that stabilizing the requirement could be helpful, I would
also note that as Hadriel mentioned, a benefit of a DNS-based approach is
that we don't really have to decide on the public-vs-private aspect right
now. We can construct a system that can be used publicly - and then later if
people want to use it on private networks they an do so. (Although in
writing this I realize that I am effectively indicating the initial
requirement should be "public".)

Dan

---

From: Michael Hammer <[email-masked]>
Date: Mon, 22 Jul 2013 21:09:28 +0000

Let me try to sum up the disconnects I see:

You assume that a Cert signing will likely be compromised and there will be
a host of revocations needed.
You assume that a DNS signing can't happen or the whole Internet would be
insecure.
Any reason you trust one more than the other?  
(Assuming your authority is competent, but my authority is incompetent is an
example of the false comparison I was talking about.)
s/DigiNotar/ICANN  similar hilarity will ensue.

Flooding the DNS with 100 million telephone number keys every 30 seconds is
doable.
Flooding the DNS with a CRL of known compromises is not workable.
Given that the number of compromises should be several orders of magnitude
lower than the Certs/CID's themselves, why would the smaller be harder?
(Note you make assumptions about how easy it might be to compromise a single
user.)
(You also seem to make assumptions about how often a cert is renewed.  For
high-value targets they could do it more often.)

With Certs, a compromised private key is not known by anybody.  Called
continues using old cert.  Bad.
With DNS, a compromised private key is magically known by DNS.  Called
fetches the public key of the compromised private key.  Ummm same diff.
Bad.
How exactly is that discovered in one case, but not the other?

With Certs, a compromised (assignee) private key requires a new cert to be
distributed (new public key associated with tel#).
With DNS, a compromised (assignee) private key doesn't need to be replaced,
we just re-sign the TXT RR record, because "The TXT RR (CID Key) only holds
the Assignee's *public* key value."
That still does not compute.

"In CIDER, if Alice's end-user private key is compromised by Charlie, then
when Charlie sends a SIP INVITE to Bob pretending to be Alice, 
Charlie would have to be able to inject a fake answer to Bob's DNS query for
Alice's public key.
Ummm, no.  Not at all, Charlie has the private key, so the DNS will confirm
that Charlie is Alice, since the supposed "good" DNS entry's public key will
work with that private key.

Mike

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Monday, July 22, 2013 1:55 PM
To: Michael Hammer
Cc: [email-masked]
Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe)

For the below, I assume you're referring to a public Internet access
model...

On Jul 22, 2013, at 10:07 AM, Michael Hammer <[email-masked]>
wrote:

> One detail that I think you are overlooking is that most calls are 
> between individual that know each other.  So, there is advantage in 
> the end system caching the information that allows it to validate a call.

It doesn't matter whether you personally know the far-end caller or not.
DNS caches (or HTTP caches for that matter) can't know the CID Key hasn't
been compromised.  If you personally think it's safe to cache your friends'
CID Keys for longer than 30 minutes, then fine cache them all day.  If
you're comfortable with just believing the keys forever, then fine cache
them forever.  That's an end host *application-layer* local policy decision,
because it requires knowledge/risk only a specific user application or human
can make. 

But from the perspective of DNS caches in the network, and the DNS cache in
the end host operating system, they can't possibly make such a decision.  So
if your SIP application asks the operating system's DNS client for an
answer, the operating system will check the authoritative source after the
TTL expires.  In my opinion, that's a *good* property, not a drawback.  Of
course your SIP application might decide to store the CID Keys for longer,
even forever, because you/it is willing to take the risk; that's your
problem to deal with if it turns out you were wrong.

> Whether that is
> a cert or a DNS CID key would not be much different, except that, as 
> you note, the DNS cache will likely be lost often.  We should design 
> for the majority of cases, not the smaller number of unknown callers.

End host operating systems do cache DNS responses, but yes they'd be
clearing them out based on TTL.  The DNS cache is "lost" because the admin
of the DNS decides to use a shorter TTL.  The reason to do that in STIR's
case would be to reduce the time between checking the number authority (the
root "signer" of the logical "cert" equivalent), for a changed or revoked
CID key.  The reason the admin would want to do that would be to have the
logical equivalent of "cert revocation" in some reasonable time period.

This makes sense because for a huge quantity of the E.164 number "certs",
the Assignee of the CID Keys will be regulated and unregulated carriers
around the World - not end users, not Enterprises, etc.  While they likely
will not use one common private key for all their E.164 numbers, it's
doubtful they'd use separate keys for each and every E.164 number.  Even the
CPU time required to generate 100 million unique RSA keys is impressive.  A
much more likely scenario is they use the same key for some X number of
E.164s, for example one key for every 10k or 100k E.164 numbers.  So one
compromised key represents a crap-load of revocations.

Even if they use a separate private key for each and every E.164, some X
number of those unique keys will reside on one server in the carrier - the
server doing the signing for that X number of E.164 sources' SIP messages.
In other words, even if every E.164 has a unique key, it's not the endpoints
doing the signing, but rather some systems in the carrier and those systems
would each have a lot of the E.164 private keys.  So again, one compromise
represents a crap-load of revocations.

> I was thinking that there could be a SIP 1xx series error code whereby 
> the called party could tell the sender it needs a new cert.  (That 
> could trigger a display to the user of "Unknown new caller begin 
> verified".)  That could also be a point where a DNS cache could be 
> queried as well.  There could be an UPDATE message then sent to provide
the cert for that call ID.

RFC 4474 has such a response code - it fails the request with a 438
response.  But how does that help for your case?  The *called* party doesn't
know the *calling* sender needs a new cert.  As far as the called party
knows, the original cert is fine.  The threat scenario is a private key is
compromised, allowing someone else to claim to be the caller.  If the cert
is retrieved by DNS or some auto-generated URL, it's hard for the attacker
to accomplish the attack; if the cert is retrieved by a URL sent in the SIP
message, then it's trivial to accomplish.

> Another detail that you may have some cognitive dissonance on is that 
> the security of the cert or the DNS entry is not secured by the 
> caching system that delivered it to the called party, but by the fact 
> that the signature of a well-known administrator cannot be spoofed.

Of course: the well-known admin's private key(s) can be compromised, and
then the DNS answers from the well-known admin can be "spoofed".  Even in
that case it's not actually trivial to accomplish spoofing the DNS answers,
fwiw.  But more importantly the situation can be fixed quickly in a scalable
manner, because the well-known admin's now-spoofable signature was itself
signed for only a limited time by a higher domain authority, ultimately
leading to ICANN's root keys. (you can read about ICANN's key procedures at
https://www.iana.org/dnssec/icann-dps.txt)

Since we're talking about a public Internet access model, if ICANN's keys
are compromised the whole Internet is basically exposed anyway, for some
time period.  I mean it's not like domain names aren't used for a whole lot
of more-important things than caller-id verification already. :)

> out.  You have proven that a bad CID key can be securely distributed.  
> My concern is about the root source of the CID key.

Ummm... how is that any worse than how certs work?  With end-entity
certificates, they're only as authentic as the trust and signature of the
root CA, and only as secure as end-entity cert holder of the private key
keeps its key *private*.  If the root CA is compromised, hilarity ensues.
(i.e., DigiNotar)  If the end-entity private key is compromised, same
problem.  The difference is in the aspect of how everyone learns about it
and the CA can effectively fix it, quickly and in a scalable manner.

> "Even if the DNS admin's DNS Key is compromised, they can change it 
> and re-sign without having to have the Assignees do anything."  This is
false.
> You would need to know what Text RRs were signed by that key, 
> invalidate all those CID keys, reissue new public/private key pairs, 
> then sign a new Text RR for however many that was.  Problem is there 
> is probably no audit as to what was signed.  At least with a cert, you 
> know what admin key signed a cert and can check any that you have to 
> flush out both the admin cert as well as the certs that it signed.

Nope.  The TXT RR (CID Key) only holds the Assignee's *public* key value.
The DNS admin does not hold, nor never knew about, the private key twin the
Assignee has for its public CID Key.  So the DNS admin can sign all TXT RRs
again, and keep its signature validity period short, because the TXT RR's
value doesn't need to change.

It doesn't in certs either, for that matter.  A CA could continuously
re-sign certs all day long (ie, generate certs from old CSRs).  The problem
is that the old certs are given back to the end entity applicant that made
the signing request, to be used in TLS/SSL, S/MIME, etc.  So you'd need to
disseminate new signed certs to all the old applicants.  That's why a cert
validity period is long, and why we need revocation lists for end-entity
certs.  In CIDER's case, the logical equivalent of the "CSR applicant" never
needs the signed "cert" back, because the "cert" is retrieved directly from
the "CA" by the STIR verifier. 

> Your rfc4474 paragraph applies for both solutions as a compromised 
> end-user private key doesn't even need a URL, just the DNS cache.  
> But, at least in those cases, that is the end-user's bad.

I don't understand what you mean.  In CIDER, if Alice's end-user private key
is compromised by Charlie, then when Charlie sends a SIP INVITE to Bob
pretending to be Alice, Charlie would have to be able to inject a fake
answer to Bob's DNS query for Alice's public key.  Charlie would have to
know what DNS cache Bob happens to use, and succeed in poisoning that cache.
DNS cache poisoning has occurred, but DNS caches learned from that: they now
employ means of making it a lot harder to perform (e.g.: randomized source
port, randomized 16-bit ID field value), and ultimately DNSSEC was created
with the goal of preventing such poisoning.  That's one of the main reasons
why one would even use DNSSEC in a CIDER public Internet access model - to
prevent such poisoning.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 22 Jul 2013 18:39:33 -0400

On Jul 22, 2013, at 2:28 PM, Henning Schulzrinne <[email-masked]> wrote:

> It seems that either a certificate or DNS-based approach can be public or private. For DNS, you'd presumably need either local DNS (restricted by network access controls of some sort) or a boatload of VPNs (which presumably have to be standardized or profiled if you want interoperability, given the multitude of VPN technologies out there).

If we're talking about a private access model but with only a centralized database and no local copies, then yes you can do it multiple ways - that's probably a good thing.  You're talking about connecting carriers to a central database thing in that model, so there's no reason the central-DB service couldn't provide multiple VPN access mechanisms of the carrier's choosing: IPsec with static keys, IPsec with IKE, SSL VPNs, MPLS VPNs, or even direct/leased T1 lines for that matter.  We don't have to standardize anything new - all those technologies are standardized.  It's a business arrangement decision which to do.  It doesn't have to be the same for every carrier.

An NPAC-style model, on the other hand, could follow the existing NPAC itself: there are local copies of the DB in the carriers, and per-call queries don't go to the real NPAC. (at least I don't think the central NPAC gets queried directly, does it?)  So if it's not, then from a DNS perspective, the NPAC doesn't have to implement anything that answers DNS queries or even smells of "DNS", nor would it need to implement HTTP query access either for that matter.  The local database copies in the carriers could provide DNS queries/answers to/from their own STIR verifiers, but they are local copies owned by the carrier for its own use, so they can do any protocol they wish.  They could use SS7/TCAP even.

The trick is how to handle stuff that's not in the NPAC, namely international numbers. 

> If you are relying on some local-access-only-DNS, you need a mechanism to distribute the data to those local DNS servers, update individual entries, do revocations, etc.

Afaik, the standards for that already exist: AXFR (RFC 1034/1035/5936), IXFR (RFC 1995), and NOTIFY (RFC 1996).  DNS servers even implement them.

But yeah, I agree it might be good to define an additional, alternative means of performing those for STIR, or even for DNS in general.  Something HTTP-based might make sense for that, for example.

Having said that, what alternative do we have for doing that?  In what model can we have local copies of a database in the carriers, yet not have to define some protocol they could use to download/synchronize/update their local database copy with a master?

> Thus, there are a number of pieces that would need to be specified for the private-DNS option in order to build a real system with thousands of validating participants.

I'm not sure which "validating participants" you mean?  In a local-access-only-DNS model, I'm assuming we're talking about a local database in carriers, to be used by their SIP STIR verifier systems, right?  There's no need for those STIR verifier systems to have some new VPN to the local database copies - they're already in a private network in the carrier today, and already query such databases today for other things: CNAM, call routing, etc.  Those queries are sent on private-network interfaces internal to the carrier.  That's how Private ENUM works, SIP works, DIAMETER works, etc.  They don't send them over IPSec or TLS internally.

> For HTTP-based solution, you'd similarly have to pick from small bag of solutions (basic, digest, client cert, all over TLS, presumably), but most client implementations are likely to support all t…

I don't follow you - I mean I don't understand which "clients" you're talking about: the SIP STIR verifiers as clients to a carrier's local database, or the carrier local databases as clients to a central master?  (man this stuff is hard to discuss in email!  We really need a WG with virtual/physical meetings)

> Another consideration is who runs what size infrastructure - given the lack of useful resolver caching, the DNS solution would likely have to be able to handle every single validation in the VPN model from the central authority (e.g., the numbering administrator).

If carriers don't have their own local copy of the DB, then of course by definition anything not in someone's local cache goes to the master authority.  The same is true of HTTP of course.

> In the HTTP data synchronization model, the load would be local to the validating carrier, with the central infrastructure pushing only updates as needed. 

What "HTTP data synchronization model"?  You lost me. :(

> Indeed, you could picture a combination of the two approaches - a carrier runs a local, private DNS service that interacts with the call control components, but the local server care and feeding is…

Sure, that's possible.  We'd still have to define how that HTTP-style cache management and bulk transfer mechanism works though.

-hadriel

---

From: Dave Crocker <[email-masked]>
Date: Tue, 23 Jul 2013 10:40:28 +0100

Jon,

On 7/22/2013 6:18 PM, Peterson, Jon wrote:
> deep into a certs-versus-DNS debate.

Sorry for my confusion.  I thought that IETF (working group) mailing 
lists were where technical analysis and choice were done.  In fact, I 
thought that was embedded in the IETF at the level of religious precept.

I hadn't realized that RAI operates according to different rules.

Just out of curiosity, since there /is/ a debate to be had -- the choice 
between certs vs. dkim-like key distribution does involve competing 
designs -- what is the proper venue for it?

> When I look at the web security world
> today, I see both certificates and the DNS playing a role,

"A" role is not the question.  The question is which is to be used for 
key distribution and based on what trust model?

Perhaps it will help to say DKIM-like (or DOSETA-based, to be even more 
au courante) rather than DNS, since the DNS can also be used to 
distribute certs.

In fact, this highlights that there are a number of different choices, 
not just two:

1. DOSETA-over-DNS

2. Certs-over-DNS (Dane-ish)

3. Certs-over-?-over HTTP

On the last, the question mark is because there's an undefined semantic 
layer -- I'm still not clear what the cert-specific protocol details 
are, that operate above HTTP.

 > and I think
> we'd be best off we tried to leave the door open to both  and see
 > where the market takes us.

That is the sort of view that always sounds appealing but merely serves 
to delay inevitable pain, a bit like asking someone to use two different 
text editors or two different email programs, so they can leave the door 
open for which to use (at any point in time).

These are core service design choices.  They have to be made at some 
point, and it isn't possible to refine the overall system design until 
these basic architectural choices are made.

As for letting the market decide, the usual way such competition is 
pursued between IETF protocols is by parallel, independent working 
groups, each with a clear focus on a single, specific architecture.  Is 
that what you are proposing?

The fuzziness (or ambiguity) of language like "both [can] play a role" 
is an example of the reason it is best to have an effort be focused on 
narrow problem-solving for a specific mechanism, rather than wandering 
back and forth and typically getting confused about what is being discussed.

>      I suspect certs are going to play a part in this, maybe

That's why it's better to explore functional and OA&M trade-offs rather 
than personal feelings.

> talking about DNS names that you go get from a DNS registrar.

Right you are pre-echoing the point about determining a name and 
administration structure that I made, towards the end of my message.

> No lesser risk of that for the DNS than for certs,

Actually there is, given that most DNS pricing has been driven towards 
commodity levels rather than premium levels.  And for a mandated new 
branch to cover this new use, it can be limited to cost-recovery pricing.

> able to provide it in either model.

Mark is correct that DKIM does not pursue per-user usage, but wrong that 
it per-user keys aren't supported, in that one can always have 
sub-domains and that provide additional granularity, down to the 
individual user.  What it doesn't do is map that granularity to a full 
email address rather than just a domain name.

> that could be launched by anyone above you in the delegation hierarchy,

 From the part of your comment that didn't get garbled, it looks as if 
"DNSSec" is the response to your point.

> You're surely right that for some implementations of DNS services,

Some?  All do TTLs.  If you mean something that that doesn't cover, then 
what is it?

Short TTLs mean any associated leaf node's values can be changed within 
a TTL time.

The essential point is that TTLs constitute a far simpler and more 
direct mechanism than CRLs.

And unless I've missed the report, they've been demonstrated to work at 
scale, over the open Internet, across very large numbers of independent 
administrations.  Where has this been demonstrated for CRLs?

> coupling between certs and TN authorities than there is between web certs

This repeats the point I made at the end (and here, it is in the next 
paragraph) which is that figuring out an appropriate mapping to a DNS 
name and administration hierarchy is the significant challenge for using 
a DNS-based scheme.  (But then, it also one of the significant 
challenges for using a /non/-DNS-based scheme...)

And just as a referesher, here's the point I cited as your "pre-echoing"...

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 23 Jul 2013 12:04:50 -0400

> Any reason you trust one more than the other?  

I don't "trust" either one - I'm more focused on the "what happens after its compromised".

> s/DigiNotar/ICANN  similar hilarity will ensue.

My point with the ICANN keys getting compromised is that caller-id verification will be the least of the problems in that scenario.  In fact, in order to retrieve certificates at all using HTTP (or retrieve CRLs/OCSP for that matter), you're already relying on DNS and ultimately ICANN.

But the good news is that because it's just one root CA for the entire Internet, if that CA's keys get compromised the news of such a thing will spread quick and wide, with operating systems, DNS caches, etc., providing security updates to reject/remove the compromised root keys.

Ultimately, no matter what we do, we do have to "trust" some root signing organization(s).  Would you rather trust one, or 200?  Do you want to check CRLs from one common root, or from 200 roots?  In the CIDER proposal, for a public Internet access model ultimately there is one true root: ICANN, the root for DNS.  That doesn't seem so crazy to me, for a public Internet access thing to do.  ICANN has already deployed DNSSEC, and it's used for other important things than just caller-id validation.

> Flooding the DNS with 100 million telephone number keys every 30 seconds is

I don't know what the above means.  In what way do you mean that?

> Flooding the DNS with a CRL of known compromises is not workable.

I don't know what the above means.  What does it mean to "flood the DNS with a CRL"?

> lower than the Certs/CID's themselves, why would the smaller be harder?

Of course the number of compromises should be lower than the number of valid CID Keys.  So?  You lost me.

> continues using old cert.  Bad.

That depends on the way in which we define retrieving the certs, and whether CRLs/OCSP is implemented.  A compromised cert would be in a CRL eventually.

> How exactly is that discovered in one case, but not the other?

Are you asking how the attacked party discovered their key has been compromised?  Or are you asking, once they discover it, how everyone else learns about it?

Obviously if you never learn your key was compromised, it won't stop being usable until it gets changed and its validity time expires.

If you learn a key was compromised, with certs you go to the CA and get new certs, and ask it to revoke the certs it signed for you, either in CRL or OCSP.  With DNSSEC you go to the DNS admin for the zone you're in, upload new CID Keys, and remove the compromised ones.  

> That still does not compute.

We were talking about if the DNS admin's DNSSEC zone-signing keys got compromised - not if the Assignee's CID private-key got compromised.  If the Assignee's CID private keys got compromised, then of course the TXT RR value changes.  The nice thing is there's no CRL/OCSP; it's "revoked" by timing out.

> work with that private key.

I was talking about once the compromise was discovered.  Obviously if Alice never discovers her key has been compromised, Charlie will be able to use her key until Alice changes it.  The odds are though that Alice will discover it - not directly, but by either being told by Bob, or by her carrier getting told one or more of its other E.164 numbers using the same key being abused.  Ultimately people do report caller-id fraud today to their carriers... we're just trying to reduce the number of incidents as much as possible.

-hadriel

---

From: Michael Hammer <[email-masked]>
Date: Tue, 23 Jul 2013 16:26:23 +0000

I think we are very close on understanding the pros and cons of each, so the
email discussion has served its purpose.

My flooding comment was standing back and looking at the forest for the
trees.
You indicated that the TTL is very small, so all the caches in the DNS need
to be flushed and 
all new calls/quries to DNS will cause the data to flow from their root
locations out towards the edge, again, every 30 seconds.
Since there are millions of calls per minute globally, that looks like a
flood of updates to me.

So, my question was looking at the volume of RRs repeatedly going out,
versus the number of CRLs that would need to go out.
Given how often a key might be compromised, it would seem that the CRL
number might be many orders of magnitude less.
As you note, if a compromise occurs, in either approach, that information
needs to get propagated to users of the network.

One more scale question to throw in here.  Anther thread mentions a web of
VPNs may be needed.
Today, we have some number of Service Providers involved.
Every additional SP would mean an increase of VPNS by N(N-1).
If we go from, say 10,000 to 100,000 or to 1M SPs does that scale?

Mike

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Tuesday, July 23, 2013 12:05 PM
To: Michael Hammer
Cc: [email-masked]
Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe)

On Jul 22, 2013, at 5:09 PM, Michael Hammer <[email-masked]>
wrote:

> You assume that a Cert signing will likely be compromised and there 
> will be a host of revocations needed.
> You assume that a DNS signing can't happen or the whole Internet would 
> be insecure.

I don't "trust" either one - I'm more focused on the "what happens after its
compromised".

> (Assuming your authority is competent, but my authority is incompetent 
> is an example of the false comparison I was talking about.) 

My point with the ICANN keys getting compromised is that caller-id
verification will be the least of the problems in that scenario.  In fact,
in order to retrieve certificates at all using HTTP (or retrieve CRLs/OCSP
for that matter), you're already relying on DNS and ultimately ICANN.

But the good news is that because it's just one root CA for the entire
Internet, if that CA's keys get compromised the news of such a thing will
spread quick and wide, with operating systems, DNS caches, etc., providing
security updates to reject/remove the compromised root keys.

Ultimately, no matter what we do, we do have to "trust" some root signing
organization(s).  Would you rather trust one, or 200?  Do you want to check
CRLs from one common root, or from 200 roots?  In the CIDER proposal, for a
public Internet access model ultimately there is one true root: ICANN, the
root for DNS.  That doesn't seem so crazy to me, for a public Internet
access thing to do.  ICANN has already deployed DNSSEC, and it's used for
other important things than just caller-id validation.

> Flooding the DNS with 100 million telephone number keys every 30 
> seconds is doable.

> Flooding the DNS with a CRL of known compromises is not workable.

I don't know what the above means.  What does it mean to "flood the DNS with
a CRL"?

> Given that the number of compromises should be several orders of 
> magnitude lower than the Certs/CID's themselves, why would the smaller be
harder?

Of course the number of compromises should be lower than the number of valid
CID Keys.  So?  You lost me.

> (You also seem to make assumptions about how often a cert is renewed.  
> For high-value targets they could do it more often.) With Certs, a 
> compromised private key is not known by anybody.  Called continues 
> using old cert.  Bad.

That depends on the way in which we define retrieving the certs, and whether
CRLs/OCSP is implemented.  A compromised cert would be in a CRL eventually.

> How exactly is that discovered in one case, but not the other?

Are you asking how the attacked party discovered their key has been
compromised?  Or are you asking, once they discover it, how everyone else
learns about it?

Obviously if you never learn your key was compromised, it won't stop being
usable until it gets changed and its validity time expires.

If you learn a key was compromised, with certs you go to the CA and get new
certs, and ask it to revoke the certs it signed for you, either in CRL or
OCSP.  With DNSSEC you go to the DNS admin for the zone you're in, upload
new CID Keys, and remove the compromised ones.  

> With Certs, a compromised (assignee) private key requires a new cert 
> to be distributed (new public key associated with tel#).
> With DNS, a compromised (assignee) private key doesn't need to be 
> replaced, we just re-sign the TXT RR record, because "The TXT RR (CID 
> Key) only holds the Assignee's *public* key value."

We were talking about if the DNS admin's DNSSEC zone-signing keys got
compromised - not if the Assignee's CID private-key got compromised.  If the
Assignee's CID private keys got compromised, then of course the TXT RR value
changes.  The nice thing is there's no CRL/OCSP; it's "revoked" by timing
out.

> "In CIDER, if Alice's end-user private key is compromised by Charlie, 
> then when Charlie sends a SIP INVITE to Bob pretending to be Alice, 
> Charlie would have to be able to inject a fake answer to Bob's DNS 
> query for Alice's public key.
> Ummm, no.  Not at all, Charlie has the private key, so the DNS will 
> confirm that Charlie is Alice, since the supposed "good" DNS entry's 
> public key will work with that private key.

I was talking about once the compromise was discovered.  Obviously if Alice
never discovers her key has been compromised, Charlie will be able to use
her key until Alice changes it.  The odds are though that Alice will
discover it - not directly, but by either being told by Bob, or by her
carrier getting told one or more of its other E.164 numbers using the same
key being abused.  Ultimately people do report caller-id fraud today to
their carriers... we're just trying to reduce the number of incidents as
much as possible.

-hadriel

---

From: Stephen Kent <[email-masked]>
Date: Tue, 23 Jul 2013 13:11:35 -0400

...
> considering the pragmatics of a very constrained mechanism for this 
> very constrained goal.
>
I think subsequent discussion on the list shows that there is not yet 
agreement on a threat
model, the number of players, in-band vs. OOB, etc. So when you argue 
for tackling narrower
goals I suspect there is not yet agreement about what those goals are.

Finally, my comments re DKIM vs. SMIME do not really support your 
argument about scope.
The two mechanisms address largely different sets of goals.

Steve

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 23 Jul 2013 15:12:57 -0400

> locations out towards the edge, again, every 30 seconds.

[minor note: it was every 30 minutes, not seconds]

> Since there are millions of calls per minute globally, that looks like a

Not from the "root" exactly.  For example, let's assume the CIDER anchor for the NANP is "1.cid.example.com".  The DNS caches/resolvers would know which DNS server IPs to access for "1.cid.example.com" all the time, because whenever its TTL expires just one call-triggered CIDER query from anyone using the DNS resolver/cache refreshes it for all calls for everyone on that resolver/cache, for the next TTL time period.

In fact the resolvers would even know the one for the NPA (area-code) level because there would be sufficient frequency of calls for that to also happen, for the NPAs that are frequently called from.  It's not a big deal if it doesn't, but as an example the odds are a DNS resolver in New York region would always know the DNS server IPs to go to for ".2.1.2.1.cid.example.com", because as soon as its TTL times out just one call from the 212 area-code to someone in New York would refresh it, for all future calls from 212 to New York until the TTL expires again.

But anyway, it's not like DNS doesn't already have to deal with far more than millions of queries per minute for ".com" or "google.com" or whatever.  It's just that the queries don't all happen to the same physical server.  The tree hierarchy is used to split the work-load among separate servers, and for busy nodes in the tree they're replicated among multiple physical servers too, and deployed geographically using anycast, and the DNS resolvers in the ISPs help reduce the workload by caching.

Regardless, a similar issue exists with HTTP and certs.  Whatever we decide the HTTP cache timeout is likely to be and whatever we decide the cert validity period is likely to be, affects the volume of HTTP queries to the CA; and there are still millions of calls per minute globally; and there are still DDoS issues and attacks.  Obviously some HTTP-based sites have figured out how to handle massive HTTP query volume as well, through numerous means.  The nice thing about a DNS-based approach is the vertical and horizontal scaling issues and their solutions are well-known, have been around for a long time, and are easily and cheaply achievable for any national country-code admin without all of them having to be a Google or Facebook.

> versus the number of CRLs that would need to go out.

Ahh, ok I see what you're getting at.  So you're thinking if the cert validity time was long, it could be cached for a long time and reduce query rates, at the expense of possibly enormous CRLs.  OK, but who would be doing the caching, and who would be checking and storing the CRL?

I mean we're talking about a public Internet access model, so for that I've been assuming we're talking about end hosts doing the STIR-specific work.  Like a softphone or smartphone app on your mobile/PC.  In such a case, as I said before, they can choose to cache the CID Keys longer, because they can make such a decision and take the risk. (it's not the DNS layer caching them in such a case, it's the app-layer)  For example they can choose to store them longer if they're in the address book.  They can even do things like cache them for a week and refresh them only once a week, or once a month, or whatever.  That's the logical equivalent of checking a CRL once a week or month or whatever, except that you don't need to store the CRL or worry about its size, because whenever you get a call from someone you don't have in your address book you'll be doing a new DNS query instead of getting the cert and comparing it against a CRL.

Even an Enterprise IP-PBX could cache them longer in its application layer, though I doubt it would be a worthwhile memory vs. CPU tradeoff for it.

But the point is the caches in the ISP's, Enterprises, etc., would not be able to cache them forever, etc.

> number might be many orders of magnitude less.

I'm not sure what "number" you're referring to - the number of entries in the CRL?  

Keys really do get compromised.  Since even in a public Internet access model there will still be very large carriers holding the private keys for signing their E.164 numbers, and they'll have those keys in a limited number of servers, I think they will want to be able to revoke a large number of them.  So I think we do have to make it practical to "revoke" millions of "certs", in a reasonable timeframe, globally. (assuming each cert represents one E.164 number)

I know this sounds like doomsday talk and fear mongering.  I can't help that.  I generally avoid/ignore "what if" scenarios that have zero real chance of happening, or if they happen then far worse things would already have happened.  I try to be pragmatic as much as possible.  But I think this scenario could actually occur.

Again, it's not the reason I think CIDER in DNS is useful - it's just one additional benefit.

> If we go from, say 10,000 to 100,000 or to 1M SPs does that scale?

Oddly, yes.  I know it seems whacky, but it already scales today in SIP - that's what happens in SIP right now.  I mean if there's a need for a "web of VPNs", it implies the CID Keys can't be made publicly available, and that it needs to only be accessible by specific trusted parties.  So there's some administrative control required for which specific organizations can access what from where.  It's not just a username/password required, but actual knowledge of what legal entity is accessing it, backed up with legally binding documentation, reliable corporate contact information, and with support and monitoring and troubleshooting and all.

The administrative overhead for such control doesn't scale, no matter what the protocol being used is... not on a world-wide basis.  There would have to be a hierarchical structure of control, similar if not identical to the PSTN, whereby the administrative headache could be split-up/divided by country, and passed down to carriers.  That already happens right now, both in SIP and for things like NPAC.  NPAC provides a feed to regulated carriers over private links, and the carriers have local copies of the DB.  They in turn provide query access to it over private links to lower-tier/non-regulated carriers.  No one entity provides query access from all SPs for NPAC; nor do they do so for SIP or whatever.  (I'm generalizing, but it gets the point across)

Likewise in SIP, it's almost always interconnected using private links or some form of a VPN (IPsec, MPLS, VLAN, whatever).  It "scales" because no one entity provides SIP access from all other SPs and Enterprises world-wide.  Some of them provide in the ballpark of 100,000 SIP trunks to Enterprises, again in private VPNs, but it's not the VPN technology that makes it burdensome or untenable.  And ultimately we're talking about a SIP in-band STIR scenario, so having the STIR-DB administrative web of control follow the SIP administrative web of control isn't crazy-talk.

Having said all that, I'm hopeful that we don't need to make it a "web of VPNs".  I absolutely expect carriers to get controlled, secure access for a whole copy of the DB for their country-code anyway, so that part doesn't matter - but I'm hopeful that we can make the data sufficiently benign to be available on the public Internet too for anyone else.  Not just for the heck of it, but because I think it would make the international calling cases simpler, as well as help detect when received caller-ids should have been STIR-secured but weren't.

-hadriel

---

From: Michael Hammer <[email-masked]>
Date: Tue, 23 Jul 2013 19:39:40 +0000

The validity time of the Certs could be some reasonable timeframe, say a
year.
The CRL would not increase indefinitely, as it would only need to list certs
compromised within that period.
Older Certs would be invalidated by their dates.

You keep saying that the SPs would keep the private keys in servers for some
reason.
While they need their own keys for administrative actions,
The private keys associated with the end-user certs should not be stored.
I think you are assuming that the SP signs for the calling party.
I am assuming that the calling party signs themselves.  (SIP Internet case)

Lastly, I can summarize you last 4 paragraphs:
So long as we maintain the current hierarchy of service providers, then it
will scale.
That seems like a public policy question, so I won't go there.

Mike

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Tuesday, July 23, 2013 3:13 PM
To: Michael Hammer
Cc: [email-masked]
Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe)

On Jul 23, 2013, at 12:26 PM, Michael Hammer <[email-masked]>
wrote:

> My flooding comment was standing back and looking at the forest for 
> the trees.
> You indicated that the TTL is very small, so all the caches in the DNS 
> need to be flushed and all new calls/quries to DNS will cause the data 
> to flow from their root locations out towards the edge, again, every 
> 30 seconds.

> Since there are millions of calls per minute globally, that looks like 
> a flood of updates to me.

Not from the "root" exactly.  For example, let's assume the CIDER anchor for
the NANP is "1.cid.example.com".  The DNS caches/resolvers would know which
DNS server IPs to access for "1.cid.example.com" all the time, because
whenever its TTL expires just one call-triggered CIDER query from anyone
using the DNS resolver/cache refreshes it for all calls for everyone on that
resolver/cache, for the next TTL time period.

In fact the resolvers would even know the one for the NPA (area-code) level
because there would be sufficient frequency of calls for that to also
happen, for the NPAs that are frequently called from.  It's not a big deal
if it doesn't, but as an example the odds are a DNS resolver in New York
region would always know the DNS server IPs to go to for
".2.1.2.1.cid.example.com", because as soon as its TTL times out just one
call from the 212 area-code to someone in New York would refresh it, for all
future calls from 212 to New York until the TTL expires again.

But anyway, it's not like DNS doesn't already have to deal with far more
than millions of queries per minute for ".com" or "google.com" or whatever.
It's just that the queries don't all happen to the same physical server.
The tree hierarchy is used to split the work-load among separate servers,
and for busy nodes in the tree they're replicated among multiple physical
servers too, and deployed geographically using anycast, and the DNS
resolvers in the ISPs help reduce the workload by caching.

Regardless, a similar issue exists with HTTP and certs.  Whatever we decide
the HTTP cache timeout is likely to be and whatever we decide the cert
validity period is likely to be, affects the volume of HTTP queries to the
CA; and there are still millions of calls per minute globally; and there are
still DDoS issues and attacks.  Obviously some HTTP-based sites have figured
out how to handle massive HTTP query volume as well, through numerous means.
The nice thing about a DNS-based approach is the vertical and horizontal
scaling issues and their solutions are well-known, have been around for a
long time, and are easily and cheaply achievable for any national
country-code admin without all of them having to be a Google or Facebook.

> versus the number of CRLs that would need to go out.

Ahh, ok I see what you're getting at.  So you're thinking if the cert
validity time was long, it could be cached for a long time and reduce query
rates, at the expense of possibly enormous CRLs.  OK, but who would be doing
the caching, and who would be checking and storing the CRL?

I mean we're talking about a public Internet access model, so for that I've
been assuming we're talking about end hosts doing the STIR-specific work.
Like a softphone or smartphone app on your mobile/PC.  In such a case, as I
said before, they can choose to cache the CID Keys longer, because they can
make such a decision and take the risk. (it's not the DNS layer caching them
in such a case, it's the app-layer)  For example they can choose to store
them longer if they're in the address book.  They can even do things like
cache them for a week and refresh them only once a week, or once a month, or
whatever.  That's the logical equivalent of checking a CRL once a week or
month or whatever, except that you don't need to store the CRL or worry
about its size, because whenever you get a call from someone you don't have
in your address book you'll be doing a new DNS query instead of getting the
cert and comparing it against a CRL.

Even an Enterprise IP-PBX could cache them longer in its application layer,
though I doubt it would be a worthwhile memory vs. CPU tradeoff for it.

But the point is the caches in the ISP's, Enterprises, etc., would not be
able to cache them forever, etc.

> number might be many orders of magnitude less.

I'm not sure what "number" you're referring to - the number of entries in
the CRL?  

Keys really do get compromised.  Since even in a public Internet access
model there will still be very large carriers holding the private keys for
signing their E.164 numbers, and they'll have those keys in a limited number
of servers, I think they will want to be able to revoke a large number of
them.  So I think we do have to make it practical to "revoke" millions of
"certs", in a reasonable timeframe, globally. (assuming each cert represents
one E.164 number)

I know this sounds like doomsday talk and fear mongering.  I can't help
that.  I generally avoid/ignore "what if" scenarios that have zero real
chance of happening, or if they happen then far worse things would already
have happened.  I try to be pragmatic as much as possible.  But I think this
scenario could actually occur.

Again, it's not the reason I think CIDER in DNS is useful - it's just one
additional benefit.

> One more scale question to throw in here.  Anther thread mentions a 
> web of VPNs may be needed.

Oddly, yes.  I know it seems whacky, but it already scales today in SIP -
that's what happens in SIP right now.  I mean if there's a need for a "web
of VPNs", it implies the CID Keys can't be made publicly available, and that
it needs to only be accessible by specific trusted parties.  So there's some
administrative control required for which specific organizations can access
what from where.  It's not just a username/password required, but actual
knowledge of what legal entity is accessing it, backed up with legally
binding documentation, reliable corporate contact information, and with
support and monitoring and troubleshooting and all.

The administrative overhead for such control doesn't scale, no matter what
the protocol being used is... not on a world-wide basis.  There would have
to be a hierarchical structure of control, similar if not identical to the
PSTN, whereby the administrative headache could be split-up/divided by
country, and passed down to carriers.  That already happens right now, both
in SIP and for things like NPAC.  NPAC provides a feed to regulated carriers
over private links, and the carriers have local copies of the DB.  They in
turn provide query access to it over private links to
lower-tier/non-regulated carriers.  No one entity provides query access from
all SPs for NPAC; nor do they do so for SIP or whatever.  (I'm generalizing,
but it gets the point across)

Likewise in SIP, it's almost always interconnected using private links or
some form of a VPN (IPsec, MPLS, VLAN, whatever).  It "scales" because no
one entity provides SIP access from all other SPs and Enterprises
world-wide.  Some of them provide in the ballpark of 100,000 SIP trunks to
Enterprises, again in private VPNs, but it's not the VPN technology that
makes it burdensome or untenable.  And ultimately we're talking about a SIP
in-band STIR scenario, so having the STIR-DB administrative web of control
follow the SIP administrative web of control isn't crazy-talk.

Having said all that, I'm hopeful that we don't need to make it a "web of
VPNs".  I absolutely expect carriers to get controlled, secure access for a
whole copy of the DB for their country-code anyway, so that part doesn't
matter - but I'm hopeful that we can make the data sufficiently benign to be
available on the public Internet too for anyone else.  Not just for the heck
of it, but because I think it would make the international calling cases
simpler, as well as help detect when received caller-ids should have been
STIR-secured but weren't.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 23 Jul 2013 17:38:38 -0400

> I am assuming that the calling party signs themselves.  (SIP Internet case)

I was wondering if that was what you meant.  You're right - I assume no matter what happens, that most of the SPs will be signing for some significant portion of their subscriber calling parties.  That way they can sign for the billions of E.164 caller-id's they control, that are not smartphones, won't be upgraded, etc.  I also think they'll be signing on behalf of most Enterprise-originated calls too, for that matter.

I don't think I'm the only one with that assumption, BTW.  At the end of the day, most SIP service providers provide a service, and most of their customers expect them to do it.  Even for Enterprise cases, most Enterprises in the World don't have SIP/VoIP expertise, don't use Asterix, and don't want to deal with the details - they pay a service provider to provide phone-call-type service, and they expect to get their money's worth.  When something goes wrong, they want to be able to yell at someone else to fix it.  There are exceptions of course - for example very large corporations and companies for whom phone service is their business (e.g., call-centers), and of course there are always folks who are unique; but for most folks it's a service they use, not something they want to worry about programming.

> That seems like a public policy question, so I won't go there.

Totally.  But that's implied in the concept of not making the STIR data publicly available, isn't it?  I mean if SIP were used on the public Internet in an open manner, like email, but the STIR data was access-controlled, how would the administrative burden of access-controlling it scale even for HTTP?  It's not like writing a script to query the whole database using HTTP is that difficult.  And it's not like a username/password prevents anything - it just requires you to get a username/password.  It's not like just anybody who passes a captcha test and has a personal email account somewhere; in fact we can't even just only let "corporations" access it.  The implied problem here is we don't want to give just anyone access - only "very special" someones.  So who are the very special someones?  How does it administratively scale to have millions of very special someones, on a World-wide basis, for just one database admin/company to control?  And why wouldn't or shouldn't the STIR access-control model follow the PSTN/SIP hierarchy model, since they're the ones who are legally assigned E.164 numbers to begin with?

-hadriel

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 23 Jul 2013 18:17:45 -0400

+1   People pay for a service and contrary to popular opinion SIP/IMS is
actually a good business for service providers.   I have zero confidence
calling party is going to sign for themselves for much the same reason I
don't have a lot of confidence that we will see handsets actually doing the
validation in significant numbers. 

I pay people to run the SMTP email servers for my domain.  I expect them to
implement tools to reduce SPAM or I will just "port" my domain elsewhere. 

As for the policy questions here .. they are not going away but at least the
structure of authority  in E.164  is well known, definable, and in the case
of the US portions of the NANP the Authority to Act is considered plenary
and fully tested in the courts.   Section 251(e) [1] of the US Act for you
budding amateur teleco lawyers out there.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hadriel Kaplan
Sent: Tuesday, July 23, 2013 5:39 PM
To: Michael Hammer
Cc: [email-masked]
Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe)

On Jul 23, 2013, at 3:39 PM, Michael Hammer <[email-masked]>
wrote:

> You keep saying that the SPs would keep the private keys in servers 
> for some reason.
> While they need their own keys for administrative actions, The private 
> keys associated with the end-user certs should not be stored.

I was wondering if that was what you meant.  You're right - I assume no
matter what happens, that most of the SPs will be signing for some
significant portion of their subscriber calling parties.  That way they can
sign for the billions of E.164 caller-id's they control, that are not
smartphones, won't be upgraded, etc.  I also think they'll be signing on
behalf of most Enterprise-originated calls too, for that matter.

I don't think I'm the only one with that assumption, BTW.  At the end of the
day, most SIP service providers provide a service, and most of their
customers expect them to do it.  Even for Enterprise cases, most Enterprises
in the World don't have SIP/VoIP expertise, don't use Asterix, and don't
want to deal with the details - they pay a service provider to provide
phone-call-type service, and they expect to get their money's worth.  When
something goes wrong, they want to be able to yell at someone else to fix
it.  There are exceptions of course - for example very large corporations
and companies for whom phone service is their business (e.g., call-centers),
and of course there are always folks who are unique; but for most folks it's
a service they use, not something they want to worry about programming.

> So long as we maintain the current hierarchy of service providers, 
> then it will scale.

Totally.  But that's implied in the concept of not making the STIR data
publicly available, isn't it?  I mean if SIP were used on the public
Internet in an open manner, like email, but the STIR data was
access-controlled, how would the administrative burden of access-controlling
it scale even for HTTP?  It's not like writing a script to query the whole
database using HTTP is that difficult.  And it's not like a
username/password prevents anything - it just requires you to get a
username/password.  It's not like just anybody who passes a captcha test and
has a personal email account somewhere; in fact we can't even just only let
"corporations" access it.  The implied problem here is we don't want to give
just anyone access - only "very special" someones.  So who are the very
special someones?  How does it administratively scale to have millions of
very special someones, on a World-wide basis, for just one database
admin/company to control?  And why wouldn't or shouldn't the ST  IR
access-control model follow the PSTN/SIP hierarchy model, since they're the
ones who are legally assigned E.164 numbers to begin with?

-hadriel

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 24 Jul 2013 01:26:41 +0000

I've been arguing that we hedge our bets too, but perhaps that we hedge
them even more than you consider below. (Forgive me that I haven't closely
tracked your tight loop with Mike Hammer, in case it sheds any light I
miss here.)

RFC4474 (/RFC4474bis) doesn't restrict access to certificates to HTTP
fetches. RFC4474 is pretty agnostic about how you get certs. We talked
about certs being included in SIP messages, so they'd arrive along with
the signature. We talked about using SIP itself to fetch them, via
SUBSCRIBE. We considered cases where verifiers had access to caches, or
even local cert stores. At the time we were doing RFC4474, HTTP seemed
like the right thing to hype for a number of reasons, so we encouraged it.
But the URL in Identity-Info is just supposed to be a helpful suggestion,
not the sole and authoritative means of access to certs. For the STIR
case, however, that hint might be useful to disambiguate for verifiers
which authority signed a SIP request, when there are multiple authorities
for a single number (the function the CIDER "public key index value" would
serve, if I understand correctly).

Part of the reason I think we're all talking past each other here is that
certs are relatively self-contained documents, and you could get them in a
number of ways, and I don't think there's any pressing need for us to
restrict those ways. For DNS proposals (if they don't just stick CA certs
in the DNS), on the other hand, the way you get a credential is
inextricably coupled to the semantics of the credential itself, which is
why the CIDER proposal isn't just a protocol, it's a whole deployment
architecture. The credentials lose any semantics if they are divorced from
the deployment environment you're supposed to fetch them from. All
credentials must be uploaded through that central service and all
credentials must be downloaded from its (distributed) deployment.

There doesn't need to be a "national authority" cloud service that manages
access to certs in this way. The reason you trust a cert isn't because you
downloaded it from the right place, it's because you trust the trust
anchor that signed the cert. This isn't about HTTP - it doesn't matter if
you found the cert lying on the ground. This is why I don't understand the
need for "hard cider," or indeed why it would be important for a
verification service to be able to derive a single canonical location from
which it will download a cert by studying the originating number alone. I
kind of see why this is important for a DNS-based solution (though the
harm DNS URI Identity-Info would do there isn't clear to me - if it points
to something you don't trust, don't trust it), but not for a cert-based
solution. If you could, for example, just receive the cert in-band with
the request, that would seem to obviate the need to go ask anyone for it.

I'm a bit unsure as well of the high-level structure of the arguments
below, effectively that carriers are the only sorts of verifiers that
matter, and that carriers probably can't use anything other than DNS.
Carriers do matter, and so do enterprises, and so do endpoints, as
potential verifiers. Of course it's true that carriers use DNS, as do
enterprises and endpoints. But none of them perform anything like the STIR
in-band verifier function today, and new code will have to be written and
new stuff deployed to make this happen - arguing that this has to be the
same stuff that's used for an unrelated existing function in the network
just doesn't persuade, given the huge differences in usage. I don't think
it would be unreasonable for DNS to play a role in credential delivery to
verifiers, for environments where it makes sense. I don't see how this
proposed use of the DNS has some decisive advantage over certificates,
though. This makes me want to hedge bets from the start. I think the
flexibility of something like Identity-Info is a way to approach that.

Jon Peterson
Neustar, Inc.

On 7/21/13 8:50 AM, "Hadriel Kaplan" <[email-masked]> wrote:

>
>I've been thinking about your questions and it occurred to me we may be
>talking past each other, or I'm not being clear enough.  It's hard to
>discuss some of this stuff in email, but anyway let me try a different
>tack...
>
>So far, there is one relatively concrete proposal for how HTTP would be
>used: RFC4474 or 4474bis, which use certs signed by someone, and
>indicates where to get the cert in an HTTP URL encoded in the SIP message
>Identity-Info header.  That model has a whole host of issues, and if by
>"HTTP" you mean that model, then we could drill-down on the practical
>problems I believe it would have.
>
>There is another way it could work using HTTP, which is essentially to
>copy the CIDER proposal but replace the DNS query-answer with HTTP
>query-answer.  The verifier would generate its own HTTP URL to resolve,
>based on the received identity information in SIP, and we'd define how it
>does that, what the cert model and encoding would be, how it gets secured
>redirection, how it times out cached copies, how to get the cert signer's
>cert, how to time that out, etc.  Let's call such a model "HARD CIDER",
>for "Http-based Access of Registry Data" or some such.[1]
>
>For a Hard Cider model to be used in a public Internet access model, we'd
>still be relying on DNS and DNSSEC, to perform resolution of the HTTP URL
>in a secure manner.  And using a generated HTTP URL implies the national
>registries are deployed as a Google/Facebook/Amazon type cloudy
>infrastructure with internal horizontal scaling technologies, etc.  But
>let's ignore that for now.
>
>The bigger problem is the target user environment: where we expect to be
>using this stuff, in carriers.  In practice, HTTP isn't frequently used
>by real-time call-handling network devices in most carriers.  It is used
>by the carrier as a corporation of course, in various other
>areas/groups/functions; and it's used in some call-control cases, usually
>by application servers providing features for specific users or calls, in
>specific scenarios.  It's far less common to have it used for every call,
>and essentially never gets used by SBCs or X-CSCFs on an every-call
>basis.  There are a variety of practical reasons for that, but it doesn't
>really matter why.  What matters is it would be a barrier to
>deployability and adoption, in the real world, if we chose it.
>
>Arguably, DIAMETER is a far more common protocol for many carriers to use
>for this type of stuff than HTTP or even DNS.  DIAMETER has its own
>challenges in actual carrier deployments, mostly around scalability and
>manageability, but we couldn't pick DIAMETER anyway because it's only
>used in some carriers and not all carriers, and rarely used by anyone
>else.
>
>As a protocol, DNS happens to be used by everyone - it's only used as
>private ENUM by some carriers not all obviously, but virtually all of
>them use DNS for at least hostname resolution, even internally.  And DNS
>client implementation happens to be available in code in all systems,
>whether it be SBCs or X-CSCFs or app servers or whatever; and its
>performance, scalability and manageability characteristics happen to be
>really good in actual carrier deployments.
>
>Having said all that, another way we could go in STIR is to just hedge
>our bets and define multiple protocols: DNS, HTTP, and maybe even
>DIAMETER.  To do that, though, it still has to be deployable as DNS,
>still have to be based on the verifier generating the URL and not have it
>sent by the originator, still have to specify the caching and clearing
>behavior, still have to support both a centralized and distributed model
>of database deployment for numbers, etc.  We've done that sort of hedging
>before in the IETF, rarely - it's a LOT more work, obviously, but it lets
>the market decide for itself what to do.
>
>If we do hedge our bets, however, I believe the most straight-forward way
>to actually do that would be to define the DNS one *first*, and then
>figure out the HTTP or DIAMETER mechanics required for doing the same
>things accessing stuff from a deployed DNS database infrastructure.
>That's because DNS as a protocol already defines the semantics,
>mechanics, and database structure; and if its used in a public Internet
>access manner then it's The Public DNS.  So a use of HTTP or DIAMETER
>would need to access it and follow its behavior.  And that has some
>bizarre deployment expectations for all parties, for example for
>international call scenarios, or for an email-style identity model.
>
>A more reasonable approach might be to define the DNS model, and then
>only define how an HTTP or DIAMETER access to the local DNS resolver
>could also work, where the verifier can only be a stub.  That's still a
>lot of work, and still involves localhost caching rules and such, but at
>least it constrains the problem somewhat.
>
>-hadriel
>[1] I don't use the term "hard" to mean it will be hard, but rather
>because "hard cider" happens to be a specific form of the drink known as
>cider. :)
>
>
>>> (1) A standard DNS hierarchy, with caching, but no synchronization. In
>>>that case, you need short TTLs if you care about revocation. With short
>>>TTLs, you get one country-level RTT for every query, even assuming no
>>>packet loss.
>> 
>> By "one country-level RTT for every query", do you mean you get one RTT
>>on average for every call, and the RTT is likely not long on average
>>because it's to a server in your geographic country?  If so, sure that
>>would likely be the case for public internet access queriers.  One RTT
>>on average, for a public Internet access model is pretty good, BTW.
>>HTTP really won't have one RTT for such public Internet access, not in
>>actual practice if this Identity-Info URL model is used.  Again, this is
>>not CIDER's raison d'etre, but just another plus.
>> 
>> 
>> No, I really don't believe you can.  You can get them if we give up on
>>the Identity-Info URL thing, and define how HTTP would work without it,
>>how the international call thing works, and so on.  But not if the cert
>>is served on some random server indicated by the Identity-Info header.
>> 
>> 
>>> The locally-cached synchronized DNS has essentially the same overhead
>>>as the locally-cached HTTP version, since the connection is nailed down.
>> 
>> Define "overhead".  Overhead for whom?  For the verifier systems HTTP
>>is more overhead - a trivial amount if the stars align, and more if
>>reality is included in the equation; but not a massive amount
>>regardless.  For the carriers, HTTP is more cost and operational
>>overhead from a deployment perspective if reality is included, but again
>>if we ignore practical realties then it's all equal.  So sure, if all
>>carriers in all nations deploy Google or Facebook style infrastructures
>>and tweak their verifiers' TCP and HTTP implementations - all for the
>>benefit of verifying a caller-id - then we're all good-to-go. ;)
>> 
>> -hadriel
>>

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 24 Jul 2013 03:56:34 +0000

On Jul 20, 2013, at 12:34 AM, Hadriel Kaplan <[email-masked]> wrote:

>  The "traditional" and regulated carriers, MSOs, etc., are the ones who want to stop it.

I don't really agree with this. If this was true, the class 5 switch that my ISDN trunk connects to would only allow me to assert the caller ID on the ISDN trunk for numbers assigned to me. However, because I am the customer, and I like to be able to set whatever caller ID I want, and my service provider makes me happy as a customer. Many providers in the US are very happy to provide me with a ISDN trunk that allows me to set whatever caller ID I want. I will note this include the  bulk of the large carriers with good reputations, it's not just fringy operators.

I think the key thing is that carriers largely try and meet the needs of their customers. And their customs are often the people that make robo calls, as well as the people that receive them.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 24 Jul 2013 05:33:41 +0100

> implement tools to reduce SPAM or I will just "port" my domain elsewhere.

This highlights a core bit of confusion in this discussion.  It concerns 
the non-normative, architectural difference between may and must.

If the technology permits signing and validating use by end-systems 
(users, enterprises, whatever), then they have the /option/ of doing 
STIR.  The fact that operational convenience makes is strongly likely 
that most/all use will be by intermediary systems such as service 
providers, rather than end-systems, is only that: operational choice.

If the design restricts use to providers, then there is no opportunity 
for enterprises or end-users to sign or validate.

Believe it or not, some individuals and some enterprises still run their 
own SMTP servers.  That folk like you and me don't does not make it 
reasonable to prevent others from doing it.

d/

ps. DKIM is an example of this choice; it's almost exclusively deployed 
amongst service hosts; but in fact the architecture permits operation 
with user agents.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 24 Jul 2013 11:44:28 +0100

Hi Jon,

I think you make some reasonable points below, but wanted to
add a bit to one of 'em. I've no position on whether or not
STIR ought hedge its bets on credential format/retrieval at
the moment btw. so this is a detail, but IMO one that's not
insignificant.

On 07/24/2013 02:26 AM, Peterson, Jon wrote:
> which it will download a cert by studying the originating number alone. 

I agree that the in-band (or out of band) identifier/blob that the
verifier uses to construct the inputs to signature checking (esp.
the "right" public key) can be handled in various ways. And as you
say the blob could contain an RFC5280/X.509 certificate (chain) or
the identifier/blob could be used to retrieve a certificate (chain)
or the missing parts thereof.

However, at some point you do need to support certificate status
checking, and for certs that means OCSP or CRLs. In either case
the verifier has to do some more work and access the network to
get status information.

The tricky point is that CRLs get big and unwieldy, or else are
very complex (e.g. delta CRLs [1], the support for which is I
think highly variable and maybe sometimes flakey). If you take
the OCSP route then the verifier is making a status check call
to the network for each signature it verifies (more-or-less),
at which point DKIM-like models start to look quite similar.

So I hope that the STIR wg, when formed, delves deeply into this
question. I doubt that the BoF or any proposal at the BoF
can really provide final answers (I include "hedge your bets"
as a proposed answer there btw).

S.

[1] http://tools.ietf.org/html/rfc5280#section-5.2.4

> I

---

From: Brian Rosen <[email-masked]>
Date: Wed, 24 Jul 2013 08:47:49 -0400

I think enterprise PBXs will assert and check identity if we provide the right tools.  That would mean automated mechanisms to acquire credentials.  If we provided provisioning mechanisms that loaded authorized numbers and credentials from the service provider who delegated the numbers, and we provided an automated way for the PBX to get the public keys to verify, I think many PBX vendors would implement that.  If it was no-touch, which I think it could be, I think that it would be a very common deployment model.

At some point, those same protocols could be extended to endpoints.  I don't see that happening real soon perhaps, but I think it will happen.

This probably takes work beyond IETF efforts (SIPforum perhaps, extensions or adjuncts to SIPconnect)

Brian

---

From: Dan York <[email-masked]>
Date: Wed, 24 Jul 2013 13:12:03 +0000

>providers, rather than end-systems, is only that: operational choice.

Agreed.  Before joining ISOC two years ago, I spent 4 years at a VoIP/IVR
application platform company providing both a cloud/hosted service and an
on-premise software solution. What I found interesting was that, at that
time anyway, the companies using on the on-premise product were often
either the very small but technically sophisticated (either a very small
company or a small project within a larger company) or the very large who
had technical staff.  In both cases they wanted to operate their own
servers on their own networks.  As a company grew there came a point where
outsourcing the service to a hosted/cloud platform made sense - and then
at some point as the company grew much larger they started to have their
own IT and developer staff and often wanted to bring the applications back
into their own data centers.  There were many exceptions to this trend, of
course, but the trend was visible.

I suspect the trend will be similar with STIR.  We'll have many
individuals and smaller entities who will run their own VoIP servers and
will want to do the signing and validation themselves.  And we'll have
very large organizations with IT and developer staff who will want to do
the signing and validation.  And the VAST majority of users will just have
their service providers do it.  As Richard noted, many will just expect
the SP to do it.

>reasonable to prevent others from doing it.

Exactly, and there will also be some network environments with high
security policies that require them to operate their own equipment and
would in this case require them to do their own signing and validating.

We need to assume in the design that the signing and validation can be
done at any point in the process, even if the operational reality will be
that in maybe 90+% of the cases all of that will be done by the service
providers.

Dan

--
Dan York
Senior Content Strategist, Internet Society
[email-masked] <mailto:[email-masked]>   +1-802-735-1624
Jabber: [email-masked] <mailto:[email-masked]>
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/deploy360/

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 24 Jul 2013 09:33:56 -0400

Good point Dave .. 

I would never suggest that the design restrict the use to service providers
only that IMHO the likely deployment scenarios would very heavily depend on
the role carriers have in the real time communications space and the known
hierarchy of authority for the numbering plan. 

What I am concerned about is that the design, at the very least, understands
the ongoing constraints in the service provider architecture and does not
propose some brand new mechanism that would be impossible to implement by
carriers in a reasonable period of time.  

-----Original Message-----
From: Dave Crocker [mailto:[email-masked]] 
Sent: Wednesday, July 24, 2013 12:34 AM
To: Richard Shockey
Cc: [email-masked]
Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe)

On 7/23/2013 11:17 PM, Richard Shockey wrote:
> I pay people to run the SMTP email servers for my domain.  I expect 
> them to implement tools to reduce SPAM or I will just "port" my domain
elsewhere.

This highlights a core bit of confusion in this discussion.  It concerns the
non-normative, architectural difference between may and must.

If the technology permits signing and validating use by end-systems (users,
enterprises, whatever), then they have the /option/ of doing STIR.  The fact
that operational convenience makes is strongly likely that most/all use will
be by intermediary systems such as service providers, rather than
end-systems, is only that: operational choice.

If the design restricts use to providers, then there is no opportunity for
enterprises or end-users to sign or validate.

Believe it or not, some individuals and some enterprises still run their own
SMTP servers.  That folk like you and me don't does not make it reasonable
to prevent others from doing it.

d/

ps. DKIM is an example of this choice; it's almost exclusively deployed
amongst service hosts; but in fact the architecture permits operation with
user agents.

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 24 Jul 2013 09:37:56 -0400

> I think the key thing is that carriers largely try and meet the needs of their customers. And their customs are often the people that make robo calls, as well as the people that receive them. 

I think we have a different concept of who the bad callers are.  My guess is in your definition is it's just a telemarketer.  To me, "telemarketers" are perfectly legal/legitimate callers.  I don't personally want to get calls from them, but that's up to a whitelist/blacklist mechanism to handle, whether it be do-not-call lists or crowd-sourced reputation lists or whatever.  To me, the bad guys are the guys generating bulk calls using *purposefully invalid* calling numbers, using Asterisk with SIP trunks to non-regulated providers.  They're using invalid calling numbers for the purpose of misleading their targets, bypassing whitelists/blacklists, etc.  I truly don't think the regulated carriers want to have those guys as their customers.

Regulated carriers allow you to assert any caller ID on an ISDN trunk because they have no real choice - they need to support the outsourced call-center and branch office call scenarios.  They need to let the PBX choose what caller ID to generate, on a call-by-call basis.  The carriers don't do it because they don't care - they do it because that's the only way they could handle that use-case in ISDN/SS7/SIP.  And it worked fine for a long time.  There *were* cases of fraud and abuse of course, but the rate was so low the carrier fraud/support departments could handle it.

Regardless, that stuff doesn't really matter.  We need their help, if we want this thing to be widely deployed and helpful/useful, for more than society's elite.  I think the carriers want to help, if for no other reason than to avoid government mandate. (I honestly think they want to do it for better reasons than that, fwiw)

-hadriel

---

From: Michael Hammer <[email-masked]>
Date: Wed, 24 Jul 2013 14:07:42 +0000

Don't forget though that CRL checks are an Idle state activity, not a per
call setup delaying activity.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stephen Farrell
Sent: Wednesday, July 24, 2013 6:44 AM
To: Peterson, Jon
Cc: [email-masked] Mail List; Hadriel Kaplan; Henning Schulzrinne
Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack model

Hi Jon,

I think you make some reasonable points below, but wanted to add a bit to
one of 'em. I've no position on whether or not STIR ought hedge its bets on
credential format/retrieval at the moment btw. so this is a detail, but IMO
one that's not insignificant.

On 07/24/2013 02:26 AM, Peterson, Jon wrote:
> 
> I've been arguing that we hedge our bets too, but perhaps that we 
> hedge them even more than you consider below. (Forgive me that I 
> haven't closely tracked your tight loop with Mike Hammer, in case it 
> sheds any light I miss here.)
> 
> about certs being included in SIP messages, so they'd arrive along 
> with the signature. We talked about using SIP itself to fetch them, 
> via SUBSCRIBE. We considered cases where verifiers had access to 
> caches, or even local cert stores. At the time we were doing RFC4474, 
> HTTP seemed like the right thing to hype for a number of reasons, so we
encouraged it.
> But the URL in Identity-Info is just supposed to be a helpful 
> suggestion, not the sole and authoritative means of access to certs. 
> For the STIR case, however, that hint might be useful to disambiguate 
> for verifiers which authority signed a SIP request, when there are 
> multiple authorities for a single number (the function the CIDER 
> "public key index value" would serve, if I understand correctly).
> 
> Part of the reason I think we're all talking past each other here is 
> that certs are relatively self-contained documents, and you could get 
> them in a number of ways, and I don't think there's any pressing need 
> for us to restrict those ways. For DNS proposals (if they don't just 
> stick CA certs in the DNS), on the other hand, the way you get a 
> credential is inextricably coupled to the semantics of the credential 
> itself, which is why the CIDER proposal isn't just a protocol, it's a 
> whole deployment architecture. The credentials lose any semantics if 
> they are divorced from the deployment environment you're supposed to 
> fetch them from. All credentials must be uploaded through that central 
> service and all credentials must be downloaded from its (distributed)
deployment.
> 
> There doesn't need to be a "national authority" cloud service that 
> manages access to certs in this way. The reason you trust a cert isn't 
> because you downloaded it from the right place, it's because you trust 
> the trust anchor that signed the cert. This isn't about HTTP - it 
> doesn't matter if you found the cert lying on the ground. This is why 
> I don't understand the need for "hard cider," or indeed why it would 
> be important for a verification service to be able to derive a single 
> canonical location from which it will download a cert by studying the
originating number alone.

I agree that the in-band (or out of band) identifier/blob that the verifier
uses to construct the inputs to signature checking (esp.
the "right" public key) can be handled in various ways. And as you say the
blob could contain an RFC5280/X.509 certificate (chain) or the
identifier/blob could be used to retrieve a certificate (chain) or the
missing parts thereof.

However, at some point you do need to support certificate status checking,
and for certs that means OCSP or CRLs. In either case the verifier has to do
some more work and access the network to get status information.

The tricky point is that CRLs get big and unwieldy, or else are very complex
(e.g. delta CRLs [1], the support for which is I think highly variable and
maybe sometimes flakey). If you take the OCSP route then the verifier is
making a status check call to the network for each signature it verifies
(more-or-less), at which point DKIM-like models start to look quite similar.

So I hope that the STIR wg, when formed, delves deeply into this question. I
doubt that the BoF or any proposal at the BoF can really provide final
answers (I include "hedge your bets"
as a proposed answer there btw).

S.

> harm DNS URI Identity-Info would do there isn't clear to me - if it 
> points to something you don't trust, don't trust it), but not for a 
> cert-based solution. If you could, for example, just receive the cert 
> in-band with the request, that would seem to obviate the need to go ask
anyone for it.
> enterprises and endpoints. But none of them perform anything like the 
> STIR in-band verifier function today, and new code will have to be 
> written and new stuff deployed to make this happen - arguing that this 
> has to be the same stuff that's used for an unrelated existing 
> function in the network just doesn't persuade, given the huge 
> differences in usage. I don't think it would be unreasonable for DNS 
> to play a role in credential delivery to verifiers, for environments 
> where it makes sense. I don't see how this proposed use of the DNS has 
> some decisive advantage over certificates, though. This makes me want 
> to hedge bets from the start. I think the flexibility of something like
Identity-Info is a way to approach that.
>> I've been thinking about your questions and it occurred to me we may 
>> be talking past each other, or I'm not being clear enough.  It's hard 
>> to discuss some of this stuff in email, but anyway let me try a 
>> different tack...
>>
>> indicates where to get the cert in an HTTP URL encoded in the SIP 
>> message Identity-Info header.  That model has a whole host of issues, 
>> and if by "HTTP" you mean that model, then we could drill-down on the 
>> practical problems I believe it would have.
>>
>> There is another way it could work using HTTP, which is essentially 
>> to copy the CIDER proposal but replace the DNS query-answer with HTTP 
>> query-answer.  The verifier would generate its own HTTP URL to 
>> resolve, based on the received identity information in SIP, and we'd 
>> define how it does that, what the cert model and encoding would be, 
>> how it gets secured redirection, how it times out cached copies, how 
>> to get the cert signer's cert, how to time that out, etc.  Let's call 
>> such a model "HARD CIDER", for "Http-based Access of Registry Data" 
>> or some such.[1]
>>
>> For a Hard Cider model to be used in a public Internet access model, 
>> we'd still be relying on DNS and DNSSEC, to perform resolution of the 
>> HTTP URL in a secure manner.  And using a generated HTTP URL implies 
>> the national registries are deployed as a Google/Facebook/Amazon type 
>> cloudy infrastructure with internal horizontal scaling technologies, 
>> etc.  But let's ignore that for now.
>>
>> The bigger problem is the target user environment: where we expect to 
>> be using this stuff, in carriers.  In practice, HTTP isn't frequently 
>> used by real-time call-handling network devices in most carriers.  It 
>> is used by the carrier as a corporation of course, in various other 
>> areas/groups/functions; and it's used in some call-control cases, 
>> usually by application servers providing features for specific users 
>> or calls, in specific scenarios.  It's far less common to have it 
>> used for every call, and essentially never gets used by SBCs or 
>> X-CSCFs on an every-call basis.  There are a variety of practical 
>> reasons for that, but it doesn't really matter why.  What matters is 
>> it would be a barrier to deployability and adoption, in the real world,
if we chose it.
>>
>> Arguably, DIAMETER is a far more common protocol for many carriers to 
>> use for this type of stuff than HTTP or even DNS.  DIAMETER has its 
>> own challenges in actual carrier deployments, mostly around 
>> scalability and manageability, but we couldn't pick DIAMETER anyway 
>> because it's only used in some carriers and not all carriers, and 
>> rarely used by anyone else.
>>
>> them use DNS for at least hostname resolution, even internally.  And 
>> DNS client implementation happens to be available in code in all 
>> systems, whether it be SBCs or X-CSCFs or app servers or whatever; 
>> and its performance, scalability and manageability characteristics 
>> happen to be really good in actual carrier deployments.
>>
>> Having said all that, another way we could go in STIR is to just 
>> hedge our bets and define multiple protocols: DNS, HTTP, and maybe 
>> even DIAMETER.  To do that, though, it still has to be deployable as 
>> DNS, still have to be based on the verifier generating the URL and 
>> not have it sent by the originator, still have to specify the caching 
>> and clearing behavior, still have to support both a centralized and 
>> distributed model of database deployment for numbers, etc.  We've 
>> done that sort of hedging before in the IETF, rarely - it's a LOT 
>> more work, obviously, but it lets the market decide for itself what to
do.
>>
>> If we do hedge our bets, however, I believe the most straight-forward 
>> way to actually do that would be to define the DNS one *first*, and 
>> then figure out the HTTP or DIAMETER mechanics required for doing the 
>> same things accessing stuff from a deployed DNS database infrastructure.
>> mechanics, and database structure; and if its used in a public 
>> Internet access manner then it's The Public DNS.  So a use of HTTP or 
>> DIAMETER would need to access it and follow its behavior.  And that 
>> has some bizarre deployment expectations for all parties, for example 
>> for international call scenarios, or for an email-style identity model.
>>
>> could also work, where the verifier can only be a stub.  That's still 
>> a lot of work, and still involves localhost caching rules and such, 
>> but at least it constrains the problem somewhat.
>>
>> -hadriel
>> because "hard cider" happens to be a specific form of the drink known 
>> as cider. :)
>>
>>
>> On Jul 20, 2013, at 8:13 PM, Hadriel Kaplan 
>> <[email-masked]>
>> wrote:
>>
>>>
>>>> (1) A standard DNS hierarchy, with caching, but no synchronization. 
>>>> In that case, you need short TTLs if you care about revocation. 
>>>> With short TTLs, you get one country-level RTT for every query, 
>>>> even assuming no packet loss.
>>>
>>> By "one country-level RTT for every query", do you mean you get one 
>>> RTT on average for every call, and the RTT is likely not long on 
>>> average because it's to a server in your geographic country?  If so, 
>>> sure that would likely be the case for public internet access 
>>> queriers.  One RTT on average, for a public Internet access model is
pretty good, BTW.
>>> HTTP really won't have one RTT for such public Internet access, not 
>>> in actual practice if this Identity-Info URL model is used.  Again, 
>>> this is not CIDER's raison d'etre, but just another plus.
>>>
>>>
>>> No, I really don't believe you can.  You can get them if we give up 
>>> on the Identity-Info URL thing, and define how HTTP would work 
>>> without it, how the international call thing works, and so on.  But 
>>> not if the cert is served on some random server indicated by the
Identity-Info header.
>>>
>>>
>>>> The locally-cached synchronized DNS has essentially the same 
>>>> overhead as the locally-cached HTTP version, since the connection is
nailed down.
>>>
>>> Define "overhead".  Overhead for whom?  For the verifier systems 
>>> HTTP is more overhead - a trivial amount if the stars align, and 
>>> more if reality is included in the equation; but not a massive 
>>> amount regardless.  For the carriers, HTTP is more cost and 
>>> operational overhead from a deployment perspective if reality is 
>>> included, but again if we ignore practical realties then it's all 
>>> equal.  So sure, if all carriers in all nations deploy Google or 
>>> Facebook style infrastructures and tweak their verifiers' TCP and 
>>> HTTP implementations - all for the benefit of verifying a caller-id 
>>> - then we're all good-to-go. ;)
>>>
>>> -hadriel
>>>

---

From: Michael Hammer <[email-masked]>
Date: Wed, 24 Jul 2013 14:22:04 +0000

So, you are saying that any DNS-based solution would have to be publicly
available?

 Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Richard Shockey
Sent: Wednesday, July 24, 2013 9:34 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe)

 Good point Dave .. 

-----Original Message-----
From: Dave Crocker [mailto:[email-masked]]
Sent: Wednesday, July 24, 2013 12:34 AM
To: Richard Shockey
Cc: [email-masked]
Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe)

elsewhere.

d/

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 24 Jul 2013 16:04:32 +0100

> call setup delaying activity.

That could be the case, or maybe it isn't, I don't know.

But full CRLs can easily get BIG, even if only consumed
periodically. And you'd still need some models of how
big in order to know if that's ok or not. So again, there
is work to be done to figure that out for this application.

Think of all this public key management like its a balloon.
You can squeeze one bit to fit what you want but another
will then protrude, possibly causing the whole thing to
burst. (I guess since this is RAI that should be a liquid
filled balloon, but I hope the analogy is clear enough:-)

S.

---

From: Michael Hammer <[email-masked]>
Date: Wed, 24 Jul 2013 15:22:05 +0000

Sure.  I am open to other ideas folks might have.

I was thinking that one is proactive per call, and reactive for revocation, 
While the other option is reactive per call, and proactive for revocation.

Would you consider CIDER as the mother of all Certs and CRLs all wrapped
into one?

Mike

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Wednesday, July 24, 2013 11:05 AM
To: Michael Hammer
Cc: [email-masked]; [email-masked]; [email-masked];

On 07/24/2013 03:07 PM, Michael Hammer wrote:
> Don't forget though that CRL checks are an Idle state activity, not a 
> per call setup delaying activity.

But full CRLs can easily get BIG, even if only consumed periodically. And
you'd still need some models of how big in order to know if that's ok or
not. So again, there is work to be done to figure that out for this
application.

Think of all this public key management like its a balloon.
You can squeeze one bit to fit what you want but another will then protrude,
possibly causing the whole thing to burst. (I guess since this is RAI that
should be a liquid filled balloon, but I hope the analogy is clear enough:-)

S.

> I think you make some reasonable points below, but wanted to add a bit 
> to one of 'em. I've no position on whether or not STIR ought hedge its 
> bets on credential format/retrieval at the moment btw. so this is a 
> detail, but IMO one that's not insignificant.
> 
> 
>> fetches. RFC4474 is pretty agnostic about how you get certs. We 
>> talked about certs being included in SIP messages, so they'd arrive 
>> along with the signature. We talked about using SIP itself to fetch 
>> them, via SUBSCRIBE. We considered cases where verifiers had access 
>> to caches, or even local cert stores. At the time we were doing 
>> RFC4474, HTTP seemed like the right thing to hype for a number of 
>> reasons, so we
> encouraged it.
>> fetch them from. All credentials must be uploaded through that 
>> central service and all credentials must be downloaded from its 
>> (distributed)
> deployment.
>>
>> manages access to certs in this way. The reason you trust a cert 
>> isn't because you downloaded it from the right place, it's because 
>> you trust the trust anchor that signed the cert. This isn't about 
>> HTTP - it doesn't matter if you found the cert lying on the ground. 
>> This is why I don't understand the need for "hard cider," or indeed 
>> why it would be important for a verification service to be able to 
>> derive a single canonical location from which it will download a cert 
>> by studying the
> the "right" public key) can be handled in various ways. And as you say 
> the blob could contain an RFC5280/X.509 certificate (chain) or the 
> checking, and for certs that means OCSP or CRLs. In either case the 
> verifier has to do some more work and access the network to get status
information.
> 
> The tricky point is that CRLs get big and unwieldy, or else are very 
> complex (e.g. delta CRLs [1], the support for which is I think highly 
> variable and maybe sometimes flakey). If you take the OCSP route then 
> the verifier is making a status check call to the network for each 
> signature it verifies (more-or-less), at which point DKIM-like models
start to look quite similar.
> question. I doubt that the BoF or any proposal at the BoF can really 
> provide final answers (I include "hedge your bets"
>> kind of see why this is important for a DNS-based solution (though 
>> the harm DNS URI Identity-Info would do there isn't clear to me - if 
>> it points to something you don't trust, don't trust it), but not for 
>> a cert-based solution. If you could, for example, just receive the 
>> cert in-band with the request, that would seem to obviate the need to 
>> go ask
> anyone for it.
>>
>> written and new stuff deployed to make this happen - arguing that 
>> this has to be the same stuff that's used for an unrelated existing 
>> where it makes sense. I don't see how this proposed use of the DNS 
>> has some decisive advantage over certificates, though. This makes me 
>> want to hedge bets from the start. I think the flexibility of 
>> something like
>>> be talking past each other, or I'm not being clear enough.  It's 
>>> hard to discuss some of this stuff in email, but anyway let me try a 
>>> different tack...
>>>
>>> message Identity-Info header.  That model has a whole host of 
>>> issues, and if by "HTTP" you mean that model, then we could 
>>> drill-down on the practical problems I believe it would have.
>>>
>>> to copy the CIDER proposal but replace the DNS query-answer with 
>>> HTTP query-answer.  The verifier would generate its own HTTP URL to 
>>> to get the cert signer's cert, how to time that out, etc.  Let's 
>>> call such a model "HARD CIDER", for "Http-based Access of Registry Data"
>>> or some such.[1]
>>>
>>> we'd still be relying on DNS and DNSSEC, to perform resolution of 
>>> the HTTP URL in a secure manner.  And using a generated HTTP URL 
>>> implies the national registries are deployed as a 
>>> Google/Facebook/Amazon type cloudy infrastructure with internal 
>>> horizontal scaling technologies, etc.  But let's ignore that for now.
>>>
>>> The bigger problem is the target user environment: where we expect 
>>> to be using this stuff, in carriers.  In practice, HTTP isn't 
>>> frequently used by real-time call-handling network devices in most 
>>> carriers.  It is used by the carrier as a corporation of course, in 
>>> various other areas/groups/functions; and it's used in some 
>>> call-control cases, usually by application servers providing 
>>> features for specific users or calls, in specific scenarios.  It's 
>>> far less common to have it used for every call, and essentially 
>>> never gets used by SBCs or X-CSCFs on an every-call basis.  There 
>>> are a variety of practical reasons for that, but it doesn't really 
>>> matter why.  What matters is it would be a barrier to deployability 
>>> and adoption, in the real world,
> if we chose it.
>>>
>>> Arguably, DIAMETER is a far more common protocol for many carriers 
>>> to use for this type of stuff than HTTP or even DNS.  DIAMETER has 
>>> its own challenges in actual carrier deployments, mostly around 
>>> As a protocol, DNS happens to be used by everyone - it's only used 
>>> as private ENUM by some carriers not all obviously, but virtually 
>>> all of them use DNS for at least hostname resolution, even 
>>> internally.  And DNS client implementation happens to be available 
>>> in code in all systems, whether it be SBCs or X-CSCFs or app servers 
>>> or whatever; and its performance, scalability and manageability 
>>> characteristics happen to be really good in actual carrier deployments.
>>>
>>> not have it sent by the originator, still have to specify the 
>>> caching and clearing behavior, still have to support both a 
>>> centralized and distributed model of database deployment for 
>>> numbers, etc.  We've done that sort of hedging before in the IETF, 
>>> rarely - it's a LOT more work, obviously, but it lets the market 
>>> decide for itself what to
> do.
>>>
>>> If we do hedge our bets, however, I believe the most 
>>> straight-forward way to actually do that would be to define the DNS 
>>> one *first*, and then figure out the HTTP or DIAMETER mechanics 
>>> required for doing the same things accessing stuff from a deployed DNS
database infrastructure.
>>> Internet access manner then it's The Public DNS.  So a use of HTTP 
>>> or DIAMETER would need to access it and follow its behavior.  And 
>>> that has some bizarre deployment expectations for all parties, for 
>>> example for international call scenarios, or for an email-style identity
model.
>>>
>>> A more reasonable approach might be to define the DNS model, and 
>>> then only define how an HTTP or DIAMETER access to the local DNS 
>>> resolver could also work, where the verifier can only be a stub.  
>>> That's still a lot of work, and still involves localhost caching 
>>> rules and such, but at least it constrains the problem somewhat.
>>>
>>> -hadriel
>>> because "hard cider" happens to be a specific form of the drink 
>>> known as cider. :)
>>>
>>>
>>>> average because it's to a server in your geographic country?  If 
>>>> so, sure that would likely be the case for public internet access

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 24 Jul 2013 11:36:08 -0400

I think they're both saying that whatever mechanisms we choose, it should be an operational choice/decision how to deploy it.  Rich's point (and mine) is that while that's of course true, we also have to keep in mind who the likely target operators of it will be, and try to fit it in something they can do in practice.

To your question: I was originally worried that using DNS for STIR would require us to make the data publicly available, and put it in The Public Internet DNS - in some ways I prefer and hope that it be publicly available, because I think it will be safe to do that and it has some additional benefits if it is publicly accessible, but I recognize that it's not my/our decision to make.  So the CIDER proposal allows it to be deployed however the national admins want for themselves.  The same could be true of an HTTP-based solution of course.

-hadriel

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 24 Jul 2013 16:45:14 +0100

> Would you consider CIDER as the mother of all Certs and CRLs all wrapped

No. I don't think "mother of all" anything applies.

I think its DKIM-like with all the associated pros and cons.

S.

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 24 Jul 2013 12:09:30 -0400

Commenting on your email in reverse-order...

> matter, and that carriers probably can't use anything other than DNS.

I didn't say that - I said they're an important (even vital) target deployer/adopter of STIR, and that requiring them to use HTTP for the querying would be a barrier to adoption, and that I think we need to avoid adding barriers to adoption by the target users/operators.

> new stuff deployed to make this happen

My goal is to reduce the amount of "new stuff" that needs to be deployed as much as possible.  Upgrading software is one thing, but deploying entire classes of new systems is a much higher barrier to adoption.  This stuff really does matter.  The effort, time and cost required for software upgrades vs. new systems is enormously different.  End-users can upgrade apps or download new ones, and Enterprises can too for that matter, without much difficulty.  But getting carriers to adopt something new is a whole different ballgame.  You know that.  The impacts of scale, capacity, troubleshooting, and management are on a different order of magnitude for carriers.

> - arguing that this has to be the
> just doesn't persuade, given the huge differences in usage.

On the contrary, some carriers use private ENUM/DNS for things eerily similar to, and directly related to, STIR.  They use them for CNAM lookups, which is arguably the exact same point in time and place where they'd be verifying a caller-id, right before a CNAM lookup, to verify they're querying for the right CNAM.  In fact, the local physical CNAM servers being queried could respond with both data records at the same time in the same DNS answer, if they're tied into the STIR database.  For example, you query it for the STIR DNS query key, and it responds with the TXT RR public key as well as a calling-name NAPTR in the same answer.  Even if it takes two separate DNS queries, but to the same server, that makes it easier to deploy and manage for the carriers.

So there is existing proof contradicting the claim: "none of them perform anything like STIR" today.

Even the deployed server vendors used for routing and number portability, which already either have the full NPAC copy themselves or perform some other protocol query to it in the back-end, would be likely candidates for being the same servers queried by verifiers for STIR data; likewise for the deployed systems that query them.  And some of those use private ENUM already today.  Far more than use HTTP, afaict.

-hadriel

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 24 Jul 2013 22:35:49 +0000

Understood that there are trade-offs in maintaining cert freshness, just
as there are trade-offs in maintaining the freshness of DNS records
(caching, TTLs, etc.) I don't mean to suggest that there's no need for a
function like OCSP, nor that if you had to do OCSP, this wouldn't have
similar properties to making a DNS query. I guess that when you try to
engineer either approach to the same operational requirements, in terms of
how fresh credentials must be and how often you check them, they're going
to end up with some very similar properties. This is kind of a worst-case
scenario for reaching consensus, though, because it's always hardest to
choose between things that are similar. That¹s why I believe a beauty
contest, or a food fight, would take a huge amount of effort, possibly
wasted effort given that market forces could find a place for either or
both.

There are subtle differences though, I think, and they have a lot to do
with how well delegation models map to the authority structures of the
telephone network, and how we scope credentials and aggregate authority.
Some of this is relevant to freshness, even. This gets into questions that
are way beyond BoF scope and well into the proposed working group, but
imagine a Carrier A wants to have a single credential that can sign for
all their numbers (and say Carrier A isn't worried about what verifiers
could analyze from that). Imagine they control many large discontinuous
blocks of numbers. We could build a DNS service that synthesizes responses
and returns to verifiers the same public key for all the numbers that
Carrier A is authoritative for. The caching properties of that approach,
though, could be very different than having a single public cert that has
that entire number range under its authority. Now imagine that instead of
just one such credential, Carrier A may want five, or fifteen, or fifty,
all with the same authority, that it wants to put into different signing
systems in different parts of their network. From my experience dealing
with the back office of telephone number authority services, I'd say these
are quite plausible requirements.

I'm not saying I have all the answers for how to approach scenarios like
that, just that these are the kinds of things we would be taking into
account if we chartered work in this credential space. For the level of
discussion to have at the BoF, I think it's sufficient for us to say that
we believe there are approaches to providing authority for telephone
numbers that will work, even if we don't currently agree on any single
direction.

Jon Peterson
Neustar, Inc.

On 7/24/13 3:44 AM, "Stephen Farrell" <[email-masked]> wrote:

>>suggestion,
>>that
>>manages
>>points
>>STIR
>>>message
>>>we'd
>>>be
>>>usually
>>>use
>>>DNS
>>>way
>>>as
>>>>>In
>>>>RTT

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 24 Jul 2013 23:48:39 +0100

On 07/24/2013 11:35 PM, Peterson, Jon wrote:
>  This is kind of a worst-case
> choose between things that are similar. 

Very good point. I guess that's why the wg chairs will get the
big bucks;-) But yeah, that kind of thing has significant potential
to disrupt a wg and figuring out how to handle the difficulty
should maybe be very high priority for the wg.

OTOH, sometimes what looks like it'll be hugely controversial
turns out not to be, e.g. if folks who're very exercised on a
topic don't actually turn up to do work in the wg.

> That¹s why I believe a beauty

Possibly so.

The counter argument is two ways to do one thing is a bad outcome.
I think everyone involved in PKI still to this day regrets that we
did that with CMP and CMC about 15 years ago. And as it happens,
I'm just about to clear a DISCUSS on a draft (EST) that is arguably
only needed because of that failure then. (In which I was as
complicit as others as a co-author of rfc 2510.)

Cheers,
S.

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 25 Jul 2013 02:08:55 -0400

On Jul 23, 2013, at 9:26 PM, "Peterson, Jon" <[email-masked]> wrote:

> not the sole and authoritative means of access to certs.

The concept of ignoring the URL is so broken, I'm still in mental denial that 4474 says you can ignore it.  Considering how carefully the IESG reads my drafts for publication, I'm at a loss as to how they let 4474 through.  

> For the STIR

How does the URL string "http://foo.com/dcjovbneoc.cer" help me figure out which authority signed the request?  I'd have to retrieve the cert from that URL... and then I'd see some CA signed it, but how do I know that CA is authoritative for that E.164 number?

It's true that the purpose of the CIDER key index value is to let there be multiple public keys in-use for the same E.164, but they're all "signed" by the same "CA" - the only one truly authoritative for the E.164 number.  But more to-the-point, it provides a way for changing the public keys while SIP messages are in-flight.  Ultimately, no matter what protocol we pick, if carriers have local database copies then it will take some time for the public keys used to sign SIP messages to get propagated out.  So you need a way to change your key in-advance, still use the old key for some period of time and then switch to using the new one, and indicate on a per-SIP-message bases which of the keys you're using.

The same thing would have been true if RFC 4474 had ever seen the light of day.  So imagine if the sender was using "http://foo.com/dcjovbneoc.cer" for some period of time, and then changed to "http://foo.com/cebcuhlked.cer".  How would this work, if a verifier ignores this URL because 4474 said it was ok?

I guess I do agree with one thing you said a while back: we do indeed have to deprecate RFC 4474.  Not because we'll define something better, but because it's broken.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 25 Jul 2013 03:59:05 -0400

On Jul 23, 2013, at 9:26 PM, "Peterson, Jon" <[email-masked]> wrote:

> restrict those ways.

Part of the problem is in fact that they are "self-contained documents".  Having certs floating around in various places with no rules other than they age out in a year or two is what raises the concern around revocations.  For example, the fact that 4474 lets the sender of the SIP message tell people where to get a cert, is the reason we would have the need for revocations and highly-scalable CRLs.

> For DNS proposals (if they don't just stick CA certs

Well... that's not actually true, but yes I would expect it to be effectively true in practice.  I mean you can, for example, have multiple anchors and multiple DNS admins for a country-code; but it wouldn't make much sense in my opinion.  Or you could, for example, split a country-code tree among multiple DNS administrations of the database.  But again I don't know why you'd want to.

> access to certs in this way.

There needs to be one or more databases somewhere to get the certs.  We've already agreed (I think?) that we don't want to identify what carriers own what numbers publicly.  Ergo, someone other than the carriers has to provide a database to get certs - even if it's just a master copy that's copied into local copies in carriers.

> The reason you trust a cert isn't because you
> anchor that signed the cert.

Technically DNSSEC doesn't require the answer to come from "the right place".  There can be caches and resolvers all over the place; you can even replicate entire trees in random locations, without being authoritative for them.  So long as the signature chain is valid, it's good.  In that sense it's quite similar to certs.

> This isn't about HTTP - it doesn't matter if
> you found the cert lying on the ground.

Simply trusting a CA because it's a "CA" is how we got to DigiNotar.  To avoid that, even if we use certs and HTTP, we'll have to have some way of scoping the CA's authority, and letting that scope change over time.  The verifiers need to know which CAs are authoritative for which country-codes, and even within country-codes they need to know which region prefix CAs are authoritative.  For example which area-codes are under which of the +1 NANP member country admin CAs, including as new area-codes are added; and as country-codes are added or changed.  Obviously we can accomplish all that using HTTP, by defining how that would work, defining some encoding/list thingy, where such a list is retrieved from, how often you check for changes, etc.  Using a DNS structure happens to let all that be done automatically.  Automation is *good*.

I know it's boring to not get to define a lot more new things, but I'm sure we can find something else to do. ;)

> This is why I don't understand the

The verifier doesn't derive a "single canonical location" from which it will download the cert.  It derives a single canonical query key - in DNS it's a DNS query key, but for HTTP it could be the URL's path portion (not hostname).  The physical "location" (ie, the server) it retrieves it from is a local policy administrative decision, but the query key it uses is consistent no matter what carrier/location it's in.

For example, a potential Hard CIDER model would be such that when you receive a call from +1-603-555-1234 with a key index of 99, you create a URL like this:
http://mylocalserver.mydomain.com/cid/16035551234/99.cer

The "mylocalserver.mydomain.com" would be replaced with whatever your local Hard CIDER server's hostname is, or even 192.168.1.2.

Why?  So that we actually get some interoperability between verifier clients and cert-serving servers.  So that we can then describe how the local server might actually know what cert to give back to the client, how it got the cert, how its local database of certs is synchronized with a master DB, how we're going to handle international numbers, etc.  You know... specify an actual solution, not just magic pixie dust.

> the request, that would seem to obviate the need to go ask anyone for it.

That would have the same problem as a HTTP URL in Identity-Info.  Letting the sender of the SIP message tell people where to get a cert (or directly giving it to them as an attachment), is the reason we would have the need for revocations and highly-scalable CRLs.  Besides, we can't send the cert in-band.  Doubling the SIP message size and relying on multi-part MIME to work end-to-end is not a way to get this stuff deployed.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 25 Jul 2013 04:29:04 -0400

> choose between things that are similar.

They're not similar.  At least not so far, as written.  RFC 4474 (or 4474bis for that matter) and CIDER are dramatically different, with very different properties and behaviors.

Trying to paint them as "similar" is a clever gambit, though. 

> are quite plausible requirements.

As discussed previously, if a carrier doesn't care whether folks can figure out what numbers it owns, and it has actual "blocks" of numbers, then we can make CIDER have a way to optimize such cases: for example, not only by storing it as a pointer, but also indicating it as such in the TXT RR, so that the verifier could know to go look for a key in a root-branch and cache it for the whole branch of nodes; or another alternative is not "synthesizing" node responses, but only responding with the root-branch one.  Those types of things are the details we'll have to get into, no doubt.  Open numbering plan issues too, fwiw.

-hadriel

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 25 Jul 2013 13:11:41 +0100

> Trying to paint them as "similar" is a clever gambit, though. 

I'm not sure that's fair since they are solving the same problem and are roughly similar in terms of levels of imperfection, so I think Jon's point holds

S

---

From: Michael Hammer <[email-masked]>
Date: Thu, 25 Jul 2013 12:57:53 +0000

Please stop making silly statements like this.

Somehow we know that the multiple CIDER CAs are good, but somehow we can't 
know that a cert CA is good.
Also, that a CIDER transaction can happen in real-time, but a non-CIDER 
transaction could not happen in real time.

As I pointed out before, if the private/public key pair of the number holder 
is compromised,
there is no difference in how you regenerate the pair and get the private key 
into the hands of the signer.
There is no difference in the time it takes to send the private key or the 
cert to that user.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of 
Hadriel Kaplan
Sent: Thursday, July 25, 2013 2:09 AM
To: Peterson, Jon
Cc: [email-masked] List
Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack model

> suggestion, not the sole and authoritative means of access to certs.

The concept of ignoring the URL is so broken, I'm still in mental denial that 
4474 says you can ignore it.  Considering how carefully the IESG reads my 
drafts for publication, I'm at a loss as to how they let 4474 through.

> which authority signed a SIP request, when there are multiple
> authorities for a single number (the function the CIDER "public key
> index value" would serve, if I understand correctly).

How does the URL string "http://foo.com/dcjovbneoc.cer" help me figure out 
which authority signed the request?  I'd have to retrieve the cert from that 
URL... and then I'd see some CA signed it, but how do I know that CA is 
authoritative for that E.164 number?

It's true that the purpose of the CIDER key index value is to let there be 
multiple public keys in-use for the same E.164, but they're all "signed" by 
the same "CA" - the only one truly authoritative for the E.164 number.  But 
more to-the-point, it provides a way for changing the public keys while SIP 
messages are in-flight.  Ultimately, no matter what protocol we pick, if 
carriers have local database copies then it will take some time for the public 
keys used to sign SIP messages to get propagated out.  So you need a way to 
change your key in-advance, still use the old key for some period of time and 
then switch to using the new one, and indicate on a per-SIP-message bases 
which of the keys you're using.

The same thing would have been true if RFC 4474 had ever seen the light of 
day.  So imagine if the sender was using "http://foo.com/dcjovbneoc.cer" for 
some period of time, and then changed to "http://foo.com/cebcuhlked.cer".  How 
would this work, if a verifier ignores this URL because 4474 said it was ok?

I guess I do agree with one thing you said a while back: we do indeed have to 
deprecate RFC 4474.  Not because we'll define something better, but because 
it's broken.

-hadriel

---

From: Dave Crocker <[email-masked]>
Date: Thu, 25 Jul 2013 15:47:41 +0100

> At some point, those same protocols could be extended to endpoints.  I don't see that happening real soon perhaps, but I think it will happen.

It sounds as if there's a design goal disconnect here.

The very general range of actors for the basic, SIP-based STIR 
environment that has been described on the list is roughly:

    user-enterprise-+                       +--user
                    |                       |
                    +--provider...provider--+
                    |                       |
               user-+                       +--enterprise-user

The architectural model that you are describing for this round of effort is:

  { Provider STIR }

                       +=====================+
                       /                     /
    user-enterprise-+  /        STIR         /  +--user
                    |  /                     /  |
                    +--/-provider...provider-/--+
                    |  /                     /  |
               user-+  /                     /  +--enterprise-user
                       /                     /
                       +=====================+

Inside the STIR box are signers and verifiers.

By saying "at some point... extended to endpoints", you are almost 
certainly calling for defining an /additional/ technical mechanism, to 
accomplish the extension.  More mechanism means more complexity and 
typically means component linkages that produce results which are not 
transparent.  (In other words, rough edges through the extension.)

The alternative is to have an architecture that immediately /permits/ 
the extended participation, but probably will have more limited 
deployment as an /operational/ choice, rather than a technical limitation.

Hence:

  { End-to-End STIR }

   +============================================================+
   /                           STIR                             /
   / user-enterprise-+                       +--user            /
   /                 |                       |                  /
   /                 +--provider...provider--+                  /
   /                 |                       |                  /
   /            user-+                       +--enterprise-user /
   /                                                            /
   +============================================================+

Again, inside the STIR box are signers and verifiers.

An effort to extend the operation will, in this case, be only that -- 
extended operation -- and won't involve defining or deploying new 
technology.

To the extent that someone claims that a post-hoc extension for the 
Provider STIR approach does not involve new technology -- new 
specification, new development, and new deployment -- please offer 
examples of this being done successfully.

d/

---

From: Brian Rosen <[email-masked]>
Date: Thu, 25 Jul 2013 12:28:39 -0400

I can't follow you, sorry.

I think initially service providers will sign and verify on behalf of their subscribers, but as time goes on the subscriber device will sign and/or verify.

I don't think the protocols change, but if devices have to get credentials that may be different from service providers (only) needing to be able to get credentials.
I do think that a provisioning protocol needs to be decided upon, and that may be selecting from existing services that download the credential into the signer.  That might, at first, be how the centralized credential services interact with service providers.  It eventually needs to be how service providers interact with PBXs, and further how PBXs and/or service providers interact with devices.  The process is the same, when we assign a number, or range of numbers, we "download" credentials, where "download" really is more complex in that it involves how the private key ends up on the signer.

Brian

On Jul 25, 2013, at 10:47 AM, Dave Crocker <[email-masked]> wrote:

> The very general range of actors for the basic, SIP-based STIR environment that has been described on the list is roughly:
> 
> 
> By saying "at some point... extended to endpoints", you are almost certainly calling for defining an /additional/ technical mechanism, to accomplish the extension.  More mechanism means more complexity and typically means component linkages that produce results which are not transparent.  (In other words, rough edges through the extension.)
> 
> 
> The alternative is to have an architecture that immediately /permits/ the extended participation, but probably will have more limited deployment as an /operational/ choice, rather than a technical limitation.
> 
> Hence:
> 
> { End-to-End STIR }
> 
> An effort to extend the operation will, in this case, be only that -- extended operation -- and won't involve defining or deploying new technology.
> 
> To the extent that someone claims that a post-hoc extension for the Provider STIR approach does not involve new technology -- new specification, new development, and new deployment -- please offer examples of this being done successfully.
> 
> d/
> -- 
> Dave Crocker

---

From: "Dwight, Timothy M \(Tim\)" <[email-masked]>
Date: Thu, 25 Jul 2013 13:14:45 -0400

The scenario Brian describes seems likely to me, though the *very* first deployments might be by non-SP companies with some particular interest in the issue (e.g., banks, who don't want their phone numbers spoofed as part of some scam, or organizations that are frequently the victim of spoofing -related pranks, such as law enforcement agencies).

I have 2 related questions.

1) If an SP "signs on behalf of its subscribers", what are they expected to sign?  FROM, P-A-ID, both, FROM but only if no P-A-ID is present or assignable, something else?  Should the SP behavior be different if the user has already signed the contents of the FROM header?

2) I understand that "prevention of fraudulent caller ID spoofing" is an objective.  Are we also trying to facilitate "benign" spoofing?  

The reason for question #2 is that a "reasonable interpretation" of 3GPP's OIP/OIR specification (TS 24.607) is that the called UE display to the user the "network asserted identity" of the calling party (P-A-ID) if available.  It doesn't explicitly say that, but it says enough negative things about use of the FROM header that that's at least a reasonable interpretation.  So I'm worried about the "benign spoofing" case where the FROM header has a valid signature but yet the called party never sees the number the caller intended, because his device gave preference to the contents of P-A-ID.

Tim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Thursday, July 25, 2013 11:29 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe)

Brian

---

From: Michael Hammer <[email-masked]>
Date: Thu, 25 Jul 2013 17:23:55 +0000

I am wondering if this could be a proxied protocol based on HTTP.  (Could
even be SIP or IMS)
that requires the path to go backwards through the number delegation chain, 
but which operates E2E between the end-user and the signing authority to
securely deliver the private key/credentials.

Each SP could validate each proxy hop, just as they would for IMS today. 
(Of course, this relies on the link-level security to know how you know who
you receive the request from.)

For example, end-user creates a one-time encryption key and encrypts that
with public key of signing authority.
Signing authority uses that symmetric secret key to encrypt the private key
going back to the end-user.

The proxy chain could start with end-user, PBX, or SP depending on
deployment scenario.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian Rosen
Sent: Thursday, July 25, 2013 12:29 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe)

I think initially service providers will sign and verify on behalf of their
subscribers, but as time goes on the subscriber device will sign and/or
verify.

I don't think the protocols change, but if devices have to get credentials
that may be different from service providers (only) needing to be able to
get credentials.
I do think that a provisioning protocol needs to be decided upon, and that
may be selecting from existing services that download the credential into
the signer.  That might, at first, be how the centralized credential
services interact with service providers.  It eventually needs to be how
service providers interact with PBXs, and further how PBXs and/or service
providers interact with devices.  The process is the same, when we assign a
number, or range of numbers, we "download" credentials, where "download"
really is more complex in that it involves how the private key ends up on
the signer.

Brian

On Jul 25, 2013, at 10:47 AM, Dave Crocker <[email-masked]> wrote:

>> At some point, those same protocols could be extended to endpoints.  I
don't see that happening real soon perhaps, but I think it will happen.
> The very general range of actors for the basic, SIP-based STIR environment
> 
> 
> The alternative is to have an architecture that immediately /permits/ the
extended participation, but probably will have more limited deployment as an
/operational/ choice, rather than a technical limitation.
> To the extent that someone claims that a post-hoc extension for the
Provider STIR approach does not involve new technology -- new specification,
new development, and new deployment -- please offer examples of this being
done successfully.

---

From: Brian Rosen <[email-masked]>
Date: Thu, 25 Jul 2013 13:25:03 -0400

The solution will define what is signed.  There are a couple of proposals on the table, but they both have some form of to, from or PAI, some form of call id and a timestamp.   We'll have to discuss what an SP does if there is already a signature.  It could add one, or it could decide not to add one.

We haven't said much yet about what happens if PAI is not the same TN as From.  We need to decide what to do.

We agreed early on that we had to support "benign spoofing".  The general mechanism is that the 3rd party is authorized by the number holder to do it and gets a credential for that purpose.  Think of it as like another level of delegation.

Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 25 Jul 2013 19:10:12 +0000

An example of the kind of company that may well need to do at least signing themselves, but possibly also validation, are hosted service providers like Twilio. They have lots of 'bring your own number' customers and customers that are often short-term, so that it seems unlikely that their SP could keep track of them all. Outsourced outbound call centers are likely in the same boat - their SP has no good way of knowing who their real customers are, given that they may be only short-timers for a specific calling campaign. That may also be true for multi-site operations such as franchises that may use a single SIP trunking SP for all their locations, each with their own local number. Universities also have accumulated a hodge podge of numbers through research centers and various outposts (random example: Columbia Computer Science has a completely separate number range from the rest of Columbia University), but they are now looking at the Internet2 national SIP provider for all their VoIP needs.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan York
Sent: Wednesday, July 24, 2013 9:12 AM
To: [email-masked]; Richard Shockey
Cc: [email-masked]
Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe)

>providers, rather than end-systems, is only that: operational choice.

Agreed.  Before joining ISOC two years ago, I spent 4 years at a VoIP/IVR application platform company providing both a cloud/hosted service and an on-premise software solution. What I found interesting was that, at that time anyway, the companies using on the on-premise product were often either the very small but technically sophisticated (either a very small company or a small project within a larger company) or the very large who had technical staff.  In both cases they wanted to operate their own servers on their own networks.  As a company grew there came a point where outsourcing the service to a hosted/cloud platform made sense - and then at some point as the company grew much larger they started to have their own IT and developer staff and often wanted to bring the applications back into their own data centers.  There were many exceptions to this trend, of course, but the trend was visible.

I suspect the trend will be similar with STIR.  We'll have many individuals and smaller entities who will run their own VoIP servers and will want to do the signing and validation themselves.  And we'll have very large organizations with IT and developer staff who will want to do the signing and validation.  And the VAST majority of users will just have their service providers do it.  As Richard noted, many will just expect the SP to do it.

>Believe it or not, some individuals and some enterprises still run 
>their own SMTP servers.  That folk like you and me don't does not make 
>it reasonable to prevent others from doing it.

Exactly, and there will also be some network environments with high security policies that require them to operate their own equipment and would in this case require them to do their own signing and validating.

We need to assume in the design that the signing and validation can be done at any point in the process, even if the operational reality will be that in maybe 90+% of the cases all of that will be done by the service providers.

Dan

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 25 Jul 2013 17:38:12 -0400

> Please stop making silly statements like this.

Which statement is silly?

> know that a cert CA is good.

I'm talking below about RFC 4474.  And yes, there really is a difference between a CA constrained in scope to what numbers it can claim, that the verifier can actually know its authoritative for those numbers, vs. a CA that can claim any number on the planet it likes.

Again, the problem DigiNotar created wasn't just a problem for their domains that they were compromised - it's that every other domain in the Internet was affected by them being compromised.

There truly is a difference between "limited trust" and "unlimited/blind trust".

> transaction could not happen in real time.

Where do I say that, below?

> There is no difference in the time it takes to send the private key or the 

I have no idea what those things have to do with my email below.
Are you talking about the same email??
[ Please stop making silly statements like those. ;) ]

-hadriel

---

From: Michael Hammer <[email-masked]>
Date: Thu, 25 Jul 2013 22:33:35 +0000

First, you are using RFC4474 as a proxy for any type of Cert-based system.  
So, I reserve the right to say that not all Cert-based systems are the same.

You clearly have some rules/characteristics that make a "good" CA.
You do not show that a Cert-based system could not also be a good CA.
(And you know it is silly to try and prove a negative, right?)

Second, let me take your statements below one by one:

> It's true that the purpose of the CIDER key index value is to let 
> there be multiple public keys in-use for the same E.164, but they're 
> all "signed" by the same "CA" - the only one truly authoritative for 
> the E.164 number.  

There is no reason that the same could not also be true for Certs.

> But more to-the-point, it provides a way for 
> changing the public keys while SIP messages are in-flight.  

If you create a new private/public key pair while the SIP message is
in-flight,
I presume it has already been signed, so the new public key is not usable 
until the SIP sender has been given the corresponding private key.

> Ultimately, no matter what protocol we pick, if carriers have local 
> database copies then it will take some time for the public keys used 
> to sign SIP messages to get propagated out.  

Ummm, you don't sign with the public key.  That would be silly, as only the
sender could decode it.

> So you need a way to 
> change your key in-advance, still use the old key for some period of 
> time and then switch to using the new one, and indicate on a
per-SIP-message bases which of the keys you're using.

Agree.  That is the same for CIDER or for Cert-based solution.

:)
Mike

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Thursday, July 25, 2013 5:38 PM
To: Michael Hammer
Cc: [email-masked]; [email-masked]
Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack model 

> Somehow we know that the multiple CIDER CAs are good, but somehow we 
> can't know that a cert CA is good.

I'm talking below about RFC 4474.  And yes, there really is a difference
between a CA constrained in scope to what numbers it can claim, that the
verifier can actually know its authoritative for those numbers, vs. a CA
that can claim any number on the planet it likes.

Again, the problem DigiNotar created wasn't just a problem for their domains
that they were compromised - it's that every other domain in the Internet
was affected by them being compromised.

There truly is a difference between "limited trust" and "unlimited/blind
trust".

> Also, that a CIDER transaction can happen in real-time, but a 
> non-CIDER transaction could not happen in real time.

> As I pointed out before, if the private/public key pair of the number 
> holder is compromised, there is no difference in how you regenerate 
> the pair and get the private key into the hands of the signer.
> There is no difference in the time it takes to send the private key or 
> the cert to that user.

-hadriel

>> reasons, so we encouraged it.
> 4474 says you can ignore it.  Considering how carefully the IESG reads 
> my drafts for publication, I'm at a loss as to how they let 4474 through.
> 
> 
>> For the STIR
>> case, however, that hint might be useful to disambiguate for 
>> verifiers which authority signed a SIP request, when there are 
> How does the URL string "http://foo.com/dcjovbneoc.cer" help me figure 
> out which authority signed the request?  I'd have to retrieve the cert 
> from that URL... and then I'd see some CA signed it, but how do I know 
> that CA is authoritative for that E.164 number?
> 
> It's true that the purpose of the CIDER key index value is to let 
> there be multiple public keys in-use for the same E.164, but they're 
> all "signed" by the same "CA" - the only one truly authoritative for 
> the E.164 number.  But more to-the-point, it provides a way for 
> changing the public keys while SIP messages are in-flight.  
> Ultimately, no matter what protocol we pick, if carriers have local 
> database copies then it will take some time for the public keys used 
> to sign SIP messages to get propagated out.  So you need a way to 
> change your key in-advance, still use the old key for some period of 
> time and then switch to using the new one, and indicate on a
per-SIP-message bases which of the keys you're using.
> 
> The same thing would have been true if RFC 4474 had ever seen the 
> light of day.  So imagine if the sender was using 
> "http://foo.com/dcjovbneoc.cer" for some period of time, and then 
> changed to "http://foo.com/cebcuhlked.cer".  How would this work, if a
verifier ignores this URL because 4474 said it was ok?
> 
> I guess I do agree with one thing you said a while back: we do indeed 
> have to deprecate RFC 4474.  Not because we'll define something 
> better, but because it's broken.
> 
> -hadriel
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 25 Jul 2013 22:57:54 +0000

Well, my aim in sending that mail was to try to show how we're talking
past each other, and I do hope this exchange makes that clear.

The implementation of a DNS deployment can involve plenty of delegation
and caching, and for scalability reasons those tend to be desirable
properties. That doesn't change the fact that the DNS is a tree, with a
root, and that logically you have to acquire authoritative records from
the "right place." What that really means is you get signed records from a
service that is rooted in and delegate from the right trust anchor - that
trust anchor basically is only accessible through that DNS tree,
descending from that root. If you found a bare public key that once lived
in a DNS zone lying on the street, nothing intrinsic about the key would
let you trust it. It can only be trusted if it's downloaded from the tree
where it belongs.

Certs have a trust anchor too, but the specific Internet service you use
to download a cert doesn't have to have any relationship with that trust
anchor. As I've said, it's even possible that a cert could accompany SIP
signaling in-band, and it would be just as trustable as it would be if you
downloaded it from some kind of "authoritative" store. The fact that
Identity-Info suggests a place where a cert can be acquired does not raise
any new risks, as far as I can tell, or any requirement to check for
revocation that wouldn't exist without Identity-Info.

Is it a problem that certs can "float around in various places" for a
time? To pretty much the same degree that it's a problem that DNS records
can be cached for a time. If there's a requirement for freshness, we'd end
up engineering something for either the DNS or certs that checks
freshness. As Cullen recently pointed out, the exact requirement here
needs some careful scrutiny: we probably don't need to revoke authority
from the donating carrier of a port in any great hurry. I think this is
engineerable for either the DNS or certs.

No one is suggesting that you trust a CA just because it's any old CA. The
prospect that there would be multiple CAs with overlapping authority
(authority for the same number ranges) is discouraged in the problem
statement draft today. But this is very comparable is there being multiple
DNS trust roots, perhaps in private deployments or in different
nationalities. I don't see a ton of difference here.

Another potential difference you raise is how the scope of authority for
CAs is specified, and how that compares to a DNS solution. Verifiers do
need to know if a CA is authoritative for a country code, say, there's no
doubt about it. If we could have an international organization that
delegates down to national regulators or what have you, that would make
this all a lot clearer. But we could deploy that for either certs or the
DNS, right? There's nothing unique about the DNS there. The problem is,
it's not clear to me that this is actually desirable or practical. Doing
this for the DNS is essentially jumping back into the problem of public
ENUM, which wasn't a sterling success. I think the alternative is to try
to work from the national level up, instead of an international root down.
This is a very important design decision, and exactly the sort of thing
we'd need to discuss were this chartered. But I'd say we face that design
decision for either CAs or the DNS. So again, I don't see a ton of
difference there either.

If we can't agree on the respects in which these approaches are similar,
we're certainly not going to agree on any respect in which there are
differences that could inform later decisions.

Jon Peterson
Neustar, Inc.

On 7/25/13 12:59 AM, "Hadriel Kaplan" <[email-masked]> wrote:

>Part of the problem is in fact that they are "self-contained documents".
>Having certs floating around in various places with no rules other than
>they age out in a year or two is what raises the concern around
>revocations.  For example, the fact that 4474 lets the sender of the SIP
>message tell people where to get a cert, is the reason we would have the
>need for revocations and highly-scalable CRLs.
>
>
>Well... that's not actually true, but yes I would expect it to be
>effectively true in practice.  I mean you can, for example, have multiple
>anchors and multiple DNS admins for a country-code; but it wouldn't make
>much sense in my opinion.  Or you could, for example, split a
>country-code tree among multiple DNS administrations of the database.
>But again I don't know why you'd want to.
>
>
>There needs to be one or more databases somewhere to get the certs.
>We've already agreed (I think?) that we don't want to identify what
>carriers own what numbers publicly.  Ergo, someone other than the
>carriers has to provide a database to get certs - even if it's just a
>master copy that's copied into local copies in carriers.
>
>
>Technically DNSSEC doesn't require the answer to come from "the right
>place".  There can be caches and resolvers all over the place; you can
>even replicate entire trees in random locations, without being
>authoritative for them.  So long as the signature chain is valid, it's
>good.  In that sense it's quite similar to certs.
>
>
>Simply trusting a CA because it's a "CA" is how we got to DigiNotar.  To
>avoid that, even if we use certs and HTTP, we'll have to have some way of
>scoping the CA's authority, and letting that scope change over time.  The
>verifiers need to know which CAs are authoritative for which
>country-codes, and even within country-codes they need to know which
>region prefix CAs are authoritative.  For example which area-codes are
>under which of the +1 NANP member country admin CAs, including as new
>area-codes are added; and as country-codes are added or changed.
>Obviously we can accomplish all that using HTTP, by defining how that
>would work, defining some encoding/list thingy, where such a list is
>retrieved from, how often you check for changes, etc.  Using a DNS
>structure happens to let all that be done automatically.  Automation is
>*good*.
>
>I know it's boring to not get to define a lot more new things, but I'm
>sure we can find something else to do. ;)
>
>
>The verifier doesn't derive a "single canonical location" from which it
>will download the cert.  It derives a single canonical query key - in DNS
>it's a DNS query key, but for HTTP it could be the URL's path portion
>(not hostname).  The physical "location" (ie, the server) it retrieves it
>from is a local policy administrative decision, but the query key it uses
>is consistent no matter what carrier/location it's in.
>
>For example, a potential Hard CIDER model would be such that when you
>receive a call from +1-603-555-1234 with a key index of 99, you create a
>URL like this:
>The "mylocalserver.mydomain.com" would be replaced with whatever your
>local Hard CIDER server's hostname is, or even 192.168.1.2.
>
>Why?  So that we actually get some interoperability between verifier
>clients and cert-serving servers.  So that we can then describe how the
>local server might actually know what cert to give back to the client,
>how it got the cert, how its local database of certs is synchronized with
>a master DB, how we're going to handle international numbers, etc.  You
>know... specify an actual solution, not just magic pixie dust.
>
>
>> I
>That would have the same problem as a HTTP URL in Identity-Info.  Letting
>the sender of the SIP message tell people where to get a cert (or
>directly giving it to them as an attachment), is the reason we would have
>the need for revocations and highly-scalable CRLs.  Besides, we can't
>send the cert in-band.  Doubling the SIP message size and relying on
>multi-part MIME to work end-to-end is not a way to get this stuff
>deployed.
>
>-hadriel
>

---

From: Dave Crocker <[email-masked]>
Date: Fri, 26 Jul 2013 12:22:04 +0100

On 7/25/2013 5:28 PM, Brian Rosen wrote:
> I don't think the protocols change,

Sorry for my confusion.  The opening text of your note that I was 
responding to seemed to imply otherwise:

      "I think enterprise PBXs will assert and check identity if we 
provide the right tools.  That would mean automated mechanisms to 
acquire credentials.  If we provided provisioning mechanisms that loaded 
authorized numbers and credentials from the service provider who 
delegated the numbers, and we provided an automated way for the PBX to 
get the public keys to verify, I think many PBX vendors would implement 
that."

All of the above sounds to me like new mechanism, which means new 
technology, which means new protocols. Since you say that you intend it 
to mean no new protocols, can you explain how to achieve these enhancements?

>               but if devices have to get
> credentials that may be different from service providers (only)
> needing to be able to get credentials.

Hmmm.  That's an interesting vector.  New credentials means new 
operational infrastructure.  While it doesn't (necessarily) mean new 
protocols or software, it's still a significant barrier to adoption... 
Unless all you mean is the obvious increment of adding credentials for 
the new actors, rather than meaning a new credential infrastructure?

> I do think that a provisioning
> protocol needs to be decided upon, and that may be selecting from
> existing services that download the credential into the signer.

I thought the interesting task was /uploading/ the public key to the 
queriable database.

Given your other comments, I guess your model is that it' the service 
operator who is dictating to the enterprise what their key will be and, 
therefore, will download it to them.

But in any case, I suspect we have a broad agreement that the 
provisioning mechanisms are essential and well might require development.

> That
> might, at first, be how the centralized credential services interact
> with service providers.

Whenever the topic is a multi-administration, global Internet service, 
reference to its being 'centralized' does not compute for me, especially 
when followed by a plural -- serviceS -- since it sounds contradictory.

Since STIR will have wide diversity -- at least involving different 
telco administration but probably also a wide range of enterprises - I 
do not understand what mean by centralized.  Please explain.

 >  It eventually needs to be how service
> providers interact with PBXs, and further how PBXs and/or service
> providers interact with devices.

Service providers?  This seems to presume that the public key provision 
  must go through the telco service providers?  Just as one's DNS 
provisioning can be independent of one's ISP, why can't one's STIR key 
provision be independent of one's telco?

d/

---

From: Dave Crocker <[email-masked]>
Date: Fri, 26 Jul 2013 12:34:39 +0100

On 7/25/2013 6:23 PM, Michael Hammer wrote:
> I am wondering if this could be a proxied protocol based on HTTP.

Mike,

Sorry, but I don't understand what you mean "proxied protocol based on 
HTTP".   Please explain.  (Type slowly since I clearly need to listen 
more carefully...)

> Each SP could validate each proxy hop,

Ditto on "proxy hop".

The diagrams I provided show relaying, but nothing was meant to be 
"proxying".  For that matter, I'm not sure what it means to "proxy" for 
this mechanism.

d/

---

From: Michael Hammer <[email-masked]>
Date: Fri, 26 Jul 2013 14:21:14 +0000

Dave,

We have a well-known mechanism with SIP, which is based on HTTP, and which 
relays the INVITEs from UA through a series of proxies before reaching the
destination UA.
IMS provides more control around how that occurs.

The UA typically registers using credentials with the first proxy.  
Subsequent hops between proxies within an SP are on secure paths.
Subsequent hops between proxies of different SPs are provisioned based on
bilateral agreements and also secured.
Record-Route keeps track of which proxies stay in the signaling path and is
used 
to create the Route header which allows subsequent transactions to follow a
defined path.
IMS uses insertion of Route headers to control the path within an SP
infrastructure.
We could probably do this in on RTT end to end.

As this is closely related to the use of SIP for VoIP, I could see there
being a new SIP method created, 
whereby the UA sends a request which is routed up the chain to a national
authority (e.g. FCC) controlled server 
that would bind a new public key to the Tel# and return a signed Cert to the
requester along the same path.  
The national authority and SPs in the path could cache that cert on the
return path and make available on publicly available site.

We know how to do SIP.  We know how to do Certs.  Just reuse of well-known
technologies.
Just thinking aloud here.

Mike

-----Original Message-----
From: Dave Crocker [mailto:[email-masked]] 
Sent: Friday, July 26, 2013 7:35 AM
To: Michael Hammer
Cc: [email-masked]
Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe)

Mike,

Ditto on "proxy hop".

The diagrams I provided show relaying, but nothing was meant to be
"proxying".  For that matter, I'm not sure what it means to "proxy" for this
mechanism.

d/

---

From: Brian Rosen <[email-masked]>
Date: Fri, 26 Jul 2013 10:30:03 -0400

Okay, it's really hard to be completely technology neutral, and actually communicate clearly.

I think that delegation of telephone numbers happen 2-8 times (that is, there are between two and say 8 delegations of a number from the root (national telephone number plan administration) to the thing that places the call.

If this was some kind of cert chain, that would mean that verifying the signing certificate could, in theory, require 7 signature verifications, plus the actual signature itself.
It also means that prior to the call, we repeated a sequence 8 times:
a) A delegation is made
b) A public and private key pair is created
c) The private key is installed in the delegate, and the public key is stored in some kind of database

Regardless of the technology, there is some protocol operation that accomplishes b and c.  If you think that the actual assignment of the number (or number range) is automated, than in fact there is a protocol for a also.

I think that the protocol needed to accomplish b and c can be used at every level of delegation, although there isn't any real barrier to having more than one.  One of the delegations is from the national number authority to a service provider.  There could be several instances of service provider to service provider delegation (number resell).  Another is a service provider to a PBX.  Another is from the PBX to a device, another is from either the PBX or the device to some authorized 3rd party (the "on behalf of" case).  In each case there is a new credential and a new private/public key pair, where the private key ends up on the delegate and the public key ends up in a database.  In each case we COULD include the actual provisioning of the number assignment as well as assuring the private key ends up on the delegate.

Notice that I did not state HOW the private key ends up on the delegate.  I usually assume it's generated on the delegate but it could be downloaded.

I think stir needs to define at least one protocol for b and c, and optionally a.

Then, if the database that holds credentials needs to be accessible from only service providers, even if there are a significant number of them, that may be a whole lot different from a situation where devices need those credentials.  The former is a controlled set of queriers, and the latter is a completely public database.  

Okay, so back to my 8 levels of delegation.

In theory, you actually have a chain of 8 signatures.   If the database DNS, the zone is delegated to some entity.  I don't think that, so far anyway, anyone has proposed that we delegate the actual DNS zones one telephone number at a time.  All the proposals have some level of centralized authority maintaining the actual DNS authoritative server.  That's "centralized".   If the database contains certs, in theory, each of the 8 delegates can have a separate database to hold their certs, but we don't think that's a good idea.  We really do think we should have a smaller number of actual signers.  That means that we have a "centralized" database maintainer, and the delegations are accomplished using this centralized service, so the cert that is used to sign is signed by the centralized server instead of the next level up delegate.  In both cases, the content is controlled by the delegates, but the database itself is operated by some more centralized entity

But in both cases, I don't imply "one".  It might be ideal to have one per country.  I think with the DNS solution, you pretty much have to do that if porting is allowed.  With certs, you could, but you could also allow all 8 to run their own if they insisted, or anything in between. 

Brian

On Jul 26, 2013, at 7:22 AM, Dave Crocker <[email-masked]> wrote:

> Sorry for my confusion.  The opening text of your note that I was responding to seemed to imply otherwise:
> 
>     "I think enterprise PBXs will assert and check identity if we provide the right tools.  That would mean automated mechanisms to acquire credentials.  If we provided provisioning mechanisms that loaded authorized numbers and credentials from the service provider who delegated the numbers, and we provided an automated way for the PBX to get the public keys to verify, I think many PBX vendors would implement that."
> 
> All of the above sounds to me like new mechanism, which means new technology, which means new protocols. Since you say that you intend it to mean no new protocols, can you explain how to achieve these enhancements?
> 
> 
> Hmmm.  That's an interesting vector.  New credentials means new operational infrastructure.  While it doesn't (necessarily) mean new protocols or software, it's still a significant barrier to adoption... Unless all you mean is the obvious increment of adding credentials for the new actors, rather than meaning a new credential infrastructure?
> 
> 
> I thought the interesting task was /uploading/ the public key to the queriable database.
> 
> Given your other comments, I guess your model is that it' the service operator who is dictating to the enterprise what their key will be and, therefore, will download it to them.
> 
> But in any case, I suspect we have a broad agreement that the provisioning mechanisms are essential and well might require development.
> 
> 
>> That
> Whenever the topic is a multi-administration, global Internet service, reference to its being 'centralized' does not compute for me, especially when followed by a plural -- serviceS -- since it sounds contradictory.
> 
> Since STIR will have wide diversity -- at least involving different telco administration but probably also a wide range of enterprises - I do not understand what mean by centralized.  Please explain.
> 
> 
> Service providers?  This seems to presume that the public key provision  must go through the telco service providers?  Just as one's DNS provisioning can be independent of one's ISP, why can't one's STIR key provision be independent of one's telco?
> 
> 
> d/
> 
> -- 
> Dave Crocker

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 26 Jul 2013 15:21:05 -0400

> So, I reserve the right to say that not all Cert-based systems are the same.

Not in the email I sent I didn't.
Jon's email was about RFC 4474 in particular, and my response was about it in particular.
I wasn't arguing about just any random cert-based model.

> (And you know it is silly to try and prove a negative, right?)

It's true I think there is a fundamental difference between the web-pki model of trusted CAs, vs. a DANE or DKIM model where the trusted "CAs" are the authority of domain names themselves.  For CIDER, that would apply to how it handles email-style names.  For E.164-based names, it's not as clear-cut because an E.164 is a separate namespace from domain names.  That's why I have an appendix in the CIDER draft proposing the authority be the same.  Obviously one could come up with a cert-based model to do that as well.  But RFC 4474 doesn't.

> There is no reason that the same could not also be true for Certs.

Of course.  But RFC 4474 doesn't.

> until the SIP sender has been given the corresponding private key.

Yes, although really the sender already has the new private key - I'm not assuming a model where someone gives the sender a private key.  It's just that the sender can't use the new private key until there's sufficient time for the system to get its public key twin spread around; it would use the old private key for a while (like ~15 minutes or so).

> Ummm, you don't sign with the public key.  That would be silly, as only the

Sorry, meant private key.

-hadriel

---

From: Michael Hammer <[email-masked]>
Date: Fri, 26 Jul 2013 20:15:04 +0000

OK, then I take it back.  I was reading too much into it.

Have a good weekend.

Mike

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Friday, July 26, 2013 3:21 PM
To: Michael Hammer
Cc: [email-masked] List
Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack model 

Not in the email I sent I didn't.
Jon's email was about RFC 4474 in particular, and my response was about it
in particular.
I wasn't arguing about just any random cert-based model.

> (And you know it is silly to try and prove a negative, right?)

It's true I think there is a fundamental difference between the web-pki
model of trusted CAs, vs. a DANE or DKIM model where the trusted "CAs" are
the authority of domain names themselves.  For CIDER, that would apply to
how it handles email-style names.  For E.164-based names, it's not as
clear-cut because an E.164 is a separate namespace from domain names.
That's why I have an appendix in the CIDER draft proposing the authority be
the same.  Obviously one could come up with a cert-based model to do that as
well.  But RFC 4474 doesn't.

>> But more to-the-point, it provides a way for changing the public keys 
>> while SIP messages are in-flight.
> 
> in-flight, I presume it has already been signed, so the new public key 
> is not usable until the SIP sender has been given the corresponding 
> private key.

Yes, although really the sender already has the new private key - I'm not
assuming a model where someone gives the sender a private key.  It's just
that the sender can't use the new private key until there's sufficient time
for the system to get its public key twin spread around; it would use the
old private key for a while (like ~15 minutes or so).

> Ummm, you don't sign with the public key.  That would be silly, as 
> only the sender could decode it.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 27 Jul 2013 06:15:14 -0400

> I think stir needs to define at least one protocol for b and c, and optionally a.

Right, I agree.  I put together some requirements for what such a protocol would need to do for a DNS-based model, in an appendix of the CIDER draft.  I call the new/needed protocol "CAPP" in there.  The idea was an Enterprise could use CAPP to its provider, which could use CAPP to a carrier, which then uses CAPP to the DNS admin.

> But in both cases, I don't imply "one".  It might be ideal to have one per country.  I think with the DNS solution, you pretty much have to do that if porting is allowed.  With certs, you could, bu…

Right, and I think having a single DNS admin per country does make sense, if they do porting anyway.  Oddly, it's still possible to split the DB up in half and give management control/responsibility to two or three companies/admins for a country, even with porting, but it would be logistically easier to just have one.

Regardless, you'd never want to have each of the 8 delegated-chain assignees run their own databases, if you plan for large carriers to have a local copy of the database.  I've kinda assumed we would want that to be possible, but it's something to discuss in the WG.

-hadriel

---

From: Dave Crocker <[email-masked]>
Date: Sat, 27 Jul 2013 12:57:38 +0100

Mike,

Thanks for the quick tutorial.  As with any extended system effort, SIP 
has developed some vocabulary that is distinctive and I hadn't rather 
stupidly hadn't grokked that that's the model I needed to consult, for 
parsing the reference.  (I /had/ seen the way that SIP uses the term 
proxy, but had forgotten.  Some of this is reminiscent of growing up in 
O/S and Arpanet land and then running into the database world or, worse, 
the IBM SNA world.  Totally different vocabularies, often for identical 
constructs.)

> Just thinking aloud here.

Given competing design choices, the nature and amount of development and 
OA&M effort probably shold affect the evaluation.  While Marshall Rose 
was mostly correct that with enough thrust, pigs /can/ fly, thrust isn't 
free.  If one design takes considerably less effort (smaller pig?) it 
tends to be easier to deploy.

d/

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sat, 27 Jul 2013 13:58:08 +0000

> I think we have a different concept of who the bad callers are.  My guess is in your definition is it's just a telemarketer.  To me, "telemarketers" are perfectly legal/legitimate callers.  I don't…

Oh no, we totally agree on who the bad guys are. But if I was deploying that, I would not be using Astrix, I'd be using a minute smuggling system on the Cisco AVID architecture. It is really good for minute smuggling and as you know I don't say that about all Cisco products. 

> 
> Regulated carriers allow you to assert any caller ID on an ISDN trunk because they have no real choice - they need to support the outsourced call-center and branch office call scenarios.

I think we will need to agree to disagree about if they have no choice here or not. I understand that they have no choice is the party line. In the end, I don't think it matters much to this conversation if you  are I are right - we both agree on they don't do it and are not like to start doing it.

I am very familiar with the call center and branch office scenarios. 

> They need to let the PBX choose what caller ID to generate, on a call-by-call basis.  The carriers don't do it because they don't care - they do it because that's the only way they could handle that use-case in ISDN/SS7/SIP.  And it worked fine for a long time.  There *were* cases of fraud and abuse of course, but the rate was so low the carrier fraud/support departments could handle it.
> 

I agree we need their help. But to get that we need to deserve their help and that requires an incentive model that makes sense for them.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sat, 27 Jul 2013 13:58:12 +0000

that makes a lot of sense to me. I also think a needs to be automated to ensure that the op-ex is low enough that SP are willing to do this.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sat, 27 Jul 2013 13:58:21 +0000

>    "I think enterprise PBXs will assert and check identity if we provide the right tools.  That would mean automated mechanisms to acquire credentials.  If we provided provisioning mechanisms that…

I find it easy to imagine a future where the enterprise delegates the number to the SP instead of the other way around. In some ways we already have that occurring in a bunch of places.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sat, 27 Jul 2013 13:58:19 +0000

> OK, you think Skype is the incentive for providing wideband audio.  Might I suggest that if that were the case, that the reason it was an incentive is because Skype represented a threat to carrier'…

I think smart phones are a threat to fixed lines. I think over the over the top services on smart phones are a threat to traditional mobile minutes on smart phones. (ditto for SMS) 

Crocker asked for an example of a place where technology A pushed technology B to deploy and visa versa. I provide HD voice as an example. 

> 
> The "threat" right now is an FCC mandate,

If I thought the only incentive for this to deploy was stick, not a carrot, I would not bother to spend another 10 seconds on it. 

> Carrier's aren't idiots. 

100% agree there. I think they are incredibly in their ability to make money.

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 29 Jul 2013 03:50:56 -0400

In line 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Cullen Jennings (fluffy)
Sent: Saturday, July 27, 2013 9:58 AM
To: Hadriel Kaplan
Cc: IETF STIR Mail List
Subject: Re: [stir] Draft STIR Charter - out of band

> 
> OK, you think Skype is the incentive for providing wideband audio.  Might
I suggest that if that were the case, that the reason it was an incentive is
because Skype represented a threat to carrier's business models?  How is
Apple/Android/whatever providing out-of-band caller-id validation a threat
to a carrier's business model?  If anything, it would relieve some pressure
on the carriers.

I think smart phones are a threat to fixed lines. I think over the over the
top services on smart phones are a threat to traditional mobile minutes on
smart phones. (ditto for SMS) 

[RS> ]  The data is actually somewhat mixed in North America.  There is
mobile substitution in key 18-35 residential demographics but you can't
ignore Enterprise-SMB where fixed lines are not declining and the number
utilization data bears that out.  Actually the effect of OTT on Voice and
SMS in North America has stabilized since NA carriers went to One Rate
national plans.  As a percentage of total minutes used per sub OTT  is still
less than 8% after all these years ..International calling is actually
different.  Europe is of course totally screwed up due to their appalling
roaming charges.

Crocker asked for an example of a place where technology A pushed technology
B to deploy and visa versa. I provide HD voice as an example. 

> The "threat" right now is an FCC mandate,

If I thought the only incentive for this to deploy was stick, not a carrot,
I would not bother to spend another 10 seconds on it. 

[RS> ] Remember we do not have good data on the scope of the problem in
Jurisdictions outside out of North America.  The FCC/CRTC problem is in part
created by their legislatures.  This work is not a silver bullet only one of
many different tools that are needed.  I would not worry about a FCC mandate
anytime soon.  It takes the FCC MUCH longer to create a Report and Order
than the IETF takes to issue a RFC.  

> Carrier's aren't idiots. 

100% agree there. I think they are incredibly in their ability to make
money. 

[RS> ]  Duh .. but they do actually have CAPEX constraints and as other
commenters have noted any solution has to understand some of the deployment
constraints their existing architecture creates.  Simple is good.

---

From: Russ Housley <[email-masked]>
Date: Mon, 29 Jul 2013 09:34:22 -0400

Hadriel and I just had a conversation in the hallway.  He really wants to give up his speaking slot in order to create more time for charter discussion.  I have posted a revised agenda.

https://datatracker.ietf.org/meeting/87/agenda/stir/

Russ

---

From: Michael Hammer <[email-masked]>
Date: Mon, 29 Jul 2013 15:12:17 +0000

Sorry.  I should have been more explicit from the start.
When one has a hammer, everything looks like a nail.  :)

I think we have a few in place systems that can be leveraged.
One is DNS, another is SIP, a third would be Diameter (in mobile networks).

Mike

-----Original Message-----
From: Dave Crocker [mailto:[email-masked]] 
Sent: Saturday, July 27, 2013 7:58 AM
To: Michael Hammer
Cc: [email-masked]
Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe)

On 7/26/2013 3:21 PM, Michael Hammer wrote:
> Dave,
>
> We have a well-known mechanism with SIP, which is based on HTTP, and 
> which relays the INVITEs from UA through a series of proxies before 
> reaching the destination UA.

Mike,

Thanks for the quick tutorial.  As with any extended system effort, SIP has
developed some vocabulary that is distinctive and I hadn't rather stupidly
hadn't grokked that that's the model I needed to consult, for parsing the
reference.  (I /had/ seen the way that SIP uses the term proxy, but had
forgotten.  Some of this is reminiscent of growing up in O/S and Arpanet
land and then running into the database world or, worse, the IBM SNA world.
Totally different vocabularies, often for identical
constructs.)

> As this is closely related to the use of SIP for VoIP, I could see 
> there being a new SIP method created, whereby the UA sends a request 
> which is routed up the chain to a national authority (e.g. FCC) 
> controlled server that would bind a new public key to the Tel# and 
> return a signed Cert to the requester along the same path.
> The national authority and SPs in the path could cache that cert on 
> the return path and make available on publicly available site.
>
> We know how to do SIP.  We know how to do Certs.  Just reuse of 
> well-known technologies.

Given competing design choices, the nature and amount of development and
OA&M effort probably shold affect the evaluation.  While Marshall Rose was
mostly correct that with enough thrust, pigs /can/ fly, thrust isn't free.
If one design takes considerably less effort (smaller pig?) it tends to be
easier to deploy.

d/

---

From: "Jan-Tilo Kirchhoff" <[email-masked]>
Date: Tue, 30 Jul 2013 09:53:01 +0200

> -----Ursprüngliche Nachricht-----
> Von: Cullen Jennings (fluffy) [mailto:[email-masked]]
> Gesendet: Samstag, 27. Juli 2013 15:58
> An: Hadriel Kaplan
> Cc: IETF STIR Mail List
> Betreff: Re: [stir] Draft STIR Charter - out of band
> 
> 
> >> I don't really agree with this. If this was true, the class 5 switch
> that my ISDN trunk connects to would only allow me to assert the caller
> ID on the ISDN trunk for numbers assigned to me. However, because I am
> the customer, and I like to be able to set whatever caller ID I want,
> and my service provider makes me happy as a customer. Many providers in
> the US are very happy to provide me with a ISDN trunk that allows me to
> set whatever caller ID I want. I will note this include the  bulk of
> the large carriers with good reputations, it's not just fringy
> operators.
> >>
> >> I think the key thing is that carriers largely try and meet the
> needs of their customers. And their customs are often the people that
> make robo calls, as well as the people that receive them.
> >
> > I think we have a different concept of who the bad callers are.  My
> guess is in your definition is it's just a telemarketer.  To me,
> "telemarketers" are perfectly legal/legitimate callers.  I don't
> personally want to get calls from them, but that's up to a
> whitelist/blacklist mechanism to handle, whether it be do-not-call
> lists or crowd-sourced reputation lists or whatever.  To me, the bad
> guys are the guys generating bulk calls using *purposefully invalid*
> calling numbers, using Asterisk with SIP trunks to non-regulated
> providers.  They're using invalid calling numbers for the purpose of
> misleading their targets, bypassing whitelists/blacklists, etc.  I
> truly don't think the regulated carriers want to have those guys as
> their customers.
> 
> Oh no, we totally agree on who the bad guys are. But if I was deploying
> that, I would not be using Astrix, I'd be using a minute smuggling
> system on the Cisco AVID architecture. It is really good for minute
> smuggling and as you know I don't say that about all Cisco products.
> 
> >
> > Regulated carriers allow you to assert any caller ID on an ISDN trunk
> because they have no real choice - they need to support the outsourced
> call-center and branch office call scenarios.
> 
> I think we will need to agree to disagree about if they have no choice
> here or not. I understand that they have no choice is the party line.
> In the end, I don't think it matters much to this conversation if you
> are I are right - we both agree on they don't do it and are not like to
> start doing it.
> 
> > They need to let the PBX choose what caller ID to generate, on a
> call-by-call basis.  The carriers don't do it because they don't care -
> they do it because that's the only way they could handle that use-case
> in ISDN/SS7/SIP.  And it worked fine for a long time.  There *were*
> cases of fraud and abuse of course, but the rate was so low the carrier
> fraud/support departments could handle it.

Actually from my experience with ISDN and Telcos in Germany when a user 
has activate this feature (often referred to as "CLIP No Screening") the 
original calling line ID is transmitted inside the carrier network and 
sometimes even send to the destination as a secondary ID. The difference 
is in the protocol elements used and the presentation and screening 
indicators. If you're interested I will look up the details in the ETSI 
standards. 
Actually I believe that transmission of the "real" number (screened / 
asserted by the carrier network) is mandatory. Emergency services, police 
etc. will always have access to this information, no matter what you send.

> >
> > Regardless, that stuff doesn't really matter.  We need their help, if
> we want this thing to be widely deployed and helpful/useful, for more
> than society's elite.  I think the carriers want to help, if for no
> other reason than to avoid government mandate. (I honestly think they
> want to do it for better reasons than that, fwiw)
> 
> I agree we need their help. But to get that we need to deserve their
> help and that requires an incentive model that makes sense for them.
> 
> >
> > -hadriel
> >
> 

Regards,

Tilo

--
Dipl. Ing. Jan-Tilo Kirchhoff    

Portfoliomanagement BluStar, OpenCom & SIP Products

Aastra Deutschland GmbH
Zeughofstr. 1
10997 Berlin · Germany

[email-masked]
www.aastra.de
 
Sitz der Gesellschaft: Berlin
Registergericht: Amtsgericht Charlottenburg HRB 37998
Geschäftsführer: Jürgen Signer, Anthony Shen