IETF Logo Mail Archive

Re: [TLS] Server validation of a second ClientHello

Ilari Liusvaara <ilariliusvaara@welho.com> Wed, 13 February 2019 14:52 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 D25FE128701 for <tls@ietfa.amsl.com>; Wed, 13 Feb 2019 06:52:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 wLhpXdzk31-O for <tls@ietfa.amsl.com>; Wed, 13 Feb 2019 06:52:15 -0800 (PST)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6382F1274D0 for <tls@ietf.org>; Wed, 13 Feb 2019 06:52:14 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 3D7FDBA3F for <tls@ietf.org>; Wed, 13 Feb 2019 16:52:12 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id LdKFPNws4EZY for <tls@ietf.org>; Wed, 13 Feb 2019 16:52:11 +0200 (EET)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id DB5362309 for <tls@ietf.org>; Wed, 13 Feb 2019 16:52:10 +0200 (EET)
Date: Wed, 13 Feb 2019 16:52:10 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Message-ID: <20190213145210.GA17286@LK-Perkele-VII>
References: <1549596678.898774.1653407000.2B2ACE8E@webmail.messagingengine.com> <1549980018.5oto7EOJll@pintsize.usersys.redhat.com> <CABcZeBNZJp+KiLEuaRZR0nO1PPEr_qcCJ9MypU104qTm6v8tcA@mail.gmail.com> <103341275.xSgb4icBHy@pintsize.usersys.redhat.com> <CABcZeBP=MGrj4x5brO5t5uf4tYumkL3Vthu=4zwhBHOYpsSJyQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CABcZeBP=MGrj4x5brO5t5uf4tYumkL3Vthu=4zwhBHOYpsSJyQ@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/7nQ11II5CGgE3XAXWQmqYk6fEB8>
Subject: Re: [TLS] Server validation of a second ClientHello
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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, 13 Feb 2019 14:52:18 -0000

On Wed, Feb 13, 2019 at 06:39:03AM -0800, Eric Rescorla wrote:
> On Wed, Feb 13, 2019 at 4:12 AM Hubert Kario <hkario@redhat.com> wrote:
> 
> > you are not suggesting that which value will be used (from first or second
> > CH), or if the connection will be aborted, to be implementation dependant
> > *by design* , do you?
> >
> 
> I'n not sure I understand your question, but I'll try to answer what I
> think it says.
> 
> 1. I do think that whether you continue the connection or abort it is an
> implementation decision and I think that the way the spec is written says
> that.
> 2. I think the spec leaves open whether you should use the first or second
> values, but I think implementations should use the second value. It's not
> clear why one would want to use the first.

One reason is that if one has state-machine handshake processing, it is
not difficult to do all the negotiation on the first pass, and then
only grab the share on second pass, if it was missing (as it is the
only retry condition).

That is what I initially implemented in TLS library I did (later
versions use stateless approach, with checks that the CHs match).


-Ilari

v2.23.0 | Report a Bug | By Email