On 2013-09-05, at 4:25 PM, Florian Weimer wrote:
> Exploiting this vulnerability successfully over the Internet against
> resolvers processing real-world traffic still seems difficult to me,
> at least if the resolver uses the Linux TCP/IP stack. This is not
> completely idle speculation because
On 2013-09-05, at 10:02 PM, Haya Shulman wrote:
> I would recommend short term patched (that we recommend in the paper) in the
> meanwhile, and addressing the deployment challenges of DNSSEC.
Some comments on these recommendations. Based on the caveats documented by
Google, I'm not sure the r
On 2013-09-06, at 1:42 PM, Robert Edmonds wrote:
> Aaron Campbell wrote:
>> Here is a thought, but I will defer to the protocol experts on plausibility.
>> The resolver knows the size of each DNS message it parses. What if it
>> didn't trust glue records contained
On 2013-09-06, at 3:44 PM, Haya Shulman wrote:
> We studied the IPID randomisation on the name servers (not the resolvers).
> Only the name server side IPID randomisation is relevant to the attack, since
> it is the response from the name server that the attacker attempts to alter
> (by crafti
On 2013-09-07, at 4:11 PM, Paul Wouters wrote:
>>> this sounds vaguely similar to unbound's "harden-referral-path" option,
>>> though it applies to all lookups.
>>
>> I researched this, and found that it was first described here:
>>
>> http://tools.ietf.org/html/draft-wijngaards-dnsext-resolver
On 2013-09-11, at 2:30 AM, Paul Vixie wrote:
> "A DNS UDP responder shall, when transmitting a message which does not
> include embedded cryptographic marks such as TSIG or DNSSEC signatures, use
> an effective DNS message payload size which is calculated as MIN(OFFERED,
> MIN(DISCOVERED, ESTI
On 2013-09-11, at 11:50 PM, Paul Vixie wrote:
>>> "A DNS UDP responder shall, when transmitting a message which does not
>>> include embedded cryptographic marks such as TSIG or DNSSEC signatures, use
>>> an effective DNS message payload size which is calculated as MIN(OFFERED,
>>> MIN(DISCOVE
