Re: [Uta] SNI text from 7672

[Daniel Margolis <[e-mail]>]

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 <[e-mail]>
wrote:

>
>
> > On Mar 22, 2018, at 4:17 PM, Daniel Kahn Gillmor <[e-mail]>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uta
>