Subject: Re: [DNSOP] [Ext] review: draft-wessels-dns-zone-digest-04.txt

From: Brian Dickson <[email-masked]>
Date: Thu, 1 Nov 2018 11:49:27 -0700

Joe wrote:

> On Nov 1, 2018, at 16:27, Paul Hoffman <paul.hoffman at icann.org> wrote:
> > The current ZONEMD draft fully supports algorithm agility. What it
> doesn't support is multiple hashes *within a single message*. Having seen
> how easy it is to screw up OpenPGP and S/MIME message processing to handle
> multiple hashes, I think having one hash per zone is much more likely to
> work.
> Suppose everybody supports digest algorithm A (e.g. it's the digest type
> that was mandatory to implement in the original specification). We use that
> in our ZONEMD RR because we have high confidence that clients will support
> it.
> At some later time digest algorithm B emerges which has some advantages
> over algorithm A. B is newer and not all software supports it. We would
> like to use B because its advantages are attractive to us, but we also want
> all of our clients to be able to use the ZONEMD RRs we publish.
> Since B is new we have lower confidence that it is supported by our
> current clients.
> We cannot use both A and B simultaneously on the publication side, since
> the specification requires us to choose just one.
> There is no signalling mechanism that will give us insight into our client
> population's support of algorithm B, even if we have non-empirical
> expectations that support will increase over time.
> Since we don't want to break things, we cannot use B.
> Joe

So, giving this some tiny bit of thought:
When is zonemd added to a response, is that when doing an AXFR?
Maybe signaling the algorithm(s) for which signature(s) are
desired/understood would do the trick?
I.e. in an EDNS option?

Do it as a list of signature combos, as an ordered list. Go through the
list, and return the answer for the first entry whose requirements are met.

E.g. I understand A and B, but can only handle a single signature. I want
to receive B if it is available, with fallback to A if it is not available.
I specify "B", "A".
E.g. I understand A and B, and want both and will accept either. I specify
"A AND B", "B", "A".
E.g. I understand A, B, and C. I can handle multiple signatures. I want C
if it is available, or both A and B if C is not available but A and B are,
and if not, any of A or B. I specify "C", "A AND B", "B", "A".

This has the side-effect of providing information about known signature
types, at least those I'm willing to advertise. (E.g. I understand the
programming language COBOL, but I won't advertise that fact on my resume.)

Brian

---

From: Joe Abley <[email-masked]>
Date: Thu, 1 Nov 2018 14:52:03 -0400

> When is zonemd added to a response, is that when doing an AXFR?

Construction of ZONEMD RRs and responding to AXFR are orthogonal.

> Maybe signaling the algorithm(s) for which signature(s) are desired/understood would do the trick?
> I.e. in an EDNS option?

I don't think so. EDNS options relate to servers exchanging DNS messages. ZONEMD relates to zones.

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 1 Nov 2018 18:53:09 +0000

> When is zonemd added to a response, is that when doing an AXFR?

Maybe, or maybe when the zone is signed, or maybe when ... It's not clear that we should be telling zone operators when they have to add this if we want as many of them to use it.

--Paul Hoffman

---

From: Brian Dickson <[email-masked]>
Date: Thu, 1 Nov 2018 12:06:49 -0700

> Construction of ZONEMD RRs and responding to AXFR are orthogonal.
Right, I just realized that... I was thinking of generation of all ZONEMD
RRs, but only returning a subset.
However, since ZONEMD RRs are DNSSEC-signed, the signature process requires
all the RRs to be included in the signature for the signature to validate.

Which means you always have to provide all of the ZONEMD records, if the
ZONEMD records are signed with the current DNSSEC method.

> I don't think so. EDNS options relate to servers exchanging DNS messages.

Hmmm... so at best it would be a one-way signal from the client to the
server, about what they support (and optionally prefer).
The server has to send all the ZONEMD records regardless.

Brian

---

From: Joe Abley <[email-masked]>
Date: Thu, 1 Nov 2018 15:09:10 -0400

On 1 Nov 2018, at 15:06, Brian Dickson <[email-masked]> wrote:

> Hmmm... so at best it would be a one-way signal from the client to the server, about what they support (and optionally prefer).

There aren't necessarily any clients or servers, DNS or otherwise. A zone could be produced and consumed in some other way.

Joe

---

From: Brian Dickson <[email-masked]>
Date: Thu, 1 Nov 2018 15:30:26 -0700

On Thu, Nov 1, 2018 at 12:09 PM Joe Abley <[email-masked]> wrote:

> There aren't necessarily any clients or servers, DNS or otherwise. A zone
> could be produced and consumed in some other way.
>
>
If it is still useful/interesting to measure algorithm support, it probably
makes sense to use methods that do that via the available mechanisms on
each of the "other way"s.

E.g. Pass similar parameters on algorithm support to http/https via the
'?VAR=VAL' component of a URI
This could possibly include:

   - Whether the client assumes all risk regarding algorithm support and
   provides no algorithm info?
   - If there is zero-overlap on algorithm support between client and
   published contents:
      - Does the client prefer HTTPS over HTTP if it is available? (Yes, it
      is safer, but some clients might not care, or even want https)
      - Does the client insist on HTTPS for transport instead? If the
      server does not do https, return 4xx in that case
      - Does the client allow HTTP transport as fall-back?
   - Whether the client does DNSSEC validation (if not, return only the
   unsigned stuff)
      - (Include the logic for HTTPS vs HTTP in the zero-overlap case)

For protocols that don't have the parameter passing capability of http's
'?', maybe implement using a suitable forest of symlinks.
(E.g. ftp://example.com/do/alg-abc/zone_with_md.txt ->
do/alg-ab/zone_with_md_ab.txt, or
ftp://example.com/no-do/alg-ab/zone_unsigned.txt ->
no-do/alg-a/zone_unsigned.txt, or .../do/alg-a/zone_with_md.txt ->
alg-a-not-supported.txt)

Basically, provide info to both the consumer and producer, about the state
of things.

Brian