You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -37,7 +37,74 @@ The protocol is designed to be lightweight, extensible, and simple to implement
37
37
38
38
{::boilerplate bcp14-tagged}
39
39
40
-
## Protocol Components
40
+
# Protocol Flow
41
+
42
+
The DNSCrypt protocol consists of two distinct phases:
43
+
44
+
1. **Initial Setup Phase** (one-time):
45
+
- The client requests the server's certificate
46
+
- The server responds with its certificate containing public keys
47
+
48
+
2. **Ongoing Communication Phase** (repeated as needed):
49
+
- The client sends encrypted DNS queries
50
+
- The server responds with encrypted DNS responses
51
+
52
+
The following diagram illustrates the complete protocol flow:
53
+
54
+
~~~
55
+
+--------+ +--------+
56
+
| | | |
57
+
| Client | | Server |
58
+
| | | |
59
+
+--------+ +--------+
60
+
| |
61
+
| 1. Request Certificate |
62
+
|---------------------------->|
63
+
| |
64
+
| 2. Certificate Response |
65
+
|<----------------------------|
66
+
| |
67
+
| 3. Encrypted Query |
68
+
|---------------------------->|
69
+
| |
70
+
| 4. Encrypted Query |
71
+
|---------------------------->|
72
+
| |
73
+
| 5. Encrypted Response |
74
+
|<----------------------------|
75
+
| |
76
+
| 6. Encrypted Response |
77
+
|<----------------------------|
78
+
| |
79
+
| 7. Encrypted Query |
80
+
|---------------------------->|
81
+
| |
82
+
| 8. Encrypted Response |
83
+
|<----------------------------|
84
+
| |
85
+
| |
86
+
~~~
87
+
88
+
The initial setup phase (steps 1-2) occurs only when:
89
+
90
+
- A client first starts using a DNSCrypt server
91
+
- The client's cached certificate expires
92
+
- The client detects a certificate with a higher serial number
93
+
94
+
After the initial setup, the client and server engage in the ongoing communication phase (steps 3-8), where encrypted queries and responses are exchanged as needed. This phase can be repeated indefinitely until the certificate expires or a new certificate is available.
95
+
96
+
Key characteristics of the ongoing communication phase:
97
+
98
+
1. **Stateless Operation**: Each query and response is independent. The server does not maintain state between queries.
99
+
100
+
2. **Out-of-Order Responses**: Responses may arrive in a different order than the queries were sent. Each response is self-contained and can be processed independently.
101
+
102
+
3. **Multiple Responses**: A single query may result in multiple responses, and responses can be received without sending new queries. For example, a server might send additional responses for a query that has multiple answers or requires additional processing.
103
+
104
+
4. **Asynchronous Communication**: The protocol does not require strict request-response pairing. A client can send multiple queries before receiving responses, and responses can be processed as they arrive.
105
+
106
+
# Protocol Components
107
+
41
108
42
109
Definitions for client queries:
43
110
@@ -69,6 +136,46 @@ Definitions for server responses:
69
136
- `<resolver-response>`: the unencrypted resolver response. The response is not modified; in particular, the query flags are not altered and the response length MUST be kept in responses prepared to be sent over TCP {{!RFC7766}}.
70
137
- `<resolver-response-pad>`: the variable-length padding.
71
138
139
+
The following diagram shows the structure of a DNSCrypt query packet:
To initiate a DNSCrypt session, a client transmits an ordinary unencrypted `TXT` DNS query to the resolver's IP address and DNSCrypt port. The attempt is first made using UDP; if unsuccessful due to failure, timeout, or truncation, the client then proceeds with TCP.
186
325
187
326
Resolvers are not required to serve certificates both on UDP and TCP.
@@ -257,10 +396,13 @@ This section discusses security considerations for the DNSCrypt protocol.
257
396
258
397
The DNSCrypt protocol provides several security benefits:
259
398
260
-
1. **Confidentiality**: DNS queries and responses are encrypted using XChaCha20-Poly1305 {{!RFC8439}}, preventing eavesdropping of DNS traffic.
261
-
2. **Integrity**: Message authentication using Poly1305 {{!RFC8439}} ensures that responses cannot be tampered with in transit.
262
-
3. **Authentication**: The use of X25519 {{!RFC7748}} for key exchange and Ed25519 for certificate signatures provides strong authentication of resolvers.
263
-
4. **Forward Secrecy**: Short-term key pairs are used for each session, providing forward secrecy.
399
+
1. **Confidentiality**: DNS queries and responses are encrypted using XChaCha20-Poly1305 {{!RFC8439}}, preventing eavesdropping of DNS traffic. For example, a query for "example.com" would be encrypted and appear as random data to an observer.
400
+
401
+
2. **Integrity**: Message authentication using Poly1305 {{!RFC8439}} ensures that responses cannot be tampered with in transit. Any modification to the encrypted response would be detected and rejected by the client.
402
+
403
+
3. **Authentication**: The use of X25519 {{!RFC7748}} for key exchange and Ed25519 for certificate signatures provides strong authentication of resolvers. Clients can verify they are communicating with the intended resolver and not an impostor.
404
+
405
+
4. **Forward Secrecy**: Short-term key pairs are used for each session, providing forward secrecy. Even if a long-term key is compromised, past communications remain secure.
264
406
265
407
## Implementation Security
266
408
@@ -270,46 +412,70 @@ Implementations should consider the following security aspects:
270
412
- Resolvers MUST rotate their short-term key pairs at least every 24 hours
271
413
- Previous secret keys MUST be securely erased after rotation
272
414
- Provider secret keys used for certificate signing SHOULD be stored in hardware security modules (HSMs)
415
+
- Example: A resolver might generate new key pairs daily at midnight UTC
273
416
274
417
2. **Nonce Management**:
275
418
- Nonces MUST NOT be reused for a given shared secret
276
419
- Clients SHOULD include timestamps in their nonces to prevent replay attacks
277
-
- Resolvers SHOULD verify that nonces are within a reasonable time window
420
+
- Resolvers SHOULD verify that nonces are within a reasonable time window (e.g., ±5 minutes)
421
+
- Example: A nonce might be constructed as: `timestamp || random_bytes`
278
422
279
423
3. **Padding**:
280
424
- Implementations MUST use the specified padding scheme to prevent traffic analysis
281
425
- The minimum query length SHOULD be adjusted based on network conditions
426
+
- Example: A 50-byte query might be padded to 256 bytes to prevent size-based fingerprinting
282
427
283
428
4. **Certificate Validation**:
284
429
- Clients MUST verify certificate signatures using the provider's public key
285
430
- Certificates MUST be checked for validity periods
286
431
- Clients MUST prefer certificates with higher serial numbers
432
+
- Example: A client might cache valid certificates and check for updates hourly
287
433
288
434
## Attack Mitigation
289
435
290
436
DNSCrypt provides protection against several types of attacks:
291
437
292
-
1. **DNS Spoofing**: The use of authenticated encryption prevents spoofed responses
293
-
2. **Amplification Attacks**: The padding requirements and minimum query length help prevent amplification attacks {{!RFC5358}}
294
-
3. **Fragmentation Attacks**: The protocol handles fragmentation in a way that prevents certain types of attacks
295
-
4. **Replay Attacks**: The use of nonces and timestamps helps prevent replay attacks
438
+
1. **DNS Spoofing**: The use of authenticated encryption prevents spoofed responses. An attacker cannot forge responses without the server's secret key.
439
+
440
+
2. **Amplification Attacks**: The padding requirements and minimum query length help prevent amplification attacks {{!RFC5358}}. For example, a 256-byte minimum query size limits the amplification factor.
441
+
442
+
3. **Fragmentation Attacks**: The protocol handles fragmentation in a way that prevents certain types of attacks. Large responses are properly fragmented and reassembled.
443
+
444
+
4. **Replay Attacks**: The use of nonces and timestamps helps prevent replay attacks. A replayed query would be detected due to nonce reuse.
296
445
297
446
## Privacy Considerations
298
447
299
448
While DNSCrypt encrypts DNS traffic, there are some privacy considerations:
300
449
301
-
1. **Resolver Knowledge**: Resolvers can still see the client's IP address unless Anonymized DNSCrypt is used
302
-
2. **Query Patterns**: Even with encryption, the size and timing of queries may reveal information
303
-
3. **Certificate Requests**: Initial certificate requests are unencrypted and may reveal client capabilities
450
+
1. **Resolver Knowledge**: Resolvers can still see the client's IP address unless Anonymized DNSCrypt is used. This can reveal the client's location and network.
451
+
452
+
2. **Query Patterns**: Even with encryption, the size and timing of queries may reveal information. Padding helps mitigate this but doesn't eliminate it completely.
453
+
454
+
3. **Certificate Requests**: Initial certificate requests are unencrypted and may reveal client capabilities. This is a one-time exposure per session.
304
455
305
456
## Operational Security
306
457
307
458
Operators should consider:
308
459
309
-
1. **Key Distribution**: Provider public keys should be distributed securely to clients
310
-
2. **Certificate Management**: Certificates should be signed on dedicated hardware, not on resolvers
311
-
3. **Access Control**: Resolvers may implement access control based on client public keys
312
-
4. **Monitoring**: Operators should monitor for unusual patterns that may indicate attacks
460
+
1. **Key Distribution**: Provider public keys should be distributed securely to clients. This might involve:
461
+
- Publishing keys on secure websites
462
+
- Using DNSSEC-signed records
463
+
- Including keys in software distributions
464
+
465
+
2. **Certificate Management**: Certificates should be signed on dedicated hardware, not on resolvers. This provides:
466
+
- Better key protection
467
+
- Centralized certificate management
468
+
- Reduced attack surface
469
+
470
+
3. **Access Control**: Resolvers may implement access control based on client public keys. This can:
471
+
- Prevent abuse
472
+
- Enable service differentiation
473
+
- Support business models
474
+
475
+
4. **Monitoring**: Operators should monitor for unusual patterns that may indicate attacks:
476
+
- High query rates from single clients
477
+
- Unusual query patterns
478
+
- Certificate request anomalies
313
479
314
480
# Operational Considerations
315
481
@@ -349,6 +515,26 @@ Key properties of Anonymized DNSCrypt:
349
515
350
516
## Client Queries
351
517
518
+
The following diagram shows the structure of an Anonymized DNSCrypt query packet:
0 commit comments