Subject: [dnsoverhttp] You've got DNS in my HTTP! No, you've got HTTP in my DNS!!!!

From: Shane Kerr <[email-masked]>
Date: Wed, 23 Nov 2016 12:47:40 +0800

All,

One thing that really stuck with me at the dnsoverhttp bar-BoF was when
someone said that DNS is adopting features that look like HTTP
(DNS sessions handling, DNS RR server-side push, etc.), and that HTTP
is adopting features that look like DNS (sending certificate chains,
providing address information, etc.).

I wonder if our models are starting to break down? Having two protocols
with seemingly very little in common adopting the same features kind of
implies that our abstractions are broken, right?

I can see a number of ways to approach this situation. We can muddle on
and end up duplicating functionality ad-hoc (not necessarily bad), we
can consider a new thingy that encompasses shared needs, we can push
each function to one part of the stack or the other. I don't know.

I don't have any proposals, just something that's been in my head. :)

Cheers,

--
Shane

---

From: George Michaelson <[email-masked]>
Date: Wed, 23 Nov 2016 14:56:15 +1000

from a network layer (IP) view, things above converging is not
surprising. its when they push in the IP header you start to worry.

So from a community which thought it had a thin model against OSI,
finding that things which layer above transport (UDP, TCP) are now
converging on shared behaviours, doesn't feel surprising.

HTTP as a transport for DNS as an application, its inevitable you're
going to see these convergences as people move where they want to do
privacy, do security, do capabilities across from their application
context, to the transport context.

and as we reinvent sessions, session layer properties emerge. thats
what mpTCP and DNS over long-held-TCP and QUIC are doing: re-asserting
state above variant transport and IP bindings

so no, I don't think this is surprising, or unexpected, or unusual.

On Wed, Nov 23, 2016 at 2:47 PM, Shane Kerr <[email-masked]> wrote:
> _______________________________________________
> dnsoverhttp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsoverhttp
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 23 Nov 2016 16:09:12 +1100

The code duplication bothers me a little.

We could decide to have some way to designate certain functions
inviolate and try to ensure that one protocol remains sovereign over
certain things.  This is what we did to splice DANE records into TLS:
those are unmodified DNS records in there.  Then we get the modern
equivalent of render unto Caesar.

I think that things will get quite soupy no matter what we say.  These
are both protocols with a range of weaknesses and patching those
weaknesses occasionally leads one into the architectural territory of
the other.  Maybe that's not a bad thing.  I for one am looking
forward to what comes out of these petri dishes.

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 23 Nov 2016 18:33:35 +0900

I do not mind if there is a new model or structure in which DNS and Web are running.  But if we want to proceed towards a real BOF or WG in IETF in near future, I think we should defined the problem with a PS draft first. 

--Davey

[email-masked]
 
From: Shane Kerr
Date: 2016-11-23 13:47
To: [email-masked]
Subject: [dnsoverhttp] You've got DNS in my HTTP! No, you've got HTTP in my DNS!!!!
All,

 

Cheers,
 
--
Shane

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 23 Nov 2016 18:17:07 +0000

> The code duplication bothers me a little.

Having two (or more) security models for the same data bothers me more than a little. That is, if addressing information has a particular set of security properties if it was gotten through a DNS query, but a different set of security properties if it was gotten from HTTP server push, that seems like an invitation to bad security assumptions in implementations. (It would probably also lead to pages of confusing and subtle security considerations in the document...)

--Paul Hoffman

---

From: Spencer Sevilla <[email-masked]>
Date: Thu, 24 Nov 2016 10:32:47 -0800

This is a really, really good point, especially when its considered that 
anyone writing an implementation might only be familiar with one of the 
models/assumptions, or just making assumptions informed by prior work on 
DNS and/or HTTP. Going back to the original idea of this thread, I think 
that no matter where we lie on duplicating functionalities or code, we 
need to have a single and consistent security model that helps inform 
assumptions about data.

Spencer