Hi, Daniel,
On 4/27/2017 11:58 PM, Daniel Kahn Gillmor wrote:
> ...
> The draft isn't strictly about HTTPS, though that context is certainly a
> prime motivating factor.
>
> It's about demultiplexing cleartext, streamed DNS from cleartext,
> streamed HTTP. This just happens to mainly be useful in evading network
> surveillance and censorship under cover of TLS :)
>
> That said, i definitely agree that the draft needs more input from the
> HTTP community. In particular, if this approach gets deployed widely,
> we'd want to ensure that future stream-based versions of HTTP are aware
> of this demuxing algorithm and don't create a start-of-stream signature
> that the algorithm might confuse with DNS.
That's the key - you need to know that port 443 and 80 are defined by
HTTP, not this document.
If you want to define a service without any coordination, you certainly
can propose to merge the current definitions of DNS and HTTP/HTTPS and
see whether that qualifies for a port assignment.
But you cannot redefine a port belonging to another party.
...
>> Keep in mind that any bit pattern that you *think* differentiates DNS
>> from HTTPS is not yours to define - it is the purview of HTTPS to define
>> or delegate in any way they see fit.
> I hope it's clear from the draft that it's not defining any
> differentiating bit pattern. Rather, it's pointing out that the
> existing specifications *already* define necessarily distinguishable bit
> patterns.
That's like saying that I can take your car because you're not currently
in it.
Ports 80 and 443 belong to HTTP/HTTPS. They *own* ***ALL*** current and
future bit patterns on that port.
The same is true for all other current assignments. And all unassigned
or reserved ports (from the assignable ranges) are effectively owned by
IANA until they are assigned.
Under no condition is it appropriate for this or any other document to
define the meaning of a bit pattern on any port **EXCEPT** those
assigned to that service.
>
>> You can certainly ask IANA for a new port on which to run both HTTPS and
>> DNS, but it is inappropriate to change port 443 without coordination.
> This seems unlikely to achieve any useful goal
It preserves the integrity of HTTP and HTTPS, and ensures that those
protocols can use whatever bit pattern they want for future variants.
> -- existing HTTPS isn't
> going to move to a new port, which means traffic on that port would be
> suspect to a would-be censor or a pervasive monitor, right?
All traffic on the Internet is already subject to censorship and
monitoring. I can't see how you can traverse someone else's link or
router without that possibility, regardless of port.
> Joe, as a thought experiment, as an IANA ports reviewer, if both the
> HTTP and DNS communities were to decide that some version of draft seems
> OK to them, what would you want the IANA Considerations section to look
> like?
IMO, either:
a) a request for a new assignment (listed as TBD in this document
until assigned; please do not squat on an unassigned port that might be
assigned in the meantime)
or
b) if you want to redefine an existing service on a currently
assigned port, a clear indication in the doc header, abstract, intro,
content, and IANA sections that this doc updates HTTP or HTTP, or
whatever service you want this to update. (which would require
confirmation by IANA in contact with the current assignee).
Joe
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
