... > So let me get this, um, straight: what people really want is > to be able > to trust the callerid but that's precisely what we can't provide. Hmm. > And many of things that you point out about breakage with 4474 is > not _really_ a fault of 4474 per se, it's that you're hoping > essentially for the impossible: having a signature survive through > a b2bua sausage factory. > > Sounds all too familiar.
It sounds familiar because email has similar problem. SIP's B2BUA 'sausage factory' is akin to email's mailing list 'sausage factory'. DKIM managed to engineer a solution to email's mailing list sausage factory, yes? There are now three proposals to engineer a solution to SIP's B2BUA 'sausage factory': draft-wing-sip-identity-media, draft-fischer-sip-e2e-sec-media, and draft-kaplan-sip-asserter-identity. The worthwhile first problem is not reputation, but just a usable white-list. Whitelists without cryptographic identity are only good until spammers successfully guess or successfully determine what identities are on your whitelist. With only 10 billion E.164 numbers in the +1 country code, it shouldn't take them nearly as long as it did for spammers to start guessing email whitelists. (I have a whitelist for [EMAIL PROTECTED], but only if it came via one of Amazon's mailers. This is because spammers learned that many people, such as me, had such a whitelist. Criminals that, today, send email that looks like it came from my bank are likely, tomorrow, to initiate VoIP calls with an E.164s that belong to my bank. I would like to have cryptographic identity standardized when that happens so that we do not incur an additional two year delay in getting it standardized and then another year delay to get it into products.) -d > I agree with the "blame me" stance, and I'm > not dissing the idea of 4474 being more flexible in what headers it > can sign. It's just that this is all very tangled with the possible, > the impossible and the unknown. > > > > > >> Waiting-and-seeing what the reputation folks actually need > versus guessing > >> what they might need, maybe, someday seems prudent to me. That's > >> doubly true because there's not been much if any uptake of 4474 and > >> I'm guessing that lack of coverage of P-A-I is not one of > the reasons. > >> Concentrating on _that_ problem seem to me the paramount concern. > >> > > > > There has not been any uptake of 4474 for a bunch of > reasons, not the least of which is there's no problem yet, > and for some/many cases we know it won't work. I have no > doubt a PASS signature is not the be-all-end-all solution. > But I do know it takes years to get something spec'ed, > implemented, tested, and deployed in any scale that will > matter. So I'm trying to do a short-cut, instead of waiting > for a problem: thus, an informational P-header. > > > A short cut! Run away! :) > > Seriously, if you want a short cut, you too could hack on one > of the open > source versions of DKIM and have something that can sign your P-A-I > (in a fit of dementia, I have actually DKIM-signed SIP > messages for grins). > DKIM is probably less brittle than 4474, but it too is > imperfect against > b2bua > grinders. > > Which all rather begs the question of what problems for what audience > we're really solving for. If it's for reputation people, I'm > not sure that > P-A-I signed/unsigned makes a big difference. Of course it's no secret > that I think that lipstick on the tel: uri pig is pretty > useless, so I'm > struggling > if there's anything more here than trying to slay the unslayable. > > 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 _______________________________________________ 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
