Elwell, John wrote:
Jiri,
Well, you could argue that P-Asserted-Identity is btn security - you
simply have to trust the chain of SIP intermediaries without having
visibility of who exactly is in that chain. I am not convinced that
DERIVE, either in its current documented form or taking into account the
many helpful suggestions during the last couple of weeks, can really
claim to add very much.
The fact that the mechanism can yield a significant number of "false
positives" (or perhaps "false negatives" is the right term) means the
mechanism, as it stands, fails to provide a safe means by which I can
decline or ignore calls I don't want, or send them to voicemail if I
don't want them right now. I think this limits its applicability.
Hi John,
My apologies for so late answers -- I have been too offline recently.
Anyhow -- while this is a certainly a legitimate concerns, I don't
think it is a prohibite one -- I think it is a migration one. That means
the value is initially low and grows with size of the "derive network".
One particularly appealing aspect of DERIVE as documented is that it
tries to avoid special behaviour at the calling side, as noted during
the meeting. So I would still appreciate any further ideas that have
this same property.
I think too that's very important. IMO, for this type of BTN security
size of the "network" is really important, and for that simplicity is
the key. For such results I'm playing a bit with the SPF idea -- would
not that be perhaps something that would gain us good adoption? It gains
as less than dialog verification, but it is still getting us BTN at
per-domain level.
I appreciate your efforts on this and, believe me, I really want to
explore all possible ideas for solving this identity problem. So don't
let the absence of success with this discourage you from submitting
other ideas.
Thank you very much indeed, -jiri
_______________________________________________
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
