Subject: [TLS] Warning alert before TLS 1.3 ServerHello

From: Roelof duToit <[email-masked]>
Date: Wed, 9 May 2018 13:14:38 -0400

In one of our tests OpenSSL 1.1.1-dev sends an unrecognized_name warning alert before a TLS 1.3 (draft 26) ServerHello.  Alert level is supposed to be implicit in TLS 1.3, but in this case it is ambiguous.  Should it even be considered a “TLS 1.3 alert” given that it arrives before the protocol version is confirmed? 

TLS 1.3 draft section 6 states that "All the alerts listed in Section 6.2 MUST be sent with AlertLevel=fatal and MUST be treated as error alerts regardless of the AlertLevel in the message”.   Is the client supposed to remember that it received a warning level alert and terminate after parsing the ServerHello?

—Roelof

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 9 May 2018 10:56:15 -0700

But it actually sends an SH? That seems odd and kind of an ambiguous point
in the spec.

-Ekr

On Wed, May 9, 2018 at 10:14 AM, Roelof duToit <[email-masked]> wrote:

> In one of our tests OpenSSL 1.1.1-dev sends an unrecognized_name warning
> alert before a TLS 1.3 (draft 26) ServerHello.  Alert level is supposed to
> be implicit in TLS 1.3, but in this case it is ambiguous.  Should it even
> be considered a “TLS 1.3 alert” given that it arrives before the protocol
> version is confirmed?
>
> TLS 1.3 draft section 6 states that "All the alerts listed in Section 6.2
> MUST be sent with AlertLevel=fatal and MUST be treated as error alerts
> regardless of the AlertLevel in the message”.   Is the client supposed to
> remember that it received a warning level alert and terminate after parsing
> the ServerHello?
>
> —Roelof
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 10 May 2018 02:07:37 +0000

This alert is actually fairly common (though I'm surprised to see OpenSSL
still doing it) and clients need to handle it, unfortunately.  Before the
client has any confirmation that it is doing TLS 1.3, it has to assume that
the server is any TLS version.

Of course, if the client isn't prepared to negotiate earlier versions, it
might choke on that alert based on the TLS 1.3 alert handling roles, so the
server shouldn't really be sending it.  If the spec is still available for
changes, it's probably worth mentioning this issue.  I forgot to check the
spec when I made/reviewed the corresponding change in NSS.
On Thu, May 10, 2018 at 3:57 AM Eric Rescorla <[email-masked]> wrote:

> But it actually sends an SH? That seems odd and kind of an ambiguous
point in the spec.

>> TLS 1.3 draft section 6 states that "All the alerts listed in Section
6.2 MUST be sent with AlertLevel=fatal and MUST be treated as error alerts
regardless of the AlertLevel in the message”.   Is the client supposed to
remember that it received a warning level alert and terminate after parsing
the ServerHello?

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 9 May 2018 23:47:52 -0400

> On May 9, 2018, at 10:07 PM, Martin Thomson <[email-masked]> wrote:
> 
> still doing it) and clients need to handle it, unfortunately. 

I may be misreading the code, but it sure looks like the alert is only
sent if the application callback for the server name extension  asks
OpenSSL to do that.  The application can just decline the extension
and let the handshake continue with a default certificate...  Is
the surprise that the alert is sent, or that it is a warning, or
something else?

-- 
-- 
	Viktor.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 10 May 2018 06:05:18 +0000

> the surprise that the alert is sent, or that it is a warning, or

It's risking a failed connection.  Though perhaps not that much more than
providing the client with a certificate it might not like.

---

From: R duToit <[email-masked]>
Date: Thu, 10 May 2018 10:59:35 -0400

The server sending the alert at warning level while knowing that it is about to negotiate TLS 1.3 seems to be in violation of the statement that "All alerts listed in Section 6.2 MUST be sent with AlertLevel=fatal," - that is probably more of an implementation issue.

The client's reaction to the warning alert is what is ambiguous.  Some TLS 1.3 client implementations will ignore the alert, while others will choke.

---- On Thu, 10 May 2018 02:05:18 -0400 Martin Thomson &lt;[email-masked]&gt; wrote ---- 

On Thu, May 10, 2018 at 1:48 PM Viktor Dukhovni &lt;[email-masked]&gt; 
wrote: 
&gt; I may be misreading the code, but it sure looks like the alert is only 
&gt; sent if the application callback for the server name extension asks 
&gt; OpenSSL to do that. The application can just decline the extension 
&gt; and let the handshake continue with a default certificate... Is 
&gt; the surprise that the alert is sent, or that it is a warning, or 
&gt; something else?

---

From: Martin Thomson <[email-masked]>
Date: Fri, 11 May 2018 10:14:53 +1000

Yep.  More so in DTLS when the alert might arrive after the client has seen
the ServerHello.
On Fri, May 11, 2018 at 12:59 AM R duToit <[email-masked]> wrote:

> The server sending the alert at warning level while knowing that it is
about to negotiate TLS 1.3 seems to be in violation of the statement that
"All alerts listed in Section 6.2 MUST be sent with AlertLevel=fatal," -
that is probably more of an implementation issue.

> The client's reaction to the warning alert is what is ambiguous.  Some
TLS 1.3 client implementations will ignore the alert, while others will
choke.

> ---- On Thu, 10 May 2018 02:05:18 -0400 Martin Thomson <
[email-masked]> wrote ----