[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0001] branch master updated: placeholder security considerations
|
From: |
gnunet |
|
Subject: |
[lsd0001] branch master updated: placeholder security considerations |
|
Date: |
Sun, 10 May 2020 21:30:17 +0200 |
This is an automated email from the git hooks/post-receive script.
martin-schanzenbach pushed a commit to branch master
in repository lsd0001.
The following commit(s) were added to refs/heads/master by this push:
new da0d417 placeholder security considerations
da0d417 is described below
commit da0d4170cdd23d1ef2605f41964a7eb0955d6d98
Author: Schanzenbach, Martin <address@hidden>
AuthorDate: Sun May 10 21:25:16 2020 +0200
placeholder security considerations
---
draft-schanzen-gns.html | 66 ++++++++++++++++++++----
draft-schanzen-gns.txt | 130 ++++++++++++++++++++++++++++++++++--------------
draft-schanzen-gns.xml | 28 ++++++++++-
3 files changed, 176 insertions(+), 48 deletions(-)
diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
index 24283da..fc0fd4f 100644
--- a/draft-schanzen-gns.html
+++ b/draft-schanzen-gns.html
@@ -1237,7 +1237,19 @@ table {
<p id="section-toc.1-1.9.1"><a href="#section-9"
class="xref">9</a>. <a href="#name-security-considerations"
class="xref">Security Considerations</a><a href="#section-toc.1-1.9.1"
class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.9.2.1">
- <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1"
class="xref">9.1</a>. <a href="#name-revocations"
class="xref">Revocations</a><a href="#section-toc.1-1.9.2.1.1"
class="pilcrow">¶</a></p>
+ <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1"
class="xref">9.1</a>. <a href="#name-abuse-mitigation" class="xref">Abuse
mitigation</a><a href="#section-toc.1-1.9.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="toc ulEmpty" id="section-toc.1-1.9.2.2">
+ <p id="section-toc.1-1.9.2.2.1"><a href="#section-9.2"
class="xref">9.2</a>. <a href="#name-zone-key-management" class="xref">Zone
key management</a><a href="#section-toc.1-1.9.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="toc ulEmpty" id="section-toc.1-1.9.2.3">
+ <p id="section-toc.1-1.9.2.3.1"><a href="#section-9.3"
class="xref">9.3</a>. <a href="#name-root-zone-management" class="xref">Root
zone management</a><a href="#section-toc.1-1.9.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="toc ulEmpty" id="section-toc.1-1.9.2.4">
+ <p id="section-toc.1-1.9.2.4.1"><a href="#section-9.4"
class="xref">9.4</a>. <a href="#name-impact-of-underlying-dht"
class="xref">Impact of underlying DHT</a><a href="#section-toc.1-1.9.2.4.1"
class="pilcrow">¶</a></p>
+</li>
+<li class="toc ulEmpty" id="section-toc.1-1.9.2.5">
+ <p id="section-toc.1-1.9.2.5.1"><a href="#section-9.5"
class="xref">9.5</a>. <a href="#name-revocations"
class="xref">Revocations</a><a href="#section-toc.1-1.9.2.5.1"
class="pilcrow">¶</a></p>
</li>
</ul>
</li>
@@ -2720,23 +2732,59 @@ table {
<h2 id="name-security-considerations">
<a href="#section-9" class="section-number selfRef">9. </a><a
href="#name-security-considerations" class="section-name selfRef">Security
Considerations</a>
</h2>
-<div id="security_rev">
+<div id="security_abuse">
<section id="section-9.1">
- <h3 id="name-revocations">
-<a href="#section-9.1" class="section-number selfRef">9.1. </a><a
href="#name-revocations" class="section-name selfRef">Revocations</a>
+ <h3 id="name-abuse-mitigation">
+<a href="#section-9.1" class="section-number selfRef">9.1. </a><a
href="#name-abuse-mitigation" class="section-name selfRef">Abuse mitigation</a>
</h3>
<p id="section-9.1-1">
+ DNS abuse: Squatting, takedowns, homographs.<a
href="#section-9.1-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="security_keymanagement">
+<section id="section-9.2">
+ <h3 id="name-zone-key-management">
+<a href="#section-9.2" class="section-number selfRef">9.2. </a><a
href="#name-zone-key-management" class="section-name selfRef">Zone key
management</a>
+ </h3>
+<p id="section-9.2-1">
+ Users need to manage and protect zone keys.<a href="#section-9.2-1"
class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="security_root">
+<section id="section-9.3">
+ <h3 id="name-root-zone-management">
+<a href="#section-9.3" class="section-number selfRef">9.3. </a><a
href="#name-root-zone-management" class="section-name selfRef">Root zone
management</a>
+ </h3>
+<p id="section-9.3-1">
+ Users must manage local root zone (availability).<a
href="#section-9.3-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="security_dht">
+<section id="section-9.4">
+ <h3 id="name-impact-of-underlying-dht">
+<a href="#section-9.4" class="section-number selfRef">9.4. </a><a
href="#name-impact-of-underlying-dht" class="section-name selfRef">Impact of
underlying DHT</a>
+ </h3>
+<p id="section-9.4-1">
+ Is significant.<a href="#section-9.4-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="security_rev">
+<section id="section-9.5">
+ <h3 id="name-revocations">
+<a href="#section-9.5" class="section-number selfRef">9.5. </a><a
href="#name-revocations" class="section-name selfRef">Revocations</a>
+ </h3>
+<p id="section-9.5-1">
Revocation payloads do NOT include a 'new' key for key replacement.
- In inclusion of such a key would have two major disadvantages:<a
href="#section-9.1-1" class="pilcrow">¶</a></p>
-<p id="section-9.1-2">
+ In inclusion of such a key would have two major disadvantages:<a
href="#section-9.5-1" class="pilcrow">¶</a></p>
+<p id="section-9.5-2">
If revocation is used after a private key was compromised,
allowing key replacement would be dangerous, because if an
adversary took over the private key, the adversary could then
broadcast a revocation with a key replacement. For the replacement,
the compromised owner would have no chance to issue even a
revocation. Thus, allowing a revocation message to replace a private
- key makes dealing with key compromise situations worse.<a
href="#section-9.1-2" class="pilcrow">¶</a></p>
-<p id="section-9.1-3">
+ key makes dealing with key compromise situations worse.<a
href="#section-9.5-2" class="pilcrow">¶</a></p>
+<p id="section-9.5-3">
Sometimes, key revocations are used with the objective of changing
cryptosystems. Migration to another cryptosystem by replacing keys
via a revocation message would only be secure as long as both
@@ -2745,7 +2793,7 @@ table {
running zones for both ciphersystems in parallel for a while. The
migration would conclude by revoking the legacy zone key only once
it is deemed no longer secure, and hopefully after most users have
- migrated to the replacement.<a href="#section-9.1-3"
class="pilcrow">¶</a></p>
+ migrated to the replacement.<a href="#section-9.5-3"
class="pilcrow">¶</a></p>
</section>
</div>
</section>
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
index 9557480..0640e4f 100644
--- a/draft-schanzen-gns.txt
+++ b/draft-schanzen-gns.txt
@@ -88,11 +88,15 @@ Table of Contents
7.1. Verification . . . . . . . . . . . . . . . . . . . . . . 23
8. Determining the Root Zone and Zone Governance . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
- 9.1. Revocations . . . . . . . . . . . . . . . . . . . . . . . 25
+ 9.1. Abuse mitigation . . . . . . . . . . . . . . . . . . . . 25
+ 9.2. Zone key management . . . . . . . . . . . . . . . . . . . 25
+ 9.3. Root zone management . . . . . . . . . . . . . . . . . . 25
+ 9.4. Impact of underlying DHT . . . . . . . . . . . . . . . . 25
+ 9.5. Revocations . . . . . . . . . . . . . . . . . . . . . . . 26
10. GANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
- 11. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 26
- 12. Normative References . . . . . . . . . . . . . . . . . . . . 28
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
+ 11. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 27
+ 12. Normative References . . . . . . . . . . . . . . . . . . . . 29
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction
@@ -102,10 +106,6 @@ Table of Contents
globally unique names. As the awareness of the central role DNS
plays on the Internet rises, various institutions are using their
power (including legal means) to engage in attacks on the DNS, thus
- threatening the global availability and integrity of information on
- the Internet.
-
-
@@ -114,6 +114,9 @@ Schanzenbach, et al. Expires 13 May 2020
[Page 2]
Internet-Draft The GNU Name System November 2019
+ threatening the global availability and integrity of information on
+ the Internet.
+
DNS was not designed with security as a goal. This makes it very
vulnerable, especially to attackers that have the technical
capabilities of an entire nation state at their disposal. This
@@ -160,9 +163,6 @@ Internet-Draft The GNU Name System
November 2019
d is a 256-bit ECDSA private key. In GNS, records are signed using
a key derived from "d" as described in Section 4.
- p is the prime of edwards25519 as defined in [RFC7748], i.e. 2^255
- - 19.
-
Schanzenbach, et al. Expires 13 May 2020 [Page 3]
@@ -170,6 +170,9 @@ Schanzenbach, et al. Expires 13 May 2020
[Page 3]
Internet-Draft The GNU Name System November 2019
+ p is the prime of edwards25519 as defined in [RFC7748], i.e. 2^255
+ - 19.
+
B is the group generator (X(P),Y(P)) of edwards25519 as defined in
[RFC7748].
@@ -214,10 +217,7 @@ Internet-Draft The GNU Name System
November 2019
DATA SIZE denotes the 32-bit size of the DATA field in bytes and in
network byte order.
- TYPE is the 32-bit resource record type. This type can be one of
- the GNS resource records as defined in Section 3 or a DNS record
- type as defined in [RFC1035] or any of the complementary
- standardized DNS resource record types. This value must be stored
+
@@ -226,6 +226,10 @@ Schanzenbach, et al. Expires 13 May 2020
[Page 4]
Internet-Draft The GNU Name System November 2019
+ TYPE is the 32-bit resource record type. This type can be one of
+ the GNS resource records as defined in Section 3 or a DNS record
+ type as defined in [RFC1035] or any of the complementary
+ standardized DNS resource record types. This value must be stored
in network byte order. Note that values below 2^16 are reserved
for allocation via IANA ([RFC6895]).
@@ -270,10 +274,6 @@ Internet-Draft The GNU Name System
November 2019
PRIVATE This is a private record of this peer and it should thus not
be published in the DHT. Thus, this flag should never be
- encountered by a resolver for records obtained from the DHT.
- Private records should still be considered just like regular
- records when resolving labels in local zones.
-
@@ -282,6 +282,10 @@ Schanzenbach, et al. Expires 13 May 2020
[Page 5]
Internet-Draft The GNU Name System November 2019
+ encountered by a resolver for records obtained from the DHT.
+ Private records should still be considered just like regular
+ records when resolving labels in local zones.
+
3.1. Record Types
A registry of GNS Record Types is described in Section 10. The
@@ -329,10 +333,6 @@ Internet-Draft The GNU Name System
November 2019
-
-
-
-
Schanzenbach, et al. Expires 13 May 2020 [Page 6]
Internet-Draft The GNU Name System November 2019
@@ -1376,7 +1376,33 @@ Internet-Draft The GNU Name System
November 2019
9. Security Considerations
-9.1. Revocations
+9.1. Abuse mitigation
+
+ DNS abuse: Squatting, takedowns, homographs.
+
+9.2. Zone key management
+
+ Users need to manage and protect zone keys.
+
+9.3. Root zone management
+
+ Users must manage local root zone (availability).
+
+9.4. Impact of underlying DHT
+
+ Is significant.
+
+
+
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 25]
+
+Internet-Draft The GNU Name System November 2019
+
+
+9.5. Revocations
Revocation payloads do NOT include a 'new' key for key replacement.
In inclusion of such a key would have two major disadvantages:
@@ -1394,14 +1420,6 @@ Internet-Draft The GNU Name System
November 2019
via a revocation message would only be secure as long as both
cryptosystems are still secure against forgery. Such a planned, non-
emergency migration to another cryptosystem should be done by running
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 25]
-
-Internet-Draft The GNU Name System November 2019
-
-
zones for both ciphersystems in parallel for a while. The migration
would conclude by revoking the legacy zone key only once it is deemed
no longer secure, and hopefully after most users have migrated to the
@@ -1430,6 +1448,16 @@ Internet-Draft The GNU Name System
November 2019
Served", as described in [RFC8126]. GANA is requested to populate
this registry as follows:
+
+
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 26]
+
+Internet-Draft The GNU Name System November 2019
+
+
Number | Name | Contact | References
---------+-----------------+---------+---------
65536 | PKEY | N/A | [This.I-D]
@@ -1453,7 +1481,35 @@ Internet-Draft The GNU Name System
November 2019
-Schanzenbach, et al. Expires 13 May 2020 [Page 26]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 27]
Internet-Draft The GNU Name System November 2019
@@ -1509,7 +1565,7 @@ Internet-Draft The GNU Name System
November 2019
-Schanzenbach, et al. Expires 13 May 2020 [Page 27]
+Schanzenbach, et al. Expires 13 May 2020 [Page 28]
Internet-Draft The GNU Name System November 2019
@@ -1565,7 +1621,7 @@ Internet-Draft The GNU Name System
November 2019
-Schanzenbach, et al. Expires 13 May 2020 [Page 28]
+Schanzenbach, et al. Expires 13 May 2020 [Page 29]
Internet-Draft The GNU Name System November 2019
@@ -1621,7 +1677,7 @@ Internet-Draft The GNU Name System
November 2019
-Schanzenbach, et al. Expires 13 May 2020 [Page 29]
+Schanzenbach, et al. Expires 13 May 2020 [Page 30]
Internet-Draft The GNU Name System November 2019
@@ -1677,4 +1733,4 @@ Authors' Addresses
-Schanzenbach, et al. Expires 13 May 2020 [Page 30]
+Schanzenbach, et al. Expires 13 May 2020 [Page 31]
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 16bb1bf..4c4710f 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -1433,6 +1433,30 @@
</section>
<section anchor="security" numbered="true" toc="default">
<name>Security Considerations</name>
+ <section anchor="security_abuse" numbered="true" toc="default">
+ <name>Abuse mitigation</name>
+ <t>
+ DNS abuse: Squatting, takedowns, homographs.
+ </t>
+ </section>
+ <section anchor="security_keymanagement" numbered="true" toc="default">
+ <name>Zone key management</name>
+ <t>
+ Users need to manage and protect zone keys.
+ </t>
+ </section>
+ <section anchor="security_root" numbered="true" toc="default">
+ <name>Root zone management</name>
+ <t>
+ Users must manage local root zone (availability).
+ </t>
+ </section>
+ <section anchor="security_dht" numbered="true" toc="default">
+ <name>Impact of underlying DHT</name>
+ <t>
+ Is significant.
+ </t>
+ </section>
<section anchor="security_rev" numbered="true" toc="default">
<name>Revocations</name>
<t>
@@ -1458,8 +1482,8 @@
migration would conclude by revoking the legacy zone key only once
it is deemed no longer secure, and hopefully after most users have
migrated to the replacement.
- </t>
- </section>
+ </t>
+ </section>
</section>
<section anchor="iana" numbered="true" toc="default">
<name>GANA Considerations</name>
--
To stop receiving notification emails like this one, please contact
address@hidden.
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [lsd0001] branch master updated: placeholder security considerations,
gnunet <=