Re: [TLS] KeyUpdate and unbounded write obligations

Ilari Liusvaara <ilariliusvaara@welho.com> Thu, 18 August 2016 09:02 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 5BFE512D0EA for <tls@ietfa.amsl.com>; Thu, 18 Aug 2016 02:02:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level:
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.247] 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 YW_ki14dPVxQ for <tls@ietfa.amsl.com>; Thu, 18 Aug 2016 02:02:38 -0700 (PDT)
Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA7212B058 for <tls@ietf.org>; Thu, 18 Aug 2016 02:02:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 5F25CEBF5; Thu, 18 Aug 2016 12:02:36 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id XsB3ALx5Bl6V; Thu, 18 Aug 2016 12:02:36 +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-smtp1.welho.com (Postfix) with ESMTPSA id 84AA9289; Thu, 18 Aug 2016 11:53:16 +0300 (EEST)
Date: Thu, 18 Aug 2016 11:53:07 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Keith Winstein <keithw@cs.stanford.edu>
Message-ID: <20160818085306.dp2nxe7stz5qtnv6@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CAF8qwaDgGHGmuBwhZEz9-=Ss2bfzNAYWfmnbMqQDxTQnMUpH7g@mail.gmail.com> <CAMzhQmOs-mj2URHnYFOB46SDBa2c4Z3_S=7bzNAgixTc_TNkEQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CAMzhQmOs-mj2URHnYFOB46SDBa2c4Z3_S=7bzNAgixTc_TNkEQ@mail.gmail.com>
User-Agent: Mutt/1.6.2-neo (2016-08-08)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/7Dog5ADWHWVfrXT72Hm6ev6b2LE>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] KeyUpdate and unbounded write obligations
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: Thu, 18 Aug 2016 09:02:40 -0000

On Thu, Aug 18, 2016 at 12:30:03AM -0700, Keith Winstein wrote:
> I think it's probably possible to make everybody happy here.
> 
> I appreciate the need to avoid allowing the other side to create an
> unbounded deferred write/compute obligation. I also think it's
> valuable to preserve the ability for "either side to force an update
> to the entire connection," and obviously I think it's valuable for the
> initiating side to get an ack that that has happened (hence PR
> #426/#580).
> 
> To mitigate the unboundedness issue, what would you think about this option:
> 
> 1) Keep everything the same as the current draft, but
> 2) Add this text: "An implementation MUST NOT advance its current
> sending generation to be greater than its current receiving generation
> plus one."

That wouldn't work very well in highly asymmetric situations. One
could add rule that allows rekeys in excess of that limit if RSN is
above some threshold. Such RSN thresholds would greatly slow down
KeyUpdate spam (e.g. reaching 2^32 takes 84GB at minimum).


Also, for DTLS, one would need limits like this to avoid exessive key
updating.


-Ilari