> On 16 May 2023, at 15:16, Steve Atkins <st...@wordtothewise.com> wrote: > > > >> On 16 May 2023, at 15:00, Jan Dušátko <jan=40dusatko....@dmarc.ietf.org> >> wrote: >> >> Hi, >> I would like to ask how you feel about the possibility of changing the >> conditions for DKIM keys stored in DNS. Best in some future RFC release >> about DKIM itself. I have a practical experience during review and cleaning >> of thousands of domain, which is exhausting. And discussion about that keys >> also with 3rd party is sometimes hard. In situation that you would like to >> discuss that, I can provide kind of examples.
(hit send too soon). The historical reason for v=DKIM1 not being mandatory, AIUI, is backwards compatibility with DomainKeys keys. There are still people out there signing with DomainKeys, and there are still people using DomainKeys public keys to sign with DKIM. While it would be nice for it to be used the only way to require it would be to make any mail signed with a public key without v=DKIM1 fail it’s DKIM signature. That would cause a lot of legitimate, signed mail to suddenly be unsigned, and that’s not going to happen. You can mechanically recognize TXT records as potentially valid DKIM keys, even if they’re not published under the _domainkey zone, by looking for a p= field that is either empty or contains a base64 encoded value that’s a valid rsa key (or other type as defined by the k= field). If it has that then it’s usable as a DKIM or DomainKeys key. Cheers, Steve >> 1) At this moment, the use of the tag "v=DKIM1;" is only RECOMMENDED and if >> this tag is used, it must be the first. Unlike, for example, SPF and DMARC, >> this is not a REQUIRED (MANDATORY) record. In case of an attempt to identify >> DKIM records, then there is a situation where it is not possible to >> determine which records are DKIM keys. Often, these keys are in other places >> where they allow to create CNAME to the expected location of the selector. >> These locations may be application dependent or may be with third parties >> configuration. From my perspective, MANDATORY record "v=DKIM1;" could help >> to identify DKIM keys much easily. > > A DKIM key will only ever be found in DNS under a name of the form > <selector>._domainkey.<something_else>. If you find a TXT record under a name > like that it’s either a valid domain key record, or it’s invalid. No other > sort of TXT > record will live there. See section 3.6.2.1 of RFC 6376. > > If you publish wildcard TXT records then you may end up inadvertently > publishing other TXT records underneath the _domainkey record. Don’t do that. > >> 2) Is it possible to specify precisely under which conditions the DKIM key >> is valid? Some third party records contain only an empty record "", others >> contain only revoked key like "p=" or it is a reference to a non-existent >> record. Unfortunately, RFCs do not provide unambiguous information on under >> which conditions this record is invalid. From my perspective, use of >> non-existing records or empty strings can draw that key useless, but rules >> specifying that in RFC or BCP will be welcome. > > It must be a TXT record that lives under the hostname I described above, and > it must contain a (possibly empty) p= field. An empty TXT record is not a > valid DKIM public key. > > It’s - obviously - possible to create a TXT record of that form that’s > unusable. A DKIM validator will return a not signed result in that case. > >> 3) The "p=key" information containing the key material information encoded >> by Base64 should occur in the key exactly once. I did not find a condition >> in RFC for the existence of this record. > > Section 3.2 of RFC 6376 says “ Tags with duplicate names MUST NOT occur > within a single tag-list; if a tag name does occur more than once, the entire > tag-list is invalid.” > > Section 3.6.1 of RFC 6376 describes the p= value as REQUIRED. > > So there must be exactly one p= in a valid DKIM public key (in text format, > as would be published via DNS, anyway). > >> I found only information on implementation behavior, when "p=", i.e. an >> empty key material, is considered revoked. However, it is not unambiguous >> whether this approach is acceptable. Also specification of that rules can >> make my life much easier. > > Cheers, > Steve > _______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
