<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Feb 28, 2021 at 12:37 PM Viktor Dukhovni <<a href="mailto:ietf-dane@dukhovni.org">ietf-dane@dukhovni.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, Feb 28, 2021 at 08:52:38PM +0100, Vladimír Čunát wrote:<br>
<br>
> On 2/28/21 8:47 PM, Paul Hoffman wrote:<br>
> >> [1]<a href="https://tools.ietf.org/html/rfc8482#section-7" rel="noreferrer" target="_blank">https://tools.ietf.org/html/rfc8482#section-7</a>  [<a href="http://tools.ietf.org" rel="noreferrer" target="_blank">tools.ietf.org</a>]<br>
> > That RFC (a) doesn't update RFC 4025 and (b) is only about QTYPE of "ANY".<br>
> <br>
> I meant just the informal future-work note focused on QTYPE=RRSIG (in <br>
> the linked section), to support my claim that there are advantages in <br>
> avoiding full replies to such queries.<br>
<br>
Not only are "full" replies not needed, detached from the RRSet for<br>
which an RRSIG is the signature, the content of the RRSIG is both<br>
useless and meaningless.  Since it can never be validated it should not<br>
be cached.<br>
<br>
An interoperable synthetic reply when the qname exists would be:<br>
<br>
    <qname> 0 IN RRSIG RRSIG 255 <numlabels> 0 <0x0> <0x0> 0 <closest-encloser> AA==<br>
<br>
A signature payload of a single 0 byte avoids potential issues with<br>
unexpected zero-length signatures.<br>
<br>
  * It is less clear what to do when the qname is wildcard-synthesized.<br>
    Should there be NSEC records to validate a wildcard-based response???<br>
<br>
My take is "no", just always set the closest encloser to equal the<br>
qname, and let the zero TTL take care of not having such replies<br>
stick around in caches to imply anything about the node.<br>
<br>
Iterative resolvers should not cache RRSIG replies, regardless of TTL.<br>
<br>
I'm writing a new stub resolver for Haskell, and even prior to this<br>
thread my plan was to not permit RRSIG queries, because they made no<br>
sense.  I could instead just return the above synthetic response without<br>
asking any upstream server, but an error telling the user they're doing<br>
the wrong thing seems more appropriate.<br></blockquote><div><br></div><div>I think this is vaguely interesting, if for no other reason that it exposes some weaknesses in the original 403[345] RFCs.</div><div><br></div><div>Two relevant questions are: </div><div><ul><li>Are the observed RRSIG queries the result of an actual client's behavior? (The alternative being diagnostic tool usage, and I'd be surprised if it was the former.) </li><li>If a validating client is either using a security-oblivious resolver (the client might be a stub or a forwarder), or has an intermediate network device interfering with DNSSEC, is it even possible to do validation, ever?</li></ul><div>It's clear that the relevant portion(s) of 403[345] don't correctly handle the RRSIG case, and pretty much cannot (since RRSIG needs to know the original QTYPE to select/filter the RRSIG).</div></div><div><br></div><div>If (big IF) there is interest in solving for the second case (validating client behind a middle box or resolver that is not returning RRSIG records, possibly not doing EDNS, and may or may not be security-aware with respect to CD and AD bits), what then?</div><div>It might be interesting to know how much of the Internet is in those situations (validating stub or validating resolver, but unable to actually validate).</div><div><br></div><div>The follow-up question, if there is a substantial portion of the client base that is impacted, which path is more likely to occur on a timely basis:</div><div><ul><li>Removal/upgrade of resolvers or middle boxes causing these issues</li><li>Deployment of new code on resolvers and clients with ways of addressing the RRSIG issue</li></ul><div>(I don't think there is any real reason or value for auth-only servers to do anything different, or at most only add the auth piece of any new logic.)</div></div><div><br></div><div>If the latter (deployment of new code) is the path of least resistance (which would be unpleasant, obviously), the question would then be: how would a client signal to a server, that it wants RRSIG records for a specific signed RRSET/RRTYPE?</div><div><br></div><div>The assumption would probably be a worst-case scenario: no EDNS, but possibly transparent path for AD/CD bits, and possibly support for new OPCODEs. (Testing real paths might be needed for the OPCODE support.)</div><div><br></div><div>The methods I can think of are basically:</div><div><ul><li>Underscore added to QNAME, to indicate the second QTYPE (either _RRSIG.QNAME for QTYPE==thing that is signed by the RRSIG, or _QTYPE.QNAME with real QTYPE being RRSIG).</li><li>New OPCODE for RRSIG, so instead of OPCODE==0 and QTYPE==FOO, have OPCODE==RRSIG and QTYPE==FOO</li><li>The returned reply would either be just the RRSIG of the right QTYPE, or the answer of QTYPE RRSET in the Answer section, and the RRSIG(s) in the Additional section</li></ul><div>Absent the above, it is probably fair to exclude RRSIG from things that can get sensible answers, and 403[345] should be updated to clarify.</div></div><div><br></div><div>(IMHO, the extra logic might not be too bad, and would potentially be useful for advancing the deployment of validating stubs.)</div><div><br></div><div>Brian</div></div></div>