Next-hop aliases: Escaping "."

[bemasc]

The "unreserved characters" set includes ".", but we actually need to escape "." to avoid Period Injection attacks.

[tfpauly]

Hm, my impression is that this attack is about making a period within a label look like a label separator.

By the time that you have a string for a name, it would already need this kind of escaping done. Put another way, the "." characters we have in the string are indeed label separators already.

[bemasc]

The draft doesn't specify how to construct the DNS name string (and in general there is not a great specification for this). The most common convention (noted in RFC 1035 Section 5.1) is to precede "." inside a label with a backslash. This draft would then percent-escape the backslash, but not the ".", so there would indeed be a "." character that is not a label separator in the final header field value.

Whatever escaping convention you choose, this is sufficiently non-obvious that I think a very clear specification and some examples are probably in order.

(This whole rigmarole is normally not a problem because URIs are restricted to contain only "hostnames", which cannot have weird characters in the labels.)

[tfpauly]

@bemasc can you look at #2529?

[martinthomson]

I realize that this is now resolved, but isn't it also possible that we could say "this field cannot be used to express names that include a literal period (".") in labels" ?

[tfpauly]

@martinthomson yeah that’s an option, although it could theoretically incentivize using dots in labels as a way to hide the CNAME from being reported

[martinthomson]

Sure. But you can add another attribute called "this-site-is-abusing-this-mechanism" for use when that happens.