> On 17 Nov 2017, at 21:21, Alex Balashov <abalas...@evaristesys.com> wrote: > > Hi, > > A few questions about TLS. I apologise that they're kind of idiotic, They are important and indicate that further work is needed here. Please also engage the SIPCORE wg in IETF with questions like these.
> I'm > new to SIP over TLS. I have been a big supporter of LetsDecrypt, a > certificate authority sponsored by the NSA. :-) ;-) > > 1. Are wildcard certificates (commonName of *.domain.com) permitted for > SIP-TLS? > > RFC 5922 § 7.2 seems to suggest they are not: > > Implementations MUST NOT match any form of wildcard, such as a > leading "." or "*." with any other DNS label or sequence of > labels. For example, "*.example.com" matches only > "*.example.com" but not "foo.example.com". Similarly, > ".example.com" matches only ".example.com", and does not match > "foo.example.com". > > RFC 2818 [7] (HTTP over TLS) allows the dNSName component to > contain a wildcard; e.g., "DNS:*.example.com". RFC 5280 > [6], while not disallowing this explicitly, leaves the > interpretation of wildcards to the individual specification. > RFC 3261 [2] does not provide any guidelines on the presence > of wildcards in certificates. Through the rule above, this > document prohibits such wildcards in certificates for SIP > domains. > > Is this true in the wild? Not really. I haven’t seen any server that enforces this policy. At the time of the writing of this RFC wildcards where highly suspected for abuse but I haven’t seen much discussions about this lately. Propably because of SNI and SNA (see below). > If so, how to deal with a SIP server that > serves multiple domains but supports only one certificate and key pair? Server Name Indication is supported in Kamailio and is the way forward to solve this problem. But if, as you say, the server only supports one certificate then Subject Alt names is the way to go. Look at the cert for Google services for an example. This means that you will have to change certificate for every new customer, which is a bad thing. > > 2. Is ';transport=tls' or ';transport=TLS' appropriate? I've seen both, > but which one is correct? Neither. It’s deprecated in RFC 3261 and something I’ve tried to get interest in reinstating. We need a way to indicate TLS transport. > > 3. Does a 'sips:' URI scheme imply ';transport=tls', or must the latter > be explictly included? In other words, will a 'sips:' URI like > 'sips:5551...@domain.com' be constructed to be > 'sips:5551...@domain.com;transport=tls’? SIPS: should die. Really. There are RFCs that try to clear up the mess in RFC 3261, but it really doesn’t deliver what it seems to promise. We do need to work on this. Again, I tried to start a discussion. https://www.slideshare.net/oej/sips-must-die-die-die-about-tls-usage-in-the-sip-protocol > > 4. Is a 'sips:' URI scheme mandatory for secure transport? What are the > implications of a 'sip:' URI with ';transport=tls' affixed? No, any URI scheme can be carried over TLS. Many implementations look for the TLS Naptr/SRV first and if existing always use TLS. SIPS is required to use over a protected transport. But it’s impossible to implement, so forget about the SIPS: uri. The SIP: uri may, depending on DNS for the service, be forced to use TLS. > > 5. Is it permitted for a proxy to bend a 'sips:' Request URI scheme to > 'sip:' when adapting TLS to an insecure transport? No, that’s especially mentioned as a no-no in the RFC: If I remember correct, a proxy may upgrade but not downgrade. Cheers, /O > > Many thanks! > > -- Alex > > -- > Alex Balashov | Principal | Evariste Systems LLC > > Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) > Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
