Hi Joe-- Thanks for the feedback!
On Thu 2017-04-27 10:13:54 -0700, Joe Touch wrote:
> Speaking as an IANA ports team reviewer:
>
> IMO this document needs to UPDATE the HTTPS specification.
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.
But will there be future stream-based versions of HTTP? afaict,
HTTP-over-QUIC is likely to be the future of HTTP, and that's a place
where this demuxing approach explicitly does not apply (since it's not
stream-based). So maybe it'll turn out that the draft doesn't scare the
HTTP community much. We should encourage their review!
I initially sent the doc for discussion here in DPRIVE because DPRIVE
offers one of the primary motivations for the work, and to make sure i
wasn't missing anything crucial from the DNS side. But i'm certainly
planning to bring the document to the attention of HTTP-specific groups.
Perhaps http...@ietf.org comes next? I'm open to other suggestions.
> 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.
> 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 -- 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?
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?
--dkg
signature.asc
Description: PGP signature
_______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
