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

From: Leonid Fainshtein <[email-masked]>
Date: Thu, 6 Aug 2020 15:55:36 +0300

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.

Best regards,
Leonid Fainshtein
Xorcom Ltd

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 10 Aug 2020 10:03:16 +0200

> On 6 Aug 2020, at 14:55, Leonid Fainshtein <[email-masked]> 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. 

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

---

From: Simon MORLAT <[email-masked]>
Date: Mon, 10 Aug 2020 14:51:07 +0200

Hi everyone,

This is my first post on an IETF mailing list, I hope I'll make it the
right way :-).
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 ?

Best regards,

Simon

Le lun. 10 août 2020 à 10:03, Olle E. Johansson <[email-masked]> a écrit :

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 10 Aug 2020 17:03:41 +0200

> On 10 Aug 2020, at 14:51, Simon MORLAT <[email-masked]> 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.
> - 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 <[email-masked] <mailto:[email-masked]>> a écrit :
> 
> 
>> On 6 Aug 2020, at 14:55, Leonid Fainshtein <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi,
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sipcore <https://www.ietf.org/mailman/listinfo/sipcore>

---

From: Roman Shpount <[email-masked]>
Date: Mon, 10 Aug 2020 14:12:23 -0400

On Mon, Aug 10, 2020 at 11:04 AM Olle E. Johansson <[email-masked]> wrote:

> https://tools.ietf.org/html/rfc6125#section-7.2
>

This section essentially says why wildcard certificates must not be used
and can only be supported for legacy applications. Not supporting wildcard
certificates does create a certain degree of pain but given security risks
should continue to be avoided.

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
One thing I've wanted for a long time is an extension which allows to
multiplex several DTLS connections over the same protocol/address/port
pair. This will allow to replicate all the current SIP over UDP deployment
scenarios using a secure protocol. Once this is available, I would
participate or author an RFC.

Best Regards,
_____________
Roman Shpount

---

From: Simon MORLAT <[email-masked]>
Date: Tue, 11 Aug 2020 10:43:56 +0200

Hi,

Thank you for all your answers, this is very helpful.
I did not know RFC 6125. Based on these considerations, I would say that
wildcard certificates will probably disappear for all applications in the
next few years.

Best regards,

Simon

---

From: Daniel-Constantin Mierla <[email-masked]>
Date: Tue, 11 Aug 2020 11:36:15 +0200

Hello,

maybe it should be split in:

1) trusting the certificate to be used for encryption, but asserting the
identity of the peer is done separately. This is the common use case
these days and the goal is to ensure the certificate belongs to the
entity owning the service by association with the main domain name.
E.g., hosted pbx providers with subdomain allocation per customer, like
custid.cloudpbx.lab. Identity of peers is ensured by other meanings like
shared secret. Here wild card certificates are very useful (with the
full left most label being the wildcard), is such case management of
certificates with full domains is getting close to impossible on large
deployments, not only painful.

2) trusting the certificate also for asserting the identity of the peer,
when it needs to match in a 1-to-1 relation. In this case wildcard
certificates are not useful, of course, but I rarely have seen it used
for this purpose.

Cheers,
Daniel

On 11.08.20 10:43, Simon MORLAT wrote:
> I did not know RFC 6125. Based on these considerations, I would say
> that wildcard certificates will probably disappear for all
> applications in the next few years.
>
> Best regards,
>
> Simon
>
>
> Le lun. 10 août 2020 à 20:12, Roman Shpount <[email-masked]
> <mailto:[email-masked]>> a écrit :
>
>
>     On Mon, Aug 10, 2020 at 11:04 AM Olle E. Johansson <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>     This section essentially says why wildcard certificates must not
>     be used and can only be supported for legacy applications. Not
>     supporting wildcard certificates does create a certain degree of
>     pain but given security risks should continue to be avoided.
>
>         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:”.
>
>
>     One thing I've wanted for a long time is an extension which allows
>     to multiplex several DTLS connections over the same
>     protocol/address/port pair. This will allow to replicate all the
>     current SIP over UDP deployment scenarios using a secure protocol.
>     Once this is available, I would participate or author an RFC.
>
>     Best Regards,
>     _____________
>     Roman Shpount 
>
>

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 11 Aug 2020 14:37:57 +0200

> On 11 Aug 2020, at 11:36, Daniel-Constantin Mierla <[email-masked]> wrote:
> 
> Hello,
> 
> 1) trusting the certificate to be used for encryption, but asserting the identity of the peer is done separately. This is the common use case these days and the goal is to ensure the certificate belongs to the entity owning the service by association with the main domain name. E.g., hosted pbx providers with subdomain allocation per customer, like custid.cloudpbx.lab. Identity of peers is ensured by other meanings like shared secret. Here wild card certificates are very useful (with the full left most label being the wildcard), is such case management of certificates with full domains is getting close to impossible on large deployments, not only painful.
> 
Opportunistic crypto always works. What we’re discussing - at least I - is some way to set up a call between trusted peers, so you are right
in dividing the use case. In order to get some undefined level of confidentiality you can just take the public key from any cert presented without
validating, much like most SMTP servers can do today.
> 2) trusting the certificate also for asserting the identity of the peer, when it needs to match in a 1-to-1 relation. In this case wildcard certificates are not useful, of course, but I rarely have seen it used for this purpose.
> 
> 
And it is today a bit undefined what the expected behaviour is. The SIP RFCs only define validation of SIP server certs with a given SIP URI. There are
a few documents from the UTA group describing expected behaviour when using DNS SRV but they are not really following the SIP one. And there’s no documentation whatsoever on client certs, so mutual auth is very hard to set up if you expect interoperability.

I will go through my old documents and presentations. I think I have tried to sort this mess up into some form of agenda a few years ago.

/O :-)
>> I did not know RFC 6125. Based on these considerations, I would say that wildcard certificates will probably disappear for all applications in the next few years.
>> 
>> Best regards,
>> 
>> Simon
>> 
>> 
>> Le lun. 10 août 2020 à 20:12, Roman Shpount <[email-masked] <mailto:[email-masked]>> a écrit :
>> 
>> On Mon, Aug 10, 2020 at 11:04 AM Olle E. Johansson <[email-masked] <mailto:[email-masked]>> wrote:
>> This section essentially says why wildcard certificates must not be used and can only be supported for legacy applications. Not supporting wildcard certificates does create a certain degree of pain but given security risks should continue to be avoided.
>> 
>> One thing I've wanted for a long time is an extension which allows to multiplex several DTLS connections over the same protocol/address/port pair. This will allow to replicate all the current SIP over UDP deployment scenarios using a secure protocol. Once this is available, I would participate or author an RFC.
>> 
>> Best Regards,
>> _____________
>> Roman Shpount 
>> 
>> 
> Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com/>
> www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>