Hello, and good evening. And fwiw and if i come through...
Bron Gondwana wrote in <[email protected]>: |I've been thinking more about the strong objection to "explicit list \ |of signed headers", which is that a new header, e.g. `Message-Evil: \ |no` could be created by a new draft and have very important security \ |properties, but the sending system doesn't know that and hence doesn't \ |include it (as blank) in the signed set of header fields, and then \ |a later system could add it, and that would be bad. | |This does require some clever security considerations and correct implem\ |entation, but I think my answer is: | |If a header field is not signed by the current instances, then can \ |be assumed to be blank in all previous instances. Any instance signing \ |a header field which was not signed by the previous instance is assumed \ |to be adding it; and receiving systems MUST NOT assume it was present \ |before. | |The latest signed copy of that header field MUST be used for any securit\ |y-related purpose, so if | |`Message-Instance: i=1` didn't sign it |`Message-Instance: i=2` did sign it, with value 'yes' |`Message-Instance: i=3` didn't sign it, but changed it to "no" with \ |instructions how to convert back | |Then the signed value is "yes", and that's the only value which can \ |be used for anything security related, and only when attributing it \ |to the system which signed `i=2`. | |I believe this is actually sufficient for good security, it doesn't \ |mandate that any instance sign ANYTHING in particular, only the things \ |for which it requires attribution. And of course if you modify anything \ |which was signed by ANY previous instance, you have to provide the \ |algebra to convert back to the value it had. Those algebras don't \ |need to be signed because they either work or they don't. I perceived this as a very interesting and important thought. Whereas, for ACDC, ..all ACDC here.., i think the most important part is that signatures of elder message revisions can be cryptographically verified, after unrolling differential changes. For this, it does not matter at all. But, for users inspecting differences visually (accordingly enpowered user interfaces provided), as well as for RFC 5863 collecting organizational trust, it makes a big difference. For example (of course that is, as you say) certain additional header field instances that "spring into existence out of nowhere" can be attributed to malicious (man in the middle) players if "C" looks at an email from "A", but "C" *knows* which header fields "A" did sign, but "A" could as such deducably did not (hope the english gets that). So, thank you for this thought, for ACDC i thus added the following (extracts -- in essence: the IANA registry that is being asked for is changed to revision counted, and the acdc= tag will announce the supported revision of the registry): + IANA is asked to introduce a revision counted registry of header + fields to be included in cryptographic signature protection; + ACDC, as below, includes the supported revision of the DB in the + cryptographic signature. + The second tag entry after "sequence" is "ianarev", + which announces the supported revision of the IANA registry of + header fields, as below. + All header fields included in the registry at that revision + <bcp14>MUST</bcp14> be included in the cryptographic signature. + </t><blockquote> + <em>Informative remark:</em> + Explicitly including the supported revision of the IANA registry + of additional header fields enables user interfaces + (also see below) to provide many supportive measures to users + that make decisions on the trustworthiness of intermediates; + it could also allow for a more thorough automatic collection of + trustworthy statistics of organizational trust + (<xref target="RFC5863"/>, section 2.5). -acdc = %x61 %x63 %x64 %x63 = sequence ":" 1*flag [ ":" id ] +acdc = %x61 %x63 %x64 %x63 = sequence ":" ianarev ":" 1*flag [ ":" id ] sequence = 1*3DIGIT; DIGIT from RFC 5234 +ianarev = 1*3DIGIT + IANA is asked to create a revision counted registry of + header fields that shall be cryptographically protected + by DKIM/ACDC in addition to the list mentioned by sections + 5.4 and 5.4.1 of + DKIM<xref target="RFC6376"/>. + This memo includes the + Author Header Field<xref target="RFC9057"/> + in both lists. + </t><t> + To ensure long time compatibility with ACDC + (maximally three digits in the "ianarev" tag entry), + IANA is asked to increment revisions conservatively, + for example maximally once a month, + and to use a format that groups header fields through + registry revisions + (like the "Age" property of Unicode characters). (Just half an hour, to be refined.) Your example cannot happen with ACDC, as i *think* it defines all things covered by former signatures must be covered. But, honestly, i have forgotten that; should be. Greetings. --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 -- [email protected] To unsubscribe send an email to [email protected]
