Subject: Re: [stir] Textual caller ID (was Re: Moving from BOF to Charter, Early Homework)

From: Stephen Kent <[email-masked]>
Date: Tue, 27 Aug 2013 23:54:49 -0400

Brian,

> ...
>
> Let me emphasize:
>
> All I want out of stir is a way to extend the signature to cover 
> whatever we come up with.  That "whatever" can be done in a recharter 
> of stir, later, or it could be done in a separate WG, as long as we 
> can extend the signature to cover other stuff.
>
I am strongly opposed to what you have suggested above! For phone 
numbers we have
a clear understanding of who is authoritative for what. For any other ID 
data, we
do not. To place the phone number AND other data under the same 
signature potentially
degrades the authentication offered for the phone number.

So, in the words of a famous former first lady, "just say no."

Steve

---

From: Richard Barnes <[email-masked]>
Date: Wed, 28 Aug 2013 09:27:26 -0400

<hat type="none"/>

On Tue, Aug 27, 2013 at 11:54 PM, Stephen Kent <[email-masked]> wrote:

> Brian,
>
>  ...
>>
>>
>> Let me emphasize:
>>
>> All I want out of stir is a way to extend the signature to cover whatever
>> we come up with.  That "whatever" can be done in a recharter of stir,
>> later, or it could be done in a separate WG, as long as we can extend the
>> signature to cover other stuff.
>>
> do not. To place the phone number AND other data under the same signature
> potentially
Hey Steve,

I think you might be a little confused here.  There is an issue of
trustworthiness here, but not one of authority.

As I understand Brian's proposal, the idea would be to include (for
example) naming information in a signed object that could be verified under
a phone number credential.  So the RP would know that the naming
information is being asserted by the holder of the phone number, but *not*
authoritatively.  "The holder of +12125551212 says that her name is
Chelsea."

By way of analogy, this is kind of like the "Ghostbusters" record in the
RPKI [1] -- the resource certificate used to verify that record attests
only to authority for a set of Internet number resources, not any of the
identifiers in the vCard in the record.  Or, imagine that someone presented
a driver's license with the name "Bradley" and said "... but call me
Chelsea".

Now, obviously you can't infer that naming information is actually true
from the fact that it verifies under a phone number credential.  But what
you could do is go to some other service and say, "Phone number +1212555121
is asserting the name Chelsea, is that correct?", and they could tell you
yes or no.

So all we're really talking about here is a second way of getting verified
additional information along with a phone number.  In addition to:
  1. Take the authenticated phone number and use it as a key to look up
additional information from a trusted service ("Who is +12125551212?"
 "Bradley")
(as we discussed earlier in this thread), we have:
  2. Take the authenticated phone number and additional information
provided by the caller, and have a trusted service verify it. ("Is
'Chelsea' a valid name for +15551212?" "Yes")

In the first case, the third party service provides the information; in the
second case, it only verifies it.  (It could be argued that there's a
privacy benefit to the second case, since the caller chooses what
information is released.  It also could provide a little more flexibility,
as illustrated above.)

In either case, though, it's clear that the phone number credential serves
only to bind the additional information to the phone number.  It does not
imply any authority to assert the additional information; that authority
needs to be come through some other channel.

The only impact for STIR in any case is that if the second model is to be
supported, then there has to be a way for the additional data to be
included in the signed object.  This will probably happen to some degree
regardless, since the signed object will attest to SIP header values, of
which the additional data could be one.  But it might also be useful to
include the additional data more directly, e.g., if will not survive in a
SIP header.

Anything in more detail than that is pretty speculative at this point,
which is why we created the new CNIT list for discussion of things like the
above two mechanisms.
<https://www.ietf.org/mailman/listinfo/cnit>

Hope this helps clarify,
--Richard

[1] <http://tools.ietf.org/html/rfc6493>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Aug 2013 10:01:29 -0400

Richard,

I understand what you are saying below, but I don't see that it adds 
much extra value.

Compare two cases:

1) as you describe below
2) only the number is signed. The caller still includes a display
    name, but it isn't signed.

In the 2nd case, the recipient still gets a name and a number, and can 
still ask that other service whether the holder of the number can assert 
that name.

The difference is that in the 2nd case the name could have been tampered 
with. But what difference does that make? It could mean that a good name 
was replaced by a bad one. But then it won't validate, and the callee 
will be presented with the number and no name.

A tamperer who could do that could also remove the signature in the 
first case. Then the callee would not be presented with either number or 
name.

Another possibility is that the caller has multiple names that it is 
permitted to use with the number. Then I suppose in (2) the tamperer 
could replace one valid name with another valid name. The callee would 
then see a name the caller didn't intend this callee to see. This 
wouldn't be possible with (1). But it is an obscure case, unlikely to be 
interesting to exploit.

Bottom line, ISTM that this functionality adds some minor benefits that 
don't seem worth the trouble.

	Thanks,
	Paul

On 8/28/13 9:27 AM, Richard Barnes wrote:

> example) naming information in a signed object that could be verified
> under a phone number credential.  So the RP would know that the naming
> information is being asserted by the holder of the phone number, but
> *not* authoritatively.  "The holder of +12125551212 says that her name
> is Chelsea."
>
> identifiers in the vCard in the record.  Or, imagine that someone
> presented a driver's license with the name "Bradley" and said "... but
> call me Chelsea".
>
> from the fact that it verifies under a phone number credential.  But
> what you could do is go to some other service and say, "Phone number
> +1212555121 is asserting the name Chelsea, is that correct?", and they
> could tell you yes or no.
>
> So all we're really talking about here is a second way of getting
> verified additional information along with a phone number.  In addition to:
> In the first case, the third party service provides the information; in
> the second case, it only verifies it.  (It could be argued that there's
> a privacy benefit to the second case, since the caller chooses what
> information is released.  It also could provide a little more
> flexibility, as illustrated above.)
>
> In either case, though, it's clear that the phone number credential
> serves only to bind the additional information to the phone number.  It
> does not imply any authority to assert the additional information; that
> authority needs to be come through some other channel.
>
> The only impact for STIR in any case is that if the second model is to
> be supported, then there has to be a way for the additional data to be
> include the additional data more directly, e.g., if will not survive in
> a SIP header.
>
> which is why we created the new CNIT list for discussion of things like
> the above two mechanisms.
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir
>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 28 Aug 2013 10:48:11 -0400

