On 26-Apr-2015 08:41 pm, Watson Ladd <[email protected]> wrote: > > On Sun, Apr 26, 2015 at 8:33 PM, 🔓Dan Wing <[email protected]> wrote: >> >> On 26-Apr-2015 08:27 pm, Watson Ladd <[email protected]> wrote: >>> >>> On Fri, Apr 24, 2015 at 9:21 AM, 🔓Dan Wing <[email protected]> wrote: >>>> >>>> On 23-Apr-2015 06:37 pm, Phillip Hallam-Baker <[email protected]> wrote: >>>> >>>> >>>> >>>> On Thu, Apr 23, 2015 at 8:57 PM, Watson Ladd <[email protected]> wrote: >>>>> >>>>> >>>>> On Apr 23, 2015 1:52 PM, "Phillip Hallam-Baker" <[email protected]> >>>>> wrote: >>>>>> >>>>> >>>>>> On Thu, Apr 23, 2015 at 4:21 PM, <emoji_u1f513.png>Dan Wing >>>>>> <[email protected]> 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?
TLS has an engaged community. The TLS protocol and its implementations have been attacked and improved through the years -- "better the devil you know." -d >> >>> 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 [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
