Subject: [Sip] impractical keying requirement in sip identity draft

From: Juha Heinanen <[email-masked]>
Date: Mon, 10 Oct 2005 21:40:25 +0300

in my opinion, it is no practical to require that a company would supply
private keying material regarding its domain to whoever party that
happens to host its sip proxy service.  that simply does not happen.

if sip srv record of, say, cisco.com, points to sip.provider.com, then
it must suffice that sip.provider.com uses its own keying material to
sign the identity of cisco.com users.

and even if sip.provider.com proxy would posses keying material of
domain cisco.com, i don't understand how it could know which server
certificate it should present to a sip ua when it establishes tls
connection with the proxy, because that happens before the sip ua has
sent any sip requests and because it is impractical to require that each
domain would have its own ip address or port at the proxy.

it may be that i'm missing something, but if not, it makes no sense for
ietf to write specifications that cannot have real world
implementations.

-- juha

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 25 Oct 2005 16:10:26 -0400

Actually, Juha, I think DNSSEC is a very promising direction for discovering keys associated with domains, including the keys used by sip-identity. For the moment, however, it remains a direction. The operational issues associated with deploying DNSSEC are well known, and while the situation has certainly gotten a lot better of late, it will still be some time before DNSSEC signatures could really become a part of the security story for applications like SIP. I don't think it would be a worthwhile exercise to try to build DNSSEC-like solutions for signing/providing keys for SIP as a work-around.

So, while I think it would be worth revisiting the use of DNSSEC for sip-identity when it becomes widely deployable, for the moment I think we would be best served to stay our current course.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Juha Heinanen [mailto:[email-masked]]
> Sent: Sunday, October 23, 2005 6:19 PM
> To: Rohan Mahy
> Cc: Peterson, Jon; [email-masked]
> Subject: Re: [Sip] impractical keying requirement in sip 
> identity draft
> 
> 
> Rohan Mahy writes:
> 
>  > Provider.net <http://Provider.net> today determines what 
> domain it is
>  > serving based on the port number (set via SRV).
> 
> are you saying that each time a provider adds a new domain to 
> its proxy,
> the proxy would need to start listening on a new port?  in all proxies
> that i know, this would mean restarting the proxy, which is very bad.
> 
> looks like the extended client hello that jon pointed to, might be a
> better solution.  but as far as i know, it is not yet supported by
> openssl library, for example.
> 
>  > Provider.net<http://Provider.net>is hosting several TLS domains and
>  > for good providers, each hosted domain
>  > can have separate certs and private keys. Example-A.com 
> does not have access
>  > to Example-B.com's private key and vice versa.
> 
> but provider needs access to both, which is my original concern.
> 
>  > Another standardized but not yet deployed way to solve 
> this problem is to
>  > use the TLS extended client hello extension to provide the 
> name of the
>  > server. When implemented, this allows the server to 
> provide the certificate
>  > of the expected domain on a single port. This is documented in RFC
>  > 3546.
> 
> yes.
> 
> all this hassle seems to result from not being able to trust dns.  why
> not simply sign the dns records pointing to the proxy after which the
> proxy would only need to sign itself?
> 
> -- juha
>