idnits 2.17.1 draft-huitema-dnssd-tls-privacy-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2019) is 1873 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '4' on line 168 -- Looks like a reference, but probably isn't: '16' on line 219 == Missing Reference: 'Ack' is mentioned on line 255, but not defined == Outdated reference: A later version (-07) exists of draft-huitema-quic-dnsoquic-06 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-18 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-18 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-30 == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-02 == Outdated reference: A later version (-08) exists of draft-ietf-dnssd-prireq-00 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Huitema 3 Internet-Draft Private Octopus Inc. 4 Intended status: Standards Track D. Kaiser 5 Expires: September 12, 2019 University of Luxembourg 6 March 11, 2019 8 Private Discovery with TLS-ESNI 9 draft-huitema-dnssd-tls-privacy-01 11 Abstract 13 DNS-SD (DNS Service Discovery) normally discloses information about 14 both the devices offering services and the devices requesting 15 services. This information includes host names, network parameters, 16 and possibly a further description of the corresponding service 17 instance. Especially when mobile devices engage in DNS Service 18 Discovery over Multicast DNS at a public hotspot, a serious privacy 19 problem arises. 21 We propose to solve this problem by developing a private discovery 22 profile for UDP based transports using TLS, such as DTLS and QUIC. 23 The profile is based on using the Encrypted SNI extension. We also 24 define a standalone private discovery service, that can be combined 25 with arbitrary applications in the same way as DNS-SD. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 12, 2019. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Discovery Service Using TLS and ESNI . . . . . . . . . . . . 3 64 2.1. Discovery Key . . . . . . . . . . . . . . . . . . . . . . 4 65 2.2. ESNI Extension for Discovery . . . . . . . . . . . . . . 5 66 2.3. Integration with DTLS . . . . . . . . . . . . . . . . . . 5 67 2.4. Integration with QUIC . . . . . . . . . . . . . . . . . . 7 68 3. Private Discovery DNS Service . . . . . . . . . . . . . . . . 8 69 4. Optional Server Arrival Announce . . . . . . . . . . . . . . 8 70 4.1. Server Arrival Announce Specification . . . . . . . . . . 9 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 5.1. Denial of Service by Spoofed Response . . . . . . . . . . 9 73 5.2. Discovery Key Compromise . . . . . . . . . . . . . . . . 10 74 5.3. Private Discovery Key Compromise . . . . . . . . . . . . 10 75 5.4. Tracking by Replay . . . . . . . . . . . . . . . . . . . 11 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 6.1. Experimental use . . . . . . . . . . . . . . . . . . . . 11 78 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 81 8.2. Informative References . . . . . . . . . . . . . . . . . 12 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 84 1. Introduction 86 DNS-SD [RFC6763] over mDNS [RFC6762] enables configurationless 87 service discovery in local networks. It is very convenient for 88 users, but it requires the public exposure of the offering and 89 requesting identities along with information about the offered and 90 requested services. Parts of the published information can seriously 91 breach the user's privacy. These privacy issues and potential 92 solutions are discussed in [KW14a] and [KW14b]. 94 When analyzing these scenarios in [I-D.ietf-dnssd-prireq], we find 95 that the DNS-SD messages leak identifying information such as the 96 instance name, the host name or service properties. 98 In this document, we propose a discovery solution that can replace 99 DNS-SD in simple deployment scenarios, with the following 100 characteristics: 102 1. We only target discovery of peers on the same local network, 103 using multicast. We make no attempt at compatibility with the 104 server based solutions such as DNSSD over Unicast DNS [RFC6763]. 106 2. We do not attempt to keep the same formats as mDNS [RFC6762]. 108 3. We assume a solution that can be integrated in an application, 109 without dependency on system support. 111 The proposed solution aligns with TLS 1.3 [RFC8446], and specifically 112 with transports of TLS over UDP, such as DTLS [I-D.ietf-tls-dtls13] 113 or QUIC [I-D.ietf-quic-transport]. The solution uses SNI encryption 114 [I-D.ietf-tls-esni]. 116 The solution assumes that entities who want to be privately 117 discovered maintain an asymmetric discovery key pair. The public 118 component of that discovery key pair and the service name of the 119 entity are provisioned to authorized discovery clients. In this 120 document, we will refer to this public component as the "Discovery 121 Key" of the server. When needed, we will refer to the private 122 component of the key pair as the "Discovery Private Key". 124 1.1. Requirements 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in [RFC2119]. 130 2. Discovery Service Using TLS and ESNI 132 In the proposed solution, the first packet of a TLS-based UDP 133 transport is broadcast or multicast over the local network. This 134 packet carries the TLS 1.3 ClientHello message, including an 135 Encrypted SNI (ESNI) extension. The ESNI is encrypted with the 136 Discovery Key of the requested service. 138 Services that are ready to be discovered listen on the broadcast or 139 multicast address and check whether the received packets contain a 140 TLS 1.3 ClientHello Message and an ESNI extension. If the extension 141 can be decrypted with the Private Discovery Key of the local service, 142 they set up a connection. 144 This mechanism only works with TLS based protocols operating over 145 UDP, such as DTLS or QUIC. 147 2.1. Discovery Key 149 Private discovery relies on the privacy of the server Discovery Key, 150 which is used to encrypt the target server name carried in the ESNI 151 extension. Clients can only discover a server if they know the 152 server's Discovery Key. Servers receiving a properly encrypted 153 discovery request do not know the identity of the client issuing the 154 request, but they know that the client belongs to a group authorized 155 to perform the discovery. 157 In the ESNI based specification, the server's Discovery Key plays the 158 same role as the ESNI Encryption Key of the client facing server, but 159 a major difference is that the Discovery Key is kept private. 160 According to standard ESNI, the client facing server publishes an 161 ESNI encryption key in the DNS. In contrast, the Discovery Key MUST 162 NOT be publicly available in the DNS. 164 The discovery key is passed to the peer in exactly the same format as 165 ESNI: 167 struct { 168 uint8 checksum[4]; 169 KeyShareEntry keys<4..2^16-1>; 170 CipherSuite cipher_suites<2..2^16-2>; 171 uint16 padded_length; 172 uint64 not_before; 173 uint64 not_after; 174 Extension extensions<0..2^16-1>; 175 } ESNIKeys; 177 This document does not discuss how the Discovery Key is provisioned 178 to authorized discovery clients. 180 The ESNI extension design assumes that several services are available 181 through a single client facing server. These different services have 182 different SNI values and length. ESNI pads these SNI to a padded 183 length specified for the client facing server, ensuring that third 184 parties cannot infer the identity of the service from the length of 185 the extension. In our design, requests for multiple services are 186 sent over multicast. If different services used different padding 187 length, third parties could infer the service identity from the ESNI 188 length. To prevent this information leakage, services participating 189 in private discovery MUST set the padded length to exactly 128 bytes. 191 2.2. ESNI Extension for Discovery 193 The ESNI extension is defined in [I-D.ietf-tls-esni] as: 195 struct { 196 CipherSuite suite; 197 KeyShareEntry key_share; 198 opaque record_digest<0..2^16-1>; 199 opaque encrypted_sni<0..2^16-1>; 200 } ClientEncryptedSNI; 202 In standard ESNI usage, the "record_digest" identifies the ESNI 203 Encryption Key. Clients using private discovery MUST leave the 204 "record_digest" empty, and encode it as a zero-length binary string. 205 The ESNI Encryption Key will be the Discovery Key of the target 206 server. 208 The KeyShareEntry is set in accordance with the ESNI specification. 209 It is combined with the server Discovery Key to encrypt the SNI. 210 According to the ESNI specification, the encrypted structure 211 contains: 213 struct { 214 ServerNameList sni; 215 opaque zeros[ESNIKeys.padded_length - length(sni)]; 216 } PaddedServerNameList; 218 struct { 219 uint8 nonce[16]; 220 PaddedServerNameList realSNI; 221 } ClientESNIInner; 223 Servers that receive the extension as part of private discovery 224 attempt to decrypt the value using their Private Discovery Key. If 225 the decryption succeeds, and if the decrypted SNI corresponds to the 226 expected value, the server will accept the discovery request. 228 2.3. Integration with DTLS 230 The message flows of DTLS 1.3 [I-D.ietf-tls-dtls13] all start with 231 the client sending a TLS ClientHello message. The following figure 232 presents a simple DTLS flow using the ESNI extension for private 233 discovery: 235 Client Server 237 ClientHello +----------+ 238 + key_share* | Flight 1 | 239 + ESNI --------> +----------+ 241 ServerHello 242 + key_share* +----------+ 243 {EncryptedExtensions} | Flight 2 | 244 {ESNI} +----------+ 245 {Certificate*} 246 <-------- {Finished} 247 [Application Data*] 249 +----------+ 250 | Flight 3 | 251 {Finished} --------> +----------+ 252 [Application Data] 254 +----------+ 255 <-------- [Ack] | Flight 4 | 256 [Application Data*] +----------+ 258 [Application Data] <-------> [Application Data] 260 The first flight consists of a single UDP packet. In classic DTLS, 261 this would be sent to the IP address and UDP port chosen for the 262 application. Instead, the client using private discovery MUST sent 263 this to the "private discovery" multicast address defined in 264 Section 6 and to the UDP port chosen for the application. 266 The multicast message sent by the client will be received by many 267 servers. The servers using private discovery MUST verify that the 268 ESNI extension is present. If it is present, each server attempts to 269 decrypt the ESNI extension using the local private discovery key, as 270 specified in Section 2.2. If the verification succeeds, the server 271 proceeds with the connection, and sends the second flight of DTLS 272 packets to the IP address and UDP port from which it received the 273 client's first flight. 275 The client receiving the second flight of messages processes them as 276 specified in DTLS 1.3 [I-D.ietf-tls-dtls13]. The client MUST verify 277 that the ESNI extension is present, and matches the expected value as 278 specified in Section 2.2. If the ESNI extension is absent or does 279 not pass verification, the entire flight MUST be ignored. If the 280 verification succeeds, the client remembers the IP address and UDP 281 port of the server, and uses it for the reminder of the session. 283 A successful ESNI exchange demonstrates to the server that the client 284 has knowledge of the server discovery key, and to the client that the 285 server is in possession of the corresponding private discovery key. 286 This is meant to restrict access to a subset of the client and server 287 population, but does not replace the need for server authentication 288 and optional client authentication as specified in TLS 1.3. 290 2.4. Integration with QUIC 292 The QUIC Transport uses TLS to negotiate encryption keys. The use of 293 TLS in QUIC is specified in [I-D.ietf-quic-tls], and can be 294 summarized as follow: 296 1. The QUIC connection starts with the client sending an Initial 297 message, carrying a TLS ClientHello and its extensions. 299 2. The server replies with its own Initial message, carrying the 300 server hello and establishing the "handshake" keys used to 301 protect the reminder of the TLS 1.3 exchange. 303 3. Server and client exchange encrypted Handshake messages to verify 304 that the session is properly established and to negotiate the 305 encryption keys of the application data. 307 4. Server and Client exchange encrypted application messages until 308 they decide to close the connection. 310 All messages are sent over UDP. 312 When using Private Discovery, the client adds an ESNI extension to 313 the ClientHello sent in the Initial message. The ESNI extension is 314 formatted a specified in Section 2.2. In classic QUIC, the Initial 315 message would be sent in a UDP packet to the IP address and UDP port 316 of the server. Instead, the client using private discovery MUST sent 317 this to the "private discovery" multicast address defined in 318 Section 6 and to the UDP port chosen for the application. 320 The multicast message sent by the client will be received by many 321 servers. The servers using private discovery MUST verify that the 322 ESNI extension is present. If it is present, each server attempts to 323 decrypt the ESNI extension using the local private discovery key, as 324 specified in Section 2.2. If the verification succeeds, the server 325 proceeds with the connection, and sends the next QUIC packets to the 326 IP address and UDP port from which it received the client's first 327 flight. 329 The client receiving the second flight of messages processes them as 330 specified in DTLS 1.3 [I-D.ietf-tls-dtls13]. The client MUST verify 331 that the ESNI extension is present, and matches the expected value as 332 specified in Section 2.2. If the ESNI extension is absent or does 333 not pass verification, the entire QUIC connection MUST be ignored. 334 If the verification succeeds, the client remembers the IP address and 335 UDP port of the server, and uses it for the reminder of the QUIC 336 connection. 338 3. Private Discovery DNS Service 340 The mechanisms discussed in Section 2 assume that an application 341 based on DTLS or QUIC is modified to enable private local discovery. 342 This does not cover all services. Further services can be supported 343 by a two-phase process in which each application is paired with an 344 implementation of the private discovery service. 346 The private discovery service is an implementation of DNS over QUIC, 347 as specified in [I-D.huitema-quic-dnsoquic], modified to also 348 implement the Private Discovery over Quic defined in Section 2.4. 349 The DNS implementation is solely for the purpose of providing a 350 service equivalent to DNS-SD. 352 The Private Discovery DNS Service is run by the service that wants to 353 be discovered. The name of the discovery service is the name of the 354 service that needs to be discovered. Clients are provisioned with 355 the associated Discovery Key. Clients discover the Private Discovery 356 DNS Service, and can then use it to obtain the DNS records associated 357 with the application service: SRV, TXT, A or AAAA records. 359 4. Optional Server Arrival Announce 361 The proposed design relies on active discovery of servers by the 362 clients. When a client arrives on a new network and wishes to 363 establish a connection to a server, it sends a multicast message that 364 tries to reach that server. This designs has two potential issues: 366 If the server is not present when a client tries to contact it, 367 the client may have to repeat the connection attempts over time. 369 If multiple clients connect to the same server, each client sends 370 a multicast message, which can translate in heavy multicast load 371 in some configurations. 373 The importance of these two issues is debatable. Many applications 374 have a peer-to-peer nature, in which peers can be either clients or 375 servers. When two peers are not present at the same time, the first 376 peer to arrive will fail to establish a connection, but the second 377 peer will succeed, without having to rely on time based repetitions. 378 Similarly, if we move from device oriented discovery to application 379 oriented discovery, the number of client per server is likely to be 380 very small, so that there will be little difference between 381 "multicast per client" and "multicast per server". 383 However, there may be configurations where a "server arrival 384 announce" message would result in fast discovery and fewer multicast 385 messages. 387 4.1. Server Arrival Announce Specification 389 The server arrival announce message is a UDP packet sent to the 390 Discovery Multicast Address reserved in Section 6 and port %lt;TBD>. 392 The format of the message will be defined in a next draft version, 393 meeting the following requirements: 395 Multiplexing: should be easily demuxed from DTLS or QUIC traffic. 397 ESNI: should contain an ESNI extension, secured with the server's 398 discovery key. 400 Replay: should contain a timestamp and the global scope IPv6 401 address of the server. 403 5. Security Considerations 405 The use of TLS 1.3 and the ESNI extension provides robust defenses 406 against attacks. In particular, Private Discovery benefits from the 407 defenses against dictionary attacks and replay attacks built in the 408 ESNI design. Protections against a residual DOS attack is discussed 409 in Section 5.1. 411 The privacy of the discovery relies on keeping the discovery key of 412 the service secret. The consequences and partial mitigation of 413 leaking the discovery key are discussed in Section 5.2. 415 Compromising of the server's private discovery key will allow an 416 attacker to break the privacy of the discovery, as discussed in 417 Section 5.3. 419 5.1. Denial of Service by Spoofed Response 421 Attackers may try to disrupt a private discovery handshake by sending 422 a spoofed Server Hello (DTLS) or a spoofed Server Initial packet 423 (QUIC). The client will reject these attempts after noticing that 424 the encrypted extensions do not include a proper ESNI extension, 425 containing the expected copy of the ESNI nonce. 427 Attackers will not succeed spoofing the server, but they could 428 succeed in denying the connection if the fake response arrives before 429 the response from the actual server, and if the implementation just 430 gave up the attempt after failing to validate the first response that 431 it received. 433 To defend against this attack, implementations SHOULD keep listening 434 for responses and attempting validation until they receive at least 435 one valid response from the expected server. 437 5.2. Discovery Key Compromise 439 The Discovery Key is known by all the authorized clients. If one of 440 these clients is compromised, the privacy of the server will be 441 compromised: attackers will be able to spoof the authorized client 442 and discover whether the server is present on a local network. 443 However, the leak can only be exploited in an active attack: the 444 attacker must actively set up a connection with the target server. 446 The attack is mitigated when the server migrates to a different 447 discovery key and restricts the availability of that key to non- 448 compromised clients. 450 Exploiting a compromised discovery key normally requires that the 451 attacker is present on the same link as the target. Attackers might 452 try to work around that limitation by sending unicast packet targeted 453 at plausible server locations. Servers participating in private 454 discovery MUST NOT accept discovery requests arriving from off-link 455 sources. 457 5.3. Private Discovery Key Compromise 459 The private component of the asymmetric key pair used for discovery 460 MUST be kept secret by the server. If it is compromised, attackers 461 can process discovery requests and verify that they can be decrypted 462 with the server's private discovery key. They could also process 463 logs of old discovery attempts. 465 The design provides two mitigations against the consequences of this 466 failure: 468 o The discovery requests do not uniquely identify the client, and 469 the attacker will only know that an attempt came from one of the 470 authorized clients. 472 o The actual communications are protected by TLS, and inherit the 473 forward secrecy properties of TLS 1.3. 475 [[TODO: consider specifying a way to rotate the discovery key, so as 476 to mitigate the lack of forward secrecy. Maybe add that to ESNI. ]] 478 5.4. Tracking by Replay 480 Suppose that an attacker has identified a client, and is capable of 481 recording the multicast messages from that client. The attacker can 482 then replay the message, triggering a response from the target server 483 if present on the network. 485 The attacker will not be able to actually establish a connection with 486 the server -- the TSL and ESNI designs protect against that. But it 487 will be able to find out that the same server that responded to the 488 client before responds now, which is a way to track the server. 490 The attacker can mount two variations of the attack: replay over 491 time, and replay at different locations. In the current design, the 492 main protection against that attack is the implementation of a 493 "discovery window", so that servers only listen to multicast requests 494 when they are "ready to be discovered". 496 [[TODO: consider adding a time stamp in an extension to ESNI.]] 498 [[TODO: consider adding the IPv6 address of the sender in an 499 extension to ESNI.]] 501 [[TODO: special consideration for server arrival announce.]] 503 6. IANA Considerations 505 IANA is required to allocate the IPv6 multicast address FF02:: 506 for use as "Private Discovery Multicast Address" described in this 507 document. 509 6.1. Experimental use 511 **RFC Editor's Note:** Please remove this section prior to 512 publication of a final version of this document. 514 Early experiments MAY use the address FF02::60DB:F6C5. This address 515 is marked in the IANA registry as unassigned. 517 7. Acknowledgments 519 [[TODO]] 521 8. References 523 8.1. Normative References 525 [I-D.huitema-quic-dnsoquic] 526 Huitema, C., Shore, M., Mankin, A., Dickinson, S., and J. 527 Iyengar, "Specification of DNS over Dedicated QUIC 528 Connections", draft-huitema-quic-dnsoquic-06 (work in 529 progress), March 2019. 531 [I-D.ietf-quic-tls] 532 Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 533 draft-ietf-quic-tls-18 (work in progress), January 2019. 535 [I-D.ietf-quic-transport] 536 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 537 and Secure Transport", draft-ietf-quic-transport-18 (work 538 in progress), January 2019. 540 [I-D.ietf-tls-dtls13] 541 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 542 Datagram Transport Layer Security (DTLS) Protocol Version 543 1.3", draft-ietf-tls-dtls13-30 (work in progress), 544 November 2018. 546 [I-D.ietf-tls-esni] 547 Rescorla, E., Oku, K., Sullivan, N., and C. Wood, 548 "Encrypted Server Name Indication for TLS 1.3", draft- 549 ietf-tls-esni-02 (work in progress), October 2018. 551 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 552 Requirement Levels", BCP 14, RFC 2119, 553 DOI 10.17487/RFC2119, March 1997, 554 . 556 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 557 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 558 . 560 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 561 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 562 . 564 8.2. Informative References 566 [I-D.ietf-dnssd-prireq] 567 Huitema, C., "DNS-SD Privacy and Security Requirements", 568 draft-ietf-dnssd-prireq-00 (work in progress), September 569 2018. 571 [KW14a] Kaiser, D. and M. Waldvogel, "Adding Privacy to Multicast 572 DNS Service Discovery", DOI 10.1109/TrustCom.2014.107, 573 2014, . 576 [KW14b] Kaiser, D. and M. Waldvogel, "Efficient Privacy Preserving 577 Multicast DNS Service Discovery", 578 DOI 10.1109/HPCC.2014.141, 2014, 579 . 582 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 583 DOI 10.17487/RFC6762, February 2013, 584 . 586 Authors' Addresses 588 Christian Huitema 589 Private Octopus Inc. 590 Friday Harbor, WA 98250 591 U.S.A. 593 Email: huitema@huitema.net 594 URI: http://privateoctopus.com/ 596 Daniel Kaiser 597 University of Luxembourg 598 6, avenue de la Fonte 599 Esch-sur-Alzette 4364 600 Luxembourg 602 Email: daniel.kaiser@uni.lu 603 URI: https://secan-lab.uni.lu/