Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt]

[Hugo Connery]

On Fri, 2017-04-28 at 23:37 +0300, Ilari Liusvaara wrote:
> On Fri, Apr 28, 2017 at 12:44:19PM -0700, Joe Touch wrote:
> > 
> > The key, however, is that this proposal is really redefining HTTP
> > ports
> > 80 and 443 (if that's the direction you go), and you need to get
> > consensus on that. It's not enough to simply say "we want to do it
> > and
> > it works as currently specd".
> 
> The properties this draft exploits for detection are completely
> fundamential to HTTP/1.x and HTTP/2. There is no way anything that
> breaks those properties can be deployed on mass scale without a new
> ALPN, which should be ample warning to the server that new things
> are going on.
> 
> This isn't "unextendable because of middleboxes", it is "unextendable
> because the endpoints can't negotiate".
> 
> 
> -Ilari

If we accept DKG's proof, it works on what *is*. 

"Cant negotiate"?  There is no negotiation.  The "server" demuxes on 
published, known, accepted, delineated protocol standards.  

Cant fix future changes and cant fix non-end-points screwing with the
stream.

Am I missing something?

/Hugo



___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt]

[Hugo Connery]

On Fri, 2017-04-28 at 16:25 -0700, Joe Touch wrote:
> > On Apr 28, 2017, at 4:21 PM, Mark Andrews  wrote:
> > 
> > Writing a draft is how we propose extensions.
> 
> The IANA considerations at least need to make that clear.
[snip].


+1 "Writing a draft ...".  

The multi-decade effort to publish, update and revise the process 
for participation in IANA affairs has failed?  Its not "clear" yet?

# [Insert responses here.]

/Hugo Connery


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt]

[Joe Touch]

> On Apr 28, 2017, at 4:21 PM, Mark Andrews  wrote:
> 
> Writing a draft is how we propose extensions.

The IANA considerations at least need to make that clear. It would help to have 
this update the HTTP RFCs and be explicit about that goal from the abstract 
onwards too. 

Joe
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt]

[Mark Andrews]

In message , Joe Touch writes:
> Hugo,
> 
> 
> On 4/28/2017 12:57 PM, Hugo Connery wrote:
> > ...
> >> But using any existing ports for new behaviors is simply not your
> >> right.
> >> ...
> > I could not more vehemently disagree.
> >
> > 1) DKG is publishing an idea to the community, not taking over
> > anything.
> That idea encourages others to squat on an existing port. I doubt either
> the IESG or IANA would allow that to proceed as an RFC of any kind.

Actually it is proposing a extension to the existing port usage
that co-exists.  Whether it was said well or not is a different
matter.  Writing a draft is how we propose extensions.

Squatting would be just doing it then begging forgiveness afterwards.

> > 2) I will run whatever software on my end-point using any port 
> > that I wish.  End of story. 
> I agree fully with that story - any service can be run on any port.
> 
> However, the integrity of the very nature of assigned ports requires is
> based on the expectation that endpoints run only the assigned service on
> the corresponding assigned port *except when other direct information
> indicates otherwise* (e.g., port override in a URL, mDNS entry, etc.)
> 
> >  Standards exist to encourage compliance,
> > not demand it.  
> That undermines the very nature of a standard.
> 
> If you want others to follow your laws, you have to respect theirs.
> 
> Joe
> 
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt]

[Joe Touch]

Hugo,


On 4/28/2017 12:57 PM, Hugo Connery wrote:
> ...
>> But using any existing ports for new behaviors is simply not your
>> right.
>> ...
> I could not more vehemently disagree.
>
> 1) DKG is publishing an idea to the community, not taking over
> anything.
That idea encourages others to squat on an existing port. I doubt either
the IESG or IANA would allow that to proceed as an RFC of any kind.

> 2) I will run whatever software on my end-point using any port 
> that I wish.  End of story. 
I agree fully with that story - any service can be run on any port.

However, the integrity of the very nature of assigned ports requires is
based on the expectation that endpoints run only the assigned service on
the corresponding assigned port *except when other direct information
indicates otherwise* (e.g., port override in a URL, mDNS entry, etc.)

>  Standards exist to encourage compliance,
> not demand it.  
That undermines the very nature of a standard.

