<div dir="ltr"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><br></div></div><div class="gmail_quote"><div dir="ltr">On Tue, Sep 11, 2018 at 5:38 PM Viktor Dukhovni <<a href="mailto:ietf-dane@dukhovni.org">ietf-dane@dukhovni.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> On Sep 11, 2018, at 5:26 PM, Paul Vixie <<a href="mailto:paul@redbarn.org" target="_blank">paul@redbarn.org</a>> wrote:<br>
> <br>
> I think what's interesting about this latest rendition of the fragmentation attack (first told to me by florian in 2008 or so, and independently rediscovered several times since then) is not that a proof of concept was able to get someone to make a certificate for the attacker using the victim's identity because dnssec was relied upon for transaction authenticity.<br>
> <br>
> rather, it's that dnssec cannot be relied upon, after all.<br>
<br>
I have not seen any evidence that shows that forgery of anything other<br>
than unsigned glue is possible via this attack in the presence of DNSSEC.<br></blockquote><div><br></div><div>Seems to me that we should sign the glue (and any other unsigned records) so that we can verify and trust the whole answer (and whole domains).  I know that won't be easy, but it seems like the right solution to me.</div><div><br></div><div>-- </div><div>Bob Harold</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Have you?  Of course if the CA's resolver is not validating or the<br>
victim's zone is not signed then DNSSEC can't help.  But in all<br>
other cases, only a DoS via broken glue should be possible, or<br>
someone's implementation is cutting corners.<br>
<br>
-- <br>
        Viktor.<br>
<br>
<br>
-- <br>
        Viktor.<br><br>
</blockquote></div></div>