<html><head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
</head><body bgcolor="#FFFFFF" text="#000000"><br>
<br>
<blockquote style="border: 0px none;"
cite="mid:A813FF54-2313-49AE-840C-02331232C639@vpnc.org" type="cite">
<div style="margin:30px 25px 10px 25px;" class="__pbConvHr"><div
style="display:table;width:100%;border-top:1px solid
#EDEEF0;padding-top:5px"> <div
style="display:table-cell;vertical-align:middle;padding-right:6px;"><img
photoaddress="paul.hoffman@vpnc.org" photoname="Paul Hoffman"
src="cid:part1.04070701.03040609@redbarn.org"
name="compose-unknown-contact.jpg" height="25px" width="25px"></div> <div
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
<a moz-do-not-send="true" href="mailto:paul.hoffman@vpnc.org"
style="color:#737F92
!important;padding-right:6px;font-weight:bold;text-decoration:none
!important;">Paul Hoffman</a></div> <div
style="display:table-cell;white-space:nowrap;vertical-align:middle;">
<font color="#9FA2A5"><span style="padding-left:6px">Monday, December
01, 2014 7:42 PM</span></font></div></div></div>
<div style="color: rgb(136, 136, 136); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody"><pre wrap="">On Dec 1, 2014, at 5:29 PM, Paul Vixie <a class="moz-txt-link-rfc2396E" href="mailto:paul@redbarn.org"><paul@redbarn.org></a> wrote:
</pre><br>
<blockquote type="cite">
<pre wrap="">... the verification tool would be new logic, either built into the secondary name server, or as an outboard tool available to the transfer mechanism.
</pre>
</blockquote><pre wrap=""><!---->
Others on this list have asked for a third use case, namely zone files sitting on disk.</pre></div>
</blockquote>
there's a program called "dnssec-verify" inside BIND9, and no doubt
similar programs inside LDNS, OpenDNSSEC, and PowerDNSSEC, that handles
zone files sitting on disk.<br>
<br>
(note, i'm in an almost pure SSD world at this point, i need to stop
saying "disk" soon.)<br>
<br>
<blockquote style="border: 0px none;"
cite="mid:A813FF54-2313-49AE-840C-02331232C639@vpnc.org" type="cite">
<div style="color: rgb(136, 136, 136); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody"><blockquote
type="cite"><pre wrap="">when i compare the complexity-cost of that tool to the contents of the <a class="moz-txt-link-rfc2396E" href="ftp://ftp.internic.net/domain"><ftp://ftp.internic.net/domain></a> directory, i see that existing tools whose complexity-cost i already pay would work just fine. (those being pgp and md5sum). so, a detached signature can in some cases meet (2) far more easily than an in-band signature.
</pre></blockquote><pre wrap=""><!---->
Your proposal skips over the "how do I trust this signing key" part. You might want to force everyone else to do the work you have done to get to that trust; others might want a simpler solution.</pre></div>
</blockquote>
<br>
a detached signature would be validated using out-of-band methods. for
example you might fetch the .MD5 file using some other method or
fetch-source, and for PGP there are key servers and so forth.<span
style="font-family: monospace;"><br>
<br>
but i'm not recommending detached signatures per se. DNSSEC is the way
to go.<br>
<br>
</span>
<blockquote style="border: 0px none;"
cite="mid:A813FF54-2313-49AE-840C-02331232C639@vpnc.org" type="cite">
<div style="color: rgb(136, 136, 136); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
<blockquote type="cite"><pre wrap="">in either case, to frustrate the MiTM, the proposed in-band signature would have to be DNSSEC based.
</pre></blockquote><pre wrap=""><!---->
No offense, but you're making no sense. Above, you give a counter-example to that assertion.</pre></div>
</blockquote>
<br>
no offense taken. you suggested a DNSSEC-based signing key, i was trying
(and failing) to agree with you.<br>
<blockquote style="border: 0px none;"
cite="mid:A813FF54-2313-49AE-840C-02331232C639@vpnc.org" type="cite">
<div style="color: rgb(136, 136, 136); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
<pre wrap="">
</pre>
<blockquote type="cite"><pre wrap="">and there is already an in-band DNSSEC-based zone identity/coherency test -- zone walking. why would we add another way to do the same thing we could do with existing DNSSEC data?
</pre></blockquote><pre wrap=""><!---->
Maybe I'm just being dense, but I'm not seeing how zone walking validates the contents of the glue records.</pre></div>
</blockquote>
<br>
i apologize for not saying so explicitly: nothing can directly validate
the contents of the glue records. two indirect methods exist, which are
(1) looking it up in a validating RDNS and seeing if the content of the
glue record you got with your zone is the same as the one signed by
DNSSEC, in a provisional validation environment that asks "what if this
glue is correct?", and (2) using the glue and noting whether the zones
reached by that NS+glue are signed with a key matching that zone's
signed DS RR. if they are signed with the right key then it doesn't
matter whether the address glue was correct or not.<br>
<br>
but you raise a very interesting issue, which is that the definition of
"zone" does not include address glue. if the per-zonefile or per-axfr
signature that you'd like to bind to the zone has to cover its glue,
then we have a very interesting set of new problems, like does this mean
all address glue or only necessary address glue (under our leaf
delegations), does it include both A and AAAA RR's, which one is hashed
first, and so on. all those rules would have to be spelled out in any
signature that was made over "all the stuff you get in an AXFR, or that
you might find in a zone file sitting on disk" rather than made over
"the zone".<br>
<br>
since NS RR's aren't signed in the parent, a zone-walk won't verify
them, and perhaps that's your most compelling argument for some new
signature which does cover those, since any unsigned child could be
spoofed if the zone file (or AXFR contents) were tampered with.
<blockquote style="border: 0px none;"
cite="mid:A813FF54-2313-49AE-840C-02331232C639@vpnc.org" type="cite">
<div style="color:#888888;margin-left:24px;margin-right:24px;"
__pbrmquotes="true" class="__pbConvBody"><blockquote type="cite"><pre wrap="">i think walking the existing zone and verifying that there are no records between the nsecs and that every signature is valid and that the nsec chain ends at the apex, is simpler.
</pre></blockquote><pre wrap=""><!---->
It is. Unless I'm missing something, it is also incomplete.
(And, of course, doesn't work for zones that use NSEC3...)
</pre></div>
</blockquote>
i don't think the root zone will ever use NSEC3. but for the sake of
unsigned delegations from the root zone, and other zones besides the
root zone that might want a similar kind of verification, i'll bite: is
there a stream cipher that will remain both correct and secure when the
zone is incrementally updated with IXFR and UPDATE deltas? because if
the cost of an IXFR or UPDATE is that the whole zone has to be
re-hashed, then this mechanism will be impractical for any zone which is
either larger than the root zone is today or modified more frequently
than the root zone is today.<br>
<br>
i'm imagining a stream cipher that begins as the H(K,zone) and then is
updated to be H(K,H_old,delta) for each change to the zone, which would
have to be calculated by the responder in the case of UPDATE, but could
then be issued as a succession of new "zone signature" RR's during IXFR.
the "zone signature" RR would have to be like SOA,
there-can-be-only-one, so what might look like a "set" of them in an
IXFR, is really a bunch of changes to the one-and-only. canonicalizing
each delta, and whether or not to include and/or canonicalize address
glue, are other questions yet outstanding.<br>
<br>
marka, is this what you were trying to express a couple of days ago?<br>
<br>
<div class="moz-signature">-- <br>Paul Vixie<br>
</div>
</body></html>