Re: [ietf-dkim] Conspicuously absent statistics
One day of statistics (7 hosts from 3 sites reporting so far) reveals: 4911 signatures contained no i= tag 3832 signatures (43.8%) had i= tags 1247 distinct d= domains were found in signatures that contained "i=" tags 1580 (41.2%) had an i= domain that matched d= and had an empty local-part 1650 (43.1%) had an i= domain that matched d= and had a local-part matching the one in From: 4 (0.1%) had an i= domain that matched d= and had a local-part different from the one in From: 467 (12.2%) had an i= domain that was a subdomain of d= and had an empty local-part None had an i= domain that was a subdomain of d= and had a local-part matching the one in From: 122 (3.2%) had an i= domain that was a subdomain of d= and had a local-part different from the one in From: I'll let this accumulate for a while and then add it to the interoperability report. From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Murray S. Kucherawy Sent: Monday, October 25, 2010 11:45 AM To: ietf-dkim@mipassoc.org Subject: [ietf-dkim] Conspicuously absent statistics Well, actually, not so conspicuous since nobody pointed it out yet... Our stats stuff is reporting absolutely nothing so far about use of "i=". I just posted a patch release that includes some code to start collecting this, and one of our sites has already rolled it out. After we've had some time to collect some numbers, I'll provide some information about what we're seeing in the wild with respect to use of "i=". ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Take two (was Re: Proposal for new text about multiple header issues)
8.14 Malformed Inputs DKIM allows additional header fields to be added to a signed message without breaking the signature. This tolerance can be abused, e.g. in a replay attack, by adding additional instances of header fields that are displayed to the end user or used as filtering input, such as From or Subject, to an already signed message in a way that doesn't break the signature. The resulting message violates section 3.6 of [MAIL]. The way such input will be handled and displayed by an MUA is unpredictable, but in some cases it will display the newly added header fields rather than those that are part of the originally signed message alongside some "valid DKIM signature" annotation. This might allow an attacker to replay a previously sent, signed message with a different Subject, From or To field. Because of this, DKIM implementers are strongly advised to reject or treat as suspicious any message that has multiple copies of header fields that are disallowed by section 3.6 of [MAIL], particularly those that are typically displayed to end users (From, To, Cc, Subject). A signing module could return an error rather than generate a signature; a verifying module might return a syntax error code or arrange not to return a positive result even if the signature technically validates. Senders concerned that their messages might be particularly vulnerable to this sort of attack and do not wish to rely on receiver filtering of invalid messages can ensure that adding additional header fields will break the DKIM signature by including two copies of the header fields about which they are concerned in the signature (e.g. "h= ... from:from:to:to:subject:subject ...). See Sections 3.5 and 5.4 for further discussion of this mechanism. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Douglas Otis > Sent: Monday, October 25, 2010 2:48 PM > To: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] Proposal for new text about multiple header issues > > > 1) During the handling of a message in conjunction with a DKIM result > > that indicates a valid signature, consider as valid only those fields > > and the body portion that was covered by the signature. Note that this > > is not to say unsigned content is not valid, but merely that the > > signature is making no statement about it. > > Bad advice. There is no other email component that can be relied upon to > restore flawed DKIM verification results, nor should DKIM relegate > determination of DKIM result validity to subsequent consumers. But neither of those was the suggestion. > > 3) For any header field listed in Section 3.6 of [MAIL] as having an > > upper bound on the number of times it can appear, include the name of > > that field one extra time in the "h=" portion of the signature to > > prevent addition of fraudulent instances. Any attachment of such > > fields after signing would thus invalidate the signature (see Section > > 3.5 and 5.4 for further discussion). > > Incomplete advice. This only provides partial protection, since it does > not prevent spoofing of a From header where an attacker controls or > utilizes a domain that does not include repeated From header entries > within the h= parameter. I'm having trouble parsing that. Please propose alternate text, or show an example of what you're describing. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
On Oct 25, 2010, at 5:48 PM, John R. Levine wrote:
>>> Isn't the more interesting attack a signature from some throwaway domain
>>> that covered a matching From: but also contained a From: indicating some
>>> high-value phish target?
>>
>> Not really, no. Signing the From: field means nothing other than that it is
>> the same as when it was sent.
>>
>> I can sign mail with d=blighty.com and "From: doola...@ebay.com" without
>> needing to play any games with multiple headers
>
> Let's say your message has two From lines, one from b...@blurfle.net, one
> from secur...@ebay.com, and you sign the first with d=blurfle.net.
> Perhaps blurfle.net even publishes discardable ADSP.
>
> My concern would be that filtering agents might notice the blurfle header and
> signature and deem it harmless,
If the filtering agent recognises blurfle.net then that would make blurfle.net
"someone trustworthy", and reduces to exactly the situation I was discussing 4
posts upstream. ("The real risk here is that someone can present a message as
signed by someone trustworthy...").
If they've never seen blurfle.net before, then there's no reason to consider
the signer trustworthy and your hypothetical filtering agent is broken.
> but an MUA would show the ebay header.
> In any event, I think it's reasonable to say that DKIM signers shouldn't sign
> a message with an extra From or Subject header,
That doesn't really add much value, as you can always grab the signed message,
add a header and resend it (unless you're also planning on mandating
h=from:from:subject:subject).
It's a perfectly reasonable policy for a DKIM signer to have, though.
> and verifiers shouldn't say the signature on such a message is good, even if
> it validates technically.
Works for me, at least at the should-as-opposed-to-SHOULD level.
I've said as much several times, and the only disagreements I've seen are
people who are saying that that's not strict enough, and that DKIM verifiers
also shouldn't verify a message that has, for example, bare linefeeds in it or
a base 64 encoded section with an eighty character line in it.
> I dug through my message archives last week, and I don't think I've ever seen
> a legit message with that flaw, so it's hard to think of a reason to cut such
> messages any slack.
Cheers,
Steve
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
>> Isn't the more interesting attack a signature from some throwaway domain >> that covered a matching From: but also contained a From: indicating some >> high-value phish target? > > Not really, no. Signing the From: field means nothing other than that it is > the same as when it was sent. > > I can sign mail with d=blighty.com and "From: doola...@ebay.com" without > needing to play any games with multiple headers Let's say your message has two From lines, one from b...@blurfle.net, one from secur...@ebay.com, and you sign the first with d=blurfle.net. Perhaps blurfle.net even publishes discardable ADSP. My concern would be that filtering agents might notice the blurfle header and signature and deem it harmless, but an MUA would show the ebay header. In any event, I think it's reasonable to say that DKIM signers shouldn't sign a message with an extra From or Subject header, and verifiers shouldn't say the signature on such a message is good, even if it validates technically. I dug through my message archives last week, and I don't think I've ever seen a legit message with that flaw, so it's hard to think of a reason to cut such messages any slack. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
On 10/24/10 9:05 PM, Murray S. Kucherawy wrote: > > Here’s my proposal for a section in Security Considerations to talk > about the malformation issues that have been discussed on the list. > This is an addition to -02 directly and does not continue from any of > the other proposals. > > 8.14 Malformed Inputs > > The universe of email is replete with software that forgives messages > which do not conform strictly to the grammar that defines what valid > email looks like. This is a long-standing practice known informally as > the robustness principle, originally coined by Jon Postel: “Be > conservative in what you do, be liberal in what you accept from others.” > > A number of popular email packages, including MTAs, MLMs, MUAs and so > forth, thus forgive or ignore properties of messages that deviate from > the standard format. A frequent example involves violations of Section > 3.6 of [MAIL] which specifies minimum and maximum counts for > particular header fields. Thus, a message with more than one From or > Subject header field is not a legal email message, but most packages > apply some trivial heuristic, e.g. use the first one and ignore the > others, to interfere minimally with delivery of mail that might still > be desirable to end users. > > This can expose those packages to subtle abuse vectors. For example, > two different handlers of a message might identify the Subject field > of a message by choosing the first one it finds. This would always > produce the same result, regardless of whether the search is top-down > or bottom-up, unless a message had more than one Subject field. > Although [MAIL] specifically disallows this instance, it is tolerated > by many mail handling agents, and so the possibility of confusion > among implementations exists. > > This case becomes more interesting when one considers that a filtering > agent might make a filtering decision based on one header field > instance but a user agent might display the other. Knowing that this > is the case, an attacker seeking to fool a user might exploit this to > get past filters and render false data to a user. > > DKIM exacerbates this concern by assigning a signature to part or all > of a message. It is possible that one could craft a message conforming > to [MAIL], then affix a DKIM signature to it, and then add header > fields atop the message that were not signed. Since many agents will > overlook the fundamental invalidity of such a message, a DKIM verifier > might produce a “valid signature” result while some other agent > assumes an unsigned field is valid and applies it (e.g., renders it to > a user) alongside some indication attesting to the message’s validity. > This is especially concerning where one of the fields in question has > to do with an identity, such as From or Sender. > > Because of this, DKIM implementers are strongly advised to apply one > or more of the following design decisions: > > 1) During the handling of a message in conjunction with a DKIM result > that indicates a valid signature, consider as valid only those fields > and the body portion that was covered by the signature. Note that this > is not to say unsigned content is not valid, but merely that the > signature is making no statement about it. > Bad advice. There is no other email component that can be relied upon to restore flawed DKIM verification results, nor should DKIM relegate determination of DKIM result validity to subsequent consumers. This would be expecting all subsequent stages of email, represented by thousands of different applications, to repeat tests that now MUST be made to mitigate exploits. Without a MUST requirement in the verification process with respect to multiple From header fields, no DKIM results can be trusted for subsequent display or sorting processing. Nor should these processes be expected to conform with the DKIM bottom-up selection of headers that MUST be singular to be compliant with RFC5322. > > 2) Refuse outright to sign or verify any message that is not > syntactically valid. > Good advice. However, without a MUST normative language, DKIM results will be prone to attack. It is not reasonable to suggest consumers of DKIM results check "something" "somewhere". This is NOT about enforcing compliance, this is about ensuring safe and actionable DKIM results. This can only be specified by the DKIM protocol. While lack of RFC5322 compliance might go unnoticed, a DKIM verifier MUST NEVER indicate a message with multiple From headers receive a PASS.Policy components could then indicate specific message handling. > > 3) For any header field listed in Section 3.6 of [MAIL] as having an > upper bound on the number of times it can appear, include the name of > that field one extra time in the “h=” portion of the signature to > prevent addition of fraudulent instances. Any attachment of such > fields after signing would thus invalidate the signature (see Sect
Re: [ietf-dkim] the usual misunderstanding about what DKIM promises
On 10/23/10 12:25 PM, Barry Leiba wrote: > On Fri, Oct 22, 2010 at 10:13 PM, Hector Santos wrote: >> John Levine wrote: > DKIM makes no statement about the validity of a "sender" address. > d/ I guess I should have said Author address. >>> DKIM makes no statement about the validity of an Author address. >> I keep reading this but there is no technical merit to show there is >> any truth to it, and in fact the only thing that is probably the >> strongest validity is the Author Address. >> >> No matter how many times it is stated and repeated, it will never be >> true. If one wants this to be true, then remove the required binding >> the Author Address, A.K.A 5322.From. > No, not at all. While I think it was probably a mistake to make the > signing of ANY header fields "MUST" (we should have just put "From" in > with the other "SHOULD" fields), the fact that "From" MUST be signed > says, in itself, nothing about the *validity* of the address (nor the > display name) in that field. That's up to the signer. Agreed, but DKIM at a minimum, requires the binding of the From header field with that of the signature. Many consumers of DKIM results may rely upon this binding as a basis to extend trust of a signature to include the From header field for trustworthy sorting or display. The signing domain, through an Out of Band method, may make assurances about the From header field as having been authenticated to protect a sorting or display process. Wherever the DKIM verification process occurs, it MUST ensure there is only a single From header field to protect these results from being trivially exploited. > It's all a question of what the signer is willing to sign. I have two > submission domains that I use. One, gmail.com, which does DKIM > signing, will only allow me to use a "From" address after it has sent > a test message to that address and seen that I can access the test > message. So it's made *some* level of confirmation that I owned the > address at the time I set it up. But there's no confirmation that I > still own the address, and there's certainly no assessment of the > display name that I associate with it. Gmail will sign mail that I > send with my old IBM addresses in the "From", though I have not worked > for IBM for over a year and a half, and no longer have any > authorization from IBM to use those addresses. > > Is that "valid"? At no time will the name be signed by IBM. Identification depends upon each domain's name reuse policy.Some domains do not allow names to be reused for this reason. If IBM were to decide to reuse your old email address for a different employee, they then risk having this name confused with the original holder of the email address. The same problem occurs for mailing-lists and other methods that depend upon seeing the same email-address. > But that's all outside the scope of DKIM. DKIM only provides > assurance of the *signing* domain, and that the message has arrived > substantially unchanged from when it was signed (modulo h= and c=). Agreed. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
On 10/25/10 2:12 PM, Steve Atkins wrote: > On Oct 25, 2010, at 1:58 PM, Murray S. Kucherawy wrote: >> Isn't the more interesting attack a signature from some throwaway domain >> that covered a matching From: but also contained a From: indicating some >> high-value phish target? > Not really, no. Signing the From: field means nothing other than that it is > the same as when it was sent. > > I can sign mail with d=blighty.com and "From: doola...@ebay.com" without > needing to play any games with multiple headers > > > The only interesting attack in this entire situation is the ability to take a > message signed by a high-reputation domain, so that it'll get delivered to > the inbox, and to replace the Subject: (and possibly From:) with your own > payload. Disagree. It could be signed by a large domain that is unlikely blocked, where the high value domain can then be spoofed because of a poorly defined DKIM verification process, regardless where the DKIM verification process happens to be located. It's also not specific to MUAs. Filtering agents can be similarly duped. >>> They can, yes, though I'm not sure that's needed to explain why this >>> may be a bad thing to allow. >> Focusing on the MUA case might inadvertently suggest to implementers of >> other components that this is not a concern for them. > True. Though it really shouldn't be a significant concern for them, as > filtering agents that are DKIM aware (should anyone create such a thing) and > have a valid DKIM identity will likely use that in preference to, say, the > From: field. And if the filtering agent is not DKIM aware, it's not an issue. DKIM verification is still DKIM verification regardless where this process is located. Stop hand waving. This process MUST be correctly defined to protect the consumers of these results. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
On Oct 25, 2010, at 1:58 PM, Murray S. Kucherawy wrote:
>> -Original Message-
>> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
>> On Behalf Of Steve Atkins
>> Sent: Monday, October 25, 2010 12:54 PM
>> To: IETF DKIM WG
>> Subject: Re: [ietf-dkim] Proposal for new text about multiple header issues
>>
>>> I'd strike "during a replay attack" because, as some have noted, the
>>> attack can be constructed deliberately on an original message.
>>
>> The real risk here is that someone can present a message as signed by
>> someone trustworthy that has content different to that which was
>> provided by the trusted signer. If the entity adding the additional
>> content is the original signer, it may be a message composition bug,
>> but it's not really any sort of attack on DKIM.
>>
>> Striking "replay attack" might make it less clear what the actual risk
>> is, rather than more clear.
>>
>> ("... can be abused, e.g. during a replay attack, by adding ..." ?)
>
> Isn't the more interesting attack a signature from some throwaway domain that
> covered a matching From: but also contained a From: indicating some
> high-value phish target?
Not really, no. Signing the From: field means nothing other than that it is the
same as when it was sent.
I can sign mail with d=blighty.com and "From: doola...@ebay.com" without
needing to play any games with multiple headers
The only interesting attack in this entire situation is the ability to take a
message signed by a high-reputation domain, so that it'll get delivered to the
inbox, and to replace the Subject: (and possibly From:) with your own payload.
>
>>> It's also not specific to MUAs. Filtering agents can be similarly
>>> duped.
>>
>> They can, yes, though I'm not sure that's needed to explain why this
>> may be a bad thing to allow.
>
> Focusing on the MUA case might inadvertently suggest to implementers of other
> components that this is not a concern for them.
True. Though it really shouldn't be a significant concern for them, as
filtering agents that are DKIM aware (should anyone create such a thing) and
have a valid DKIM identity will likely use that in preference to, say, the
From: field. And if the filtering agent is not DKIM aware, it's not an issue.
Cheers,
Steve
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] wildcards, was Focusing on 4871bis
John, The reported issue was about *mixed* TXT usage caused by wildcards. And it amounted to a large Domain Hosting vendor ONLY offering this for spf: *.example.com IN TXT "v=spf1 .." And that created mixed query results after adding DKIM related TXT records. The proposed correction text is a) reminder to avoid using them and b) for verifiers to be ready to deal with it. i.e. be able to parse for the right DKIM related text string. -- HLS John R. Levine wrote: >>> Forgive me if I repeat myself, but I still don't see anything wrong >>> with this: > >>> *._domainkey.example.com IN TXT "v=DKIM1; p=; n=revoked" > >> Do you have an actual use case for that sort of thing, or is it just >> an example to poke at the "thou shalt not wildcard" wording? > > That example above revokes all unknown keys. > > On this message, I've encoded a timestamp and the pid into the DKIM > signature selector, so I can use my DNS query logs to get an idea of > who's checking the signatures on what messages. > > These may not be fabulous uses of wildcards, but they are at worst > harmless. There's a lot of places in the DKIM spec where we say if you > do so-and-so, you'll be sorry. I'd like to avoid saying that unless we > have a good reason to do so, and I only see problems with wildcards > above the _domainkey label. > > Regards, > John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for > Dummies", > Please consider the environment before reading this e-mail. http://jl.ly > > > > > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of Steve Atkins
> Sent: Monday, October 25, 2010 12:54 PM
> To: IETF DKIM WG
> Subject: Re: [ietf-dkim] Proposal for new text about multiple header issues
>
> > I'd strike "during a replay attack" because, as some have noted, the
> > attack can be constructed deliberately on an original message.
>
> The real risk here is that someone can present a message as signed by
> someone trustworthy that has content different to that which was
> provided by the trusted signer. If the entity adding the additional
> content is the original signer, it may be a message composition bug,
> but it's not really any sort of attack on DKIM.
>
> Striking "replay attack" might make it less clear what the actual risk
> is, rather than more clear.
>
> ("... can be abused, e.g. during a replay attack, by adding ..." ?)
Isn't the more interesting attack a signature from some throwaway domain that
covered a matching From: but also contained a From: indicating some high-value
phish target?
> > It's also not specific to MUAs. Filtering agents can be similarly
> > duped.
>
> They can, yes, though I'm not sure that's needed to explain why this
> may be a bad thing to allow.
Focusing on the MUA case might inadvertently suggest to implementers of other
components that this is not a concern for them.
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
On Oct 25, 2010, at 12:19 PM, Murray S. Kucherawy wrote:
>> -Original Message-
>> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
>> On Behalf Of Steve Atkins
>> Sent: Monday, October 25, 2010 9:56 AM
>> To: IETF DKIM WG
>> Subject: Re: [ietf-dkim] Proposal for new text about multiple header issues
>>
>> 8.14 Malformed Inputs
>>
>> DKIM allows additional headers to be added to a signed message without
>> breaking the signature. This tolerance can be abused during a replay
>> attack by adding additional copies of headers that are displayed to the
>> end user, such as From or Subject, to an already signed message in a
>> way that doesn't break the signature.
>
> I'd strike "during a replay attack" because, as some have noted, the attack
> can be constructed deliberately on an original message.
The real risk here is that someone can present a message as signed by someone
trustworthy that has content different to that which was provided by the
trusted signer. If the entity adding the additional content is the original
signer, it may be a message composition bug, but it's not really any sort of
attack on DKIM.
Striking "replay attack" might make it less clear what the actual risk is,
rather than more clear.
("... can be abused, e.g. during a replay attack, by adding ..." ?)
> I'd also probably want to include some of my original text that sets up why
> various agents are so permissive today.
I'm not sure the history adds anything, and briefer tends to lead to a clearer
call to action.
(And it annoys Mark, and may be continuing a misinterpretation of the
robustness principle and...).
>> The resulting message violates section 3.6 of [MAIL] so the way it will
>> be handled and displayed by an MUA is unpredictable - but in some cases
>> they will display the newly added headers rather than those that are
>> part of the originally signed message. This might allow an attacker to
>> replay a previously sent, signed message with a different Subject,
>> From or To field.
>
> It's also not specific to MUAs. Filtering agents can be similarly duped.
They can, yes, though I'm not sure that's needed to explain why this may be a
bad thing to allow.
>
>> 1) Rejecting or treating as suspicious any message that has multiple
>> copies of headers that are disallowed by section 3.6 of [MAIL],
>> particularly those that are displayed to the end user (From, To, Cc,
>> Subject).
>>
>> 2) Treating any message that has multiple copies of headers that are
>> disallowed by section 3.6 of [MAIL] as not DKIM signed.
>
> These almost say the same thing to me. For example, "treat as unsigned"
> could be rolled into "treat as suspicious". And I'd prefer to show 3.6 as an
> example of a more general problem, in case later some vector is found using
> MIME.
They're somewhat different. The first case involves recognizing that such
messages are likely an attempt to be deceitful, and hence that the mail is
unwanted. It's an approach that affects parts of the mail delivery system
outside of DKIM, and will directly affect mail routing and delivery, and so can
only be implemented by a broader system architect, not by a DKIM implementor.
The second simply removes the DKIM-related benefit to this sort of attempt at
deceit, removing the benefit of doing it. It doesn't make any broader
judgement, and it can be handled entirely inside the DKIM verifier, without
having any behavior change in the rest of the mail system, other than that
implied by a lack of signature.
> And I'd prefer to show 3.6 as an example of a more general problem, in case
> later some vector is found using MIME.
I'd prefer to stick to actual concerns, for now - stressing theoretical risks
for which we have no idea how they could be implemented is a slippery slope.
(I'm assuming that "l=" is going to be removed - if not, that would change
things considerably as far as the likelihood of some sort of mime-related body
change).
> If you concur, I'll take another run at it.
Sure.
Cheers,
Steve
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] wildcards, was Focusing on 4871bis
Forgive me if I repeat myself, but I still don't see anything wrong with this: *._domainkey.example.com IN TXT "v=DKIM1; p=; n=revoked" Do you have an actual use case for that sort of thing, or is it just an example to poke at the "thou shalt not wildcard" wording? That example above revokes all unknown keys. On this message, I've encoded a timestamp and the pid into the DKIM signature selector, so I can use my DNS query logs to get an idea of who's checking the signatures on what messages. These may not be fabulous uses of wildcards, but they are at worst harmless. There's a lot of places in the DKIM spec where we say if you do so-and-so, you'll be sorry. I'd like to avoid saying that unless we have a good reason to do so, and I only see problems with wildcards above the _domainkey label. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly smime.p7s Description: S/MIME Cryptographic Signature ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Steve Atkins > Sent: Monday, October 25, 2010 9:56 AM > To: IETF DKIM WG > Subject: Re: [ietf-dkim] Proposal for new text about multiple header issues > > 8.14 Malformed Inputs > > DKIM allows additional headers to be added to a signed message without > breaking the signature. This tolerance can be abused during a replay > attack by adding additional copies of headers that are displayed to the > end user, such as From or Subject, to an already signed message in a > way that doesn't break the signature. I'd strike "during a replay attack" because, as some have noted, the attack can be constructed deliberately on an original message. I'd also probably want to include some of my original text that sets up why various agents are so permissive today. > The resulting message violates section 3.6 of [MAIL] so the way it will > be handled and displayed by an MUA is unpredictable - but in some cases > they will display the newly added headers rather than those that are > part of the originally signed message. This might allow an attacker to > replay a previously sent, signed message with a different Subject, > From or To field. It's also not specific to MUAs. Filtering agents can be similarly duped. > 1) Rejecting or treating as suspicious any message that has multiple > copies of headers that are disallowed by section 3.6 of [MAIL], > particularly those that are displayed to the end user (From, To, Cc, > Subject). > > 2) Treating any message that has multiple copies of headers that are > disallowed by section 3.6 of [MAIL] as not DKIM signed. These almost say the same thing to me. For example, "treat as unsigned" could be rolled into "treat as suspicious". And I'd prefer to show 3.6 as an example of a more general problem, in case later some vector is found using MIME. If you concur, I'll take another run at it. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Statistics about DKIM and MIME
On 10/25/2010 10:01 AM, Murray S. Kucherawy wrote: In the particular case of multipart/signed there were 106 messages where the RSA verification failed, but 122 where it passed but the body hash at the verifier didn't match the one in the signature. So more failures occur from body changes than do from header changes. This smells suspiciously like middle boxen doing HIPAA-like things with SMIME. Let's just blame Jon Callas :) Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Statistics about DKIM and MIME
On Oct 25, 2010, at 8:07 AM, John R. Levine wrote: >> The one that stands out is "multipart/signed" (from RFC1847) which drops to >> about a 65% survival rate. I don't know much about how this is typically >> formatted or treated enroute, but it was easily the biggest outlier in the >> report. Not sure if that should be a surprise to us or not. > > I'm surprised. That suggests something often adds the S/MIME signature after > the DKIM signature, but as far as I know, S/MIME signatures are usually > applied by the MUA. Someone was hawking a box to sign and verify RFC 2015 PGP signatures at the enterprise firewall a few years back. That'd break DKIM signatures with a multipart/signed outermost type. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Conspicuously absent statistics
Well, actually, not so conspicuous since nobody pointed it out yet... Our stats stuff is reporting absolutely nothing so far about use of "i=". I just posted a patch release that includes some code to start collecting this, and one of our sites has already rolled it out. After we've had some time to collect some numbers, I'll provide some information about what we're seeing in the wild with respect to use of "i=". ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] wildcards, was Focusing on 4871bis
On Oct 25, 2010, at 8:11 AM, John R. Levine wrote: hangText="NOTE:"> The use of wildcard TXT records in the DNS will produce a response to a DKIM query that is unlikely to be valid DKIM key record. This problem applies to many other types of queries, and client software that processes DNS responses needs to take this problem into account. >>> >>> I haven't heard anything but support for adding that. > > Forgive me if I repeat myself, but I still don't see anything wrong with this: > > *._domainkey.example.com IN TXT "v=DKIM1; p=; n=revoked" > > I'm trying to figure out the clearest way to say that wildcards for key > records within the _domainkey subtree are OK, while wildcards above it cause > problems since they are very unlikely to be key records. Do you have an actual use case for that sort of thing, or is it just an example to poke at the "thou shalt not wildcard" wording? If the former, I've got a mild argument that it's slightly poor practice. If the latter, carry on. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] wildcards, was Focusing on 4871bis
On 10/25/2010 10:26 AM, Eliot Lear wrote: > Won't be visible because you are querying what amounts to a > specific application through the use of the label. ... > There should be no other existing records, and if so, they're > there to override the wildcard. Right. The underscore naming construct really is impressively useful for eliminating all sorts of scaling and interaction problems... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] wildcards, was Focusing on 4871bis
On 10/25/10 5:11 PM, John R. Levine wrote: > > Forgive me if I repeat myself, but I still don't see anything wrong > with this: > > *._domainkey.example.com IN TXT "v=DKIM1; p=; n=revoked" > > I'm trying to figure out the clearest way to say that wildcards for > key records within the _domainkey subtree are OK, while wildcards > above it cause problems since they are very unlikely to be key records. Going through my list of arguments I'm coming up short. Let's see: 1. Dangerous to other applications. Nope. Won't be visible because you are querying what amounts to a specific application through the use of the label. 2. Doesn't work with existing records Nope. There should be no other existing records, and if so, they're there to override the wildcard. 3. ??? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Statistics about DKIM and MIME
> -Original Message- > From: John R. Levine [mailto:jo...@iecc.com] > Sent: Monday, October 25, 2010 8:07 AM > To: Murray S. Kucherawy > Cc: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] Statistics about DKIM and MIME > > > The one that stands out is "multipart/signed" (from RFC1847) which drops > > to about a 65% survival rate. I don't know much about how this is > > typically formatted or treated enroute, but it was easily the biggest > > outlier in the report. Not sure if that should be a surprise to us or not. > > I'm surprised. That suggests something often adds the S/MIME signature > after the DKIM signature, but as far as I know, S/MIME signatures are > usually applied by the MUA. > > Do the stats say what kind of failure it was, e.g. body hash or header > hash? Actually it's worse than I said originally. We track pass/fail in two bits, one being whether or not the crypto lined up and the other being whether or not the body hashes matched. Thus, it's possible to get a "pass" coupled with a body hash change. I had only selected for the first bit. So here are the stats again. The first column is obviously the media type; the second is the count of signatures covering a message with that type as the outermost MIME part; the third column is the number of those that passed in both the crypto and the body hash sense, and the fourth is the pass percentage. application/ms-tnef 26 23 88.5% application/pdf 16 16 100% message/disposition-notification 10 10 100% message/rfc8222 2 100% multipart/alternative 290865 265270 91.2% multipart/mixed 38509 35370 91.8% multipart/related 7959714989.8% multipart/report 958 883 92.2% multipart/signed 314 86 27.4% text 13 13 100% text/calendar 34 32 94.1% text/html 63144 55880 88.5% text/plain72195 55415 76.8% In the particular case of multipart/signed there were 106 messages where the RSA verification failed, but 122 where it passed but the body hash at the verifier didn't match the one in the signature. So more failures occur from body changes than do from header changes. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
On Oct 24, 2010, at 10:50 PM, Murray S. Kucherawy wrote: >> -Original Message- >> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] >> On Behalf Of Steve Atkins >> Sent: Sunday, October 24, 2010 10:36 PM >> To: IETF DKIM WG >> Subject: Re: [ietf-dkim] Proposal for new text about multiple header issues >> >> That still expands the API from the DKIM verifier quite a lot - it >> requires the verifier to explicitly list which headers are signed, and >> which aren't (that the h= field doesn't do that is what we're having >> problems with). It would also require that to be pushed all the way >> downstream to other pieces of software, perhaps via something similar >> to an extended Authentication-Results type of header. >> >> That's not impossible, but seems very complex for the specific problem >> we're considering - we just need to communicate "This message violated >> 5322, specifically in a way that makes us think the sender is trying to >> game DKIM" (either by flagging the mail as syntactically invalid and >> suspicious at some point in the mail stream, or invalidating the DKIM >> signature). >> [...] > > You seem to have some specific ideas in mind already. Can you propose some > alternate text? Sure. Taking into account some of the other feedback too: --- 8.14 Malformed Inputs DKIM allows additional headers to be added to a signed message without breaking the signature. This tolerance can be abused during a replay attack by adding additional copies of headers that are displayed to the end user, such as From or Subject, to an already signed message in a way that doesn't break the signature. The resulting message violates section 3.6 of [MAIL] so the way it will be handled and displayed by an MUA is unpredictable - but in some cases they will display the newly added headers rather than those that are part of the originally signed message. This might allow an attacker to replay a previously sent, signed message with a different Subject, From or To field. Because of this, inbound mail system implementors should consider defending against this sort of replay attack by either 1) Rejecting or treating as suspicious any message that has multiple copies of headers that are disallowed by section 3.6 of [MAIL], particularly those that are displayed to the end user (From, To, Cc, Subject). 2) Treating any message that has multiple copies of headers that are disallowed by section 3.6 of [MAIL] as not DKIM signed. Senders who feel that their messages might be particularly vulnerable to this sort of attack who don't want to rely on receiver filtering of invalid messages can ensure that adding additional headers will break their DKIM signature by including two copies of the headers they're concerned about in the signature (e.g. "h= ... from:from:to:to:subject:subject ...). See section 3.5 and 5.4 for further discussion. --- It's significantly less subtle than your phrasing, but I think bluntness and clarity win out for a security discussion. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
On 10/25/2010 8:16 AM, Ian Eiloart wrote: > Actually, my verifier produces two bits: one for the headers, and one for > the body. In terms of authentication, that might not mean much. It is > useful for debugging, though. We need to be careful to distinguish between software and protocol. Software is free to do whatever it wants. The DKIM Signing specification, however, deals with constrained, standardized behavior. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
--On 24 October 2010 22:10:34 -0700 Steve Atkins wrote: > > A DKIM verifier generates a single bit, "validly signed or not", > and an identifier in the "validly signed" case. Actually, my verifier produces two bits: one for the headers, and one for the body. In terms of authentication, that might not mean much. It is useful for debugging, though. It also says if the public key was unavailable, or contained a syntax error: For what it's worth, today, on one cluster, I see these counts: 12 invalid - public key record (currently?) unavailable 19 invalid - syntax error in public key record 31 verification failed - body hash mismatch (body probably modified in transit) 285 verification failed - signature did not verify (headers probably modified in transit) 1776 verification succeeded -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] wildcards, was Focusing on 4871bis
hangText="NOTE:"> The use of wildcard TXT records in the DNS will produce a response to a DKIM query that is unlikely to be valid DKIM key record. This problem applies to many other types of queries, and client software that processes DNS responses needs to take this problem into account. I haven't heard anything but support for adding that. Forgive me if I repeat myself, but I still don't see anything wrong with this: *._domainkey.example.com IN TXT "v=DKIM1; p=; n=revoked" I'm trying to figure out the clearest way to say that wildcards for key records within the _domainkey subtree are OK, while wildcards above it cause problems since they are very unlikely to be key records. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly smime.p7s Description: S/MIME Cryptographic Signature ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Statistics about DKIM and MIME
The one that stands out is "multipart/signed" (from RFC1847) which drops to about a 65% survival rate. I don't know much about how this is typically formatted or treated enroute, but it was easily the biggest outlier in the report. Not sure if that should be a surprise to us or not. I'm surprised. That suggests something often adds the S/MIME signature after the DKIM signature, but as far as I know, S/MIME signatures are usually applied by the MUA. Do the stats say what kind of failure it was, e.g. body hash or header hash? Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly smime.p7s Description: S/MIME Cryptographic Signature ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
On 10/25/2010 7:47 AM, John Levine wrote: >> A DKIM verifier generates a single bit, "validly signed or not", >> and an identifier in the "validly signed" case. > > Well, actually, if you read 4871, it also produces an edited version > of the message. Please cite the text in the specification that defines this output process and/or result. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
>> The thought is that two Subject lines is worth rejecting, an extra at >> sign in the Message-ID is not. > >I'm fine with that if we think implementers will find it easier to construct a >comprehensive "likely" list versus just enforcing the spec. It's not easier but I'm with Steve here. People are not likely to implement a spec that says that verifiers fail due to trivial syntax errors in the message. At this point, the only things I'm aware of that present a risk of bad rendering are duplicate headers and l= that doesn't cover the whole message. That list may grow in the future, but I doubt it will grow very fast. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
>A DKIM verifier generates a single bit, "validly signed or not", >and an identifier in the "validly signed" case. Well, actually, if you read 4871, it also produces an edited version of the message. As I suggested in my message a few days ago, I don't think that's what we intended, and we should fix 4871bis so it doesn't say that any more. > And that makes DKIM overall a poor place to do anything other than >mention specific issues that directly affect the DKIM security model. Agreed. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Statistics about DKIM and MIME
On 10/25/10 1:31 PM, Rolf E. Sonneveld wrote: Hi, Murray, On 10/25/10 6:21 AM, Murray S. Kucherawy wrote: OpenDKIM now has enough data to make some interesting observations about signatures and MIME. As far as MIME encodings go (only the "outermost" encoding was counted), there was a pretty common theme: binary failed 4% of the time quoted-printable failed 4% of the time 7bit failed 7.7% of the time base64 failed 7.8% of the time 8bit failed 14% of the time 16bit (?!) never failed (though there was only one attempt) I expected 8bit to fail more for some reason. Interesting figures. Especially the 16bit ;-) As far as MIME parts go (again, only the "outermost" MIME type was counted), most of them have about a 90-93% survival rate which is about in line with general signature survival rates. This still leaves the question open whether there is any relation between MIME labelling and -content transfer encoding, or none at all. Clarification: it was my intention to say: [...] between MIME labelling and -content transfer encoding on one side, and DKIM signature 'survival' on the other side. Or no relationship at all. /rolf ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Statistics about DKIM and MIME
Hi, Murray, On 10/25/10 6:21 AM, Murray S. Kucherawy wrote: OpenDKIM now has enough data to make some interesting observations about signatures and MIME. As far as MIME encodings go (only the "outermost" encoding was counted), there was a pretty common theme: binary failed 4% of the time quoted-printable failed 4% of the time 7bit failed 7.7% of the time base64 failed 7.8% of the time 8bit failed 14% of the time 16bit (?!) never failed (though there was only one attempt) I expected 8bit to fail more for some reason. Interesting figures. Especially the 16bit ;-) As far as MIME parts go (again, only the "outermost" MIME type was counted), most of them have about a 90-93% survival rate which is about in line with general signature survival rates. This still leaves the question open whether there is any relation between MIME labelling and -content transfer encoding, or none at all. The one that stands out is "multipart/signed" (from RFC1847) which drops to about a 65% survival rate. I'm not sure whether 'survival' is the correct term in your report. I assume you mean percentages of DKIM signatures that verify correctly as seen by the verifier? The other 7-10% of signatures can also come from Bad Actors who replay signatures with different content of the message. It is possible they arrive unchanged at the verifier and then fail verification, but that doesn't mean the (replayed) DKIM signature did not 'survive'. I don't know much about how this is typically formatted or treated enroute, but it was easily the biggest outlier in the report. Not sure if that should be a surprise to us or not. In general the fundamental question here is indeed about survival rate: what is the real and 'exact' percentage of messages, signed by domain example.com that still verifies correctly after n hops by the verifier where n = 1,2,3,4... /rolf ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] the usual misunderstanding about what DKIM promises
--On 22 October 2010 22:13:13 -0400 Hector Santos wrote: > John Levine wrote: DKIM makes no statement about the validity of a "sender" address. d/ >>> I guess I should have said Author address. >> >> DKIM makes no statement about the validity of an Author address. > > I keep reading this but there is no technical merit to show there is > any truth to it, and in fact the only thing that is probably the > strongest validity is the Author Address. Actually, it depends on what one means by "validity". If one simply means that the author address hasn't been modified since the message was signed, then DKIM does speak to the validity. If one means that the author address was used with the permission of the owner of the address, then a DKIM signature helps only if you know something about the signer. The likelihood of the author address being used with permission of the author will increase if signers make efforts to forbid domain spoofing. However, there's always the possibility that an account has been compromised, for example by a phisher. > No matter how many times it is stated and repeated, it will never be > true. If one wants this to be true, then remove the required binding > the Author Address, A.K.A 5322.From. > > I will go on to suggest that this ongoing design confusion of trying > to water it down with unrestricted resigners is what got this WG all > bogged down in trying to teach the world that the From really means > nothing but only the signer does. It even reduces the incentive for > adopters to invest in Domain DKIM Signing because they really have no > power over controlling who can take control of their own messages or > those that purports to be from them. They have really little payoff. > > My point is it really hasn't help DKIM to continue to water down the > validity of the author address. If it wasn't a required binding, then > there begins some truth to the statement. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Focusing on 4871bis
--On 22 October 2010 11:23:16 -0700 "Murray S. Kucherawy" wrote: >> This is what is in the pending -03 draft in section 6.1.2: >> >>> hangText="NOTE:"> The use of wildcard TXT records in the >> DNS will produce a response to a DKIM query that is >> unlikely to be valid DKIM key record. This problem >> applies to many other types of queries, and client >> software that processes DNS responses needs to take this >> problem into account. > > I haven't heard anything but support for adding that. > > Nit: s/will/can/ More Nit: It should probably say either "will produce a response…that is unlikely", or "can produce a response…that is not". The former states that the problem will occur frequently, the latter says nothing about the frequency, but readers may infer that the problem will be infrequent. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] the usual misunderstanding about what DKIM promises
On 23/Oct/10 21:25, Barry Leiba wrote: > DKIM makes no statement about the validity of a "sender" address. >>> >>> DKIM makes no statement about the validity of an Author address. >> >> No matter how many times it is stated and repeated, it will never be >> true. If one wants this to be true, then remove the required binding >> the Author Address, A.K.A 5322.From. > > No, not at all. While I think it was probably a mistake to make the > signing of ANY header fields "MUST" (we should have just put "From" in > with the other "SHOULD" fields), the fact that "From" MUST be signed > says, in itself, nothing about the *validity* of the address (nor the > display name) in that field. That's up to the signer. A way to clarify this point is to say /why/ From MUST be signed. For simplicity, I restrict my guessing to two possible reasons: A) From MUST be signed because assuming that h= is not empty may simplify something. The "From" header was chosen somewhat randomly among fields that would have deserved a SHOULD anyway. B) DKIM mandates signing From in order to pave the way for ADSP. Indeed, ADSP semantics is largely anticipated in DKIM, although not specified in the details. The latter reason would require normative text to guard against double fields in 4871bis, for consistency with RFC 4871's implicit assumptions. IMHO, the new text in Murray's proposal would be easier to understand if reason A, Barry's quoted paragraph above, or any similar informal explanation were also added to the draft. > Gmail will sign mail that I send with my old IBM addresses in the > "From", though I have not worked for IBM for over a year and a > half, and no longer have any authorization from IBM to use those > addresses. > > Is that "valid"? Yes, in the sense that it is what the Author choose. More precisely: The originator fields indicate the mailbox(es) of the source of the message. The "From:" field specifies the author(s) of the message, that is, the mailbox(es) of the person(s) or system(s) responsible for the writing of the message. It doesn't have to be a working mailbox, e.g. nore...@example.com. The responsibility that a signer claims may be delegated, e.g. "I make no attempt at all to control my users' From: lines, since I know them all and don't expect them to misbehave." Even syntactical validity checks may be delegated to the Author's client, according to message submission policies. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
