Re: [ietf-dkim] Pete's review of 4871bis

2011-07-01 Thread Douglas Otis 
On 6/30/11 9:53 AM, Murray S. Kucherawy wrote:
>> -Original Message-
>> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
>> On Behalf Of Charles Lindsey
>> Sent: Thursday, June 30, 2011 7:05 AM
>> To: DKIM
>> Subject: Re: [ietf-dkim] Pete's review of 4871bis
>>
>> The problem is that an apparently valid signature (albeit atching the
>> wrong From) is likely to give a false impression of validity somewhere
>> along the line unless modules down the line are watchig for this case (and
>> for sure MUAs will not be watching for it for a long time, so it is the
>> ISPs/boundary agents that need to do it).
> If the advent of DKIM means that numerous modules implementing other 
> specifications loosely suddenly have to pay a price for doing so, then that's 
> the reality, and I still don't see how that's a problem DKIM needs to fix.  
> Sure, we need to document the nuances DKIM introduces, but it's still not an 
> attack against DKIM, so this remains the wrong place to deal with it in a 
> normative sense.
>
> If you prefer the loose application of other standards, don't use DKIM (and 
> lose out on its benefits).
Murray,

DKIM is not enforcing RFC5322's format.  Nor is it reasonable to expect 
that SMTP has either.

It is reasonable to expect security related protocols validate input.  
Whether a message gets rejected or dropped is immaterial.  For DKIM's 
output to be usable, it must be clear what was signed without expecting 
subsequent message handlers to adopt bottom-up selection.  Otherwise, 
DKIM can not be safely deployed in an incremental fashion as claimed in 
its introduction.

-Doug



___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Pete's review of 4871bis

2011-07-01 Thread Douglas Otis 
On 6/29/11 11:49 AM, Pete Resnick wrote:
> On 6/29/11 11:20 AM, Charles Lindsey wrote:
>> I agree that 8.14 is poorly written (and it was even worse a while back).
>> However, there most certainly IS an attack here, which is NOT the same as
>> the related attack discussed in 8.15, and cannot be prevented by putting
>> extra entries in the 'h=' tag. Unfortunately, many WG members have failed
>> to understand the difference between the two. Here is the attack,
>> described in plain terms:
>>
>>
>> A phisher obtains a throwaway domain and creates a public/private key pair
>> for
>> it. He then sends messages of the following form:
>>
>> 
>>
>> To: some.sucker@anywhere.example
>> From: eBay
>> Date: Tue, 17 May 2011 13:21:06 +0100
>> Subject: Some plausible Ebay subject
>> 
>> From: a.phisher@mythrowayawdomain.example
>> DKIM-Signature: v=1; a=rsa-sha256; d=mythrowayawdomain.example;
>>  h=from:to:subject:date; ... b=
>>
>> Body of message of typical Phish style.
>>
>> -
>>
>> A compliant DKIM verifier will report that as a validly signed message.
> The second From field is absolutely irrelevant in the example. The
> phisher could simply leave out the From field with their address in it
> and sign the ebay From field.
>
> And that's not an attack. The signer signed the message and the
> signature verifies. *DKIM* has done its job successfully and has not
> been attacked. DKIM communicates from the signer to the verifier. The
> signer *can't* attack itself. You *might* characterize this as an attack
> against 5322 (in that From addresses are not bound in any secure way to
> the actual author), but DKIM does not even attempt to address that
> attack, so it's not an attack against DKIM. You go on to say something
> that is an attack, but again you get the analysis wrong:
>
>> The
>> Ebay signature is irrelevant for the signing process (so even if Ebay has
>> declared a "Discardable" ADSP policy it will not be invoked).
> Now *that's* the attack. But it's NOT AN ATTACK ON DKIM! It's an attack
> on ADSP. If ADSP sees the above message and doesn't discard it, then
> ADSP has done the wrong thing. If ADSP has a bug where it thinks it
> ought not discard the above message (with the appropriate policy), then
> that should be fixed. It should certainly be called out in the security
> considerations of ADSP. But it's NOT a security consideration for DKIM.
This is a poor example of a potential problem.  The problem may occur 
whenever email acceptance is predicated upon the signing domain.

