Re: [sipcore] Enabling the wildcard certificates for SIP TLS implementation

> On 10 Aug 2020, at 14:51, Simon MORLAT <simon.morlat@gmail.com> wrote:
> 
> Hi everyone,
> 
> This is my first post on an IETF mailing list, I hope I'll make it the right way :-).
Welcome!

> Just to give a few information about me, I'm the original author of Linphone, a free-software SIP softphone, and now co-owner and manager of Belledonne Communications, the company developing Linphone since 2010.
> 
> Thanks to Leonid to raise this concern. I must say I always found RFC 5922 really strange with this prohibition of wildcard certificates, with no reason given.
> Actually, if wildcard certificates are good for https as well as for many internet services, I would expect an argument that explains how SIP is different from all others and why as such, wildcard certificates are bad.
> Fundamentally, I don't see why sip should be different from http on this aspect.
> I must admit that in Linphone's SIP implementation we have finally decided, a couple of years ago, not to follow RFC5922 on this point.
> Because SIP services can comprise multiple nodes and rely on SRV records (which http usually does not), it is very convenient to use wildcard certificates. At this time Letsencrypt wasn't existing yet. I agree that this limitation is now more easy to overcome.
> Our decision was motivated by:
> - the convenience of wildcard certificates for SIP services (with multiple SRV balanced hosts)
> - the absence of any argumentation for this in RFC5922, which is something really odd compared to all RFCs and even drafts I could read. Could it be a mistake ?
> 
> I hope too someone can give us a clear argument. Otherwise, could it be envisaged to publish some kind of errata or new RFC that changes this requirement ?
> 

I found documentation in RFC 6125 from the “Using TLS in applications” working group.
https://tools.ietf.org/html/rfc6125#section-7.2 <https://tools.ietf.org/html/rfc6125#section-7.2>

Also note the documentation covering SIP in section B.9.

While we may do as HTTPS with DNS Subject Alt Names, we can’t do that with the URI Subject Alt Names that we prefer to use in SIP,
but doesn’t have widespread use.

Changes are done by publishing a new RFC, not with Errata. That will open up a whole can of worms, but we need to open it
and specify how SIP over TLS should work. Like the "transport=TLS” stuff and deprecating “SIPS:”.

I have spoken about this a number of times. Some docs are to be found on slideshare.net/oej <http://slideshare.net/oej> 

Cheers,
/O

> Best regards,
> 
> Simon
> 
> 
> Le lun. 10 août 2020 à 10:03, Olle E. Johansson <oej@edvina.net <mailto:oej@edvina.net>> a écrit :
> 
> 
>> On 6 Aug 2020, at 14:55, Leonid Fainshtein <leonid.fainshtein@xorcom.com <mailto:leonid.fainshtein@xorcom.com>> wrote:
>> 
>> Hi,
>> The "7.2.  Comparing SIP Identities" of RFC-5922 prohibits the usage of wildcard certificates.
>> The reasons for this limitation are not clear. The restriction only complicates the multi-home SIP servers configuration and maintenance. 
>> I suggest enabling the wildcard certificates for SIP.
> 
> With wide-spread support for TLS SNI and free services like Letsencrypt I don’t really see a problem with not supporting wildcards.
> 
> On the other side, I do agree that the argumentation for this limitation is missing. I remember there was a widespread discussion
> over multiple working groups about problems with wildcards. Let’s see if we can dig up something from other RFCs or if someone
> has a clear argument.
> 
> /O
> 
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org <mailto:sipcore@ietf.org>
> https://www.ietf.org/mailman/listinfo/sipcore <https://www.ietf.org/mailman/listinfo/sipcore>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore