Re: [Din] [OPSEC] blockchain for IP addresses draft update

"Roque Gagliano (rogaglia)" <rogaglia@cisco.com> Wed, 04 July 2018 12:09 UTC

Return-Path: <rogaglia@cisco.com>
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 55F44130E4B for <din@ietfa.amsl.com>; Wed, 4 Jul 2018 05:09:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level:
X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 T9r0kp3fX_gd for <din@ietfa.amsl.com>; Wed, 4 Jul 2018 05:09:10 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6177130E06 for <din@irtf.org>; Wed, 4 Jul 2018 05:09:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17626; q=dns/txt; s=iport; t=1530706150; x=1531915750; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=NzkZmiVK3+330cARcbpPSwcOWYOZKWcGM2QJj2AEWNk=; b=HWeSp3aT1ZNNlX1tgLC7HfNEpei1HhuUGVTJPZHNoFVGrYvPORkWHgjQ f7uBZ8OsTHUF4XjNfW+fKWgsTppTzxxCShAjumgGEPun3KAHWhe4Damor DupmMimKmKxIJyR5KV6wdvm8TkBC3uBBu0PWKaYOf7LZG06ofEaGb8qVa E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CCAgA1uDxb/5tdJa1cDgsBAQEBAQEBAQEBAQEHAQEBAQGCU3ZifygKg3CUIRmCB5AfhQ4UgWYLI4RJAheCDCE1FwECAQECAQECbRwMhTYBAQEEI0cEGwIBCBEDAQIoAwICAjAUCQgCBAESgyABgRtkD6gughyDegEBhFeBNQWIRyaBVj+BNoFqUC6DGAIDAYEkWBaCSzGCJAKHQIonh2UJAoYEiRqBQIZ3hSCHe4I6hy0CERMBgSQeATaBPQ0IcBU7KgGCPoIkF4hZhQQEATVvAY5hAiQEA4EBgRoBAQ
X-IronPort-AV: E=Sophos;i="5.51,306,1526342400"; d="scan'208,217";a="138540286"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jul 2018 12:09:09 +0000
Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w64C99s7017895 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Jul 2018 12:09:09 GMT
Received: from xch-rtp-011.cisco.com (64.101.220.151) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 4 Jul 2018 08:09:08 -0400
Received: from xch-rtp-011.cisco.com ([64.101.220.151]) by XCH-RTP-011.cisco.com ([64.101.220.151]) with mapi id 15.00.1320.000; Wed, 4 Jul 2018 08:09:08 -0400
From: "Roque Gagliano (rogaglia)" <rogaglia@cisco.com>
To: Jordi Paillissé Vilanova <jordip@ac.upc.edu>, David Mazieres expires 2018-09-30 PDT <mazieres-pebagr7ysjghwpqkcqqnjjf4ta@temporary-address.scs.stanford.edu>, "sidrops@ietf.org" <sidrops@ietf.org>, "din@irtf.org" <din@irtf.org>, Stephane Bortzmeyer <bortzmeyer@nic.fr>, "sandy@tislabs.com" <sandy@tislabs.com>, Greg Skinner <gregskinner0@icloud.com>, "leo@vegoda.org" <leo@vegoda.org>, "Alberto Rodriguez Natal (natal)" <natal@cisco.com>, "Vina Ermagan (vermagan)" <vermagan@cisco.com>, "Fabio Maino (fmaino)" <fmaino@cisco.com>, Albert Cabellos <acabello@ac.upc.edu>, "opsec@ietf.org" <opsec@ietf.org>
Thread-Topic: [OPSEC] [Din] blockchain for IP addresses draft update
Thread-Index: AQHUEh4PNQ99JdAUUUS0yUmJnadF4KR/Mv+AgAAs94A=
Date: Wed, 04 Jul 2018 12:09:08 +0000
Message-ID: <9BC0DE80-D827-414B-916B-C102C3460563@cisco.com>
References: <153028668788.30332.9615982545028670114.idtracker@ietfa.amsl.com> <fbe24301-9827-090d-d1e6-fd60fd2de7f7@ac.upc.edu> <87lgat633l.fsf@ta.scs.stanford.edu> <ee6d93bf-6f79-a4a9-9f1e-a786860f9c5b@ac.upc.edu>
In-Reply-To: <ee6d93bf-6f79-a4a9-9f1e-a786860f9c5b@ac.upc.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.e.1.180613
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.55.172.244]
Content-Type: multipart/alternative; boundary="_000_9BC0DE80D827414B916BC102C3460563ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/din/1ttxH6PDLW_WCEdua11-duSwITg>
X-Mailman-Approved-At: Wed, 04 Jul 2018 21:08:57 -0700
Subject: Re: [Din] [OPSEC] blockchain for IP addresses draft update
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, 04 Jul 2018 12:09:14 -0000