When this domain is of sufficient volume where this domain constrains 
the From to being within the same domain or verified by a ping-back, on 
that basis their messages should be safe to accept.  However when 
pre-pended From header fields are not precluded from producing valid 
signatures, (a silent condition) acceptance on the basis of a high 
volume signature would not be safe, whether or not ADSP is applied.
>> Normal
>> readers
>> using current MUAs will see just the From: Ebay header and, believing that
>> their ISP has done some magical cryptographic checks to prevent bogus Ebay
>> messages from getting through, will be reassured.
> Again, the second From is not required for that to happen. If MUAs
> believe that some magical crypto thing happens to a message with
> "d=badguy.example" and "From: ebay" (with no other From's), then they
> get what they paid for.
Agreed.  But then this would not be basing acceptance on the signing domain.
>> The present draft does make some woolly attempts to fix this problem.
>> Section
>> 3.8 says "verifiers SHOULD take reasonable steps to ensure that the
>> messages
>> they are processing are valid according to [RFC5322] ... ". But gives no
>> guidance as to what "reasonable" means (and full RFC5322 compliance
>> checking
>> is notoriously hard). It now refers to to both 8.14 and 8.15, but leaves
>> it to the implelemtor to work out what he needs to do.
> As this conversation has developed (here and off line), I'm getting
> convinced that 3.8 is a red herring. DKIM deals perfectly well with the
> obsolete message format, including multiple From fields. I think the 3.8
> admonition is overblown.
>
>> In my opinion, there needs to be some REQUIRED action in the verifier which
>> will result in a PERMFAIL, and which would then catch all attacks of this
>> nature. But the WG consensus has been against this.
> If the WG is against it, it is correct. This is NOT a PERMFAIL condition
> for DKIM. It is probably a PERMFAIL condition for ADSP, but that's a
> different document.
So much for safe incremental deployment. :^(

-Doug
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Pete's review of 4871bis

2011-06-30 Thread Murray S. Kucherawy 
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
> On Behalf Of Charles Lindsey
> Sent: Thursday, June 30, 2011 7:05 AM
> To: DKIM
> Subject: Re: [ietf-dkim] Pete's review of 4871bis
> 
> The problem is that an apparently valid signature (albeit atching the
> wrong From) is likely to give a false impression of validity somewhere
> along the line unless modules down the line are watchig for this case (and
> for sure MUAs will not be watching for it for a long time, so it is the
> ISPs/boundary agents that need to do it).

If the advent of DKIM means that numerous modules implementing other 
specifications loosely suddenly have to pay a price for doing so, then that's 
the reality, and I still don't see how that's a problem DKIM needs to fix.  
Sure, we need to document the nuances DKIM introduces, but it's still not an 
attack against DKIM, so this remains the wrong place to deal with it in a 
normative sense.

If you prefer the loose application of other standards, don't use DKIM (and 
lose out on its benefits).

___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Pete's review of 4871bis

2011-06-30 Thread Charles Lindsey 
On Wed, 29 Jun 2011 18:31:04 +0100, Murray S. Kucherawy  
 wrote:

>> -Original Message-
>> From: ietf-dkim-boun...@mipassoc.org  
>> [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey
>> Sent: Wednesday, June 29, 2011 9:20 AM
>> To: DKIM
>> Subject: Re: [ietf-dkim] Pete's review of 4871bis
>>
>> I agree that 8.14 is poorly written (and it was even worse a while  
>> back).
>> However, there most certainly IS an attack here, which is NOT the same  
>> as
>> the related attack discussed in 8.15, and cannot be prevented by putting
>> extra entries in the 'h=' tag. Unfortunately, many WG members have  
>> failed
>> to understand the difference between the two.
>
> That's a mischaracterization of the objection.  "h=from:from:..." was  
> not meant to address the attack about which you are complaining.

True, but up to a couple of months ago that was not clear in 8.14/8.15,  
and I suspect some WG members still have not caught up with the  
distinction.

> Nobody has said either of the two variants of this attack are not valid  
> concerns.  The dispute is about what module in the handling of a message  
> is responsible for detecting and dealing with it.

That is true enough, but there is no indication anywhere as to what  
subsequent modules in the chain ARE to be responsible for it, axcept for  
ADSP (and I agree with Pete that it is an attack on ADSP); but the WG  
seems to have washed its hands of ADSP.
>
> Since the problem exists even with a message that is not DKIM-signed, I  
> still fail to understand how this is specifically a DKIM problem.

The problem is that an apparently valid signature (albeit atching the  
wrong From) is likely to give a false impression of validity somewhere  
along the line unless modules down the line are watchig for this case (and  
for sure MUAs will not be watching for it for a long time, so it is the  
ISPs/boundary agents that need to do it).

-- 
Charles H. Lindsey -At Home, doing my own thing
Tel: +44 161 436 6131   
   Web: http://www.cs.man.ac.uk/~chl
Email: c...@clerew.man.ac.uk  Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9  Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Pete's review of 4871bis

2011-06-30 Thread Charles Lindsey 
On Wed, 29 Jun 2011 19:49:27 +0100, Pete Resnick   
wrote:

> On 6/29/11 11:20 AM, Charles Lindsey wrote:

>> A phisher obtains a throwaway domain and creates a public/private key  
>> pair
>> for
>> it. He then sends messages of the following form:
>>
>> 
>>
>> To: some.sucker@anywhere.example
>> From: eBay
>> Date: Tue, 17 May 2011 13:21:06 +0100
>> Subject: Some plausible Ebay subject
>> 
>> From: a.phisher@mythrowayawdomain.example
>> DKIM-Signature: v=1; a=rsa-sha256; d=mythrowayawdomain.example;
>> h=from:to:subject:date; ... b=
>>
>> Body of message of typical Phish style.
>>
>> -
>>
>> A compliant DKIM verifier will report that as a validly signed message.
>>
>
> The second From field is absolutely irrelevant in the example. The
> phisher could simply leave out the From field with their address in it
> and sign the ebay From field.

But not with Ebay's private key, and that would surely get spotted (with  
or without ADSP).
>
> And that's not an attack. The signer signed the message and the
> signature verifies. *DKIM* has done its job successfully and has not
> been attacked. DKIM communicates from the signer to the verifier. The
> signer *can't* attack itself.

Sure, but this is an attack directed against Ebay. If the signer succeeds  
in fooling both the verifier/policy module/whatever else the ISP provides,  
and thereby in fooling the ultimate recipient, then something has gone  
badly wrong.

The ultimate recipient is not interested in arcane details of who has  
attacked whom, or who was responsible, or which RFC has been broken; he  
just discovers that he has been fooled (and his pocket emptied), and all  
he can see is that the people who were supposed to protect him are busy  
passing the buck amongst themselves.

-- 
Charles H. Lindsey -At Home, doing my own thing
Tel: +44 161 436 6131   
   Web: http://www.cs.man.ac.uk/~chl
Email: c...@clerew.man.ac.uk  Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9  Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Pete's review of 4871bis

2011-06-29 Thread SM 
Hi John,
At 09:40 29-06-2011, John R. Levine wrote:
>there's still a lot left.  If Pete can force us to strip out more of the
>gratuitous stuff and stick to telling people how to do reliably
>interoperable signing and verification, the actual standards part of the
>standard, he'll be doing everyone a favor in the long run.

Agreed.

Regards,
-sm 

___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Pete's review of 4871bis

2011-06-29 Thread ned+dkim 
+1

Ned

> RFC 4871 is full of gratuitous and often wrong advice on everything from
> APIs to MUA design to key management.  4871bis got rid of some of it, but
> there's still a lot left.  If Pete can force us to strip out more of the
> gratuitous stuff and stick to telling people how to do reliably
> interoperable signing and verification, the actual standards part of the
> standard, he'll be doing everyone a favor in the long run.

> R's,
> John
> ___
> 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] Pete's review of 4871bis

