> On Mar 22, 2018, at 4:17 PM, Daniel Kahn Gillmor <[email protected]>
> wrote:
>
>>
>> [...] The
>> server MAY rely on SNI to determine which certificate chain to
>> present to the client. Clients that don't send SNI information may
>> not see the expected certificate chain.
>>
>> If the server's TLSA records match the server's default certificate
>> chain, the server need not support SNI. In either case, the server
>> need not include the SNI extension in its TLS HELLO, as simply
>> returning a matching certificate chain is sufficient. Servers
>> MUST NOT enforce the use of SNI by clients, as the client may be
>> using unauthenticated opportunistic TLS and may not expect any
>> particular certificate from the server. If the client sends no SNI
>> extension or sends an SNI extension for an unsupported domain, the
>> server MUST simply send some fallback certificate chain of its
>> choice. The reason for not enforcing strict matching of the
>> requested SNI hostname is that DANE TLS clients are typically willing
>> to accept multiple server names but can only send one name in the SNI
>> extension. The server's fallback certificate may match a different
>> name acceptable to the client, e.g., the original next-hop domain.
>
> for reference, Viktor is proposing this text for inclusion in the
> MTA-STS draft, to ensure that servers are liberal about SNI -- it should
> be up to the client to reject a failed authentication, not for the
> server to pre-emptively abort.
"Approximately" this text, since it needs a bit of adjustment to make it
less DANE-specific. Specifically:
>> If the server's TLSA records match the server's default certificate
>> chain, the server need not support SNI. In either case, the server
>> need not include the SNI extension in its TLS HELLO, as simply
>> returning a matching certificate chain is sufficient.
Needs to be generalized. The first sentence would be changed to talk
about servers that don't need SNI because they only have one identity
and a single matching certificate, so no point in doing SNI. The
second sentence points out that there's no need to ACK the SNI
extension, just return a sensibly chosen certificate.
Further down:
>> The reason for not enforcing strict matching of the
>> requested SNI hostname is that DANE TLS clients are typically willing
>> to accept multiple server names but can only send one name in the SNI
>> extension.
Actually applies to STS servers that also do DANE, or in any case because
clients that do opportunistic STARTTLS should not (and generally don't,
though some broken ones reject the certificate and then send in cleartex!)
care what chain is returned.
So this needs a bit of translation to STS, but the general idea is the
same, and much of the language is applicable.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
