IETF Logo Mail Archive

Re: [TLS] Warning alert before TLS 1.3 ServerHello

R duToit <r@nerd.ninja> Thu, 10 May 2018 14:59 UTC

Return-Path: <r@nerd.ninja>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F971243FE for <tls@ietfa.amsl.com>; Thu, 10 May 2018 07:59:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nerd.ninja
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76lg0L4nIryT for <tls@ietfa.amsl.com>; Thu, 10 May 2018 07:59:39 -0700 (PDT)
Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8DF91241FC for <tls@ietf.org>; Thu, 10 May 2018 07:59:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1525964375; s=zoho; d=nerd.ninja; i=r@nerd.ninja; h=Date:From:To:Cc:Message-Id:In-Reply-To:References:Subject:MIME-Version:Content-Type; l=3988; bh=GCbV98XohYe7HvirVYR3p0h2W6hiJRkyA4pCV/J21x0=; b=yrZ1deLI17DLL0uwUYhvZ/VnV5OBZCpEvuLtSIlff+Q9glLrB3JGs2qK1O2EEjUU TVX+YksDTv9a3ysvdsSoBfNhh9Np+/H15pEOCSbKkwUQkN21XSBASX5nheM7TlbYrl4 dikkppRKwpETJJqkZE0TUsACPArA/Rx3aPdzv1Lo=
Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1525964375179174.29971095914402; Thu, 10 May 2018 07:59:35 -0700 (PDT)
Date: Thu, 10 May 2018 10:59:35 -0400
From: R duToit <r@nerd.ninja>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Message-Id: <1634a908489.1177ed3d735485.6019683877747033038@nerd.ninja>
In-Reply-To: <CABkgnnUCW35XnvzgP=44EqMj+fm1rCu=6T_iU2JkC4K3XGumjw@mail.gmail.com>
References: <EB30106F-F089-4A2B-845E-FF560399DD55@nerd.ninja> <CABcZeBO8_nHpxRZgeeH3wvP7hAYQGwDAu4vcYmjoZTmpOeoXqw@mail.gmail.com> <CABkgnnWMHmTtjdW0cyN9SHRhEGC+D6adKyPNH4K=JmpKeHiRiQ@mail.gmail.com> <D9C0941E-B5B4-42B0-B35E-D6E963D56EB4@dukhovni.org> <CABkgnnUCW35XnvzgP=44EqMj+fm1rCu=6T_iU2JkC4K3XGumjw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_86147_1485997327.1525964375177"
X-Priority: Medium
User-Agent: Zoho Mail
X-Mailer: Zoho Mail
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/CmUGml3Gtfw0_Rqz4wScWN4Phz4>
Subject: Re: [TLS] Warning alert before TLS 1.3 ServerHello
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 May 2018 14:59:40 -0000

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;martin.thomson@gmail.com&gt; wrote ---- 

On Thu, May 10, 2018 at 1:48 PM Viktor Dukhovni &lt;ietf-dane@dukhovni.org&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? 
 
It's risking a failed connection. Though perhaps not that much more than 
providing the client with a certificate it might not like. 
 
_______________________________________________ 
TLS mailing list 
TLS@ietf.org 
https://www.ietf.org/mailman/listinfo/tls

v2.23.0 | Report a Bug | By Email