2011-06-29 Thread Murray S. Kucherawy 
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
> On Behalf Of Dave CROCKER
> Sent: Wednesday, June 29, 2011 11:56 AM
> To: Pete Resnick
> Cc: DKIM
> Subject: Re: [ietf-dkim] Pete's review of 4871bis
> 
> If I missed it, I apologize, but have you define what you mean by "attack on
> DKIM"?  And why is it important to distinguish which category an attack
> falls into?

I'll offer this up:

Something is an "attack on DKIM" if it involves input that can cause DKIM to 
report a "pass" when it should report a "fail", or report "d=example.com" when 
it should've said "d=example.org".

Since the general output of DKIM is pass/fail and a domain name plus some other 
optional signature stuff, I fail to see how double-From type attacks are 
attacks on DKIM.  Rather, I think these things we're discussing are attacks on 
MUAs (or on ADSP implementations) that fail to do RFC5322 enforcement or fail 
to understand what DKIM is telling them.


___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Pete's review of 4871bis

2011-06-29 Thread Dave CROCKER 


On 6/29/2011 11:49 AM, Pete Resnick wrote:
> Now*that's*  the attack. But it's NOT AN ATTACK ON DKIM! It's an attack


So?

The original directive to produce a threats analaysis was for threats to 
recipients that DKIM might help remedy.

Clearly, techniques later designed to circumvent or exploit DKIM weaknessare 
also relevant, but they aren't the only attacks that are relevant here.  Also, 
I'm just guessing that that's what you mean by "attack on DKIM".

If I missed it, I apologize, but have you define what you mean by "attack on 
DKIM"?  And why is it important to distinguish which category an attack falls 
into?

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] Pete's review of 4871bis

2011-06-29 Thread Pete Resnick 
On 6/29/11 11:20 AM, Charles Lindsey wrote:

