On Thu, Nov 1, 2018 at 12:09 PM Joe Abley <[email protected]> wrote:
> On 1 Nov 2018, at 15:06, Brian Dickson <[email protected]> > wrote: > > > 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. >> > > 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. > > > 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
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
