On Sun, Apr 26, 2015 at 8:33 PM, 🔓Dan Wing <dw...@cisco.com> wrote: > > On 26-Apr-2015 08:27 pm, Watson Ladd <watsonbl...@gmail.com> wrote: >> >> On Fri, Apr 24, 2015 at 9:21 AM, 🔓Dan Wing <dw...@cisco.com> wrote: >>> >>> On 23-Apr-2015 06:37 pm, Phillip Hallam-Baker <i...@hallambaker.com> wrote: >>> >>> >>> >>> On Thu, Apr 23, 2015 at 8:57 PM, Watson Ladd <watsonbl...@gmail.com> wrote: >>>> >>>> >>>> On Apr 23, 2015 1:52 PM, "Phillip Hallam-Baker" <i...@hallambaker.com> >>>> wrote: >>>>> >>>> >>>>> On Thu, Apr 23, 2015 at 4:21 PM, <emoji_u1f513.png>Dan Wing >>>>> <dw...@cisco.com> wrote: >>>>> >>>>>> I am not an expert on DTLS but that was the concern that made me avoid >>>>>> using >>>>>> it. I want a completely stateless resolver, not just UDP. >>>>>> >>>>>> That means using either a very fast ECC scheme for authentication or >>>>>> some >>>>>> sort of kerberos ticket. >>>>>> >>>>>> >>>>>> I believe "Transport Layer Security (TLS) Session Resumption without >>>>>> Server-Side State", https://tools.ietf.org/html/rfc5077 solves that >>>>>> problem. >>>>>> It works with TLS and with DTLS. >>>>> >>>>> That is an option in DTLS. >>>>> >>>>> For a DTLS based scheme to be acceptable, client support has to be >>>>> mandatory. >>>>> >>>>> If we do that, I have no problem with the additional overhead. >>>>> >>>>> >>>>> The question then is whether we can profile DTLS without in effect >>>>> requiring a new implementation library. >>>> >>>> This doesn't solve the actual problem, as compared with DNS/UDP. >>>> >>>> DTLS resumption requires a round trip: the server keeps that state alive >>>> as a new DTLS connection, and then the client or server closes it after >>>> using it. So if you have 10,000 clients, even if only 100 of them issue >>>> queries a second, but over two minutes they all do, you will either force >>>> them all to pay the latency price of reopening the connection or store >>>> state >>>> for 10,000 DTLS sessions. >>>> >>>> Another problem is with anycast. Ordinarily failover is completely >>>> transparent to users: the packets go somewhere else, and get responded to. >>>> I >>>> don't see how this works with TLS, unless you do fancy stateful failover >>>> tricks. >>>> >>>> The easiest solution is to encrypt packets with a public key that the >>>> servers have, or force every packet to contain something equivalent to >>>> resumption data. But that requires not using TLS/DTLS. >>>> >>>> Sincerely, >>>> Watson Ladd >>> >>> >>> Ah, then it doesn't work. >>> >>> I can't see why people are so insistent on clinging to a familiar label. Is >>> it because it is easier to put blind faith in TLS than consider how it >>> works? >>> >>> >>> Hugs and kisses, Phillip. >>> >>> >>> It is time to write down requirements. >> >> If you actually want to ensure that all devices using DNS can >> transition to the new protocol, you need to not change how the packet >> flows work or require massive handling of state. Only DNSCrypt-like >> solutions can do this: TLS can't. > > Not even TLS early data > (https://tools.ietf.org/html/draft-ietf-tls-tls13-05#section-7.3.2.5.3)?
0-RTT is an upcoming feature in TLS 1.3. It's pretty gory, and amounts to doing what DNSCrypt does now, only doesn't exist or is implemented yet. Furthermore, TLS 1.3 opens connections, even with early data. If what we end up with is doing the same crypto operations as DNSCrypt, but with the extra complexity of managing connections (opening, closing, resuming, etc), what is the advantage? > >> Now, maybe it's enough to get almost >> all the ISPs and browser vendors on board. But unless you are a >> browser vendor, or a DNS cache appliance vendor, you don't know what >> the actual constraints on latency and state are. >> >> We know that approaches similar to DNSCrypt don't have these problems. >> That they haven't been written up is regrettable, but we should be >> sure that before committing to a solution, we make sure that either >> solves the problem, or if it doesn't, that we come back and go for one >> that does. What we shouldn't do is ignore issues we've been told about >> because "we solved the problem! (TM)". > > -d > -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