> I agree that 8.14 is poorly written (and it was even worse a while back).
> However, there most certainly IS an attack here, which is NOT the same as
> the related attack discussed in 8.15, and cannot be prevented by putting
> extra entries in the 'h=' tag. Unfortunately, many WG members have failed
> to understand the difference between the two. Here is the attack,
> described in plain terms:
>
>
> A phisher obtains a throwaway domain and creates a public/private key pair
> for
> it. He then sends messages of the following form:
>
> 
>
> To: some.sucker@anywhere.example
> From: eBay
> Date: Tue, 17 May 2011 13:21:06 +0100
> Subject: Some plausible Ebay subject
> 
> From: a.phisher@mythrowayawdomain.example
> DKIM-Signature: v=1; a=rsa-sha256; d=mythrowayawdomain.example;
> h=from:to:subject:date; ... b=
>
> Body of message of typical Phish style.
>
> -
>
> A compliant DKIM verifier will report that as a validly signed message.
>

The second From field is absolutely irrelevant in the example. The 
phisher could simply leave out the From field with their address in it 
and sign the ebay From field.

And that's not an attack. The signer signed the message and the 
signature verifies. *DKIM* has done its job successfully and has not 
been attacked. DKIM communicates from the signer to the verifier. The 
signer *can't* attack itself. You *might* characterize this as an attack 
against 5322 (in that From addresses are not bound in any secure way to 
the actual author), but DKIM does not even attempt to address that 
attack, so it's not an attack against DKIM. You go on to say something 
that is an attack, but again you get the analysis wrong:

> The
> Ebay signature is irrelevant for the signing process (so even if Ebay has
> declared a "Discardable" ADSP policy it will not be invoked).

Now *that's* the attack. But it's NOT AN ATTACK ON DKIM! It's an attack 
on ADSP. If ADSP sees the above message and doesn't discard it, then 
ADSP has done the wrong thing. If ADSP has a bug where it thinks it 
ought not discard the above message (with the appropriate policy), then 
that should be fixed. It should certainly be called out in the security 
considerations of ADSP. But it's NOT a security consideration for DKIM.

> Normal
> readers
> using current MUAs will see just the From: Ebay header and, believing that
> their ISP has done some magical cryptographic checks to prevent bogus Ebay
> messages from getting through, will be reassured.
>

Again, the second From is not required for that to happen. If MUAs 
believe that some magical crypto thing happens to a message with 
"d=badguy.example" and "From: ebay" (with no other From's), then they 
get what they paid for.

> The present draft does make some woolly attempts to fix this problem.
> Section
> 3.8 says "verifiers SHOULD take reasonable steps to ensure that the
> messages
> they are processing are valid according to [RFC5322] ... ". But gives no
> guidance as to what "reasonable" means (and full RFC5322 compliance
> checking
> is notoriously hard). It now refers to to both 8.14 and 8.15, but leaves
> it to the implelemtor to work out what he needs to do.
>

As this conversation has developed (here and off line), I'm getting 
convinced that 3.8 is a red herring. DKIM deals perfectly well with the 
obsolete message format, including multiple From fields. I think the 3.8 
admonition is overblown.

> In my opinion, there needs to be some REQUIRED action in the verifier which
> will result in a PERMFAIL, and which would then catch all attacks of this
> nature. But the WG consensus has been against this.
>

If the WG is against it, it is correct. This is NOT a PERMFAIL condition 
for DKIM. It is probably a PERMFAIL condition for ADSP, but that's a 
different document.

pr

-- 
Pete Resnick
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Pete's review of 4871bis

2011-06-29 Thread Dave CROCKER 


On 6/29/2011 9:40 AM, John R. Levine wrote:
> RFC 4871 is full of gratuitous and often wrong advice on everything from
> APIs to MUA design to key management.  4871bis got rid of some of it, but
> there's still a lot left.  If Pete can force us to strip out more of the
> gratuitous stuff and stick to telling people how to do reliably
> interoperable signing and verification, the actual standards part of the
> standard, he'll be doing everyone a favor in the long run.


Well, perhaps you are right.

After all, the group's ability to make decisions about changes, it's enthusiasm 
for such an effort and the community's demonstrated problems with the 
problematic text are all clear enough to easily justify our continuing to 
expend 
significant effort and to further delay publication of this document.

Not.

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] Pete's review of 4871bis

2011-06-29 Thread John R. Levine 
> The first thing is that it's out of scope to address changes to things
> that were in RFC 4871, which was approved by the working group, the
> community, and the IESG in 2007, if it's simply a question of one or
> two people not liking those things so much -- even if one or two of
> those people now sit on the IESG.  The working group has really made
> an effort to avoid casual changes, and I support that, as chair and
> document shepherd.

