<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jun 9, 2015 at 5:55 AM, Edward Lewis <span dir="ltr"><<a href="mailto:edward.lewis@icann.org" target="_blank">edward.lewis@icann.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>On 6/9/15, 3:12, "Kevin Chen" <<a href="mailto:kchen@mit.edu" target="_blank">kchen@mit.edu</a>> wrote:<br>
<br>
>><br>
>>which looks quite simple, however the KSK DNSKEY from <a href="http://hollington.ca" target="_blank">hollington.ca</a> is<br>
>> part of the DS set. The only notable part of the DS set is that it<br>
>> contains 4 keys, among which is an older (?) with a longer hash.<br>
><br>
>RFC 4509 says:<br>
><br>
>    Implementations MUST support the use of the SHA-256 algorithm in DS<br>
>    RRs.  Validator implementations SHOULD ignore DS RRs containing SHA-1<br>
>    digests if DS RRs with SHA-256 digests are present in the DS RRset.<br>
><br>
>I assume the various resolvers are making different choices with regard<br>
>to SHOULD.<br>
<br>
</span>Hmmm, I would have never interpreted that requirement that way.  I always<br>
had in mind "per key."</blockquote><div><br></div><div>The example in the RFC seems to present it that way as well.  That might be part of the problem (I had interpreted it--and implemented it--that way).<br></div><div><pre>   o  A zone includes multiple DS records for a given child's DNSKEY,
      each of which uses a different digest type.

   o  A validator accepts a weaker digest even if a stronger one is
      present but invalid.</pre>But when you consider a downgrade attack, the attacker only needs the lowest hanging fruit.  That means that *any* DS (regardless of DNSKEY) with the weaker digest type could potentially be used for falsifying a DNSKEY.<br><br>Casey<br></div></div></div></div>