If you want others to follow your laws, you have to respect theirs.

Joe

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt]

[Joe Touch]

On 4/28/2017 1:37 PM, Ilari Liusvaara wrote:
>> The key, however, is that this proposal is really redefining HTTP ports
>> 80 and 443 (if that's the direction you go), and you need to get
>> consensus on that. It's not enough to simply say "we want to do it and
>> it works as currently specd".
> The properties this draft exploits for detection are completely
> fundamential to HTTP/1.x and HTTP/2. There is no way anything that
> breaks those properties can be deployed on mass scale without a new
> ALPN, which should be ample warning to the server that new things
> are going on.

All I'm asking is that this doc makes it very clear that it intends to
redefine the services on ports 80 and/or 443, if that's the way you go.

I'll leave it to others to decide whether that's a good idea or not.

Joe
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt]

[Joe Touch]

Hi, Daniel,

On 4/28/2017 12:14 AM, Daniel Kahn Gillmor wrote:
> In particular, the approach i've described in the draft only works for
> client-speaks-first, stream-based protocols. 
I don't think you can assert that it works except where you have
checked, and only for the *current* definition of those protocols.

Keep in mind that ports are assigned to current *and all future*
versions of a protocol, so all bets are off the instant you stop
looking. Which means, effectively, that you can never assert that this
works on an existing port assignment UNTIL you coordinate with that
port's assignee, and they confirm that their service will never conflict
with your definition.

That also implies that this service cannot be defined as valid for any
service that isn't already assigned. That would effectively be squatting
on the entire port space.

Joe

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt]

[Ray Bellis]

On 28/04/2017 08:42, Daniel Kahn Gillmor wrote:

> But does the non-predictability requirement hold in stream-based DNS,
> where the establishment of the stream itself provides at least as good
> protection against spoofed responses?  If it holds in cleartext
> stream-based DNS, does it also hold for encrypted, streamed DNS, where
> the channel itself provides significantly *better* protection against
> spoofed responses.

What if the stream is being unwrapped before it reaches the eventual
destination,  e.g. a hypothetical TLS endpoint that forwards the
received queries over UDP  ?

Who's responsibility is it to make sure those forwarded queries can't be
spoofed?

It's a stretch, I know, but the point is to make us consider how
removing security features might have unintended consequences upstream.

Ray

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt]

[Daniel Kahn Gillmor]

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

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt]

[Shumon Huque]

On Thu, Apr 27, 2017 at 9:21 PM, Paul Hoffman  wrote:

> On 27 Apr 2017, at 17:51, Shumon Huque wrote:
>
> Perhaps we should revisit the decision not to encrypt the ALPN
>> extension (NPN redux?).
>>
>
> The term "we" is probably not appropriate here. It was not this WG that
> made that decision: it was the TLS WG, after multiple threads with (I
> believe) hundreds of messages.


Yeah, I should have been more precise. By "we", I was referring to TLS or
perhaps the larger IETF community (and not DPRIVE) ..

-- 
Shumon Huque
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt]

[Joe Touch]

On 4/27/2017 12:01 PM, Joe Touch wrote:
> Hi, Christina,
>
> On 4/27/2017 11:51 AM, Christian Huitema wrote:
PS - my sincere apologies to Christian.