RFC 4871 is full of gratuitous and often wrong advice on everything from 
APIs to MUA design to key management.  4871bis got rid of some of it, but 
there's still a lot left.  If Pete can force us to strip out more of the 
gratuitous stuff and stick to telling people how to do reliably 
interoperable signing and verification, the actual standards part of the 
standard, he'll be doing everyone a favor in the long run.

R's,
John
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Pete's review of 4871bis

2011-06-29 Thread Murray S. Kucherawy 
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
> On Behalf Of Charles Lindsey
> Sent: Wednesday, June 29, 2011 9:20 AM
> To: DKIM
> Subject: Re: [ietf-dkim] Pete's review of 4871bis
> 
> I agree that 8.14 is poorly written (and it was even worse a while back).
> However, there most certainly IS an attack here, which is NOT the same as
> the related attack discussed in 8.15, and cannot be prevented by putting
> extra entries in the 'h=' tag. Unfortunately, many WG members have failed
> to understand the difference between the two.

That's a mischaracterization of the objection.  "h=from:from:..." was not meant 
to address the attack about which you are complaining.

> In my opinion, there needs to be some REQUIRED action in the verifier which
> will result in a PERMFAIL, and which would then catch all attacks of this
> nature. But the WG consensus has been against this.

This was discussed ad nauseam.  The consensus reached was that DKIM is the 
wrong place to enforce compliance of RFC5322.  Rather, we stipulate that we 
expect those modules to do their jobs properly.

Nobody has said either of the two variants of this attack are not valid 
concerns.  The dispute is about what module in the handling of a message is 
responsible for detecting and dealing with it.

Since the problem exists even with a message that is not DKIM-signed, I still 
fail to understand how this is specifically a DKIM problem.

-MSK

___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Pete's review of 4871bis

2011-06-29 Thread Pete Resnick 
On 6/29/11 11:11 AM, Barry Leiba wrote:
> Pete:
> I'll mostly let the editors reply to this, but there are a couple of
> things I want to say first.
>
> The first thing is that it's out of scope to address changes to things
> that were in RFC 4871, which was approved by the working group, the
> community, and the IESG in 2007, if it's simply a question of one or
> two people not liking those things so much -- even if one or two of
> those people now sit on the IESG.  The working group has really made
> an effort to avoid casual changes, and I support that, as chair and
> document shepherd.
>

Yup, absolutely agreed. As I said, I do need to sort these comments into 
"serious", "I hope the WG looks at", and "Pete makes a comment that can 
be ignored". I didn't want to spring this long list on folks Thursday 
morning and not at least give people a chance to digest them. I'll work 
today on that list.

>> 1. I find the use of the word "INFORMATIVE" throughout the document
>> superfluous. No other word (e.g., NORMATIVE) is used in its place. I
>> think they should all be removed. They serve no purpose.
>>  
> This is one category of those things that appeared in 4871.

Yes. Definitely in the category of "Pete makes a comment that can be 
ignored". If the WG finds that implementation of 4871 was not hindered 
by this, and it wasn't added without consideration, so be it. I hold my 
nose and put up with it.

> I also strongly disagree that they serve no purpose.
>

Bar BOF to be arranged on the "INFORMATIVE/NORMATIVE" verbal tick that 
has developed in the IETF.

>> 4. Section 3.4.4:
>>
>>INFORMATIVE NOTE: It should be noted that the relaxed body
>>canonicalization algorithm may enable certain types of extremely
>>crude "ASCII Art" attacks where a message may be conveyed by
>>adjusting the spacing between words.  If this is a concern, the
>>"simple" body canonicalization algorithm should be used instead.
>>
>> This is not an attack, or at the very least it is not an attack on DKIM.
>> You can play this same game with MIME encodings or other textual tricks.
>> I don't see any justification for this note being in this document.
>>  
> It's a very weak attack, and might be something we shouldn't bother
> mentioning, but it is an attack, and one that the working group
> decided to put into 4871.  One thing that DKIM ensures is that someone
> can't put, say, a line that says "viagra" into the middle of an
> otherwise legitimate message without invalidating the signature.  But
> with relaxed body canonicalization, an attacker can insert and remove
> spaces at will, wherever there's already a space, and that can be used
> to create the word "viagra" in ASCII art, though quite crudely.
>

So I don't understand. You're saying that a MITM can insert and delete 
spaces freely, so they're going to be able to change my text to make it 
appear that it has a different message? That would be an attack, but 
rather insane.

I *suspect* that what this really means is that the *signer* can insert 
funny messages. But (see below) *the signer cannot be the attacker*. 
It's nonsense.

Either way, the paragraph needs clarification.

