TLS seems like a poor choice for any new cryptographic transport, it is a very complicated protocol with a considerable amount of implementation complexity, computational and network costs. DTLS seems poorer still, as it is an adaptation of primitives never intended for datagram transmission.
But feedback on the draft: * It's unclear how your protocol would really mitigate an active attacker sending bogus responses. Won't the attacker still be able to disrupt the DTLS session? Allowing session multiplexing by query-id likely amplifies this risk. * In DTLS, the ClientHello is in the plain - this presents opportunities for downgrade attacks and inference making. Considering the proposal advocates for hardcoding the certificate, why not just use a key from the off? * Some nameservers definitely don't just "not respond" when they get messages they don't understand :/ * Is the entire protocol subject to the simplest downgrade attack of all? Just cause the first server response to be dropped and regular DNS will be used? * How long should session state persist? * The network costs of certificate transmission probably pale in comparison to the computational costs of key negotiation. How should trivial key-exchange ddos attacks be prevented? * TLS Heartbeat messages do not permit asymmetric MTU discovery. On Wed, Apr 23, 2014 at 6:47 AM, Dan Wing <d...@danwing.org> wrote: > For discussion. > > DNS queries and responses are visible to network elements on the path > between the DNS client and its server. These queries and responses > can contain privacy-sensitive information which is valuable to > protect. An active attacker can send bogus responses causing > misdirection of the subsequent connection. > > To counter passive listening and active attacks, this document > proposes the use of Datagram Transport Layer Security (DTLS) for DNS, > to protect against passive listeners and certain active attacks. As > DNS needs to remain fast, this proposal also discusses mechanisms to > reduce DTLS round trips and reduce DTLS handshake size. The proposed > mechanism runs over the default DNS port and can also run over an > alternate port. > > http://tools.ietf.org/html/draft-wing-dnsop-dnsodtls > > -d > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- Colm
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
