-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In message <[email protected]>, Dave Crocker <[email protected]> writes
>> DKIM1 (the current RFC) specifies on a per-email basis which header >> fields should be signed. However, many email senders do not appreciate >> that numerous header fields impact how an email is handled, displayed >> and responded to -- and that if these are not signed then there is scope >> for security problems to arise. This is a Bad Thing. > >I don't recall hearing discussion of this serious problem here in the IETF, >never-mind from 'many' email senders. > >Who are they? How can we vet your assertion? well here's a recent discussion on an Exim mailing list https://lists.exim.org/lurker/message/20250813.165035.2d7a779b.en.html and of course there is Jianjun Chen, Vern Paxson and Jian Jiang: Composition Kills: A Case Study of Email Sender Authentication, USEUSENIX Security, 2020 ISTR another similar paper but my Google-foo will not locate it just at the moment >Also: I'm not clear what you mean by "numerous header fields impact". That >sounds like a desire for fewer header fields, but I suspect you don't mean >that. So, please explain. I mean that the number of header fields which impact how a user is presented with a message and its metadata is more than a small number >> There is a further problem with DKIM1 in that header fields may appear >> more than once (even though RFC5322 might forbid this for many header >> fields). As various people have described it is not uncommon for >> different parts of a mail system to use different instances of these >> duplicated fields, so that a verifier might check instance 1 but the >> user will be shown instance 2 (or vice versa). This is Also Bad. > >There have been references to this, over the years, but I don't recall seeing >documentation of it. Examples of this being a problem in actual practice >would >be helpful. the USENIX paper is a reasonable starting point >> So best practice for DKIM1 is to have a rather long list of header >> fields (combining all the various bits of advice) > >Some documentation of the aggregate advice, and some IETF rough consensus on >that advice would be helpful. As in, essential. I am not currently in the business of writing I-Ds about DKIM1, and this would not be easy to do. M3AAWG failed to come to a consensus and merely has woolly phrasing "Sign a reasonable set of header fields" in their current Best Practice document :-( >> and oversign every >> header field that is actually present. If this actually done then >> there's quite a lot of bytes being shifted around with every email... > >Just to make sure I understand this point (and I recall your making it >before): >you are concerned that explicitly listing all of the header fields covered by >the signature will add enough bits to messages to be a burden for mail >processing software? well... Accept-Language:Alternate-Recipient:ARC-Authentication-Results:ARC- Message-Signature:ARC-Seal:Archived-At:Authentication-Results:Auto- Submitted:Autoforwarded:Autosubmitted:Bcc:Cc:Comments:Content- Alternative:Content-Description:Content-Disposition:Content- Duration:Content-features:Content-ID:Content-Identifier:Content- Language:Content-Location:Content-MD5:Content-Return:Content-Transfer- Encoding:Content-Translation-Type:Content-Type:Conversion:Conversion- With-Loss:DL-Expansion-History:Date:Deferred-Delivery:Delivery- Date:Discarded-X400-IPMS-Extensions:Discarded-X400-MTS- Extensions:Disclose-Recipients:Disposition-Notification- Options:Disposition-Notification-To:Downgraded-Bcc:Downgraded- Cc:Downgraded-Final-Recipient:Downgraded-In-Reply-To:Downgraded-Message- Id:Downgraded-Original-Recipient:Downgraded-References:Encoding:Encrypte d:Expires:Expiry-Date:From:Generate-Delivery-Report:HP- Outer:Importance:In-Reply-To:Incomplete-Copy:Keywords:Language:Latest- Delivery-Time:List-Archive:List-Help:List-ID:List-Owner:List-Post:List- Subscribe:List-Unsubscribe:List-Unsubscribe-Post:Message- Context:Message-ID:Message-Type:MIME-Version:MMHS-Exempted-Address:MMHS- Extended-Authorisation-Info:MMHS-Subject-Indicator-Codes:MMHS-Handling- Instructions::MMHS-Message-Instructions:MMHS-Codress-Message- Indicator:MMHS-Originator-Reference:MMHS-Primary-Precedence:MMHS-Copy- Precedence:MMHS-Message-Type:MMHS-Other-Recipients-Indicator-To:MMHS- Other-Recipients-Indicator-CC:MMHS-Acp127-Message-Identifier:MMHS- Originator-PLAD:MT-Priority:Obsoletes:Organization:Original-Encoded- Information-Types:Original-From:Original-Message-ID:Original- Recipient:Originator-Return-Address:Original-Subject:PICS-Label:Prevent- NonDelivery-Report:Priority:Received:Received-SPF:References:Reply- By:Reply-To:Require-Recipient-Valid-Since:Resent-Bcc:Resent-Cc:Resent- Date:Resent-From:Resent-Message-ID:Resent-Reply-To:Resent-Sender:Resent- To:Sender:Sensitivity:Solicitation:Subject:Subject:Summary:Supersedes:Su persedes:TLS-Report-Domain:TLS-Report-Submitter:TLS-Required:To:VBR- Info:X400-Content-Identifier:X400-Content-Return:X400-Content- Type:X400-MTS-Identifier:X400-Originator:X400-Received:X400-Recipients:X 400-Trace; plus all the header field names that ARE present of course for the oversigning (OK, a few of those don't have security properties...) >> So in DKIM2 our first design decision was to get rid of over-signing by >> specifying that if a header field is signed then all instances are >> combined and signed. Assume hat is the case as we move on... > >"then all instances are combined and signed" but it is not clear what this >means, my I-D has some wording ... but doubtless that can be improved >that is different from current practice. yes >If there are two To: fields, then the current list of fields will include >to,to. actually no .. in most instances to,to in h= means only one To: header field will be found in the message >In concrete, technical terms, what are you proposing that is different:? I think you should have read further ... what I am proposing is my (D) section [...] >Worse, whatever list is developed now will be inadequate eventually. only if someone invents a new Trace header field, but we could change the I-D to specify Received: and Return-Path explicitly (which is sort of the case already) rather than implicitly because they are Trace header fields. >The framework that you've been describing, here and earlier has three >characteristics: > >1. Specifying fields required to be covered >2. Permitting signers to add more fields >3. Making the required set be implied rather than listed explicitly I described such a framework -- but that is not what we settled on in the design -- we settled on "sign every header except" and the list of exceptions is pretty short - -- richard @ highwayman . com "Nothing seems the same Still you never see the change from day to day And no-one notices the customs slip away" -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQA/AwUBaM9SI2HfC/FfW545EQKJugCeLqt4VbW2mtMyjvSI3bcEJx1uRfUAn3hY t63eKOsbBuu9gAY3yeaaEYNR =lALW -----END PGP SIGNATURE----- _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
