Re: [Ietf-dkim] RFC 8463: DNS textual form underspecified
I mean ok, non-issue.
Scott Kitterman wrote in
<717c7103-311a-4c60-a3bf-72ea41cbc...@kitterman.com>:
|On April 14, 2024 7:13:55 PM UTC, Steffen Nurpmeso \
|wrote:
|>Scott Kitterman wrote in
|> <2c92eb24-3332-436c-a0bb-d4bac3322...@kitterman.com>:
|>|On April 14, 2024 1:53:07 AM UTC, Steffen Nurpmeso \
|>|wrote:
|>|>Scott Kitterman wrote in
|>|> <5368ac9a-51d5-4aec-ab19-613dbead7...@kitterman.com>:
|>|>|On April 14, 2024 12:51:26 AM UTC, Steffen Nurpmeso |>|> \
|>|>|>Thanks to Hanno Böck (known from ossec and more) i was pointed to
|>|>|>my falsely published ED25519 DKIM key.
...
|>|>|>I realize that RFC 8463 says repeatedly that the base64-encoded
|>|>|>representation of an ED25519 key is 44 bytes, and that the
|>|>|>examples go for this. Still there is no wording that the entire
|>|>|>ASN.1 structure shall be thrown away.
|>|>|
|>|>|At the time we wrote what became RFC 8463, ASN.1 for ED25519 was not \
|>|>|specified yet. Openssl didn't support ED25119 either. I'm not sure \
|>|>|what you think we should have put in that we didn't.
|>|>|
|>|>|It seems to me that you are saying that the RFC is correct and clear, \
|>|>|but that you were certain you knew better than the RFC. That's not \
|>|>|a thing an RFC can fix.
|>|>
|>|>There *is* RFC 8410 to which 8463 refers, around the same time.
...
|>|I don't see it? Where is the reference to 8410?
|>
|>Yes you are right. 8463 only refers to 8032, and does not mention
|>8410 at all. This is a complete misunderstanding. I have 8410
..
|>I think now that i understand that 8463 just "invents its own
|>protocol" instead of embedding itself into the CMS / X509 / PKI
|>infrastructure i no longer like it at all. What a mess. It is
|>Wireguard VPN / SSH etc raw algorithm logic!
|
|Since nothing else existed at the time we did the work, I'm not sure \
|what else we could have done instead. B64 of the public key isn't \
|that hard to do. Honestly, it was much easier to deal with implementing \
|it than RSA shoved into ASN.1.
But please allow me some doubts as there are widely available and
audited cryptographic libraries around that offer interfaces to
deal with these issues.
|Ultimately, DKIM stuff is for DKIM and I don't think it's a huge problem \
|if it's slightly different than other things. In dkimpy I included \
|tools to generate keys correctly. I think that as long as library \
|providers do that, this is a non-issue.
It is an intransparent binary blob of random data.
And it remains so when decoded. Who wants that in the DNS.
To trumple upon you all and this non-issue even further as it is
Monday, these are my DKIM records
v=DKIM1; k=ed25519; p=NhvcV4tLaGvK4sSxWEWzjfpntCeyj7s4smQ+JM1LE0Y=
v=DKIM1; k=rsa; h=sha256;
p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAniKuBSPAv5QtXEv08pP5uKWMIP3QvmSq3P2Ick/wMTnRv3xqCQPtXu7ick/qt05df/RNLlSIUVL0szhAq8Ua2QporQ53xs8llprY7y0ZpZpUrhUsvwa1GCF2o2DFnD9mWDq5wepxvDRLKpfJu6faz0eFNRL8fyR3ER7EqegrA6+dl6vX+eZLCp/qlhnMhlh/zio8irdCap9W28g+m5Wpqn2p3qhXjqdWKpQUwSu194O+lF19cdLLXpx2L+pW4r8TM/xi2dzNC0/3KEm+zWqhWZZV2T8oRk3mjoMfpMr1v2Yo2RIk7Q6akFna/Bqkt+zJvbu/Yso15x+JTQw6MPvSCwIDAQAB
Everyone who knows can apply
openssl base64 -d | openssl asn1parse -inform DER
and will get somehow "useful" results for that latter, but nothing
but an error for the former.
The same person who wrote 8032 wrote 8410 and that in turn
was IETF-published earlier than 8463.
There is also RFC 7250 "Using Raw Public Keys in Transport Layer
Security (TLS) and Datagram Transport Layer Security (DTLS)" from
2014, and many more ASN.1 / X509 / CMS etc infrastructural
emissions from the IETF for which i am not an expert, but anyhow
in all this context a binary blob of intransparent data is an
"illegal alien".
How about a RFC for asn1ed25519-sha256 DKIM keys which simply
includes the 16 base64-encoded ASN.1 structure bytes?
Or asn1ed25519-blake2 (RFC 7693), which is now also widely
available (and if only for that RFC 9106 Argon2 monster)?
Maybe this will help the switch away from RSA?
It is otherwise not understandable in this world of hysteric
encryption-scheme reduction (ie in TLS land just two or three
years ago i was shouted at on nmh-workers at nongnu dot org by
a well known US army (navy i think) security guy well-known for
his Kerberos/GSSAPI prospect once i said something about TLSv1.1,
and as of today in practice i only see TLSv1.3, and the developer
of the HTTP server software i use reduced to forward-secrecy-plus
("CipherString" => "EECDH+AESGCM:CHACHA20:!PSK:!DHE") # default
which is not much but at least has some TLSv1.2 left:
# openssl ciphers -v EECDH+AESGCM:CHACHA20:!PSK:!DHE).
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/m
Re: [Ietf-dkim] RFC 8463: DNS textual form underspecified
On April 14, 2024 7:13:55 PM UTC, Steffen Nurpmeso wrote: >Scott Kitterman wrote in > <2c92eb24-3332-436c-a0bb-d4bac3322...@kitterman.com>: > |On April 14, 2024 1:53:07 AM UTC, Steffen Nurpmeso \ > |wrote: > |>Scott Kitterman wrote in > |> <5368ac9a-51d5-4aec-ab19-613dbead7...@kitterman.com>: > |>|On April 14, 2024 12:51:26 AM UTC, Steffen Nurpmeso \ > |>|>Thanks to Hanno Böck (known from ossec and more) i was pointed to > |>|>my falsely published ED25519 DKIM key. > |>|>Until now that simply was the complete ED25519 public key, just > |>|>like for RSA, instead of extracting the actual "bitstring data" > |>|>from the standardized ASN.1 container, which starts at offset 16 > |>|>(or -offset=12 if you use "openssl asn1parse -noout -out -" aka > |>|>the binary blob). > |>|> > |>|>I realize that RFC 8463 says repeatedly that the base64-encoded > |>|>representation of an ED25519 key is 44 bytes, and that the > |>|>examples go for this. Still there is no wording that the entire > |>|>ASN.1 structure shall be thrown away. > |>| > |>|At the time we wrote what became RFC 8463, ASN.1 for ED25519 was not \ > |>|specified yet. Openssl didn't support ED25119 either. I'm not sure \ > |>|what you think we should have put in that we didn't. > |>| > |>|It seems to me that you are saying that the RFC is correct and clear, \ > |>|but that you were certain you knew better than the RFC. That's not \ > |>|a thing an RFC can fix. > |> > |>There *is* RFC 8410 to which 8463 refers, around the same time. > |>It defines exactly this, no? It says there are no further > |>parameters, but it does not say "hey so you can go and just leave > |>that niche container off". > |>Sure it is 44 bytes, but the entire thing is 64. > |>It is de-facto only the single example in A.2 which reveals the > |>total ignorance of ASN.1, and it is about brisbane and football, > |>which i cannot glue together (letting aside it is written by an > |>american, and who knows what kind of "football" that is?, as > |>i seem to know they say "soccer" for what i would think, but it is > |>4am so i do not truly think anyhow. Saturday night all right for > |>fighting, ah.) (OpenSSL in mid 2017, at least a bit.) > |>Thus: smart, very smart. Is always too smart for some. > |>Just leave them behind. > | > |I don't see it? Where is the reference to 8410? > >Yes you are right. 8463 only refers to 8032, and does not mention >8410 at all. This is a complete misunderstanding. I have 8410 >since February 2023, and 8032 since 31st of January this year, >coming from a completely different background, having read 5480 >(Elliptic Curve Cryptography Subject Public Key Information) and >more in the past, and am a CMS and x.509 "fanatic". > >I think now that i understand that 8463 just "invents its own >protocol" instead of embedding itself into the CMS / X509 / PKI >infrastructure i no longer like it at all. What a mess. It is >Wireguard VPN / SSH etc raw algorithm logic! Since nothing else existed at the time we did the work, I'm not sure what else we could have done instead. B64 of the public key isn't that hard to do. Honestly, it was much easier to deal with implementing it than RSA shoved into ASN.1. Ultimately, DKIM stuff is for DKIM and I don't think it's a huge problem if it's slightly different than other things. In dkimpy I included tools to generate keys correctly. I think that as long as library providers do that, this is a non-issue. Scott K Scott K ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] RFC 8463: DNS textual form underspecified
Scott Kitterman wrote in <2c92eb24-3332-436c-a0bb-d4bac3322...@kitterman.com>: |On April 14, 2024 1:53:07 AM UTC, Steffen Nurpmeso \ |wrote: |>Scott Kitterman wrote in |> <5368ac9a-51d5-4aec-ab19-613dbead7...@kitterman.com>: |>|On April 14, 2024 12:51:26 AM UTC, Steffen Nurpmeso \ |>|>Thanks to Hanno Böck (known from ossec and more) i was pointed to |>|>my falsely published ED25519 DKIM key. |>|>Until now that simply was the complete ED25519 public key, just |>|>like for RSA, instead of extracting the actual "bitstring data" |>|>from the standardized ASN.1 container, which starts at offset 16 |>|>(or -offset=12 if you use "openssl asn1parse -noout -out -" aka |>|>the binary blob). |>|> |>|>I realize that RFC 8463 says repeatedly that the base64-encoded |>|>representation of an ED25519 key is 44 bytes, and that the |>|>examples go for this. Still there is no wording that the entire |>|>ASN.1 structure shall be thrown away. |>| |>|At the time we wrote what became RFC 8463, ASN.1 for ED25519 was not \ |>|specified yet. Openssl didn't support ED25119 either. I'm not sure \ |>|what you think we should have put in that we didn't. |>| |>|It seems to me that you are saying that the RFC is correct and clear, \ |>|but that you were certain you knew better than the RFC. That's not \ |>|a thing an RFC can fix. |> |>There *is* RFC 8410 to which 8463 refers, around the same time. |>It defines exactly this, no? It says there are no further |>parameters, but it does not say "hey so you can go and just leave |>that niche container off". |>Sure it is 44 bytes, but the entire thing is 64. |>It is de-facto only the single example in A.2 which reveals the |>total ignorance of ASN.1, and it is about brisbane and football, |>which i cannot glue together (letting aside it is written by an |>american, and who knows what kind of "football" that is?, as |>i seem to know they say "soccer" for what i would think, but it is |>4am so i do not truly think anyhow. Saturday night all right for |>fighting, ah.) (OpenSSL in mid 2017, at least a bit.) |>Thus: smart, very smart. Is always too smart for some. |>Just leave them behind. | |I don't see it? Where is the reference to 8410? Yes you are right. 8463 only refers to 8032, and does not mention 8410 at all. This is a complete misunderstanding. I have 8410 since February 2023, and 8032 since 31st of January this year, coming from a completely different background, having read 5480 (Elliptic Curve Cryptography Subject Public Key Information) and more in the past, and am a CMS and x.509 "fanatic". I think now that i understand that 8463 just "invents its own protocol" instead of embedding itself into the CMS / X509 / PKI infrastructure i no longer like it at all. What a mess. It is Wireguard VPN / SSH etc raw algorithm logic! --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] RFC 8463: DNS textual form underspecified
On April 14, 2024 1:53:07 AM UTC, Steffen Nurpmeso wrote: >Scott Kitterman wrote in > <5368ac9a-51d5-4aec-ab19-613dbead7...@kitterman.com>: > |On April 14, 2024 12:51:26 AM UTC, Steffen Nurpmeso \ > |wrote: > |>Hello. > |> > |>Thanks to Hanno Böck (known from ossec and more) i was pointed to > |>my falsely published ED25519 DKIM key. > |>Until now that simply was the complete ED25519 public key, just > |>like for RSA, instead of extracting the actual "bitstring data" > |>from the standardized ASN.1 container, which starts at offset 16 > |>(or -offset=12 if you use "openssl asn1parse -noout -out -" aka > |>the binary blob). > |> > |>I realize that RFC 8463 says repeatedly that the base64-encoded > |>representation of an ED25519 key is 44 bytes, and that the > |>examples go for this. Still there is no wording that the entire > |>ASN.1 structure shall be thrown away. > | > |At the time we wrote what became RFC 8463, ASN.1 for ED25519 was not \ > |specified yet. Openssl didn't support ED25119 either. I'm not sure \ > |what you think we should have put in that we didn't. > | > |It seems to me that you are saying that the RFC is correct and clear, \ > |but that you were certain you knew better than the RFC. That's not \ > |a thing an RFC can fix. > >There *is* RFC 8410 to which 8463 refers, around the same time. >It defines exactly this, no? It says there are no further >parameters, but it does not say "hey so you can go and just leave >that niche container off". >Sure it is 44 bytes, but the entire thing is 64. >It is de-facto only the single example in A.2 which reveals the >total ignorance of ASN.1, and it is about brisbane and football, >which i cannot glue together (letting aside it is written by an >american, and who knows what kind of "football" that is?, as >i seem to know they say "soccer" for what i would think, but it is >4am so i do not truly think anyhow. Saturday night all right for >fighting, ah.) (OpenSSL in mid 2017, at least a bit.) >Thus: smart, very smart. Is always too smart for some. >Just leave them behind. I don't see it? Where is the reference to 8410? Scott K ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] RFC 8463: DNS textual form underspecified
Scott Kitterman wrote in <5368ac9a-51d5-4aec-ab19-613dbead7...@kitterman.com>: |On April 14, 2024 12:51:26 AM UTC, Steffen Nurpmeso \ |wrote: |>Hello. |> |>Thanks to Hanno Böck (known from ossec and more) i was pointed to |>my falsely published ED25519 DKIM key. |>Until now that simply was the complete ED25519 public key, just |>like for RSA, instead of extracting the actual "bitstring data" |>from the standardized ASN.1 container, which starts at offset 16 |>(or -offset=12 if you use "openssl asn1parse -noout -out -" aka |>the binary blob). |> |>I realize that RFC 8463 says repeatedly that the base64-encoded |>representation of an ED25519 key is 44 bytes, and that the |>examples go for this. Still there is no wording that the entire |>ASN.1 structure shall be thrown away. | |At the time we wrote what became RFC 8463, ASN.1 for ED25519 was not \ |specified yet. Openssl didn't support ED25119 either. I'm not sure \ |what you think we should have put in that we didn't. | |It seems to me that you are saying that the RFC is correct and clear, \ |but that you were certain you knew better than the RFC. That's not \ |a thing an RFC can fix. There *is* RFC 8410 to which 8463 refers, around the same time. It defines exactly this, no? It says there are no further parameters, but it does not say "hey so you can go and just leave that niche container off". Sure it is 44 bytes, but the entire thing is 64. It is de-facto only the single example in A.2 which reveals the total ignorance of ASN.1, and it is about brisbane and football, which i cannot glue together (letting aside it is written by an american, and who knows what kind of "football" that is?, as i seem to know they say "soccer" for what i would think, but it is 4am so i do not truly think anyhow. Saturday night all right for fighting, ah.) (OpenSSL in mid 2017, at least a bit.) Thus: smart, very smart. Is always too smart for some. Just leave them behind. Ciao from Germany, --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] RFC 8463: DNS textual form underspecified
John Levine wrote in <20240414010739.d752f8861...@ary.qy>: |It appears that Steffen Nurpmeso said: |>|I realize that RFC 8463 says repeatedly that the base64-encoded |>|representation of an ED25519 key is 44 bytes, and that the |>|examples go for this. Still there is no wording that the entire |>|ASN.1 structure shall be thrown away. | |Yeah, I should have been clearer. | |>That cannot be the reason Google, Microsoft and more do not |>support that, right. It is a bit bizarre that these huge RSA keys |>are used all over the place, whereas the even stripped-naked ones |>are not. | |It's the same reason as the last umpteen times you asked. I am the wire and Google is the Bird. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] RFC 8463: DNS textual form underspecified
On April 14, 2024 12:51:26 AM UTC, Steffen Nurpmeso wrote: >Hello. > >Thanks to Hanno Böck (known from ossec and more) i was pointed to >my falsely published ED25519 DKIM key. >Until now that simply was the complete ED25519 public key, just >like for RSA, instead of extracting the actual "bitstring data" >from the standardized ASN.1 container, which starts at offset 16 >(or -offset=12 if you use "openssl asn1parse -noout -out -" aka >the binary blob). > >I realize that RFC 8463 says repeatedly that the base64-encoded >representation of an ED25519 key is 44 bytes, and that the >examples go for this. Still there is no wording that the entire >ASN.1 structure shall be thrown away. At the time we wrote what became RFC 8463, ASN.1 for ED25519 was not specified yet. Openssl didn't support ED25119 either. I'm not sure what you think we should have put in that we didn't. It seems to me that you are saying that the RFC is correct and clear, but that you were certain you knew better than the RFC. That's not a thing an RFC can fix. Scott K ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] RFC 8463: DNS textual form underspecified
It appears that Steffen Nurpmeso said: > |I realize that RFC 8463 says repeatedly that the base64-encoded > |representation of an ED25519 key is 44 bytes, and that the > |examples go for this. Still there is no wording that the entire > |ASN.1 structure shall be thrown away. Yeah, I should have been clearer. >That cannot be the reason Google, Microsoft and more do not >support that, right. It is a bit bizarre that these huge RSA keys >are used all over the place, whereas the even stripped-naked ones >are not. It's the same reason as the last umpteen times you asked. R's, John ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] RFC 8463: DNS textual form underspecified
Steffen Nurpmeso wrote in <20240414005126.pzjJO4pr@steffen%sdaoden.eu>: |Thanks to Hanno Böck (known from ossec and more) i was pointed to |my falsely published ED25519 DKIM key. |Until now that simply was the complete ED25519 public key, just |like for RSA, instead of extracting the actual "bitstring data" |from the standardized ASN.1 container, which starts at offset 16 |(or -offset=12 if you use "openssl asn1parse -noout -out -" aka |the binary blob). | |I realize that RFC 8463 says repeatedly that the base64-encoded |representation of an ED25519 key is 44 bytes, and that the |examples go for this. Still there is no wording that the entire |ASN.1 structure shall be thrown away. That cannot be the reason Google, Microsoft and more do not support that, right. It is a bit bizarre that these huge RSA keys are used all over the place, whereas the even stripped-naked ones are not. A nice Sunday i wish to everyone, if at all possible. Ciao from Germany, --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
[Ietf-dkim] RFC 8463: DNS textual form underspecified
Hello. Thanks to Hanno Böck (known from ossec and more) i was pointed to my falsely published ED25519 DKIM key. Until now that simply was the complete ED25519 public key, just like for RSA, instead of extracting the actual "bitstring data" from the standardized ASN.1 container, which starts at offset 16 (or -offset=12 if you use "openssl asn1parse -noout -out -" aka the binary blob). I realize that RFC 8463 says repeatedly that the base64-encoded representation of an ED25519 key is 44 bytes, and that the examples go for this. Still there is no wording that the entire ASN.1 structure shall be thrown away. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
