Re: [TLS] Post-handshake Finished when rejecting a CertificateRequest

Ilari Liusvaara <ilariliusvaara@welho.com> Tue, 02 August 2016 07:49 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 5DA3412B008 for <tls@ietfa.amsl.com>; Tue, 2 Aug 2016 00:49:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.187
X-Spam-Level:
X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] 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 yoaAlNzt2LRZ for <tls@ietfa.amsl.com>; Tue, 2 Aug 2016 00:49:05 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 59B1D12B004 for <tls@ietf.org>; Tue, 2 Aug 2016 00:49:03 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 47943E996; Tue, 2 Aug 2016 10:49:02 +0300 (EEST)
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 ofmIafubFPiU; Tue, 2 Aug 2016 10:49:01 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 280502310; Tue, 2 Aug 2016 10:49:01 +0300 (EEST)
Date: Tue, 2 Aug 2016 10:48:54 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Martin Thomson <martin.thomson@gmail.com>
Message-ID: <20160802074854.GA21071@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CABkgnnVUHmqDjkRn3LaV=Bz7_X_Y4oShkSyXg8h5E9=bKoLAog@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CABkgnnVUHmqDjkRn3LaV=Bz7_X_Y4oShkSyXg8h5E9=bKoLAog@mail.gmail.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/5Un2TYHTwDHIhZhBcm3JoHS5CFw>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Post-handshake Finished when rejecting a CertificateRequest
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 02 Aug 2016 07:49:07 -0000

On Tue, Aug 02, 2016 at 03:03:13PM +1000, Martin Thomson wrote:
> https://github.com/tlswg/tls13-spec/issues/572
> 
> Discuss.

Yeah, noticed that when trying to implement stuff. I do not see any
point in sending Finished in that case. Not sending Finished would
also make implementations that don't support post-handshake auth
simpler.

Also, what exact base key does that Finished use? Client's current
traffic secret at the beginning of the Finished (the sequence of
traffic secrets is the same client and server, but the values may
be out of sync.)?


I also noticed the hash forking issue. Even if I personally
nowadays deal with forkable hashes (even to the point of implmenting
multitap via forking) that is the only place forking is done.

However, those hash constructs look different from the ones in
handshake (not just different base context), which means those would
likely have to be implemented separtedly, increasing implmentation
effort.

However, if one wanted to use extra hashing there, so construction is
both compatible with the in-handshake one and doesn't require forking,
one would need to be a bit careful to stay out of cryptographic roughs.
E.g. it might be necressary to pad the hash to multiple of hash input
blocksize (like how HMAC does such padding with the key).




-Ilari