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)? > 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 _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
