IETF Logo Mail Archive

Re: [Din] Quorum slice representation in revised SCP draft draft-mazieres-dinrg-scp-02

David Mazieres <dm-list-ietf-ilc@scs.stanford.edu> Wed, 13 June 2018 19:27 UTC

Return-Path: <dm-list-ietf-ilc@scs.stanford.edu>
X-Original-To: din@ietfa.amsl.com
Delivered-To: din@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01843130E87 for <din@ietfa.amsl.com>; Wed, 13 Jun 2018 12:27:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=scs.stanford.edu
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 bXnNovymXZ8z for <din@ietfa.amsl.com>; Wed, 13 Jun 2018 12:27:15 -0700 (PDT)
Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 942A312426A for <din@irtf.org>; Wed, 13 Jun 2018 12:27:15 -0700 (PDT)
Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.16.0.21/8.16.0.21) with ESMTP id w5DJREKZ023929; Wed, 13 Jun 2018 12:27:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=scs.stanford.edu; s=scs; t=1528918034; bh=bqTlqhGVxt8GVkistHFOCnvcTaL5iM1bghGyq2VuJ2A=; h=From:To:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version; b=C/jycmUg4361Qrayvt7C3LpbCKKu7mFgYnEAC62GXvTZzQwlPAkC7WOc6RlsnFUdO WdevlPlBi17zJINxDuw6/q90FXsDeIkct7sGYFJSbhzWK/U1sWpmW+St6EM5oyrhz/ eHCoIHqhfE+uHPNLXWAgTZcQR4gD/6TSagds59tA=
Received: (from dm@localhost) by market.scs.stanford.edu (8.16.0.21/8.16.0.21/Submit) id w5DJRETC079453; Wed, 13 Jun 2018 12:27:14 -0700 (PDT)
From: David Mazieres <dm-list-ietf-ilc@scs.stanford.edu>
To: Piers Powlesland <pierspowlesland@gmail.com>
Cc: din@irtf.org
In-Reply-To: <CAFXacX=cmOP0MuceF9Mukf3RngenFx2eBB=wWWai+RRb1em+4w@mail.gmail.com>
References: <CAFXacX=QsPgu=jcgUtAJbQRnBZA_CmbY+AvjoovCoWuuVPqESQ@mail.gmail.com> <87k1r3bdaq.fsf@ta.scs.stanford.edu> <CAFXacX=cmOP0MuceF9Mukf3RngenFx2eBB=wWWai+RRb1em+4w@mail.gmail.com>
Reply-To: David Mazieres expires 2018-09-11 PDT <mazieres-pwsaw25hqze5vad5kp8shgvgpi@temporary-address.scs.stanford.edu>
Date: Wed, 13 Jun 2018 12:27:14 -0700
Message-ID: <87bmcecwrx.fsf@ta.scs.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/din/drsgOjkdSmL53MIHwOLFXy9zHIM>
Subject: Re: [Din] Quorum slice representation in revised SCP draft draft-mazieres-dinrg-scp-02
X-BeenThere: din@irtf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" <din.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/din>, <mailto:din-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/din/>
List-Post: <mailto:din@irtf.org>
List-Help: <mailto:din-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/din>, <mailto:din-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Jun 2018 19:27:17 -0000

Piers Powlesland <pierspowlesland@gmail.com> writes:

> Thanks David,
>
> That makes a bunch of sense.
>
> If I did want to encode a bunch of explicit slices in a manner similar to
> that discussed in the whitepaper using the SCPQuorumSet structure (
> https://tools.ietf.org/html/draft-mazieres-dinrg-scp-02#section-3.3). I
> guess I could have a top level set with the threshold set to 1 and then
> encode each quorum slice in separate SCPQuorumSet1 instances each of which
> would have the threshold set to the length of their validators.
>
> Reading that section again I'm wondering why only 2 levels of nesting are
> allowed?

Again, it's a compromise between flexibility and practical aspects.
Arbitrary recursion would make checking more expensive.  More
practically, many implementations of XDR use recursive functions to
parse recursive data structures, so would be vulnerable to DoS attacks
that blow out the stack if the structures could nest arbitrarily.

David

v2.23.0 | Report a Bug | By Email