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

> On 11 Aug 2020, at 11:36, Daniel-Constantin Mierla <miconda@gmail.com> wrote:
> 
> 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.
> 
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 :-)
> Cheers,
> Daniel
> 
> On 11.08.20 10:43, Simon MORLAT wrote:
>> 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
>> 
>> 
>> Le lun. 10 août 2020 à 20:12, Roman Shpount <roman@telurix.com <mailto:roman@telurix.com>> a écrit :
>> 
>> On Mon, Aug 10, 2020 at 11:04 AM Olle E. Johansson <oej@edvina.net <mailto:oej@edvina.net>> wrote:
>> 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>
>>  
>> 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 
>> 
>> 
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf.org <mailto:sipcore@ietf.org>
>> https://www.ietf.org/mailman/listinfo/sipcore <https://www.ietf.org/mailman/listinfo/sipcore>
> -- 
> 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>