Florian Weimer wrote:
> And you better randomize some bits covered by RRSIGs on DS RRsets.
> Directly signing data supplied by non-trusted source is quite risky.
> (It turns out that the current signing schemes have not been designed
> for this type of application, but the general crypto community
Florian Weimer writes:
> * Perry E. Metzger:
>
>> Actually, there are routine attacks on DNS infrastructure these days,
>> but clearly they're not cryptographic since that's not
>> deployed. However, a large part of the point of having DNSSEC is that we
>> can then trust the DNS to be accurate so
* John Gilmore:
> So the standard got sent back to the beginning and redone to deal with
> the complications of deployed servers and records with varying algorithm
> availability (and to make DSA the "officially mandatory" algorithm).
> Which took another 5 or 10 years.
And it's still not clear t
* Victor Duchovni:
> The optimization is for DDoS conditions, especially amplification via
> forged source IP DNS requests for ". IN NS?". The request is tiny,
> and the response is multiple KB with DNSSEC.
There's only one required signature in a ". IN NS" response, so it
isn't as large as you su
* Jack Lloyd:
> On Sat, Oct 17, 2009 at 02:23:25AM -0700, John Gilmore wrote:
>
>> DSA was (designed to be) full of covert channels.
>
> True, but TCP and UDP are also full of covert channels.
And you better randomize some bits covered by RRSIGs on DS RRsets.
Directly signing data supplied by non
* Perry E. Metzger:
> Actually, there are routine attacks on DNS infrastructure these days,
> but clearly they're not cryptographic since that's not
> deployed. However, a large part of the point of having DNSSEC is that we
> can then trust the DNS to be accurate so we can insert things like
> cry
