Subject: [Uta] SNI text from 7672

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 22 Mar 2018 14:49:18 -0400

https://tools.ietf.org/html/rfc7672#section-8.1

   [...] 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.

-- 
	Viktor.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 22 Mar 2018 20:17:26 +0000

>    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.

       --dkg

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 22 Mar 2018 19:38:01 -0400

> On Mar 22, 2018, at 4:17 PM, Daniel Kahn Gillmor <[email-masked]> wrote:
> 
>> 
>>   [...] The

"Approximately" this text, since it needs a bit of adjustment to make it
less DANE-specific.  Specifically:

>>   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
>>   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.