(spellcheck is evil ;-(

Joe

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt]

[Marc.Mosko]

I think I’m missing something about this proposal, at least in the case of a 
general demux protocol.  If you detach TLS from a specific application context, 
who provides the certificates and evaluates the trust anchors?  If you don’t 
have a traffic secret, how do you hide the demux signaling?  It seems like 
having a general purpose TLS demux would require delegating all that to some 
other process including the DH exchange?

I can see how, as draft draft-dkg-dprive-demux-dns-http-00 puts it, a special 
terminator might offer two protocols of DNS and HTTP, but those are both being 
offered by the same application that share the same TLS credentials, yes?

Thanks,
Marc

> On Apr 27, 2017, at 11:51 AM, Christian Huitema  wrote:
> 
> 
> 
> On 4/27/2017 10:48 AM, Joe Touch wrote:
>> ...
>> 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).
> 
> Well, things do change. The most interesting thing that we did observe
> is the generalized used of TLS. The stack used to be IP/TCP/App, and in
> that case you really need to demux at the TCP layer, and you can do that
> using ports. The stack that we do have now is IP/TCP/TLS/App, or
> IP/Quic/TLS/App. We could still demux at the TCP layer, but we could
> also demux at the TLS layer. As DKG points out, demuxing at the TLS
> layer does hide some of the metadata, and thus provides better privacy
> and resistance to censorship than demuxing on the clear text TCP port.
> 
> Of course, one only gets the privacy benefits if the TLS demuxing is not
> based on clear text fields like the SNI or the ALPN. DKG proposes an
> heuristic, based on the observation that the first bytes of application
> data are enough to differentiate HTTP and DNS. Heuristics like these
> have the advantage of being easily deployed. They do have the
> inconvenient of affecting the long term evolution of the application
> protocols. We may want to look at a robust long term alternative.
> 
> HTTP2 actually took a step in that direction. This is specified in
> section 3.5 of RFC 7540. "Each endpoint is required to send a connection
> preface as a final confirmation of the protocol in use and to establish
> the initial settings for the HTTP/2 connection.  The client and server
> each send a different connection preface." The spec goes on to specify a
> 24 byte string, corresponding to the ASCII value "PRI *
> HTTP/2.0\r\n\r\nSM\r\n\r\n", which the server acknowledges by sending a
> "SETTINGS" frame.
> 
> So maybe we could build on that, and let application register their
> specific 24 bytes string, allowing for demux on top of TLS. That would
> define an organized process.
> 
> -- Christian Huitema
> 
> 
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt]

[Joe Touch]

Hi, Christina,

On 4/27/2017 11:51 AM, Christian Huitema wrote:
> So maybe we could build on that, and let application register their
> specific 24 bytes string, allowing for demux on top of TLS. That would
> define an organized process.
>
> -- Christian Huitema

This can be done for a new service to be defined, which then might
qualify for a new IANA for a port assignment.

AFAICT, no one can redefine any existing service, even ones that use
TLS, this way, though.

I'm not sure whether it would be a good idea, though - my view is that
this just serves to push port demuxing - which already exists outside
TLS - inside TLS.

Joe

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt]

[Christian Huitema]

On 4/27/2017 10:48 AM, Joe Touch wrote:
> ...
> 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).

Well, things do change. The most interesting thing that we did observe
is the generalized used of TLS. The stack used to be IP/TCP/App, and in
that case you really need to demux at the TCP layer, and you can do that
using ports. The stack that we do have now is IP/TCP/TLS/App, or
IP/Quic/TLS/App. We could still demux at the TCP layer, but we could
also demux at the TLS layer. As DKG points out, demuxing at the TLS
layer does hide some of the metadata, and thus provides better privacy
and resistance to censorship than demuxing on the clear text TCP port.

Of course, one only gets the privacy benefits if the TLS demuxing is not
based on clear text fields like the SNI or the ALPN. DKG proposes an
heuristic, based on the observation that the first bytes of application
data are enough to differentiate HTTP and DNS. Heuristics like these
have the advantage of being easily deployed. They do have the
inconvenient of affecting the long term evolution of the application
protocols. We may want to look at a robust long term alternative.

HTTP2 actually took a step in that direction. This is specified in
section 3.5 of RFC 7540. "Each endpoint is required to send a connection
preface as a final confirmation of the protocol in use and to establish
the initial settings for the HTTP/2 connection.  The client and server
each send a different connection preface." The spec goes on to specify a
24 byte string, corresponding to the ASCII value "PRI *
HTTP/2.0\r\n\r\nSM\r\n\r\n", which the server acknowledges by sending a
"SETTINGS" frame.

So maybe we could build on that, and let application register their
specific 24 bytes string, allowing for demux on top of TLS. That would
define an organized process.

-- Christian Huitema


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt]

[Hugo Maxwell Connery]

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).

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?

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 [dns-privacy-boun...@ietf.org] on behalf of Joe Touch 
[to...@isi.edu]
Sent: Thursday, 27 April 2017 19:13
To: Daniel Kahn Gillmor; Jan Včelák
Cc: dns-privacy@ietf.org
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
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt]

[Tony Finch]

Section 3.2.2 HTTP/1

