Re: [TLS] TLS 1.3 PR #426: KeyUpdate message: add receive_generation field

Ilari Liusvaara <ilariliusvaara@welho.com> Sat, 05 March 2016 09:48 UTC

Return-Path: <ilariliusvaara@welho.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383341B2BA7 for <tls@ietfa.amsl.com>; Sat, 5 Mar 2016 01:48:54 -0800 (PST)
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, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 0_E4DSd-4BgS for <tls@ietfa.amsl.com>; Sat, 5 Mar 2016 01:48:51 -0800 (PST)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id F3E331B2BA4 for <tls@ietf.org>; Sat, 5 Mar 2016 01:48:50 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 913DD21FB; Sat, 5 Mar 2016 11:48:49 +0200 (EET)
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-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id ySViq92q6hcv; Sat, 5 Mar 2016 11:48:49 +0200 (EET)
Received: from LK-Perkele-V2 (87-100-151-39.bb.dnainternet.fi [87.100.151.39]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 44C8A21C; Sat, 5 Mar 2016 11:48:49 +0200 (EET)
Date: Sat, 05 Mar 2016 11:48:43 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Philip Levis <pal@cs.stanford.edu>
Message-ID: <20160305094843.GA13115@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CAB=4g8Jp-04RQKSXDpos5PczdFfMU8bEv242qzf1HnC=aP0F2Q@mail.gmail.com> <20160226122425.GA32313@LK-Perkele-V2.elisa-laajakaista.fi> <CABcZeBPASnrmGwUY44BuYtip354ju9PiuJdVnkKFV22Q9Xem+A@mail.gmail.com> <4E97445F-95CD-49A1-91A6-9F9FE94F0C48@cs.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <4E97445F-95CD-49A1-91A6-9F9FE94F0C48@cs.stanford.edu>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: ilariliusvaara@welho.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/6odjTlGIfmWFqUmT1FJHnLBqP5Q>
Cc: Dan Boneh <dabo@cs.stanford.edu>, Judson Wilson <judsonw@stanford.edu>, Keith Winstein <keithw@cs.stanford.edu>, Henry Corrigan-Gibbs <henrycg@stanford.edu>, "Riad S. Wahby" <rsw@cs.stanford.edu>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS 1.3 PR #426: KeyUpdate message: add receive_generation field
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Sat, 05 Mar 2016 09:48:54 -0000

On Sat, Mar 05, 2016 at 12:46:01AM -0800, Philip Levis wrote:
 
> Something I think that might not have been clear is this proposal
> doesn’t in any way change how KeyUpdates are generated or processed.
> In that way, crossings do not matter for the protocol. However, from
> an application standpoint, when a KeyUpdate is performed, there can
> be ambiguities on which keys are in use. Ambiguities in secure
> protocols can create problematic edge cases, like the one Judson
> outlined. We’d like it to be possible to resolve those ambiguities
> without changing TLS or adding any significant complexity.

There should be no ambiguities from application standpoint. The whole
reason for fully asynchronous design is that the application does not
have to care about rekeying (other than setting parameters if the
defaults aren't suitable).

And TLS stacks only need to know current valid receive keys (which
is just one key for non-datagram TLS) and the newest send key.

> Ilari, do you see a security flaw in having one side know which
> keys the other side is using? Explicit information between the
> two endpoints seems like a good idea to me. Or do you think this
> change makes TLS more complex and harder to implement correctly?

I don't think the application needs to know that. And TLS stacks
know valid receive keys anyway.

And thanks to fully asynchronous design, have fun if client
requests 27GB Blu-Ray ISO over HTTP/1.1 and server decides to
rekey...


The security problems arise when one uses this as basis to reveal
keys (which is not something TLS libraries should even support, just
the existence of API breaks the security models in all sorts of
nasty ways).



-Ilari