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

Hey DKG,

Throwing my .02 in, although it's similar to what you've heard from others upthread --

I wouldn't do this for h1; it'll be an interop nightmare. H2 gives you the properties you want and the implementation / testing burden is much more realistic.

For H2, I wouldn't use an ALPN token; define a new frame type or two that you can send optimistically before SETTINGS sync, stopping them if you don't get the right SETTING from your peer. Realistically, this is going to need to be configured into the client anyway, so there's some amount of pre-arrangement.

Cheers,



> On 4 May 2017, at 11:26 am, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
> 
> On Thu 2017-05-04 11:11:59 +1000, Martin Thomson wrote:
>> On 4 May 2017 at 10:43, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
>>> I address this in the draft section "Why not ALPN?" -- if anyone thinks
>>> the text there could be improved, i'd be happy to hear suggestions for
>>> how to change it.
>> 
>> Mike is suggesting that you define one that is "http + dns" or maybe
>> "http or dns", which would mean that you could use either.  Then you
>> convince existing HTTP clients to use that (a few browsers would do
>> the job).  Even if they didn't actually DO DNS, you would still be
>> able to hide in the mass/mess that they represent.
> 
> hm, it sounds like that won't work for h2, given Patrick's point that h2
> isn't client-speaks-first.  Right?  If we tried to do something like
> "h2|dns", it seems like it would introduce a potential latency hit for
> any h2-specific client that proposed it, because the server couldn't
> send its first frame unsolicited.  I know you can't speak for Mozilla,
> but would you imagine firefox opting into this for normal http/2
> connections?
> 
>> In TLS 1.3, the server choice is hidden, so even where the server
>> doesn't pick this choice, it works.  In TLS 1.2, you probably want to
>> convince a few servers to pick this new thing, but that obviously
>> means more work for those servers.
> 
> For http/1.x, the draft is arguing that using an ALPN label is
> unnecessary -- so if that's right, what would we gain from a new ALPN
> label over using the existing HTTP/1.1 mechanism (i.e., either no ALPN
> or the ALPN token "http/1.1")?
> 
> It looks to me like the new ALPN label introduces costs:
> 
> * implementations on both server and client need to specify it
> 
> * client implementations need to verify that it was chosen, and fail if
>   not
> 
> * network monitors can see that it was offered and discriminate against
>   the offerer at least (TLS 1.3), and in some cases the established
>   connections (TLS 1.2 and earlier).
> 
> What are the benefits of introducing a new ALPN label for demuxing
> HTTP/1.1 from DNS?
> 
> Thanks for the discussion,
> 
>     --dkg

--
Mark Nottingham   https://www.mnot.net/

Received on Tuesday, 9 May 2017 01:21:10 UTC