Agreed.  The incremental benefit of having the asserted name covered by the
signature is that the recipient knows that the caller added it, and not,
say, some intermediate carrier.  As to whether that's worthwhile
information, YMMV.

--Richard

On Wed, Aug 28, 2013 at 10:01 AM, Paul Kyzivat <[email-masked]>wrote:

> Richard,
>
> I understand what you are saying below, but I don't see that it adds much
> extra value.
>
> Compare two cases:
>
> 1) as you describe below
> was replaced by a bad one. But then it won't validate, and the callee will
> be presented with the number and no name.
>
> A tamperer who could do that could also remove the signature in the first
> case. Then the callee would not be presented with either number or name.
>
> permitted to use with the number. Then I suppose in (2) the tamperer could
> replace one valid name with another valid name. The callee would then see a
> name the caller didn't intend this callee to see. This wouldn't be possible
> with (1). But it is an obscure case, unlikely to be interesting to exploit.
>
>> <https://www.ietf.org/mailman/**listinfo/cnit<https://www.ietf.org/mailman/listinfo/cnit>
>> >
>>
>> Hope this helps clarify,
>> --Richard
>>
>>
>> [1] <http://tools.ietf.org/html/**rfc6493<http://tools.ietf.org/html/rfc6493>
>> >
>>
>>
>> ______________________________**_________________
>> stir mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/stir<https://www.ietf.org/mailman/listinfo/stir>
>>
>>
> ______________________________**_________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/stir<https://www.ietf.org/mailman/listinfo/stir>
>

---

From: Dave Crocker <[email-masked]>
Date: Wed, 28 Aug 2013 07:59:59 -0700

On 8/28/2013 7:48 AM, Richard Barnes wrote:
>   The incremental benefit of having the asserted name covered by the
> signature is that the recipient knows that the caller added it

As long as the semantics of the signature assert this explicitly, yes.

By way of demonstrating this point, DKIM's semantics merely asserts that 
such adjunct information included in the signature hash was 'present' at 
the time of signing, rather than asserting its validity or even 
ownership by the signer.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 28 Aug 2013 11:34:16 -0400

Exactly, but we've already ruled out malicious transit carriers for STIR.

-hadriel

On Aug 28, 2013, at 10:48 AM, Richard Barnes <[email-masked]> wrote:

> Agreed.  The incremental benefit of having the asserted name covered by the signature is that the recipient knows that the caller added it, and not, say, some intermediate carrier.  As to whether that's worthwhile information, YMMV.
> 
> --Richard

---

From: Stephen Kent <[email-masked]>
Date: Thu, 29 Aug 2013 02:23:44 -0400

Richard.

> Hey Steve,
>
> I think you might be a little confused here.
or you're a little confused about me being confused :-).
> There is an issue of trustworthiness here, but not one of authority.
not in all of the proposals I've seen.
> *not* authoritatively.  "The holder of +12125551212 says that her name 
and that, IMHO, is a bad thing. We have a lot of experience that 
suggests that users
will not appreciate this subtle distinction.
> By way of analogy, this is kind of like the "Ghostbusters" record in 
> the RPKI [1] -- the resource certificate used to verify that record 
> attests only to authority for a set of Internet number resources, not 
> any of the identifiers in the vCard in the record.  Or, imagine that 
> someone presented a driver's license with the name "Bradley" and said 
> "... but call me Chelsea".
GB has minimal adverse effect if the signer of the record lies, compared 
to what we
are talking about here.
> Now, obviously you can't infer that naming information is actually 
> true from the fact that it verifies under a phone number credential. 
>  But what you could do is go to some other service and say, "Phone 
> number +1212555121 is asserting the name Chelsea, is that correct?", 
> and they could tell you yes or no.
yes, you could, that does not make it a good idea.
>   1. Take the authenticated phone number and use it as a key to look 
> up additional information from a trusted service ("Who is 
> +12125551212?"  "Bradley")
yes, these are two options, but several others have been put forth.
> In the first case, the third party service provides the information; 
> in the second case, it only verifies it.  (It could be argued that 
> there's a privacy benefit to the second case, since the caller chooses 
> what information is released.  It also could provide a little more 
agreed.
> serves only to bind the additional information to the phone number. 
>  It does not imply any authority to assert the additional information; 
> that authority needs to be come through some other channel.
yes, but Brian suggested, at one point, that the originating SP should 
use the
same key to sign both the number and an asserted name. That, I suggest, 
is a bad idea.
> included in the signed object.
Which signed object? One generated by originating SP, one provided by 
the SP for
the called party, or an object provided by a third party? (don't bother 
answering, as
this is a rhetorical question.)
>  This will probably happen to some degree regardless, since the signed 
> object will attest to SIP header values, of which the additional data 
> could be one.  But it might also be useful to include the additional 
> data more directly, e.g., if will not survive in a SIP header.
maybe.
> which is why we created the new CNIT list for discussion of things 
> like the above two mechanisms.
I hope my replies help clarify my comments too.

Steve