Subject: [stir] edits to draft-kaplan-stir-fried

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 9 Sep 2013 20:00:05 +0000

Attached is a set of proposed edits to stir-fried (stir FAQ) as a diff from the published version.

I apologize, in advance, for the form.  Prior to publishing, I was given an opportunity to comment on the text, which I failed to do in a timely manner, and just about the time I got the comments done, Hadriel had published his draft and had made some updates to it.  I don't have the source available to easily reproduce the edits.  Accordingly, this diff shows a lot of changes that are not actual proposed edits.

If accepted, I'll be happy to work with Hadriel to make it easier to incorporate the changes in his current source document.

In private correspondence, he questioned some of these edits.  Those comments and my responses are:
With regard to some of your changes:

1) For the overview of the proposed solutions, you've added text that says the in-band and out-of-band (1) use the same credentials and (2) are performed by similar entities.  I don't believe that's true - or at least, I don't believe that most people in the WG agree with that.  Several of the out-of-band proponents consistently emphasize that PBX's and smartphones would be the ones doing the out-of-band stuff, which is a different set of actors than the in-band proponents have been emphasizing would do in-band stuff.  Also, I have seen no consistent view/description of what the "credentials" are for out-of-band at all.

<br>I believe that the out of band proponents have proposed the credentials be the same.
I believe that the signing of the data should be able to be performed by the end point or a service provider.  We've also talked about a PBX signing.  The actual credential could be different in those two cases, representing the delegation from a national number authority to the SP or a number resell to the SP vs a delegation from the SP to the end user. For in-band I believe any party on the path, including any SP or the endpoint should be able to validate.   In the out of band case, only the terminating SP or the terminating end user would be able to validate.

There is no agreement on the view/description of credentials for either in band or out of band, other than they have a public/private key pair.  For example, some in band credential proposals are full X.509 certs and others are a plain private key in the DNS.  The credential needed for out of band is exactly the same I believe, although I though it may need an additional pointer to the CPS (or equivalent).

2) For the question of why we're focused on SIP, you added:
   We also observe that most of the problem calls are SIP-originated.
   Probably that is because there VoIP service providers that are more
   willing to allow their subscribers to use any calling party number
   they want to.

I haven't seen any actual numbers that show most of the problem calls are SIP-originated.  Are there some numbers?
<br>don't have numbers.  Perhaps Henning does. I have been told most of the problem is SIP-originated by a couple of independent sources, but I have no verifiable facts.

3) For the question on proposed out-of-band solution, you added this:
   It proposes that the sender encrypt identity information for the
   recipient (such that only the recipient can decrypt it) and store
   it in a database selected by the recipient.  The recipient queries
   the database when it receives the call and obtains the identity
   information.  The proposal assumes the sender can query the credential
   database to obtain the public key of the recipient and the identity of
   the database to store the sender’s information in.

I don't believe Ekr's draft says that.  It doesn't stipulate whose CPS database is used for storing the CPR stuff, except by hinting at it in one sentence; most of the doc assumes/implies a single CPS.  I think the powerpoint slides shown in Wash DC might have described it as you said, but even back then I thought they were backward.  Alice should put the CPR in her CPS, and Bob should retrieve it from her CPS.  ISTM doing it that way solves a lot of problems.

<br>EKR's draft says:

   The discussion above is written in terms of a single CPS, but this
   potentially has scaling problems, as well as allowing the CPS to
   learn about every call.  These issues can be alleviated by having a
   federated CPS.  If a credential lookup service is already available,
   the CPS location can also be stored in the callee's credentials.

Brian

---

From: Robert Sparks <[email-masked]>
Date: Tue, 10 Sep 2013 09:23:12 -0500

Brian - Thanks for breaking the silence...

We've had several folks suggest this would work well as a wiki page. The 
wiki we have at
<http://trac.tools.ietf.org/wg/stir/trac/wiki> is open for anyone with a 
tools account to write on.
I've moved the link to the fried draft to 
<http://trac.tools.ietf.org/wg/stir/trac/wiki/FAQ> (you can get
to that from the FAQ link on the main page).

Hadriel - would you try dropping the next version on that page, 
replacing that link, and lets see how using that as
a place to keep an FaQ going works?

Please keep the arguments about what the proposals actually say on list.

RjS

On 9/9/13 3:00 PM, Rosen, Brian wrote:
> I apologize, in advance, for the form.  Prior to publishing, I was 
> given an opportunity to comment on the text, which I failed to do in a 
> timely manner, and just about the time I got the comments done, 
> Hadriel had published his draft and had made some updates to it.  I 
> don't have the source available to easily reproduce the edits. 
>  Accordingly, this diff shows a lot of changes that are not actual 
> proposed edits.
>
> If accepted, I'll be happy to work with Hadriel to make it easier to 
> incorporate the changes in his current source document.
>
> 1) For the overview of the proposed solutions, you've added text that 
> says the in-band and out-of-band (1) use the same credentials and (2) 
> are performed by similar entities.  I don't believe that's true - or 
> at least, I don't believe that most people in the WG agree with that. 
>  Several of the out-of-band proponents consistently emphasize that 
> PBX's and smartphones would be the ones doing the out-of-band stuff, 
> which is a different set of actors than the in-band proponents have 
> been emphasizing would do in-band stuff.  Also, I have seen no 
> consistent view/description of what the "credentials" are for 
> out-of-band at all.
>
> I believe that the signing of the data should be able to be performed 
> by the end point or a service provider.  We've also talked about a PBX 
> signing.  The actual credential could be different in those two cases, 
> representing the delegation from a national number authority to the SP 
> or a number resell to the SP vs a delegation from the SP to the end 
> user. For in-band I believe any party on the path, including any SP or 
> the endpoint should be able to validate.   In the out of band case, 
> only the terminating SP or the terminating end user would be able to 
> validate.
>
> There is no agreement on the view/description of credentials for 
> either in band or out of band, other than they have a public/private 
> key pair.  For example, some in band credential proposals are full 
> X.509 certs and others are a plain private key in the DNS.  The 
> credential needed for out of band is exactly the same I believe, 
> although I though it may need an additional pointer to the CPS (or 
> equivalent).
>
>
>
> I haven't seen any actual numbers that show most of the problem calls 
> are SIP-originated.  Are there some numbers?
> <br>don't have numbers.  Perhaps Henning does. I have been told most 
> of the problem is SIP-originated by a couple of independent sources, 
> but I have no verifiable facts.
>
>
>    the database to store the sender's information in.
>
> I don't believe Ekr's draft says that.  It doesn't stipulate whose CPS 
> database is used for storing the CPR stuff, except by hinting at it in 
> one sentence; most of the doc assumes/implies a single CPS.  I think 
> the powerpoint slides shown in Wash DC might have described it as you 
> said, but even back then I thought they were backward.  Alice should 
> put the CPR in her CPS, and Bob should retrieve it from her CPS.  ISTM 
> doing it that way solves a lot of problems.
>
> <br>EKR's draft says:
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 10 Sep 2013 11:14:22 -0400

Sure!
-hadriel

On Sep 10, 2013, at 10:23 AM, Robert Sparks <[email-masked]> wrote:

> We've had several folks suggest this would work well as a wiki page. The wiki we have at 
> <http://trac.tools.ietf.org/wg/stir/trac/wiki> is open for anyone with a tools account to write on.
> I've moved the link to the fried draft to <http://trac.tools.ietf.org/wg/stir/trac/wiki/FAQ> (you can get
> Hadriel - would you try dropping the next version on that page, replacing that link, and lets see how using that as