Re: [Ietf-dkim] DKIM issues (tag "v=DKIM1", tag "p=")

[Dave Crocker]

On 6/12/2023 12:33 PM, Barry Leiba wrote:

DomainKeys was already made Historic when RFC 4870 was published in
2007.  Look at the RFC status.


Indeed.  Upper right corner of the page: rfc4870 



It is relatively common to have a working specification come from the 
community, as input to an IETF standards effort, and to publish the 
community specification as a companion document, usually as Informational.


Marking one as Historic is, I think, relatively unusual.  As I recall, 
in this case, it was an explicit decision, as an informal encouragement 
to have existing users of Domainkeys move to using the (then) 
newly-minted DKIM.


d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM issues (tag "v=DKIM1", tag "p=")

[Barry Leiba]

DomainKeys was already made Historic when RFC 4870 was published in
2007.  Look at the RFC status.

Barry

On Mon, Jun 12, 2023 at 1:18 PM Jan Dušátko
 wrote:
>
> Murray, Dave
>
> I would like to ask another question about the following.
> - DomainKey (RFC 4870) only allows signatures to be used with RSA-SHA1
> algorithm, which is now considered obsolete. I have not found support
> for other algorithms.
> - At the moment I am trying to monitor the frequency of signature
> occurrence with DomainKey and so far I have not found any occurrence. I
> would like to continue monitoring for about 3 months.
> - Given DomainKey's replacement with DKIM, the question is whether it
> would not be appropriate to declare DomainKey historic and no longer use
> it.
> In that case, there couldn't be problem to allow decomissioning of
> DomainKey.
>
> Regards
>
> Jan
>
> Dne 16. 5. 2023 v 18:00 Dave Crocker napsal(a):
> > On 5/16/2023 8:52 AM, Murray S. Kucherawy wrote:
> >> Also, a change to make this REQUIRED would take forever for the world
> >> to adapt.
> > As noted, if it's a TXT record and it is in a DKIM DNS naming path, it
> > better be a DKIM record.
> >
> > Also, versions numbers are pretty much useless.  So leaving it out
> > does little damage.
> >
> > If a version change marks addition of some features, then the presence
> > of the features' markings are self-indicating.
> >
> > If a version change marks a change to the basic standard -- ie, a
> > change that is incompatible with the previous version -- then it is
> > not a version change.  It is creation of a new protocol.
> >
> > c/
> >
>
> --
> -- --- - -
> Jan Dušátko
>
> Tracker number: +420 602 427 840
> e-mail: j...@dusatko.org
> GPG Signature:  https://keys.dusatko.org/E535B585.asc
> GPG Encrypt:https://keys.dusatko.org/B76A1587.asc
>
> ___
> Ietf-dkim mailing list
> Ietf-dkim@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-dkim

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM issues (tag "v=DKIM1", tag "p=")

[Jan Dušátko]

Murray, Dave

I would like to ask another question about the following.
- DomainKey (RFC 4870) only allows signatures to be used with RSA-SHA1 
algorithm, which is now considered obsolete. I have not found support 
for other algorithms.
- At the moment I am trying to monitor the frequency of signature 
occurrence with DomainKey and so far I have not found any occurrence. I 
would like to continue monitoring for about 3 months.
- Given DomainKey's replacement with DKIM, the question is whether it 
would not be appropriate to declare DomainKey historic and no longer use 
it.
In that case, there couldn't be problem to allow decomissioning of 
DomainKey.


Regards

Jan

Dne 16. 5. 2023 v 18:00 Dave Crocker napsal(a):

On 5/16/2023 8:52 AM, Murray S. Kucherawy wrote:
Also, a change to make this REQUIRED would take forever for the world 
to adapt.
As noted, if it's a TXT record and it is in a DKIM DNS naming path, it 
better be a DKIM record.


Also, versions numbers are pretty much useless.  So leaving it out 
does little damage.


If a version change marks addition of some features, then the presence 
of the features' markings are self-indicating.


If a version change marks a change to the basic standard -- ie, a 
change that is incompatible with the previous version -- then it is 
not a version change.  It is creation of a new protocol.


c/



--
-- --- - -
Jan Dušátko

Tracker number: +420 602 427 840
e-mail: j...@dusatko.org
GPG Signature:  https://keys.dusatko.org/E535B585.asc
GPG Encrypt:https://keys.dusatko.org/B76A1587.asc

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM issues (tag "v=DKIM1", tag "p=")

[Jan Dušátko]

Hi
thank you for answers. Seems that I overlooked some details inside RFCs 
and my idea are not needed as I think


Murray S. Kucherawy wrote:
> if it's a TXT record and it is in a DKIM DNS naming path, it better 
be a DKIM record.
You are right. I trying to do strict syntax check, but I also looking 
for arguments, which let me to remove invalid keys.


Dne 16. 5. 2023 v 17:52 Murray S. Kucherawy napsal(a):

On Tue, May 16, 2023 at 7:00 AM Jan Dušátko  wrote:


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.


