Pierce, Chris, and Martin,
Please bear with the long email, I have a section for each of you below. I have also copied the IP-NNI email distribution list for transparency.
Pierce,
Thank you for calling me after the ALIII certificate subgroup meeting. I am really glad we were able to discuss the contribution. Below is summary of our call:
At a high level, I think everything you have so far is really good.
I think there are some things that can be simplified, particularly the AAT. I think this could be nearly identical in format to the SHAKEN SPC token. I would just remove the ca boolean given I don't think we want to support SCAs in ALIII. I also think we should use the TNAuthList x.509 extension in ALIII just like we do in SHAKEN (and only allow SPCs, no TNs, like SHAKEN). I am NOT suggesting that we reuse the SHAKEN PKI. The PA certificates, CA certificates, and service provider certificates in ALIII should all be independent of the SHAKEN PKI. But that doesn't mean we can't reuse the same APIs and certificate extensions we defined in the SHAKEN PKI.
I think our refusal to reference ACME in this document is a major mistake. I am NOT proposing that we mandate ACME. However, I am not aware of any standards for domain validation that are defined outside of ACME related standards. So that means that if we are unwilling to reference any ACME related standard in this document, we would then either need to 1) define our own domain validation procedure or 2) not describe the domain validation procedure. I think it is a mistake for IP-NNI (a group focused on telecom network interfaces) to attempt to define a procedure for domain validation (a complex security topic that has nothing to do with telecom). And I think this document needs to describe a domain validation procedure because if not here, where and by who would the domain validation procedure for ALIII be defined? Therefore, I think referencing the ACME standards is the best option we have. But I want to repeat that I am not saying that ACME should be a mandate. CAs should be able to offer alternative protocols (e.g., CMP or proprietary protocols) so long as they are able to describe in their CPS how they are able to perform domain validation that meets or exceeds the level of security the ACME domain validation mechanisms (dns-01, http-01, etc.) provide.
Chris,
You sent the following (very well written) email.
======
Hi Pierce,
Happy to jump on a call. We've done a lot of work around automation of certificate management for SIP connectivity outside of the ATIS ALIII work, and we previously discounted ACME due to the inherent complexity brought about by the Domain Validation mechanism, and the fact that it was speficically designed for Web (HTTPS) connections, rather than SIP over TLS or other protocols.
RFC8555 mandates Domain Validation be carried out through 1 of 2 options (RFC8737 adds a 3rd option), but each of these brings unique challenges:
HTTP-01 - This mechanism uses HTTP requests to the ACME Client (in our case, that'd be an SBC run by the AVSP) in order to validate the requestor is the same entity as listed against the FQDN in the request. The issue here is that, because the SBC is not a web server, you'd need to run a web server against every SIP interface on the SBC. If you have 100's of interconnects, this would end up with a significant performance hit. Additionally, as it's running on port 80, you're making the SBC more vulnerable to discovery through port scanning, and providing a whole new server layer that needs to be secured. My recommendation is that this method be explicitly excluded from the ALIII specs for the SIP over TLS certificates for these reasons.
DNS-01 - This mechanism requires the ACME Client to publish a TXT record with the token to the DNS server, which the ACME Server can verify. However the RFC does not specify any mechanism for the publication of the TXT record. This can lead to messy implementation as each DNS provider uses bespoke API's for DNS zone management. The best solution we would have here is to mandate that these updates use the DNS UPDATE method outlined in RFC2136. I believe this would be the most feasible method for Domain Validation of a SIP endpoint for ACME, as it doesn't open any additional ports on the SBC, and does not require any significant additional resources to be running on the SBC. However, while most DNS providers should support RFC2136, there's no guarantee that they do.
TLS-ALPN-01 - This was introduced in RFC8737 as an alternate mechanism for Domain Validation. It validates the domain using a TLS handshake, which makes it a little better than HTTP-01 (as it's agnostic to the application protocol) but it mandates that this handshake be performed against port 443 on the SBC. This would of course make the SBC vulnerable to discovery through port scanning on the public internet. Additionally, support from Public CA's is very limited. It appears that LetsEncrypt support it, but doesn't look like other major CA's like DigiCert, Sectigo etc do (yet).
The other option could be to mandate the use of a different certificate management protocol, such as CMPv2, that doesn't use this Domain Validation mechanism (as that's being handled out of band in the spec anyway).
Please let me know if you want to discuss in a call.
Regards,
Chris
======
Your comments on HTTP-01 and TLS-ALPN-01 make sense; they really aren't good validation mechanisms for SIP devices. Also, I agree with you, DNS-01 is the most feasible method, though it does pose some challenges (particularly lack of standardization around DNS updates). However, I am confused by the conclusion of this email. Are you saying we should just skip domain validation? If yes, then what prevents man-in-the-middle attacks for ALIII mTLS connections (which use domains and are susceptible to man-in-the-middle attacks unless the domains are validated)? If no, then how do you propose we perform domain validation?
Martin,
I would like to propose that in this document we describe the certificate issuance process using ACME but provide the option for alternatives. This would be similar to what we did in ATIS-1000080, we referenced and described ACME but did not mandate it. If you disagree, then can you please help me understand what the plan is for this document? Do you think ALIII doesn't need domain validation? Or is there some other domain validation standard we can reference that I am just not aware of? Or do you think we should define our own domain validation mechanism? Or do you think we should not define it in standards at all, in which case, where and by who would it be defined?
Sincerely,
Alec Fenichel
Chief Technology Officer