>> 5. Section 3.4.5:
>>
>>INFORMATIVE IMPLEMENTATION NOTE: Using body length limits enables
>>an attack in which an attacker modifies a message to include
>>content that solely benefits the attacker.  It is possible for the
>>appended content to completely replace the original content in the
>>end recipient's eyes, such as via alterations to the MIME
>>structure or exploiting lax HTML parsing in the MUA, and to defeat
>>duplicate message detection algorithms.  To avoid this attack,
>>signers should be wary of using this tag, and verifiers might wish
>>to ignore the tag, perhaps based on other criteria.
>>
>> I don't understand how this is an attack. If the signer said, "I'm
>> signing the first n bytes of the body of this message" and the verifier
>> is able to verify that the signature is valid for n bytes of the body,
>> the algorithm has succeeded. At most, this should lead to an admonition
>> that unsigned data is not verified and therefore should not be trusted,
>> but that seems obvious.
>>  
> Of course, that's why it's an informative implementation note.

Though this appears again later in the document.

> You're
> saying that it's not worth pointing out pitfalls, and that we should
> stick to the facts of the protocol.

No, that's not what I'm saying. If you want to put in an admonition, so 
be it. It's just not an attack.

>> 10. Section 3.5, "h=":
>>
>>   INFORMATIVE EXPLANATION: The exclusion of the header field name
>>   and colon as well as the header field value for non-existent
>>   header fields allows detection of an attacker that inserts an
>>   actual header field with a null value.
>>
>> I cannot parse that sentence. I hav

Re: [ietf-dkim] Pete's review of 4871bis

2011-06-29 Thread Barry Leiba 
>> to create the word "viagra" in ASCII art, though quite crudely.
>
> So I don't understand. You're saying that a MITM can insert and delete 
> spaces freely, so they're going to be able to change my text to make it 
> appear that it has a different message? That would be an attack, but 
> rather insane.

Yes, exactly.  It's  talking about a mitm inserting spaces freely into a signed 
message.  And, yes, it's quite insane.

b

 
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Pete's review of 4871bis

2011-06-29 Thread Charles Lindsey 
On Wed, 29 Jun 2011 05:46:06 +0100, Pete Resnick   
wrote:

> 32. Section 8.14: This is a complete mischaracterization of the problem.
> This is absolutely not an attack vector. If a signer wishes to prevent
> additional *known* header fields from being verified, it can simply use
> the technique outlined in 8.15. If the signer chooses not to do that, it
> is expressing the intent that it considers messages valid that have
> additional header fields added. *That's* the security consideration:
> Signers should know that failing to include, e.g., "h=...:from:from:..."
> on messages with one "From:" header field are leaving themselves open to
> this attack. The attack is not on the verifier. Additionally:
>
> Note that the technique for using "h=...:from:from:...", described in
> Section 8.15 below, is of no effect in the case of an attacker that
> is also the signer.
>
> That sentence is utter nonsense. The signer *can't* be the attacker for
> purposes of DKIM when it comes to the header fields it's willing to
> sign. The Introduction (section 1) makes it absolutely clear that DKIM
> is about transmitting information from a signer to a verifier.
>
> Section 8.14 needs to be completely rewritten. It is nonsensical as it
> stands.

I agree that 8.14 is poorly written (and it was even worse a while back).  
However, there most certainly IS an attack here, which is NOT the same as  
the related attack discussed in 8.15, and cannot be prevented by putting  
extra entries in the 'h=' tag. Unfortunately, many WG members have failed  
to understand the difference between the two. Here is the attack,  
described in plain terms:


A phisher obtains a throwaway domain and creates a public/private key pair  
for
it. He then sends messages of the following form:



To: some.sucker@anywhere.example
From: eBay 
Date: Tue, 17 May 2011 13:21:06 +0100
Subject: Some plausible Ebay subject

From: a.phisher@mythrowayawdomain.example
DKIM-Signature: v=1; a=rsa-sha256; d=mythrowayawdomain.example;
   h=from:to:subject:date; ... b=

Body of message of typical Phish style.

-

A compliant DKIM verifier will report that as a validly signed message. The
Ebay signature is irrelevant for the signing process (so even if Ebay has
declared a "Discardable" ADSP policy it will not be invoked). Normal  
readers
using current MUAs will see just the From: Ebay header and, believing that
their ISP has done some magical cryptographic checks to prevent bogus Ebay
messages from getting through, will be reassured.

The present draft does make some woolly attempts to fix this problem.  
Section
3.8 says "verifiers SHOULD take reasonable steps to ensure that the  
messages
they are processing are valid according to [RFC5322] ... ". But gives no
guidance as to what "reasonable" means (and full RFC5322 compliance  
checking
is notoriously hard). It now refers to to both 8.14 and 8.15, but leaves  
it to the implelemtor to work out what he needs to do.

