Re: Looking for clarification on reasonable assurance section of RFC 7838

On 13/02/23 2:58 pm, Jaikiran Pai wrote:
> Hello HTTP working group team,
>
> I was going through  the "HTTP Alternate Services" RFC 7838 
> https://www.rfc-editor.org/rfc/rfc7838. Section 2.1 specifies the 
> expectations for host authentication and how clients can establish 
> reasonable assurance that the advertised alternate service should be 
> used. Very specifically, the RFC states:
>
> "Clients MUST have reasonable assurances that the alternative service 
> is under control of and valid for the whole origin.
> ...
>
> For the purposes of this document, "reasonable assurances" can be 
> established through use of a TLS-based protocol with the certificate 
> checks defined in [RFC2818]. Clients MAY impose additional criteria 
> for establishing reasonable assurances.
>
> For example, if the origin's host is "www.example.com" and an 
> alternative is offered on "other.example.com" with the "h2" protocol, 
> and the certificate offered is valid for "www.example.com", the client 
> can use the alternative."
>
> Here, the RFC expects that the certificate offered by the origin (in 
> this case "www.example.com") is valid for the origin 
> (www.example.com). Right?
>
> Or is the RFC expecting that the certificate offered by the 
> alternative service (at "other.example.com") is (also) valid for the 
> origin (www.example.com), perhaps through the use of "Subject 
> Alternative Name" in the certificate offered by "other.example.com"?

The reason I ask this is because later in a subsequent section 2.3, the 
RFC states:

"A client MUST NOT use a TLS-based alternative service unless the client 
supports TLS Server Name Indication (SNI). Note that the SNI information 
provided in TLS by the client will be that of the origin, not the 
alternative..."

Assuming the client has established reasonable assurance by validating 
(only) the TLS certificate of the origin (www.example.com), the client 
will then initiate a TLS connection against the alt-service at 
other.example.com and send SNI hostname "www.example.com" in the TLS 
extension. The alt-service will use the SNI hostname to decide what 
certificate to present in the TLS handshake. For the alt-service TLS 
handshake to be successful, the alt-service would have to present a TLS 
certificate which corresponds to the origin (www.example.com), since the 
client initiated the TLS handshake using SNI hostname "www.example.com". 
If it doesn't, then as per section 3 of RFC-6066 
https://www.rfc-editor.org/rfc/rfc6066#section-3, the TLS handshake 
would fail (in non-interactive clients). Did I understand it correctly?

The RFC for AltService isn't too clear on this part, so I was hoping I 
would get some insight on whether this assessment is accurate. If this 
has been discussed previously, please point me to those threads and I 
will go over them - my search in the mailing list hasn't produced 
anything informative.

-Jaikiran

Received on Tuesday, 14 February 2023 10:30:51 UTC