Subject: [Uri-review] Proposed scheme registration: sdns (DNS stamps)

From: Frank Denis <[email-masked]>
Date: Wed, 24 Oct 2018 17:58:55 +0200

Scheme name: sdns

Status: Provisional

Applications/protocols that use this scheme name: stub DNS resolvers and DNS proxies

Contact: Frank Denis <[email-masked]>

Change controller: Frank Denis <[email-masked]>

References: https://dnscrypt.info/stamps-specifications/

Scheme syntax: sdns://<base64 encoded parameters>

Scheme semantics:
The scheme is used to encode parameters required for a DNS client to
securely connect to an upstream server, in a protocol-independent way.

Encoding consideration:
URIs are guaranteed to only contain characters from the URL-safe variant of Base64.

Interoperability considerations: None

Security considerations:
Clients must verify the authenticity and integrity of URIs before using them.

---

From: Ted Hardie <[email-masked]>
Date: Wed, 24 Oct 2018 09:31:55 -0700

Hi Frank,

Thanks for sending the proposal to the list.  A couple of high level
comments.

First, the syntax you present uses //, which doesn't seem to be correct to
me.  If I'm reading the specification correctly, the URL doesn't have a
hierarchical part and does not rely on an authority section (which is what
the // delimits in RFC 3986 syntax).

2nd, it's not clear in the description of addresses how they would be fed
into the algorithm you provide in some of the corner cases.  For example:

"addr is the IP address of the server. It can be an empty string, or just a
port number."  Is the port number represented with a preceding colon?

For IPv6 hosts which use [ and ] as delimeters, is the input URL-encoded
before being base64 encoded?  Are scopes permitted?

For hostname, the document says  that hostname is the server host name
which will also be used as a SNI name.  If the hostname uses one of the
IDNA characters outside the URL-permitted range, is it encoded with URL
encoding or punycode?

As a stylistic note, I think sdns is likely to be confused with the
existing dns scheme name, and I would suggest using "dns-stamps" for
additional clarity.

Thanks again for the opportunity to comment,

Ted Hardie

On Wed, Oct 24, 2018 at 9:00 AM Frank Denis <ietf=
[email-masked]> wrote:

> _______________________________________________
> Uri-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uri-review
>

---

From: Frank Denis <[email-masked]>
Date: Wed, 24 Oct 2018 19:09:47 +0200

> On 24 Oct 2018, at 18:31, Ted Hardie <[email-masked]> wrote:
> 
> Hi Frank,

  Hi Ted,

> Thanks for sending the proposal to the list.  A couple of high level comments.  
> 
> First, the syntax you present uses //, which doesn't seem to be correct to me.  If I'm reading the specification correctly, the URL doesn't have a hierarchical part and does not rely on an authority section (which is what the // delimits in RFC 3986 syntax). 

  All the sdns URIs currently in use share a global namespace. However, the parameters specifically use URL-safe base64 to avoid slashes, so URIs can later:

- Support namespaces
- Support implementation-specific filters (e.g. `sdns://.../ipv6only)

> 2nd, it's not clear in the description of addresses how they would be fed into the algorithm you provide in some of the corner cases.  For example:
> "addr is the IP address of the server. It can be an empty string, or just a port number."  Is the port number represented with a preceding colon?  

  A preceding colon is required. The description has been updated to clarify this. Thanks!

> For IPv6 hosts which use [ and ] as delimeters, is the input URL-encoded before being base64 encoded?  Are scopes permitted?

  Scopes are permitted, and are supported by current implementations. The document has been updated to reflect this.

  Strings are not encoded individually, besides being preceded by their length.

  The entire concatenation of all parameters is eventually base64-encoded. The document has been updated to clarify this.

> For hostname, the document says  that hostname is the server host name which will also be used as a SNI name.  If the hostname uses one of the IDNA characters outside the URL-permitted range, is it encoded with URL encoding or punycode?

  SNI names in certificates are raw binary strings. Given the context, we probably shouldn’t apply any encoding either. The document has been updated to clarify this.

> As a stylistic note, I think sdns is likely to be confused with the existing dns scheme name, and I would suggest using "dns-stamps" for additional clarity.

  This is definitely doable, but would be break all existing implementations and servers lists, 

> Thanks again for the opportunity to comment,

  Thanks for your very helpful comments, Ted.

---

From: Eric Johnson <[email-masked]>
Date: Wed, 24 Oct 2018 17:49:14 -0700

I don't typically chime in on these proposals much, but this one strikes me
as odd. I don't understand the point of having a string representation if
the entirety of the string - except the leading scheme name - is base 64
encoded. Well, OK, I get it for a URI scheme where the underlying data is
actually binary, such as the "data" scheme, except even with that, the
"media-type" is not base64 encoded. This scheme doesn't seem to fit that
model.

The previous comment about the "//" is correct. This is *not* a
hierarchical scheme, so it should not have a "//". That is, "../foobar" is
a meaningless relative URI to apply to the proposed sdns scheme.

I took a random example from
https://github.com/DNSCrypt/dnscrypt-resolvers/blob/master/v2/public-resolvers.md

sdns://AgMAAAAAAAAADDM1LjIzMS42OS43NyA-GhoPbFPz6XpJLVcIS1uYBwWe4FerFQWHb9g_2j24OBJkbnMtZ2NwLmFhZmxhbG8ubWUKL2Rucy1xdWVyeQ

When this is expanded, based on the demo <https://dnscrypt.info/stamps/>, I
find that this is:
protocol: DNS-over-HTTP/2
IP:35.231.69.77
host-name: dns-gcp.aaflalo.me
DNSSEC: true
No logs: true
No filter: false
Hashes: 3e1a1a0f6c53f3e97a492d57084b5b9807059ee057ab1505876fd83fda3db838
Makes me wonder why this can't just be represented as:

sdns:dns-over-http2:ip-35.231.69.77:hn-dns-gcp.aaflolo.me:
dnssec:nologs:hashes-3e1a1a0f6c53f3e97a492d57084b5b9807059ee057ab1505876fd83fda3db838

Maybe I don't understand all the design parameters behind the original
proposal? My proposed above form has a whole bunch of up-sides. It is easy
to visually inspect for certain aspects of correctness, it is more robust
in the face of future enhancements, and it is order-insensitive. Maybe my
idea is completely off base, in which case, it would be very helpful to
augment the proposed specification to clarify why the current proposed
opaque form is *required*.

If compatibility with existing tools is required, then there are multiple
paths:
- check for hierarchy use in existing implementions (sdns:// parsed
differently from sdns:...)
- register a under a new scheme, and phase out support for the existing
sdns:// uses

Eric.

On Wed, Oct 24, 2018 at 10:12 AM Frank Denis <ietf=
[email-masked]> wrote:

> > First, the syntax you present uses //, which doesn't seem to be correct
> to me.  If I'm reading the specification correctly, the URL doesn't have a
>   All the sdns URIs currently in use share a global namespace. However,
> the parameters specifically use URL-safe base64 to avoid slashes, so URIs
> can later:
>
> - Support namespaces
> > 2nd, it's not clear in the description of addresses how they would be
> fed into the algorithm you provide in some of the corner cases.  For
> example:
> > "addr is the IP address of the server. It can be an empty string, or
> just a port number."  Is the port number represented with a preceding
> colon?
>
>   Scopes are permitted, and are supported by current implementations. The
> document has been updated to reflect this.
>
>   The entire concatenation of all parameters is eventually base64-encoded.
> The document has been updated to clarify this.
>
>
>   SNI names in certificates are raw binary strings. Given the context, we
> probably shouldn’t apply any encoding either. The document has been updated
> to clarify this.
>
>

---

From: Frank Denis <[email-masked]>
Date: Thu, 25 Oct 2018 16:00:42 +0200

Hi Eric,

> On 25 Oct 2018, at 02:49, Eric Johnson <eric=[email-masked]> wrote:
> 
> The previous comment about the "//" is correct. This is *not* a hierarchical scheme, so it should not have a "//". That is, "../foobar" is a meaningless relative URI to apply to the proposed sdns scheme.

  The `//` can be removed, then. Clients and libraries can be updated to handle both cases until all published sources are updated to the new format.

> Maybe I don't understand all the design parameters behind the original proposal?

  The main motivation behind the current scheme is to avoid requiring different encoding rules for individual parameters. This makes implementations easier, less bug-prone, and more secure.

  Having some components URL-encoded, other components hex-encoded, and other being binary flags, and characters such as `:` and `-` in your example acting both as separators and as valid characters within names/IP addresses can lead to broken parsers.

  The current scheme has only one way to encode parameters, no matter what their type is, can deal with binary data such as keys and signatures, is trivial to implement, and doesn’t require nested encoding systems.

  It also makes it more obvious to users about what exactly has to be copied/pasted from a list (where sdns URLs are mixed with human-readable descriptions) to a configuration file.

> If compatibility with existing tools is required, then there are multiple paths:
> - check for hierarchy use in existing implementions (sdns:// parsed differently from sdns:...)
> - register a under a new scheme, and phase out support for the existing sdns:// uses

  There will be a transition period, but `sdns://` <sdns://%60> and `sdns:` can be parsed differently.

  Thanks for your comments,

  -Frank.