Subject: Re: [Uta] SNI text from 7672

From: Daniel Margolis <[email-masked]>
Date: Wed, 18 Apr 2018 15:18:55 +0000

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-masked]>
wrote:

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 18 Apr 2018 11:46:45 -0400

> On Apr 18, 2018, at 11:18 AM, Daniel Margolis <[email-masked]> wrote:
> 
> 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. 

Looks largely fine to me.  I am not fond of the HTTP-specific dictum:

  HTTP servers MUST respond with a certificate chain that matches the policy
  hostname or abort the TLS handshake if unable to do so.

If that's what HTTPS requires generally, so be it, but if this goes beyond HTTPS requirements, then I think the decision of whether to abort the handshake belongs
with the client and NOT the server.  If the client is willing to accept "the wrong"
certificate, there's nothing the server can do about that.  An attacker won't
abort the connection.  Presenting a default certificate, when one that matches
the SNI is not available makes it much easier for the client to troubleshoot the
problem.

----

On a related note, it has just been brought to my attention that Gmail's SMTP servers
refuse to negotiate TLS 1.3 when the connecting SMTP client offers TLS 1.3, but does not send SNI, they instead negotiate TLS 1.2 and return a self signed certificate instead of the usual CA-issued certificate.  The subject DN is:

   OU=No SNI provided; please fix your client., CN=invalid2.invalid

And yet, when SNI is presented, the same default CA-issued certificate is returned regardless of the SNI value!  While TLS 1.3 says that servers MAY require SNI, and hence 
that clients SHOULD send SNI, and SNI is mandatory to *implement*, it is NOT mandatory to use.

Forcing a downgrade to TLS 1.2, and failing authentication to boot, for lack of SNI seems rather counter-productive.  Is there a good reason to do this?

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Wed, 18 Apr 2018 15:54:14 +0000

On Wed, Apr 18, 2018 at 5:47 PM Viktor Dukhovni <[email-masked]>
wrote:

> If that's what HTTPS requires generally, so be it, but if this goes beyond
> HTTPS requirements, then I think the decision of whether to abort the
> handshake belongs

Yes, this struck me as odd, as well, so I'm glad you called it out. I'm not
sure what the reasoning was behind that sentence. I would note, I guess,
that clients MUST require a matching cert, or else they're not
protocol-compliant, but there's no reason to require the server to do
anything here, really.

> refuse to negotiate TLS 1.3 when the connecting SMTP client offers TLS
> 1.3, but does not send SNI, they instead negotiate TLS 1.2 and return a
> self signed certificate instead of the usual CA-issued certificate.  The
> subject DN is:
>
> And yet, when SNI is presented, the same default CA-issued certificate is
> returned regardless of the SNI value!  While TLS 1.3 says that servers MAY
> require SNI, and hence
> Forcing a downgrade to TLS 1.2, and failing authentication to boot, for
> lack of SNI seems rather counter-productive.  Is there a good reason to do
> this?
>

How is it counter-intuitive? TLS 1.3 requires SNI, no?

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 18 Apr 2018 19:23:12 +0300

> How is it counter-intuitive? TLS 1.3 requires SNI, no?

No, it does not.

- The server MAY require SNI.
- The client SHOULD send SNI.
- If the server requires SNI and client does not send one,
  the server SHOULD send missing_extension alert.

-Ilari

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 18 Apr 2018 12:24:23 -0400

> On Apr 18, 2018, at 11:54 AM, Daniel Margolis <[email-masked]> wrote:
> 

No, TLS 1.3, *does not* require SNI.  SNI is mandatory to implement, but NOT mandatory to use:
  
 https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.4.2.2

 -  The "server_name" [RFC6066] and "certificate_authorities"
    extensions are used to guide certificate selection.  As servers
    MAY require the presence of the "server_name" extension, clients
    SHOULD send this extension, when applicable.

 [...]

 Additionally, all implementations MUST support use of the
 "server_name" extension with applications capable of using it.
 Servers MAY require clients to send a valid "server_name" extension.
 Servers requiring this extension SHOULD respond to a ClientHello
 lacking a "server_name" extension by terminating the connection with
 a "missing_extension" alert.

Downgrading to TLS 1.2 with a deliberately unverifiable certificate seems rather drastic.

In the world of SMTP, with SMTP server names determined indirectly
and generally insecurely from MX records, it is not generally clear
what name one would use in SNI, and many SMTP clients don't send it
at all.  Some authenticate servers against the nexthop domain (the
envelope recipient domain), others might authenticate the MX host,
or just do unauthenticated opportunistic TLS.  This has worked
acceptably well with TLS <= 1.2

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Wed, 18 Apr 2018 16:25:12 +0000

Ah, then I don't know. There was some more discussion of this on the mailop
list (as I know Viktor saw), but it doesn't seem to have resolved this
question.

(I don't know offhand what the actual or intended behavior here is, aside
from what Viktor shared, so take what I say with a big grain of salt.)