Hi Jordi,

Very good document.

I hate to ask things without providing code but I believe it would be great if you add a section regarding the “relying party”, how would the validation algorithm would look like and what is the bootstrap process. I can see that some public key info would need to be known by the RP.

Regards,
Roque


From: OPSEC <opsec-bounces@ietf.org> on behalf of Jordi Paillissé Vilanova <jordip@ac.upc.edu>
Date: Wednesday 4 July 2018 at 13:28
To: David Mazieres expires 2018-09-30 PDT <mazieres-pebagr7ysjghwpqkcqqnjjf4ta@temporary-address.scs.stanford.edu>, "sidrops@ietf.org" <sidrops@ietf.org>, "din@irtf.org" <din@irtf.org>, Stephane Bortzmeyer <bortzmeyer@nic.fr>, "sandy@tislabs.com" <sandy@tislabs.com>, Greg Skinner <gregskinner0@icloud.com>, "leo@vegoda.org" <leo@vegoda.org>, "Alberto Rodriguez Natal (natal)" <natal@cisco.com>, "Vina Ermagan (vermagan)" <vermagan@cisco.com>, "Fabio Maino (fmaino)" <fmaino@cisco.com>, Albert Cabellos <acabello@ac.upc.edu>, "opsec@ietf.org" <opsec@ietf.org>
Subject: Re: [OPSEC] [Din] blockchain for IP addresses draft update


Hi David,

Indeed, we did not delve deeper into the PoS algorithm. This depends on the specific implementation, our opinion is that an Algroand-like would be a good option, and if it can tolerate a large portion of offline participants even better. In addition, we think that punishing or deposit mechanisms are not desirable because they don't fit the characteristics of the scenario. Overall the incentive is "a more secure Internet", we believe that this is well-aligned with the economical interests of the participants.

Regarding SCP, the fact that you only need to trust your neighbours may prove very convenient in this scenario. As you said, it reflects current Internet trust schemes, this basically means that BGP Peering = Trust = Stellar quorum slices. We'll look into this for the next iteration of the draft.

Thanks

Jordi

El 02/07/18 a les 17:59, David Mazieres ha escrit:

Jordi Paillissé Vilanova <jordip@ac.upc.edu><mailto:jordip@ac.upc.edu> writes:



(apologies for cross-posting)



Dear all,



We have submitted a new version of the draft addressing comments

received both on the mailing list and IETF meetings.



Thanks to all of you for taking the time to read the draft :)



Regards,



Jordi

Very interesting draft.  One high-level comment, I would avoid terms

like "tamper-proof" or really anything-"proof" except possibly in the

context of information-theoretic security, in favor of tamper-resistant.

This is particularly important in the context of blockchains that have

experienced a number of forks in practice and where it would likely take

only a few tens of millions of dollars a day to tamper with history.



I think the draft would benefit from a much finer-grained consideration

of several different forms of proof-of-stake, because there are a number

of assertions that do not hold for all forms of proof of stake.  E.g.,

will there be delegation like peercoin, randomization like algorand,

penalties like Casper, sleepy nodes like snowwhite?



And while of course I'm biased on this issue, I think that a

Byzantine-agreement-based approach like SCP

(https://datatracker.ietf.org/doc/draft-mazieres-dinrg-scp/) would work

better than PoS.  SCP is well matched to the Internet peering model,

which we already know is a workable decentralized governance model.  You

may not agree, but it would at least be nice for the document to explain

why you reject this approach.



David