Hadriel, > -----Original Message----- > From: Hadriel Kaplan [mailto:[EMAIL PROTECTED] > Sent: 15 March 2008 17:36 > To: Elwell, John; IETF SIP List > Subject: RE: Straw-man for rfc4474 and e164 > > > > > -----Original Message----- > > From: Elwell, John [mailto:[EMAIL PROTECTED] > > > > What I want is the end domain, e.g., my bank. Being assured > my call is > > secured as far as my service provider gives me no confidence it is > > secured as far as my bank or whatever domain I want to > communicate with. > > That is why "email-style" is so much better than phone-number-based. > > Sure, and that works well for domain names you recognize, if > your UA displays it, because really you're mentally treating > it as an email-style URI. (and also why Paul said this would > only work for whitelists) But if it is a call from > sip:[EMAIL PROTECTED] signed by cht.com.tw, it would > mean nothing to most people. [JRE] Exactly, and therefore if the person claims to be from my bank I would probably be very suspicious.
> The verifier would think it's > fine as would your UAS, and it may be fine (Chunghwa Telecom > is a legit telco). Or it may be that CHT got it from a CLID > spoofer service in the PSTN, or CHT is mis-configured, or a > CLID spoofer provider itself. (they're not, but you wouldn't > know that, and the fact that a +1 number came from Chunghwa > Telecom is suspicious) > > The straw-man says CHT would only sign it "if it believes > that calls to that number will reach the user". I'm not > actually sure what that means. I think you mean if calls to > that username number would reach the same domain that's > signing it?? Regardless, if CHT *were* to offer a CLID > spoofer service, it would obviously sign it anyway, and no > one would be wiser. For email-style URI's that's not > possible, because CHT can't sign sip:[EMAIL PROTECTED] > Siemens could sign it maliciously, but doing so only spoofs > siemens.com's users. Whereas CHT signing > sip:[EMAIL PROTECTED] maliciously actually spoofs the > real owner of +12128675309 globally, because it is treated by > machines and humans as a global identity regardless of the domain. [JRE] I think what the straw man meant is that CHT should sign it if, by routing a return request back to CHT, CHT would be able to route that return request to the entity that was the source of the original request. So if CHT somehow authenticated the original request as coming from [EMAIL PROTECTED], it could sign it has having come from [EMAIL PROTECTED] and then, on receiving a return request to [EMAIL PROTECTED], could route it on to [EMAIL PROTECTED] How helpful is this to the receiver of the original request? It just means that return routability via CHT should work, and not that CHT.com is the end domain from which the original request came. Not very useful for authentication purposes. But on the other hand, an unchanged From URI ([EMAIL PROTECTED]) might be more useful. John _______________________________________________ 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
