Hi, Hugo,
On 4/27/2017 10:34 AM, Hugo Maxwell Connery wrote: > Hi all, > > This is the argument that I expected; single port allocation looks > clean, and enables "simple" delivery of processing resources. > > That's why we created ports, no? (please flame here, I have no > idea about this historical claim). See RFC7605, which includes a detailed history. In brief: Ports serve two purposes - demultiplexing IDs to enable multiple connections to a host with a single IP address, and (for first-contact from client to server) to indicate the default service that receives incoming "first contact" requests. You could certainly define a new service that combines HTTPS and DNS on a single port. Note that RFC6335 and RFC7605 both recommend against creating new ports for existing services, but it *might* be arguable that the combined service is somehow uniquely distinct (that would need to be successfully argued, though). > The underlying question raised by this lovely proposition is: > > Was that such a great idea in the first place, now that we know > that surveillance is **what happens on the internet**. > > We need the tech community to re-evaluate assumptions based > on what has been learned since RFC7258. > > I do not suggest that DKG's suggestion is the answer, but I suggest > that it is worth consideration, and more importantly, the concepts > behind it need considering. > > Should we mandate that all future protocols are "demuxible" from > all previous? Well, that's the role ports serve within transport protocols. And the role that the "protocol" field serves in IPv4, the "next header" field serves in IPv6, and the "ethertype" field serves in Ethernet... We always need a way to demux based on protocol, either by a signal from the lower-level protocol (these fields) or in-band (as in TCPMUX, though only historic now, or out of band, e.g., mDNS). However, if you're proposing we do this for ALL services currently assigned to ports, IMO that's a bad idea - it just serves to push port demuxing one layer in, which only creates a war of escalation with NATs, firewalls, and routers - creating an Internet within a flow. So the question here is - why these two? Joe > For me, I say "looks like a good idea" (stream based over TLS). > > Bring on the discussion. > > Regards, > Hugo Connery > -- > Head of IT, DTU Environment, http://www.env.dtu.dk > ________________________________________ > From: dns-privacy [[email protected]] on behalf of Joe Touch > [[email protected]] > Sent: Thursday, 27 April 2017 19:13 > To: Daniel Kahn Gillmor; Jan Včelák > Cc: [email protected] > Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener > [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] > > Hi, all, > > Speaking as an IANA ports team reviewer: > > IMO this document needs to UPDATE the HTTPS specification. > > Otherwise, it's basically encouraging squatting on port 443 TCP, which > is inappropriate. > > 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. > > 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. > > Joe > > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
