[TLS] Re: RFC 9849 clarifying split mode security

[Florentin Rochet <[e-mail]>]

Le 10/04/26 à 16:43, Ben Schwartz a écrit :

> On Fri, Apr 10, 2026 at 7:26 AM Florentin Rochet 
> <[e-mail]> wrote:
>
>     ZjQcmQRYFpfptBannerEnd
>
>     I think the Client-Facing Server can generate a valid signing key
>     and its certificate, and get the certificate signed  by answering
>     the ACME challenge on behalf of the Backend Server. It does not
>     need the Backend Server to reveal its own signing key. So,
>     impersonation seems possible in a regular active attacker settings.
>
> I don't object to this threat model, but it is not the threat model 
> generally used in TLS.  In this threat model, TLS is not secure 
> against transport intermediaries (e.g. a TCP load balancer), who are 
> also in a position to intercept ACME challenges.  TLS assumes that it 
> is being used with a secure PKI.

There are indeed subtle situations in which active attackers may abuse 
the Web PKI. The one you mention with load-balancers depends on where 
these machines are located and how we model trust. I *believe* they're 
usually located close to the destination server and can been seen as a 
body part of what the server is, if you allow me this analogy. So, they 
aren't "separated" as worded by the RFC.

A situation closer to the split-mode problem would in my opinion a BGP 
hijack followed by an ACME challenge.   Of course the TLS protocol 
cannot deal with this issue by itself, but it does not mean it is not 
recognized as an issue.

I think the problem I have with the RFC is that it is unclear about the 
privacy guarantees. In the one hand, Section 3.1 says:

>     In split mode, the provider is not the origin server for private
>     domains.  Rather, the DNS records for private domains point to the
>     provider, and the provider's server relays the connection back to the
>     origin server, who terminates the TLS connection with the client.
>     Importantly, the service provider does not have access to the
>     plaintext of the connection beyond the unencrypted portions of the
>     handshake.

establishing that the service provider has no access to the data stream. 
Well, this is only true if the service provider does not abuse the PKI 
it is been set-up with, and we need this trust assumption. So at best, 
the split-mode would be secure in a honest-but-curious client-facing 
provider settings. I think this should be explicit.

In the other hand, Section 10.1 seems to establish that there is a trust 
relationship with the client-facing provider, but fails to be explicit 
on what trust assumption we have. I think this is going to create confusion.

>     Is there a method for a backend server to authorize certificate
>     issuance for its domain only by DNS records?
>
> Yes: the CAA record with specified "validationmethods" (RFC 8657, 
> Section 3), e.g.
>
> example.com 
> <http://example.com/>. 
> IN CAA 0 issue "example.net 
> <http://example.net/>; 
> validationmethods=dns-01"

Great, thank you :-)

>     Is there a way for client to notice such a policy and refuse any
>     other certificate?
>
> No.  CAA records are not intended for use by clients.  To benefit from 
> CAA records, clients must choose root CAs whom they trust to respect 
> CAA directives.  Clients that wish to use TLS with trust rooted 
> exclusively in the DNS can use DANE (RFC 7671).

If I am not mistaken, DANE is not supported by some major browser 
vendors :( But do we need DANE? This was designed to bypass CAs; here we 
only need to cooperate on issuance policies, and there might be a path 
forward that does not sacrifice the current efforts to improve the PKI 
(e.g., CT logs).

Best,

Florentin