In my opinion, there needs to be some REQUIRED action in the verifier which
will result in a PERMFAIL, and which would then catch all attacks of this
nature. But the WG consensus has been against this.

There are clearly related attacks, possibly involving duplications of  
other headers (including some MIME headers), and there are similar attacks  
involving replays and men-in-the-middle and which are covered under 8.15.  
But the one I have shown is the real killer IMHO.

-- 
Charles H. Lindsey -At Home, doing my own thing
Tel: +44 161 436 6131   
   Web: http://www.cs.man.ac.uk/~chl
Email: c...@clerew.man.ac.uk  Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9  Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Pete's review of 4871bis

2011-06-29 Thread Barry Leiba 
Pete:
I'll mostly let the editors reply to this, but there are a couple of
things I want to say first.

The first thing is that it's out of scope to address changes to things
that were in RFC 4871, which was approved by the working group, the
community, and the IESG in 2007, if it's simply a question of one or
two people not liking those things so much -- even if one or two of
those people now sit on the IESG.  The working group has really made
an effort to avoid casual changes, and I support that, as chair and
document shepherd.

> 1. I find the use of the word "INFORMATIVE" throughout the document
> superfluous. No other word (e.g., NORMATIVE) is used in its place. I
> think they should all be removed. They serve no purpose.

This is one category of those things that appeared in 4871.  I also
strongly disagree that they serve no purpose.  It's useful to make it
clear when we have informative text that readers might misunderstand
to be normative.  In any case, it's harmless, even if you don't like
it for stylistic reasons.  But the bottom line is that these were
there before, and should stay there now... except, of course, for
removing or changing ones that are wrong or truly unclear.

> 4. Section 3.4.4:
>
>       INFORMATIVE NOTE: It should be noted that the relaxed body
>       canonicalization algorithm may enable certain types of extremely
>       crude "ASCII Art" attacks where a message may be conveyed by
>       adjusting the spacing between words.  If this is a concern, the
>       "simple" body canonicalization algorithm should be used instead.
>
> This is not an attack, or at the very least it is not an attack on DKIM.
> You can play this same game with MIME encodings or other textual tricks.
> I don't see any justification for this note being in this document.

It's a very weak attack, and might be something we shouldn't bother
mentioning, but it is an attack, and one that the working group
decided to put into 4871.  One thing that DKIM ensures is that someone
can't put, say, a line that says "viagra" into the middle of an
otherwise legitimate message without invalidating the signature.  But
with relaxed body canonicalization, an attacker can insert and remove
spaces at will, wherever there's already a space, and that can be used
to create the word "viagra" in ASCII art, though quite crudely.

Personally, I think it's a silly thing to worry about, and that we
shouldn't mention it.  But it's not up to me: it has working group
consensus from before RFC 4871 was published.

> 5. Section 3.4.5:
>
>       INFORMATIVE IMPLEMENTATION NOTE: Using body length limits enables
>       an attack in which an attacker modifies a message to include
>       content that solely benefits the attacker.  It is possible for the
>       appended content to completely replace the original content in the
>       end recipient's eyes, such as via alterations to the MIME
>       structure or exploiting lax HTML parsing in the MUA, and to defeat
>       duplicate message detection algorithms.  To avoid this attack,
>       signers should be wary of using this tag, and verifiers might wish
>       to ignore the tag, perhaps based on other criteria.
>
> I don't understand how this is an attack. If the signer said, "I'm
> signing the first n bytes of the body of this message" and the verifier
> is able to verify that the signature is valid for n bytes of the body,
> the algorithm has succeeded. At most, this should lead to an admonition
> that unsigned data is not verified and therefore should not be trusted,
> but that seems obvious.

Of course, that's why it's an informative implementation note.  You're
saying that it's not worth pointing out pitfalls, and that we should
stick to the facts of the protocol.  Maybe.  Maybe this should be in
the informative documents, the overview and the deployment guide.
Maybe several of the similar items should.  The working group chose to
put it into RFC 4871 instead.

It's worth noting that this is warning about a tag that the working
group considers VERY problematic, and that the WG thought hard about
removing in the progression to DS.  In the end, we did not have
consensus to remove it.  We do have consensus to leave in the
warnings.

> 10. Section 3.5, "h=":
>
>          INFORMATIVE EXPLANATION: The exclusion of the header field name
>          and colon as well as the header field value for non-existent
>          header fields allows detection of an attacker that inserts an
>          actual header field with a null value.
>
> I cannot parse that sentence. I have no idea what it means.

