Re: [Ietf-dkim] DKIM Signature
Dne 27. 10. 2023 v 23:02 John Levine napsal(a): It appears that Scott Kitterman said: On October 27, 2023 2:56:30 PM UTC, "Murray S. Kucherawy" wrote: On Sun, Oct 1, 2023 at 1:50 AM Jan Dušátko wrote: I would like to ask to consider the possibility of defining a DKIM signature using Ed448. [...] My view is that more encryption algorithms are bad for interoperability. For DKIM signing/verifying to work, senders and verifiers need a common algorithm. More choices make this more complex to achieve. We standardized ed25119 as a hedge against unknown vulnerability in RSA. ... Since we already have ed25519, why would we want ed448? If ed25519 is a ten ton steel door on our cardboard box, ed448 is a fifteen ton steel door. R's, John In my opinion, the verifiability of the place and time of origin needs to be addressed, which is one of the reasons to use DKIM: - Ed25519 has a security equivalent of 125b, a little less than the currently required security equivalent 128b (more-less the same) - Ed448, like Ed25519, is standardized both within TLS 1.3 and for digital signature thanks to NIST and ETSI - RSA should be vulnerable to Shor algorithm (one QFT) in the future - ECDSA/EDDSA should be vulnerable to modified Shor algorithm (two QFTs) in the future - PQC migration will also need to be addressed in the near future It is not a question of how many algorithms there will be, but what algorithms will be involved. In my view, RSA has a huge disadvantage with key length (DNS response size) and a lower increase in security due to the increase in key size. In contrast, both Curve25519 and Ed448 fit into one answer and have a significantly higher security equivalent. Question if makes sense to secure that cardboard box of SMTP protocol with a one-ton vault door, my answer is simply yes. Because cryptography has the ability to prove a place of origin while protecting against modification. But is it possible and feasible? Regards Jan ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
[Ietf-dkim] DKIM Signature
Hi, I would like to ask to consider the possibility of defining a DKIM signature using Ed448. The current Ed25519 has a security equivalent of 125b, Ed448 has a security equivalent of 224b, yet their total length is acceptable in terms of the DNS packet size. The load generated by the signature algorithm is higher, but it still works better in relation to the corresponding security equivalent for RSA. Moreover, an RSA algorithm with the corresponding strength will be challenging to transfer within the DNS response. - the key for Ed448 has 56B, after transcoding to Base64 then 76B - the key for Ed25519 has 32B, after transcoding to Base64 then 44B The mechanism for Ed448 is part of the definition of TLS 1.3, FIPS 186-5 as well as eIDAS and ETSI (TS 103523). Regards Jan ___ 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, 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=")
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...@dusatk
[Ietf-dkim] DKIM issues (tag "v=DKIM1", tag "p=")
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. 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. 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. 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 ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM update - header tag
Dne 13. 3. 2023 v 16:08 Murray S. Kucherawy napsal(a): On Fri, Mar 10, 2023 at 10:48 AM Jan Dušátko wrote: I got recommendation to propose changes in that mailing group. My work depend on appropriate protection of our brand, however this tasks require also management of records required for that protection. We have huge problem with identification of selector records required by DKIM and also this make for us problem with compatibility. We would like to strongly follow RFCs, but sometimes v=DKIM1 tag are resolved like issue as well as sometime missing of that tag do the same. This is a reason, why I would like to propose mitigation of problem, caused by word RECOMMENDED in standard RFC 6376: [...] Just to clarify: Are you saying the identification of a DKIM record in the DNS is uncertain unless "v=DKIM1" is present? -MSK Yes, exactly, you are right. Although DKIM FQDN records must be in the format [selector]._domainkey.domain.tld, this not impact any records prepared to create CNAME for other domains. As for the internal format, if the record contains only a key (p="base64encodedkey"), it is difficult to verify whether it is really a DKIM record. Especially in the case of a corrupted encoded record. 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 ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
[Ietf-dkim] DKIM signature algorithms
Dear, I would like to recommend change/extend support of algorithms for DKIM signage. Last update of algorithms are in RFC 8463, still not widely supported. Right now we facing issues with the long DKIM key distribution and lack of support, allowing the ECC signature can solve problem with key size. Elliptic curve signatures: I would like to recommend not only Ed25519, but also Ed448. Thanks to clever design, signatures based on on that algorithms can avoid of nonce collisions. But this could be real risk for the DSS standard curve implementation. | Key size | Curve | Nonce | Security Equivalent | Hash | --+--+-+--+-+--+ Ed25519 | 255b | Twisted Edwards | Text+Key | 125b | SHA256 | Ed448 | 448b | Twisted Edwards | Text+Key | 224b | SHAKE256 | NIST P256 | 256b | Weierstrass | Random | 128b | SHA256 | NIST P384 | 384b | Weierstrass | Random | 192b | SHA384 | NIST P521 | 521b | Weierstrass | Random | 230b | SHA512 | RSA signatures: But the RSA signature, require extremely long private keys. To assure similar security equivalent, need to be at the least 12 times longer. But RSA have sub-exponential complexity. Key size | Security Equivalent | -+-+ 1024b | 96b | 2048b | 112b | 3072b | 128b | 4096b | 160b | The signature based on RSA has some issues, but based on key properties nobody will be able to decide between them. In case of change required, need to be mentioned i DKIM key. Use of k=rsa for PKCS#1 v 1.5 as default value or k=rsa-pss for PKCS#1 v 2.2 RSA-PSS are probably the only solution. PKCS#1 v 1.0, obsolete, has not been supported PKCS#1 v 1.5, obsolete, vulnerable by Bleichenbacher family of attacks PKCS#1 v 2.2 RSA-PSS (DSS standard), described in NIST FIPS 186-5 Support: EU directive eIDAS and ETSI standard ETSI TS 119312 support signatures based on RSA PKCS#1 v 1.5, RSA-PSS, ED25519, ED448, NIST P-256, NIST P-384, NIST P-521 NIST FIPS 186-5 support signatures based on RSA PKCS#1 v 1.5, RSA-PSS, ED25519, ED448, NIST P-256, NIST P-384, NIST P-521 RFC 8446 TLS 1.3 support signatures based on RSA PKCS#1 v 1.5, RSA-PSS, ED25519, ED448, NIST P-256, NIST P-384, NIST P-521 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 ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
[Ietf-dkim] DKIM update - header tag
Dear, I got recommendation to propose changes in that mailing group. My work depend on appropriate protection of our brand, however this tasks require also management of records required for that protection. We have huge problem with identification of selector records required by DKIM and also this make for us problem with compatibility. We would like to strongly follow RFCs, but sometimes v=DKIM1 tag are resolved like issue as well as sometime missing of that tag do the same. This is a reason, why I would like to propose mitigation of problem, caused by word RECOMMENDED in standard RFC 6376: v= Version of the DKIM key record (plain-text; RECOMMENDED, default is "DKIM1"). If specified, this tag MUST be set to "DKIM1" (without the quotes). This tag MUST be the first tag in the record. Records beginning with a "v=" tag with any other value MUST be discarded. Note that Verifiers must do a string comparison on this value; for example, "DKIM1" is not the same as "DKIM1.0". I would like to recommend change work RECOMMENDED to MANDATORY, where whole article be after change v= Version of the DKIM key record (plain-text; MANDATORY, default is "DKIM1"). If specified, this tag MUST be set to "DKIM1" (without the quotes). This tag MUST be the first tag in the record and this tag must exist. Records beginning with a "v=" tag with any other valueMUST be discarded. Note that Verifiers must do a string comparison on this value; for example, "DKIM1" is not the same as "DKIM1.0". -- -- --- - - 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
