Thanks. I think this is consistent with what was added here: https://github.com/mrisher/smtp-sts/blob/master/mta-sts.txt#L633. If not, let me know.
Thanks again. On Fri, Mar 23, 2018 at 12:38 AM Viktor Dukhovni <[email protected]> wrote: > > > > 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 >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