It's a horrible sentence, and needs rewording (or removal).  But I
know what it means.  When you sign an empty header field (like
"Floob:"), you are signing the field name ("floob"), the colon, and
the terminating CRLF (with a null value).  When you "sign" a header
field that doesn't exist in the message, you are signing a complete
null string: a null field name, and a null (absent) colon, value, an

[ietf-dkim] Pete's review of 4871bis

2011-06-28 Thread Pete Resnick 
Folks,

I've been reviewing 4871bis for the IESG review on Thursday. I've got a 
huge number of comments. Some of them (e.g., the first two below) are 
quite trivial or simple issues that I expect you'd either have no issue 
with or that I'm happy to ignore; some of them are clearly not trivial 
at all. I have not entered a ballot position yet, and I haven't sorted 
through all of the comments to decide if any are worthy of entering a 
DISCUSS, but I suspect that some of them are. I therefore wanted to post 
this to the WG list so you all get an idea of what I'm thinking about. 
Tomorrow I'll spend some time cleaning these up and sorting them by 
category instead of by order of the document.

I apologize for the lateness of this review; it's probably something I 
should have done a long time ago.

Comments:

1. I find the use of the word "INFORMATIVE" throughout the document 
superfluous. No other word (e.g., NORMATIVE) is used in its place. I 
think they should all be removed. They serve no purpose.

2. The ABNF "0*" construct is not normally used. Why not just "*"?

3. Section 2.7: I don't understand what the word "module" means in this 
context. It sounds like some sort of specific implementation, not part 
of a protocol. I don't know what it means to deliver values to a module.

4. Section 3.4.4:

   INFORMATIVE NOTE: It should be noted that the relaxed body
   canonicalization algorithm may enable certain types of extremely
   crude "ASCII Art" attacks where a message may be conveyed by
   adjusting the spacing between words.  If this is a concern, the
   "simple" body canonicalization algorithm should be used instead.

This is not an attack, or at the very least it is not an attack on DKIM. 
You can play this same game with MIME encodings or other textual tricks. 
I don't see any justification for this note being in this document.

5. Section 3.4.5:

   INFORMATIVE IMPLEMENTATION NOTE: Using body length limits enables
   an attack in which an attacker modifies a message to include
   content that solely benefits the attacker.  It is possible for the
   appended content to completely replace the original content in the
   end recipient's eyes, such as via alterations to the MIME
   structure or exploiting lax HTML parsing in the MUA, and to defeat
   duplicate message detection algorithms.  To avoid this attack,
   signers should be wary of using this tag, and verifiers might wish
   to ignore the tag, perhaps based on other criteria.

I don't understand how this is an attack. If the signer said, "I'm 
signing the first n bytes of the body of this message" and the verifier 
is able to verify that the signature is valid for n bytes of the body, 
the algorithm has succeeded. At most, this should lead to an admonition 
that unsigned data is not verified and therefore should not be trusted, 
but that seems obvious. There might be an attack on an MUA that does not 
verify the DKIM signature, but that seems outside the scope of this 
document.

6. Section 3.5:

v= Version (MUST be included).  This tag defines the version of this
   specification that applies to the signature record.  It MUST have
   the value "1".  Note that verifiers must do a string comparison on
   this value; for example, "1" is not the same as "1.0".

Why "string comparison" here? There's no case sensitivity to worry 
about. There's no character encoding to worry about. Why not instead 
say, "Note that verifiers must (MUST?) ensure that the value is '1'; for 
exmaple '1' is not the same as '1.0'"? (Seem similar text in 3.6.1.) And 
why is the value not listed as "plain-text"?

7. Section 3.5: It would be nice to subsection each tag here. (e.g., 
"v=" could be 3.5.1, etc.)

8. Section 3.5, "h=":

It would be nice to add a sentence similar to the one in 5.4: "The field 
MAY contain multiple instances of a header field name; this means that 
multiple occurrences of the header field are being signed by the signing 
algorithm."

9. Section 3.5, "h=":

  INFORMATIVE EXPLANATION: By "signing" header fields that do not
  actually exist, a signer can allow a verifier to detect
  insertion of those header fields after signing.  However, since
  a signer cannot possibly know what header fields might be
  created in the future, and that some MUAs might present header
  fields that are embedded inside a message (e.g., as a message/
  rfc822 content type), the security of this solution is not
  total.

a. I don't understand what MUAs presenting "header fields that are 
embedded inside a message" has to do with anything.

b. I don't know what the words, "the security of this solution is not 
total" are supposed to mean.

Don't you simply mean: "However, since a signer cannot possibly know 
what header fields might be defined in the future, this mechanism can't 
be used to prevent the addition of any possible unknown