Hi Richard, hi all, I think that the discussion was helpful at all.
And I thought about a possible solution just yesterday.
It looks like:
1. Keep keys in DNS.
2. Save only hashes in the messages themselves.
3. As long as SHA3 is not natively supported by
hardware, only SHA-512 should be used because
SHA-256 and SHA-384 are known to be susceptible
to Length-Extension-Attacks.
If you, Bron and Wei keep on using JSON, you should consider
flattening it like an array of flat objects:
[
{
"host": "mail.example.com",
"selector": "dkim2-s1",
"h": "from:to:subject:date",
"sig": "signature-1",
"sig-alg": "aes256-gcm-sha512",
"hash": "sha512-header-hash-1",
"sig-exp": 1789311600,
"key-exp": 1820847600
}
{
"host": "mail.example.org",
"selector": "dkim2-s2",
"h": "from:to:subject:date",
"sig": "signature-2",
"sig-alg": "ed448-sha512",
"hash": "sha512-header-hash-2",
"sig-exp": 1789311600,
"key-exp": 1820847600
}
]
Possible algorithms should only be: AES256-CNAC-SHA512,
AES256-GCM-SHA512, Ed448-SHA512 and Ed25519-SHA512.
This would be evaluated fast by any parser, but not as fast as
simple tag=value pairs.
BTW to Bron: I know you would say the array gets too big. But
architectural complexity is much worse than a long array.
BTW to Pietro: Would you possibly confirm that setting a key
expiration is required?
Regards,
Timo
It looks like Richard Clayton aimed to say:
> In message <[email protected]>, Timo
> Gerke <[email protected]> writes
>
>> I personally do not have a problem with JSON, but we strictly
>> have to limit object depth.
>
> the JSON schema in the DKIM 2 spec already limits the depth
>
>> BTW: This concept completely contradicts the principles of
>> RFC 5322.
>
> I don't understand that comment ... but if you are truly worried about
> unlimited depth then you should break away from DKIM2 and start writing
> an IETF draft to update RFC2046 ... MIME multipart and MIME message can
> both be nested to any arbitrary limit (albeit, good luck interworking
> when you get past two or three)
>
>> Standard JSON specifications lack strict object-key ordering
>
> absolutely ... why is this a problem ?
>
>> and
>> duplicate key handling.
>
> JSON schemas cannot forbid duplicate keys ... so you have identified an
> actual issue that the spec needs to address (though just providing some
> text would have been far quicker and easier for all concerned).
>
> I will add some text to the -07 spec to explicitly forbid duplicate key
> values.
>
> I will note that JSON parsing libraries already have calling parameters
> for this issue -- since the consensus is that duplicate keys are pretty
> much always wrong -- so implementors will be able to deal with this
> change very quickly (if indeed they are not already doing so).
>
>> Introducing nested object complexity into
>> the transport layer creates serialization risks that flat, native
>> tag-value structures inherently avoid—which is why DKIM1 worked
>> without JSON for 15 years.
>
> it escapes me what serialization could possibly be required ...
>
> ... and should probably note that DKIM1 did not have JSON but does have
> its own complex set of issues relating to duplicates that many systems
> deal with extremely poorly. See for example the "Inbox Invasion" paper
> by Zhang et al. We believe that DKIM2 fully addresses authentication
> issues related to the type of header field issues that they identified.
>
Timo Gerke
Hamburg, Germany
"If you think technology can solve your security
problems then you don't understand the problems
and you don't understand the technology."
-- Bruce Schneier
OpenPGP_0x9F03DF9F597BF31E.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
