Re: [Ietf-dkim] RFC 8463: DNS textual form underspecified

[Steffen Nurpmeso <[e-mail]>]

I mean ok, non-issue.

Scott Kitterman wrote in
 <[e-mail]>:
 |On April 14, 2024 7:13:55 PM UTC, Steffen Nurpmeso <[e-mail]> \
 |wrote:
 |>Scott Kitterman wrote in
 |> <[e-mail]>:
 |>|On April 14, 2024 1:53:07 AM UTC, Steffen Nurpmeso <[e-mail]> \
 |>|wrote:
 |>|>Scott Kitterman wrote in
 |>|> <[e-mail]>:
 |>|>|On April 14, 2024 12:51:26 AM UTC, Steffen Nurpmeso <[e-mail]\
 |>|>|> \
 |>|>|>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)