Dean Willis wrote:
>
> On Apr 4, 2008, at 1:20 PM, Michael Thomas wrote:
>> Rather than work on a solution, I'd rather hear why a receiver cares
>> about any of this. Ie, what does the consumer of this information do
>> differently? The experience from the email world thus far is "not much"
>> which makes me suspicious this is too abstract a problem for the outside
>> world to care about.
>>
>
> That's a fair question.
>
> The worry is that an RFC 4474 identity assertion forms what is
> essentially a contract verification "I, identity service example.com,
> have verified according to best current practices that the party
> originating this message is authorized to use the identity
> sip:[EMAIL PROTECTED]".
Is 4474 really that emphatic? Can you point me to the section that defines
that (sorry, I'm not being rhetorical). That's a pretty high barrier,
and strikes
me as a very hard thing for any bulk signing service to guarantee. DKIM
is far weaker.
>
> We generally assume the "best current practices" something on the
> order of "the party in question has presented credentials based on a
> secret known to sip:[EMAIL PROTECTED] and presumably unknown to other
> parties, and this presentation is consistent with prior interactions
> had by this identity service and sip:[EMAIL PROTECTED]".
That puts an awful lot of responsibility on the signer, especially if the
signer isn't colocated with the credential verification. With DKIM, we
do not make that kind of guarantee; it's up to the domain itself to
determine what the best practices are which might be some cryptographic
guarantee (say, SMTP auth), or might be layer 8 guarantee ("you'll
lose your job if you do this"). By not making any explicit guarantee
about the authorization to use a given local part, we skate around
this thorny issue and frankly makes it a lot easier to roll out a signer.
>
> But when the identity assertion is coming from a PSTN caller ID, it's
> significantly less authoritative statement: "I, the identity service
> at example.com, think that this request came from +12142821376 because
> this is the calling party identifier presented to my telephony
> interface."
Why is this limited to just the PSTN? Given your average megacorp or
telephant,
the possibility for spoofing of the local part seems pretty significant
when you're
talking about bulk signers. Weakening the guarantees to "you can complain
to my SIP admins" is a lot easier to achieve in real life.
>
> There is a profound liability distinction between these two. Failure
> to resolve it means that RFC 4474 identity headers would never be more
> credible than PSTN caller-ID, and we seem to think they need to be
> more credible.
I don't buy this: PSTN caller id is a cross domain transitive trust model.
4474 limits this to domain boundaries. That people want to put e.164
like thingies in the localpart doesn't change who controls the namespace:
it's the domain's, fullstop. Trying to go anything beyond saying that the
localpart is anything beyond an opaque blob as far as the receiver is
concerned is essentially saying that I want to tell you my rules for laying
out my name space, part of which has thingies that look (but aren't)
e.164 blobs.
I really don't think you want to go here. The complexity here is
enormous.
But I'm not sure that my question was answered though: what do you
expect a receiver to do differently? Are you thinking about human
factors on the UAS? Something else?
Mike
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
