[rssac-caucus] Opening RSSAC-002 for revision [AXFR]

[John Heidemann]

On Tue, 20 Oct 2015 18:18:54 -0000, P Vixie wrote: 
>"To my reading that very much looks like an expectation of consistent
>results across all operators."
>
>Yes.
>
>On October 20, 2015 11:08:11 AM PDT, Ray Bellis <ray at isc.org> wrote:
>
>    On 20/10/2015 17:58, Romeo Zwart wrote:
>    
>         Please keep in mind that for this particular metric 'consistent results
>         across all operators' are not necessarily to be expected. As RSSAC-002
>         itself also explains, the goal of providing this metric was "to detect
>         any trends in the growth of the zone". Of course serious issues like
>         truncated zone files are a different thing altogether, but size
>         differences related to compression differences could occur.
>    
>    In between the text Duane quoted, and what you've quoted above, RSSAC002
>    says:
>    
>    "The size of the compiled root zone is not expected to change from
>    operator to operator; but in an effort to ensure consistency in the root
>    system all operators should report the size of the root zone so if there
>    are any differe!
>     nces
>    that are seen on the platform they can be identified
>    and remedied."
>    
>    To my reading that very much looks like an expectation of consistent
>    results across all operators.
>    
>    To be fair, if everyone _emulated_ an AXFR using the given parameters,
>    that's what you'd get, but if you perform a real AXFR and measure the
>    results, you probably won't.
>    
>    FWIW, I endorse the later suggestion that the measurement should be made
>    on the *uncompressed* zone post AXFR.

To pick up at the end of this thread,
what I'm hearing is:

current goal A: "ensure consistency in the root system all operators
    should report the size of the root zone so if there are any
    differences that are seen on the platform they can be identified and
    remedied."

current method A: report zone transfer size.

But the problem Duane reported at the start of this thread is: transfer
size is unclearly specified, so it's not consistent across letters.

Various people have proposed tightening the definition, the limit of
which is:

proposed method B: basically do exactly what bind8 does, and anything
else is a bug.

That path WILL succeed in getting consistency across letters.


I have nothing against bind8, 
but I think we've failed to accomplish the actual goal, because:
"same size" != "no differences in contents".
Given known attacks on md5 and threats on sha1, even some cryptographic
hashes don't prove consistency.

There seems little benefit (and non-zero cost!) to going to great
lengths to get an perfect number, when it won't actually answer the
question (!).  I suggest we need to align our technical methods with the
question we're asking.  Perhaps either:

new goal C: each root should detect changes in its trend of size.

new method C: each letter should report zone transfer size consistently
across its reporting (but not necessarily across other letters)

OR

old goal D: Each letter should guarantee consistency of the zone
contents against the master copy.

new method D: some cryptographic checksum on a precisely specified input
that produces a result that actually proves goal D.


But let's not incrementally create something that splits the difference,
lest we build the worlds most carefully engineered, Stradivarius-esque
ukulele.


   -John Heidemann