On 22-Apr-2015 07:25 pm, Phillip Hallam-Baker <i...@hallambaker.com> wrote: > > > On Wed, Apr 22, 2015 at 6:24 PM, Ted Hardie <ted.i...@gmail.com > <mailto:ted.i...@gmail.com>> wrote: > On Wed, Apr 22, 2015 at 10:15 AM, <emoji_u1f513.png>Dan Wing <dw...@cisco.com > <mailto:dw...@cisco.com>> wrote: > During the DPRIVE meeting in Dallas, several questions came up about UDP > versus TCP. We had previously submitted a "DNS over DTLS" document which > predated DPRIVE. We re-submitted the document with a few edits and a > filename that makes it easier to find, > https://tools.ietf.org/html/draft-wing-dprive-dnsodtls > <https://tools.ietf.org/html/draft-wing-dprive-dnsodtls>, diffs at > https://tools.ietf.org/rfcdiff?url1=draft-wing-dnsop-dnsodtls-01&url2=draft-wing-dprive-dnsodtls-00 > > <https://tools.ietf.org/rfcdiff?url1=draft-wing-dnsop-dnsodtls-01&url2=draft-wing-dprive-dnsodtls-00> > > The working group may want to consider the advantages of DNS over DTLS over > UDP compared to using TCP: > > * No reliance on operating system support of TCP Fast Open [RFC7413] to > achieve same number of round trips. > * Avoidance of TCP's network head of line blocking. > > > ​Just to confirm my understanding, with DTLS plus anycast, you'd have similar > issues for restart as TCP (state being associated with a single endpoint, > timeout required for flushing state). Is that your thinking as well?​ > > regards, > > Ted > > 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 <https://tools.ietf.org/html/rfc5077> solves that problem. It works with TLS and with DTLS. > There are TLS features that may be sufficient but I worry about the number of > framing bytes. The DTLS 1.2 record format has 13 bytes of framing, https://tools.ietf.org/html/rfc6347#page-26 <https://tools.ietf.org/html/rfc6347#page-26>. Content Type is 8 bits and version is 16 bits. struct { ContentType type; ProtocolVersion version; uint16 epoch; // New field uint48 sequence_number; // New field uint16 length; select (CipherSpec.cipher_type) { case block: GenericBlockCipher; case aead: GenericAEADCipher; // New field } fragment; } DTLSCiphertext; TLS 1.2 has 5 bytes of framing (because it doesn't have the epoch and sequence_number). -d
_______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