Is there a SP missing between the request-target and the HTTP-version in
the diagram of the shortest possible request?

Section 4.3 Opcode / 4.6 ANCOUNT NSCOUNT

Do you want to support UPDATE? If not it should probably be ruled out up
front, since it changes some of the analysis (though not the result,
since octet 5 will be zero for DNS).

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Thames, Dover, Wight, Portland, Plymouth: North or northwest, backing west for
a time, 4 or 5, decreasing 3 at times. Slight or moderate. Showers, then rain
for a time except in Plymouth. Good, occasionally moderate.

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt]

[Petr Špaček]

On 27.4.2017 02:43, Daniel Kahn Gillmor wrote:
> Hi Jan--
> 
> On Wed 2017-04-26 11:05:33 +0200, Jan Včelák wrote:
>> thank you for writing this down. The draft is great. And it's awesome
>> that it's accompanied with an actual running code.
> 
> thanks!  and thanks for the quick review :)
> 
>> A have just a few notes after reading the draft for the first time:
>> - For the sake of simplicity, I would suggest dropping the part about
>> HTTP/0.9. I don't think it's worth the effort keeping it supported.
> 
> That would definitely make the document much simpler :) I suppose i
> should float this by the HTTP community, to see whether they agree that
> it's ok to drop HTTP/0.9.
> 
>> - The Section 3 (Overview of initial octets) is a little bit chaotic
>> and scattered. Maybe it would be more readable if you just provided
>> pointers to specification of the protocols without providing much
>> details, then shown the initial octets (or headers) side by side
>> without analysing the content, and in the end walked by the bytes from
>> the beginning while discussing the values.
> 
> I understand what you're saying, i'm not sure how to do this exactly.
> With DNS, the fields are fixed size and have fixed meaning, but with
> HTTP, there's an abstract grammar.  So they don't just "line up" side by
> side, as it were.
> 
> I can certainly remove the copied text and just leave pointers to other
> documents, but that seems like it effectively asks the reader to do a
> bunch of pointer chasing when i've already done the pointer-chasing for
> them.

Let me state that I like current version with copied text. For me it is
really easier to follow than jumping between documents.

Petr Špaček  @  CZ.NIC

> 
> Any concrete suggestions for how to improve it?  It's maintained in
> markdown at https://gitlab.com/dkg/hddemux and i welcome merge requests
> or patches!
> 
>> - I love how simple the algorithm is in the end. And the proof is
>> great.
> 
> I'm glad you like it too -- i'm happy that it seems possible to be
> strictly confident in the demuxing.
> 
>   --dkg

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt]

[Daniel Kahn Gillmor]

Hi Jan--

On Wed 2017-04-26 11:05:33 +0200, Jan Včelák wrote:
> thank you for writing this down. The draft is great. And it's awesome
> that it's accompanied with an actual running code.

thanks!  and thanks for the quick review :)

> A have just a few notes after reading the draft for the first time:
> - For the sake of simplicity, I would suggest dropping the part about
> HTTP/0.9. I don't think it's worth the effort keeping it supported.

That would definitely make the document much simpler :) I suppose i
should float this by the HTTP community, to see whether they agree that
it's ok to drop HTTP/0.9.

> - The Section 3 (Overview of initial octets) is a little bit chaotic
> and scattered. Maybe it would be more readable if you just provided
> pointers to specification of the protocols without providing much
> details, then shown the initial octets (or headers) side by side
> without analysing the content, and in the end walked by the bytes from
> the beginning while discussing the values.

I understand what you're saying, i'm not sure how to do this exactly.
With DNS, the fields are fixed size and have fixed meaning, but with
HTTP, there's an abstract grammar.  So they don't just "line up" side by
side, as it were.

I can certainly remove the copied text and just leave pointers to other
documents, but that seems like it effectively asks the reader to do a
bunch of pointer chasing when i've already done the pointer-chasing for
them.

Any concrete suggestions for how to improve it?  It's maintained in
markdown at https://gitlab.com/dkg/hddemux and i welcome merge requests
or patches!

> - I love how simple the algorithm is in the end. And the proof is
> great.

I'm glad you like it too -- i'm happy that it seems possible to be
strictly confident in the demuxing.

  --dkg


signature.asc
Description: PGP signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy