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
- [TLS] TLS 1.3 PR #426: KeyUpdate message: add rec… Judson Wilson
- Re: [TLS] TLS 1.3 PR #426: KeyUpdate message: add… Ilari Liusvaara
- Re: [TLS] TLS 1.3 PR #426: KeyUpdate message: add… Eric Rescorla
- Re: [TLS] TLS 1.3 PR #426: KeyUpdate message: add… Philip Levis
- Re: [TLS] TLS 1.3 PR #426: KeyUpdate message: add… Ilari Liusvaara