draft-schanzen-pils.xml (13748B)
1 <?xml version='1.0' encoding='utf-8'?> 2 <!DOCTYPE rfc [ 3 <!ENTITY RFC1034 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml"> 4 <!ENTITY RFC1035 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml"> 5 <!ENTITY RFC1928 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1928.xml"> 6 <!ENTITY RFC2119 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> 7 <!--<!ENTITY RFC2693 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2693.xml">--> 8 <!ENTITY RFC2782 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2782.xml"> 9 <!ENTITY RFC3629 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml"> 10 <!ENTITY RFC3686 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3686.xml"> 11 <!ENTITY RFC3826 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3826.xml"> 12 <!ENTITY RFC4033 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml"> 13 <!ENTITY RFC5237 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5237.xml"> 14 <!--<!ENTITY RFC3912 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3912.xml">--> 15 <!ENTITY RFC5869 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5869.xml"> 16 <!ENTITY RFC5890 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5890.xml"> 17 <!ENTITY RFC5895 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5895.xml"> 18 <!ENTITY RFC6066 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6066.xml"> 19 <!ENTITY RFC6761 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6761.xml"> 20 <!ENTITY RFC6895 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6895.xml"> 21 <!ENTITY RFC6979 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6979.xml"> 22 <!ENTITY RFC7363 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7363.xml"> 23 <!ENTITY RFC8806 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8806.xml"> 24 <!ENTITY RFC8126 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml"> 25 <!ENTITY RFC8174 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml"> 26 <!ENTITY RFC8244 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8244.xml"> 27 <!ENTITY RFC8324 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8324.xml"> 28 <!ENTITY RFC8499 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8499.xml"> 29 <!ENTITY RFC9106 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9106.xml"> 30 <!ENTITY RFC9180 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9180.xml"> 31 <!ENTITY I-D.ietf-dnsop-alt-tld PUBLIC '' "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dnsop-alt-tld.xml"> 32 ]> 33 <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> 34 <?rfc strict="yes" ?> 35 <?rfc toc="yes" ?> 36 <?rfc symrefs="yes"?> 37 <?rfc sortrefs="yes" ?> 38 <?rfc compact="yes" ?> 39 <?rfc subcompact="no" ?> 40 <rfc xmlns:xi="http://www.w3.org/2001/XInclude" 41 category="info" 42 docName="draft-schanzen-pils-00" 43 ipr="trust200902" 44 obsoletes="" updates="" 45 submissionType="independent" 46 xml:lang="en" 47 version="3"> 48 <!-- xml2rfc v2v3 conversion 2.26.0 --> 49 <front> 50 <title abbrev="PILS"> 51 The Peer Identity Lifecycle Service (PILS) 52 </title> 53 <seriesInfo name="Internet-Draft" value="draft-schanzen-pils-00"/> 54 <author fullname="Martin Schanzenbach" initials="M." surname="Schanzenbach"> 55 <organization>Fraunhofer AISEC</organization> 56 <address> 57 <postal> 58 <street>Lichtenbergstrasse 11</street> 59 <city>Garching</city> 60 <code>85748</code> 61 <country>DE</country> 62 </postal> 63 <email>martin.schanzenbach@aisec.fraunhofer.de</email> 64 </address> 65 </author> 66 <author fullname="ch3" initials="" surname="ch3"> 67 <organization>GNUnet e.V.</organization> 68 <address> 69 <postal> 70 <street></street> 71 <city>Lenggries</city> 72 <code></code> 73 <country>DE</country> 74 </postal> 75 <email>ch3@mailbox.org</email> 76 </address> 77 </author> 78 79 <!-- Meta-data Declarations --> 80 <area>General</area> 81 <workgroup>Independent Stream</workgroup> 82 <keyword>transport protocols</keyword> 83 <abstract> 84 <t> 85 This document contains the GNUnet peer lifecycle service 86 specification. 87 </t> 88 <t> 89 This document defines the normative wire format of peer identity lifecycle protocols, 90 cryptographic routines and security 91 considerations for use by implementers. 92 </t> 93 <t> 94 This specification was developed outside the IETF and does not have 95 IETF consensus. It is published here to inform readers about the 96 function of GNUnet peer identity lifecycles, guide future implementations, and ensure 97 interoperability among implementations including with the pre-existing 98 GNUnet implementation. 99 </t> 100 </abstract> 101 </front> 102 <middle> 103 <section anchor="introduction" numbered="true" toc="default"> 104 <name>Introduction</name> 105 <t> 106 Consider the following scenario: You use your GNUnet peer day-to-day from home. 107 One day, you decide to take a trip. With your device, and GNUnet peer. 108 Let's assume you take that trip by plane to Oceania. 109 It may be dangerous for you, depending on your activities and occupation at home, 110 if your GNUnet peer would reconnect to the network when you arrive on Oceania and 111 advertise your Peer ID because it would be linkable to the your peer's activities 112 back home. 113 </t> 114 <t> 115 More generally, we would like some degree of Peer unlinkability, depending on the 116 context in which we run our peer. 117 Ideally, the Peer ID changes when the context changes. 118 </t> 119 <t> 120 Changing PeerID requires further considerations than simply unlinkability. 121 For example it may seem prudent to use dedicated, randomly generated public key per address. 122 The reason why this is a bad idea is hidden in requirements from higher layers: 123 Having the peer handle multiple peer identities for each endpoint address will cause the connectivity on the DHT overlay to deteriorate. 124 The same physical node in the network may be reachable on N different endpoints. 125 If each of those endpoints is associated with a random peer identity (and advertised as such) other peers 126 may populate their routing tables with more than one of those addresses, in the worst case all N of them. 127 However, any connection establishment to the same node in the network does not improve connectivity and 128 resiliance of the overlay network. 129 Likely, connectivity will degrade and if the peer is no longer reachable (churn / peer offline) more than one 130 entry in the routing table will have to be replaced with new connections that in turn will again possibly 131 only be connections to the same local node in the network. 132 </t> 133 <t> 134 This document details a method to deterministically derive a peer identity from the current set of 135 endpoint addresses the peer is available at currently. 136 This provides a reasonable tradeoff between unlinkability for certain use cases, and stability for higher 137 layers in the GNUnet protocol stack. 138 </t> 139 <t> 140 This specification was developed outside the IETF and does not have 141 IETF consensus. It is published here to guide implementers 142 and ensure interoperability among implementations. 143 </t> 144 <section numbered="true" toc="default"> 145 <name>Requirements Notation</name> 146 <t> 147 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 149 "OPTIONAL" in this document are to be interpreted as described in 150 BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only 151 when, they appear in all capitals, as shown here. 152 </t> 153 </section> 154 </section> 155 <section anchor="notation" numbered="true" toc="default"> 156 <name>Notation</name> 157 <t> 158 We use the notation and terminology of <xref target="RFC9180"/> throughout 159 this document. 160 </t> 161 </section> 162 <section anchor="address_hash" numbered="true" toc="default"> 163 <name>Address hash</name> 164 <t> 165 The address hash is calculated over the concatenation of all 166 address strings (URIs) using SHA-512. 167 The addresses <bcp14>MUST</bcp14> be sorted alphanumerically. 168 The byte 0x00 is used as a separator between URIs in the hash input. 169 Consequently the hash may simply be calculated over the full C strings 170 including their 0-terminator. 171 Due to the flexibility of possible URI values this prevents any kind of odd 172 common-prefix case in which hashes may collide. 173 </t> 174 </section> 175 <section anchor="pid_derivation" numbered="true" toc="default"> 176 <name>Peer ID Derivation</name> 177 <t> 178 Given an address hash h_addr and an initial key seed, the 179 deterministic address-derived peer ID is calculated using HKDF (<xref target="RFC5869"/>) as: 180 </t> 181 <figure anchor="figure_key_schedule" title="The Key Schedule."> 182 <artwork name="" type="" align="left" alt=""><![CDATA[ 183 prk = HKDF-Extract(h_addr,seed) 184 sk = HKDF-Expand(prk, "gnunet-pils-contextual-peer-key", 32) 185 ]]></artwork> 186 </figure> 187 <t> 188 "." shows the argument position of the input variable from the incoming arrow. 189 </t> 190 <t> 191 FIXME: Possibly needs algorithm for Elligator to iteratively try secret keys that can be 192 used. 193 </t> 194 </section> 195 <section> 196 <name>Security and Privacy Considerations</name> 197 <t> 198 TODO: Crypto considerations. 199 </t> 200 <t> 201 While the approach provides some privacy in certain use cases, it is not a general solution 202 to prevent peer identity linkability. 203 For example, if the peer is configured a permanent, static and global address it will be trivially 204 linkable even if PILS derives different peer identities. 205 As such, the peer identity derivation is aimed to protect common use cases for the average user 206 where it is to be expected that no such global and static address is availalble as outlined in the 207 introduction. 208 </t> 209 <t> 210 It may seem odd why GNUnet does not use a dedicated, randomly generated public key per address. 211 The reason is hidden in requirements from higher layers: Having the peer handle multiple peer identities 212 for each endpoint will cause the connectivity on the DHT overlay to deteriorate. 213 The same physical node in the network may be reachable on N different endpoints. 214 If each of those endpoints is associated with a random peer identity (and advertised as such) other peers 215 may populate their routing tables with more than one of those addresses, in the worst case all N of them. 216 However, any connection establishment to the same node in the network does not improve connectivity and 217 resiliance of the overlay network. 218 Likely, connectivity will degrade and if the peer is no longer reachable (churn / peer offline) more than one 219 entry in the routing table will have to be replaced with new connections that in turn will again possibly 220 only be connections to the same local node in the network. 221 </t> 222 </section> 223 <!-- gana --> 224 <section> 225 <name>Implementation and Deployment Status</name> 226 <t> 227 There is one implementation conforming to this specification, written in C. 228 The implementation is part of <xref target="GNUnet"/> and represents the original and reference implementation. 229 </t> 230 <t> 231 FIXME test vectors 232 </t> 233 </section> 234 <section> 235 <name>Test Vectors</name> 236 <t> 237 The following test vectors can be used by implementations to test 238 for conformance with this specification. Unless indicated otherwise, 239 the test vectors are provided as hexadecimal byte arrays. 240 </t> 241 <section> 242 <name>PID Derivation</name> 243 <artwork name="" type="" align="left" alt=""> 244 <![CDATA[ 245 Addresses (sorted): 246 gnunet+udp://6.7.8.9 247 gnunet+tcp://1.2.3.4 248 gnunet+https://example.gnu 249 250 Address hash: 251 6c57def87391551d 252 2d5b16abb8072e42 253 dc389a3a85723fcb 254 a26afdcaccaea027 255 3af57a3e0e1d8777 256 8099afb0e9a00995 257 c444927a120f0170 258 732d4fe0f50e3cb2 259 260 Seed key: 261 50d7b652a4efeadf 262 f37396909785e595 263 2171a02178c8e7d4 264 50fa907925fafd98 265 266 Derived key: 267 9b8d17711be50a07 268 e7d984bd9c1e6d9c 269 f5492cfb2713f8cb 270 42eaf251573f39d7 271 ]]> 272 </artwork> 273 </section> 274 </section> 275 <!-- <section> 276 <name>Acknowledgements</name> 277 <t> 278 FIXME 279 </t> 280 </section> --> 281 </middle> 282 <back> 283 <references> 284 <name>Normative References</name> 285 &RFC2119; 286 &RFC5869; 287 &RFC8174; 288 &RFC9180; 289 290 </references> 291 <references> 292 <name>Informative References</name> 293 <reference anchor="GNUnet" target="https://git.gnunet.org/gnunet.git"> 294 <front> 295 <title>gnunet.git - GNUnet core repository</title> 296 <author initials="GNUnet e.V." surname="" 297 fullname=""> 298 </author> 299 <date month="" year="2023" /> 300 </front> 301 </reference> 302 </references> 303 </back> 304 </rfc>