Re: [TLS] Alert after sending ServerHello

Ilari Liusvaara <ilariliusvaara@welho.com> Wed, 26 April 2017 07:20 UTC

Return-Path: <ilariliusvaara@welho.com>
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 B5D19131977 for <tls@ietfa.amsl.com>; Wed, 26 Apr 2017 00:20:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
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 t-FoZ59dl2zC for <tls@ietfa.amsl.com>; Wed, 26 Apr 2017 00:20:05 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id E2C3313196C for <tls@ietf.org>; Wed, 26 Apr 2017 00:19:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 941BB366D8; Wed, 26 Apr 2017 10:19:54 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id bwSPmepTcw-c; Wed, 26 Apr 2017 10:19:54 +0300 (EEST)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 4D71D27B; Wed, 26 Apr 2017 10:19:54 +0300 (EEST)
Date: Wed, 26 Apr 2017 10:19:52 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Roelof Du Toit <Roelof_Dutoit@symantec.com>, "tls@ietf.org" <tls@ietf.org>
Message-ID: <20170426071952.GA29159@LK-Perkele-V2.elisa-laajakaista.fi>
References: <EAF9D3D6-A87D-450D-BCFB-36F8CDC8B14F@symantec.com> <CABkgnnW9M2Jx77vBtUiGH1y67f6XKbAygOQg_EptqkApxhkZPw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CABkgnnW9M2Jx77vBtUiGH1y67f6XKbAygOQg_EptqkApxhkZPw@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/aRzEYIaoCvOmENxcAzNyOX7D_Uk>
Subject: Re: [TLS] Alert after sending 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: Wed, 26 Apr 2017 07:20:13 -0000

On Wed, Apr 26, 2017 at 04:35:31PM +1000, Martin Thomson wrote:
> You are allowed to out NSS.  We know that it's not ideal.
> 
> I wrote that code and it's unencrypted for what I think is a good
> reason (others very much disagree).  In part, it has to do with 0-RTT.
> 
> In 0-RTT, we want to ensure that the client is able to continue
> sending 0-RTT until the entire server flight is received.  Thus, we
> don't change out the keys until we receive and process the server
> Finished.  The same code is used in 1-RTT.  I think that we have a bug
> in that the alerts are 0-RTT encrypted; it might be better to send
> them in the clear as well.

AFAIK, the only situations where client can abort sending 0-RTT data
is noticing lack of server EarlyData extension (so server isn't
listening anyway), or if the entiere handshake is aborted.. Doing it
in other situations leads to subtle race conditions.

Of course, EarlyData is in EncryptedExtensions, so one must use the
Server Handshake keys to decrypt it. Which means processing ServerHello
without installing Client Handshake Keys (since one is still encrypting
0-RTT).

> In effect, we assume that the entire flight is processed atomically
> and generate errors based on that.  Only when the entire flight is
> processed cleanly do we install keys and respond.

My implementation processes message-by-message. So it installs the
client handshake keys after ServerHello.
 
> This is a pain for us, we don't have the code that Ilari talks about,
> so some of our tests end up hitting decode errors on the server, but
> it's been manageable thus far.

The code I was talking about was handling the special case that the
server might receive either encrypted or unencrypted alert in response
to its flight. And the difference it makes is just what error is
declared as abort reason.


-Ilari