From 1dbd20326831fc5d3762931c0fda05818c855857 Mon Sep 17 00:00:00 2001 From: Marcin Rataj Date: Fri, 22 May 2020 13:43:54 +0200 Subject: [PATCH 1/4] Create 2020-05-21--design-discussion-subdomains-dns-label-limit.md --- ...n-discussion-subdomains-dns-label-limit.md | 93 +++++++++++++++++++ 1 file changed, 93 insertions(+) create mode 100644 meeting-notes/2020/Q2/2020-05-21--design-discussion-subdomains-dns-label-limit.md diff --git a/meeting-notes/2020/Q2/2020-05-21--design-discussion-subdomains-dns-label-limit.md b/meeting-notes/2020/Q2/2020-05-21--design-discussion-subdomains-dns-label-limit.md new file mode 100644 index 00000000..16c800f3 --- /dev/null +++ b/meeting-notes/2020/Q2/2020-05-21--design-discussion-subdomains-dns-label-limit.md @@ -0,0 +1,93 @@ +# Design Discussion: Subdomain support for CIDs longer than 63 characters + +## Context + +Full explanation: https://github.com/ipfs/go-ipfs/issues/7318 + +**tl;dr** + +[RFC 1034](https://tools.ietf.org/html/rfc1034#page-7) states that "each node has a label, +which is zero to 63 octets in length", this means CID in subdomain can't be longer than 63 characters. + +If we split at 63rd character that will produce TLS error because it is impossible +to have TLS cert for more than one wildcard level (`*.*.ipns.dweb.link`), as clarified in [RFC6125](https://tools.ietf.org/html/rfc6125#page-27) +and implemented by browser vendors. + +DNS length limits were known, but we did not include inlined ed25519 in evaluation at a time, and this recent development changes the timeline, so we need to have a fixes for longer CIDs and TLS for IPNS websites. + +The Goal of this meeting is to find the least invasive path forward. + + +## Participants + +- @Stebalien +- @lidel +- @ribasushi +- @aschmahmann + + + +## Options vs Tradeoffs + +### Generic fix + +Split after 63rd char: "Do it anyway" ? +add support, if not for ed25519, it will be useful for longer CIDs (they won't have TLS anyway) + + +### IPNS/ed25519-specific fixes + +Anything we can do to give IPNS websites created with ed25519 TLS without warnings? + +| Fix | TLS for IPNS | TLS for long CID | touches libp2p | different text representation in subdomain than base32 | +| --- | --- | --- | --- | --- | +| custom multicodec for ed25519 keys | YES | NO | YES | NO | +| Allow PeerIDs as multihash in base32 (only in `*.ipns` subdomains) | YES | NO | NO | YES | +| PeerIDs as CIDv1 in base36 | YES | NO | YES | YES | +| "sha256 split in two" idea [missing notes, sorry!] | YES | ? | NO | YES | + +## Notes + +- all agree that touching key encoding in libp2p too expensive atm +- leaking browser limitations down the stack is something we want to avoid, looking for a surgical fix that is compatible with CIDv1 specs + +- base36 makes ed25519 fit in a single DNS label + - missing from multibase - keeps need to register + - could be used only for IPNS +- AI: test 63 character domain on Cloudflare + - OK: confirmed 63 works: https://abc012345678901234567890123456789012345678901234567890123456789.lidel.org/ + ("github pages" proxied via Cloudflare that gives automatic TLS cert) +- **Plan for enabling TLS for IPNS with ed25519 on subdomain gateways** + - implement support for base36 in go and js (multibase support) + - ship with go-ipfs 0.6 ad js-ipfs, giving us one release overlap + - in parallel implement splitting after 63rd char (for longer CIDs that are not ed25519 keys) + - switch to ed25519 keys in go-ipfs 0.7 by default + - mvp: make subdomain gateway redirect upgrade ed25519 to base36 + + +### Open questions + +Things TBD, with provisional decisions for MVP: + +- should we use base36: + - only for ed25519? (yes for mvp) + - only on subdomain gateways? (yes for mvp) + - always, or only when libp2p-key can't fit in a single DNS label? (only ed25519 for mvp) + - or maybe we should change the default text representation of ipns keys everywhere in IPFS? + - .. should this get bubbled up to libp2p? + - if so, should we update https://github.com/libp2p/specs/blob/master/RFC/0001-text-peerid-cid.md ? + + +### Side-discussions + +- ot: dnslink – how to add security? + - (a) DNSSec - no-cigar: relies on root keys, hard to set up + - (b) sign dnslink record and add TXT record with CID of signature + - at some point in the future start redirecting to `.ipns-insecure.` if not signed + +- ot: solve "what is IPNS" problem + - mostly renaming things in docs, to remove confusion in ecosystem + - propose a split on next core impl. meeting: + - "IPNS" as a generic mutable namespace + - pick a new name for libp2p-key based subset of "IPNS" ("signed records", "IPRS", etc) + From c3324c57ed63e619315a45d820be2356c932bd6c Mon Sep 17 00:00:00 2001 From: Marcin Rataj Date: Fri, 22 May 2020 13:58:06 +0200 Subject: [PATCH 2/4] Update meeting-notes/2020/Q2/2020-05-21--design-discussion-subdomains-dns-label-limit.md Co-authored-by: Peter Rabbitson --- .../2020-05-21--design-discussion-subdomains-dns-label-limit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meeting-notes/2020/Q2/2020-05-21--design-discussion-subdomains-dns-label-limit.md b/meeting-notes/2020/Q2/2020-05-21--design-discussion-subdomains-dns-label-limit.md index 16c800f3..57552a0c 100644 --- a/meeting-notes/2020/Q2/2020-05-21--design-discussion-subdomains-dns-label-limit.md +++ b/meeting-notes/2020/Q2/2020-05-21--design-discussion-subdomains-dns-label-limit.md @@ -76,7 +76,7 @@ Things TBD, with provisional decisions for MVP: - or maybe we should change the default text representation of ipns keys everywhere in IPFS? - .. should this get bubbled up to libp2p? - if so, should we update https://github.com/libp2p/specs/blob/master/RFC/0001-text-peerid-cid.md ? - + - or should we phase out base32 completely, and not use it in any API/CLI UX going forward ### Side-discussions From 6aa3c8381acd6fa1b27422cc0a085d9794535a79 Mon Sep 17 00:00:00 2001 From: Marcin Rataj Date: Fri, 22 May 2020 22:22:16 +0200 Subject: [PATCH 3/4] Update meeting-notes/2020/Q2/2020-05-21--design-discussion-subdomains-dns-label-limit.md --- ...20-05-21--design-discussion-subdomains-dns-label-limit.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/meeting-notes/2020/Q2/2020-05-21--design-discussion-subdomains-dns-label-limit.md b/meeting-notes/2020/Q2/2020-05-21--design-discussion-subdomains-dns-label-limit.md index 57552a0c..ccecddc8 100644 --- a/meeting-notes/2020/Q2/2020-05-21--design-discussion-subdomains-dns-label-limit.md +++ b/meeting-notes/2020/Q2/2020-05-21--design-discussion-subdomains-dns-label-limit.md @@ -48,7 +48,10 @@ Anything we can do to give IPNS websites created with ed25519 TLS without warnin ## Notes -- all agree that touching key encoding in libp2p too expensive atm +- changing the way we represent keys in libp2p is expensive and may introduce problems in the future + - right now all key types represented as CIDs get `libp2p-key` codec + - this makes it easy to add support for different key types in the future without the need for updating CID/multicodec-related libraries + - if we introduce a custom multicodec for ed25519 this creates bad precedent of moving key type to multicodec layer: leaking abstractions and making it harder to support across implementations - leaking browser limitations down the stack is something we want to avoid, looking for a surgical fix that is compatible with CIDv1 specs - base36 makes ed25519 fit in a single DNS label From cf93dd85b2858bb144837cff2499f18c91537bd2 Mon Sep 17 00:00:00 2001 From: Marcin Rataj Date: Wed, 15 Jul 2020 09:53:32 +0200 Subject: [PATCH 4/4] Update 2020-05-21--design-discussion-subdomains-dns-label-limit.md --- ...5-21--design-discussion-subdomains-dns-label-limit.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/meeting-notes/2020/Q2/2020-05-21--design-discussion-subdomains-dns-label-limit.md b/meeting-notes/2020/Q2/2020-05-21--design-discussion-subdomains-dns-label-limit.md index ccecddc8..a1b46952 100644 --- a/meeting-notes/2020/Q2/2020-05-21--design-discussion-subdomains-dns-label-limit.md +++ b/meeting-notes/2020/Q2/2020-05-21--design-discussion-subdomains-dns-label-limit.md @@ -94,3 +94,12 @@ Things TBD, with provisional decisions for MVP: - "IPNS" as a generic mutable namespace - pick a new name for libp2p-key based subset of "IPNS" ("signed records", "IPRS", etc) +----- + +### Update from 2020-07-14 + +We decided to simplify our approach and merged [ED25519 support in subdomains](https://github.com/ipfs/go-ipfs/pull/7441) + - works with TLS certs + - defaults to base36 (instead of base32) in subdomains for all libp2p-keys + - b36 fix will be attempted for all long CIDs if original base is too long + - returns error if CID is still too long to be loaded via subdomain (this might be the case if you use custom hash functions eg. `sha-512`)