I don't get the impression that identifying a record that contains a valid
DKIM key record is hard.  The ABNF is pretty clear.  It's certainly easier
to say "does this start v=DKIM1;?" than it is to run a full parser on it,
but I imagine if you try to stuff a random string through a DKIM key
parser, it'll know pretty quickly most of the time that the record isn't
valid given the second character pretty much has to be "=" which is going
to trim a lot of cruft right away.

Also, a change to make this REQUIRED would take forever for the world to
adapt.  There's a great deal of inertia out there, and the benefit of such
a change isn't going to be obvious to the broader community, so you're
going to find records in the current format for years to come, and
implementations would justifiably accept the old format for some long
transition period.
I understand and accept this approach, but I would like to make a few 
comments based on the timeline. Domainkey was standardized in 2007, in 
the same year it was replaced by DKIM. This standard was replaced in 
2011 by a newer one, which continues to expand. In my opinion, for the 
sake of interoperability, it is also necessary to address the gradual 
transition to more complex technologies, as well as to prepare these 
technologies for possible replacement. In my opinion, this is the 
purpose of header records. Then the question is, is 16 years enough 
time, given the age of email 50 years? Currently, technologies like DKIM 
are used to protect the domain (brand) from misuse, and the importance 
of these technologies will continue to grow.


Dave Crocker wrote:

If a version change marks a change to the basic standard -- ie, a change 
that is incompatible with the previous version -- then it is not a 
version change.  It is creation of a new protocol.


I understand. I did not take proper care about former DomainKey, which can make 
everything worse. Simple backward compatibility and I forget it.


Are you talking about DKIM records out in the general Internet, or only
within domains you control?
I talking about domains under my control. But part of records has been 
provided by 3rd party, I would like to enforce strict compliance with 
current RFCs (SPF, DKIM, DMARC ...)



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.


I disagree that this is ambiguous.  An empty string isn't a valid DKIM key
record.  An empty "p=" value is a valid DKIM key record indicating "there
was a key here, but it's been revoked".


Steve Aktins wrote:


Section 3.6.1 of RFC 6376 describes the p= value as REQUIRED.


I overlooked that before, which make negotiation about compliance harder.


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. 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.


I also disagree that this is ambiguous.  The RFC is pretty clear about what
an empty "p=" means.

-MSK


Regards

Jan

--
-- --- - -
Jan Dušátko

Tracker number: +420 602 427 840
e-mail: j...@dusatko.org
GPG Signature:  https://keys.dusatko.org/E535B585.asc
GPG Encrypt:https://keys.dusatko.org/B76A1587.asc

Re: [Ietf-dkim] DKIM issues (tag "v=DKIM1", tag "p=")

[Dave Crocker]

On 5/16/2023 8:52 AM, Murray S. Kucherawy wrote:
Also, a change to make this REQUIRED would take forever for the world 
to adapt.
As noted, if it's a TXT record and it is in a DKIM DNS naming path, it 
better be a DKIM record.


Also, versions numbers are pretty much useless.  So leaving it out does 
little damage.


If a version change marks addition of some features, then the presence 
of the features' markings are self-indicating.


If a version change marks a change to the basic standard -- ie, a change 
that is incompatible with the previous version -- then it is not a 
version change.  It is creation of a new protocol.


c/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM issues (tag "v=DKIM1", tag "p=")

[Murray S. Kucherawy]

On Tue, May 16, 2023 at 7:00 AM Jan Dušátko  wrote:

> 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.
>

I don't get the impression that identifying a record that contains a valid
DKIM key record is hard.  The ABNF is pretty clear.  It's certainly easier
to say "does this start v=DKIM1;?" than it is to run a full parser on it,
but I imagine if you try to stuff a random string through a DKIM key
parser, it'll know pretty quickly most of the time that the record isn't
valid given the second character pretty much has to be "=" which is going
to trim a lot of cruft right away.

Also, a change to make this REQUIRED would take forever for the world to
adapt.  There's a great deal of inertia out there, and the benefit of such
a change isn't going to be obvious to the broader community, so you're
going to find records in the current format for years to come, and
implementations would justifiably accept the old format for some long
transition period.

Are you talking about DKIM records out in the general Internet, or only
within domains you control?


> 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.
>

I disagree that this is ambiguous.  An empty string isn't a valid DKIM key
record.  An empty "p=" value is a valid DKIM key record indicating "there
was a key here, but it's been revoked".


> 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. 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.
>

I also disagree that this is ambiguous.  The RFC is pretty clear about what
an empty "p=" means.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM issues (tag "v=DKIM1", tag "p=")

[Steve Atkins]

> On 16 May 2023, at 15:16, Steve Atkins  wrote:
> 
> 
> 
>> On 16 May 2023, at 15:00, Jan Dušátko  
>> 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 
> ._domainkey.. 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

Re: [Ietf-dkim] DKIM issues (tag "v=DKIM1", tag "p=")

[Steve Atkins]

> On 16 May 2023, at 15:00, Jan Dušátko  
> 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.
> 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 
._domainkey.. 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