headers
Pete Resnick | 29 Jun 2011 06:46

Pete's review of 4871bis

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:
(Continue reading)

Permalink | Reply |
headers
Barry Leiba | 29 Jun 2011 18:11
Picon
Favicon
Gravatar

Re: Pete's review of 4871bis

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
(Continue reading)

Permalink | Reply |
headers
Pete Resnick | 29 Jun 2011 18:39

Re: Pete's review of 4871bis

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.
(Continue reading)

Permalink | Reply |
headers
John R. Levine | 29 Jun 2011 18:40

Re: Pete's review of 4871bis

> 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
Permalink | Reply |
headers
Dave CROCKER | 29 Jun 2011 20:02

Re: Pete's review of 4871bis


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
Permalink | Reply |
headers
ned+dkim | 29 Jun 2011 20:28

Re: Pete's review of 4871bis

+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
Permalink | Reply |
headers
SM | 29 Jun 2011 22:09

Re: Pete's review of 4871bis

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
Permalink | Reply |
headers
Charles Lindsey | 29 Jun 2011 18:20
Picon
Picon

Re: Pete's review of 4871bis

On Wed, 29 Jun 2011 05:46:06 +0100, Pete Resnick <presnick <at> qualcomm.com>  
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,
(Continue reading)

Permalink | Reply |
headers
Murray S. Kucherawy | 29 Jun 2011 19:31

Re: Pete's review of 4871bis

> -----Original Message-----
> From: ietf-dkim-bounces <at> mipassoc.org [mailto:ietf-dkim-bounces <at> 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
(Continue reading)

Permalink | Reply |
headers
Charles Lindsey | 30 Jun 2011 16:04
Picon
Picon

Re: Pete's review of 4871bis

On Wed, 29 Jun 2011 18:31:04 +0100, Murray S. Kucherawy  
<msk <at> cloudmark.com> wrote:

>> -----Original Message-----
>> From: ietf-dkim-bounces <at> mipassoc.org  
>> [mailto:ietf-dkim-bounces <at> 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.
(Continue reading)

Permalink | Reply |
headers
Murray S. Kucherawy | 30 Jun 2011 18:53

Re: Pete's review of 4871bis

> -----Original Message-----
> From: ietf-dkim-bounces <at> mipassoc.org [mailto:ietf-dkim-bounces <at> 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).
Permalink | Reply |
headers
Douglas Otis | 1 Jul 2011 23:11

Re: Pete's review of 4871bis

On 6/30/11 9:53 AM, Murray S. Kucherawy wrote:
>> -----Original Message-----
>> From: ietf-dkim-bounces <at> mipassoc.org [mailto:ietf-dkim-bounces <at> 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.
(Continue reading)

Permalink | Reply |
headers
Pete Resnick | 29 Jun 2011 20:49

Re: Pete's review of 4871bis

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 <at> anywhere.example
> From: eBay<ebay <at> ebay.co.uk>
> Date: Tue, 17 May 2011 13:21:06 +0100
> Subject: Some plausible Ebay subject
> <Lots of other normal headers>
> From: a.phisher <at> mythrowayawdomain.example
> DKIM-Signature: v=1; a=rsa-sha256; d=mythrowayawdomain.example;
>         h=from:to:subject:date; ....... b=<valid signature>
>
> Body of message of typical Phish style.
>
> -------------
>
> A compliant DKIM verifier will report that as a validly signed message.
(Continue reading)

Permalink | Reply |
headers
Dave CROCKER | 29 Jun 2011 20:55

Re: Pete's review of 4871bis


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
Permalink | Reply |
headers
Murray S. Kucherawy | 29 Jun 2011 21:26

Re: Pete's review of 4871bis

> -----Original Message-----
> From: ietf-dkim-bounces <at> mipassoc.org [mailto:ietf-dkim-bounces <at> 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.
Permalink | Reply |
headers
Charles Lindsey | 30 Jun 2011 16:16
Picon
Picon

Re: Pete's review of 4871bis

On Wed, 29 Jun 2011 19:49:27 +0100, Pete Resnick <presnick <at> qualcomm.com>  
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 <at> anywhere.example
>> From: eBay<ebay <at> ebay.co.uk>
>> Date: Tue, 17 May 2011 13:21:06 +0100
>> Subject: Some plausible Ebay subject
>> <Lots of other normal headers>
>> From: a.phisher <at> mythrowayawdomain.example
>> DKIM-Signature: v=1; a=rsa-sha256; d=mythrowayawdomain.example;
>>         h=from:to:subject:date; ....... b=<valid signature>
>>
>> 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
(Continue reading)

Permalink | Reply |
headers
Douglas Otis | 1 Jul 2011 23:43

Re: Pete's review of 4871bis

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 <at> anywhere.example
>> From: eBay<ebay <at> ebay.co.uk>
>> Date: Tue, 17 May 2011 13:21:06 +0100
>> Subject: Some plausible Ebay subject
>> <Lots of other normal headers>
>> From: a.phisher <at> mythrowayawdomain.example
>> DKIM-Signature: v=1; a=rsa-sha256; d=mythrowayawdomain.example;
>>          h=from:to:subject:date; ....... b=<valid signature>
>>
>> Body of message of typical Phish style.
>>
>> -------------
>>
>> A compliant DKIM verifier will report that as a validly signed message.
(Continue reading)

Permalink | Reply |
headers
Barry Leiba | 29 Jun 2011 19:02
Picon
Favicon
Gravatar

Re: Pete's review of 4871bis

>> 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
Permalink | Reply |

Gmane