Re: [dnssd] I-D Action: draft-ietf-dnssd-srp-23.txt

Hm, good question. I think I was sufficiently under pressure when I did
that code that I may have forgotten to document why I used that value. I'll
have to revisit it. Next week. :)

On Tue, Oct 31, 2023 at 5:15 PM Alexander Clouter <alex+ietf@coremem.com>
wrote:

> Hello,
>
> On Fri, 4 Aug 2023, at 23:37, internet-drafts@ietf.org wrote:
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories. This Internet-Draft is a work item of the Extensions for
> Scalable
> > DNS Service Discovery (DNSSD) WG of the IETF.
> >
> >    Title           : Service Registration Protocol for DNS-Based Service
> Discovery
> >    Authors         : Ted Lemon
> >                      Stuart Cheshire
> >    Filename        : draft-ietf-dnssd-srp-23.txt
> >    Pages           : 40
> >    Date            : 2023-08-04
>
> I've been working on my own implementation and stumbled onto some greyness
> around the KEY RR.
>
> I have not been able to find anything definitive on what the flags should
> be set to, maybe I missed it though.
>
> Appendix C provides an example where flags=513 and if you go spelunking
> through the mdnsresponder[1] and openthread[2] sources you find they both
> use this value too.
>
> >From this you can of course go an swot up on RFC2535 section 3.1.2 to
> decode 513, and it mostly makes sense why the values are as they are, but
> as a reader I only came to this conclusion after reading another
> implementation and not from this draft.
>
> It would be helpful to include a suggestion guiding the reader as right
> now I personally am using '513' as a magic interop number instead of
> because I consciously decided it suited my needs.
>
> Maybe something along the lines of a new section just before section 6.6
> ('Required Signature Algorithm'):
> ----
> Section 6.X: Guidance on the KEY RR Flag Field
>
> RFC2535 section 3.1.2 breaks this field up in to several parts and it is
> RECOMMENDED:
>
>  * A/C: set to 0b01 (prohibit confidentiality)
>  * NAMTYP: set to 0b10 (ie. HOST/ENTITY[3])
>  * SIG: set to 0b0001 (ie. GENERAL)
>
> It is RECOMMENDED you use 16897 (0b0100001000000001) but as an SRP
> registrar you MUST accept 'A/C & 0b10 == 0'.
> ----
>
> I am proposing A/C=0b01 as I do not know enough about the DNSSEC crypto
> sausage making machine to state what should be and hoping this prompts
> someone who knows this to suggest something more appropriate.
>
> Cheers
>
> Alex
>
> [1]
> https://github.com/Abhayakara/mdnsresponder/blob/d7779d704ef6e4724d0d0fd4a11a91ff9caa4004/ServiceRegistration/srp-client.c#L1203
> [2]
> https://github.com/openthread/openthread/blob/7074a43e4577d32d5535d52e7940ed2ea7e3a528/src/core/net/srp_client.cpp#L1309
> [3] wonderfully you can only tell the difference between ENTITY and HOST
> by reading the bind9 source[4] to find out they map to the same value
> [4]
> https://github.com/isc-projects/bind9/blob/3f205f3218915e00d5a7162d7665adfef473d8ba/bin/dnssec/dnssec-keygen.c#L589
>
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd
>