Subject: [ietf-dkim] ISSUE: tag l=2 and dealing with leading blank lines for SIMPLE c14n.

From: Hector Santos <[email-masked]>
Date: Mon, 22 Jan 2007 07:32:49 -0500

hmmmmm,,

I read the DKIM-BASE specs a few times now and I don't see anything nor 
do I recall any list discussion about the body content containing 
leading <CRLF> lines and dealing with them, especially in relationship 
to the much debated l=2 or SIMPLE c14n "empty" message.

Consider the following RFC 2822 message:

    headers:<CRLF>
    <CRLF>           <-- RFC x2822 header/body delimiter
    <CRLF>           <-- Beginning of body
    12345678<CRLF>
    12345678<CRLF>
    <CRLF>

Here we have 24 message body bytes with 1 leading blank lines.

It would be super silly to set a L=2 to hash only the first two bytes 
here where the two bytes are <CRLF>. This would result in a facsimile of 
an of empty message which has an exploitable body altering hole.

I think we need one more LINE of text in the DKIM-BASE.

    "Although it is possible to hash only a part of the
     SIMPLE canonicalized message body, it is highly discouraged
     to hash only two octets if the leading two octets are <CR><LF> and
     there additional non <CR><LF> octets."

I am just winging it above so maybe ERIC or someone else can better 
state this.

I just think that we went at length to explain the special consideration 
when L=2 for the SIMPLE c14n "empty" message and the need to add a 
<CRLF> to the hashing feed if required, that it is probably to also 
stipulate or highlight that partial hashing should not include hashing 
only 2 bytes with <CRLF> leading blank lines.

---
HLS

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

---

From: Jim Fenton <[email-masked]>
Date: Tue, 23 Jan 2007 22:34:51 -0800

Hector Santos wrote:
> hmmmmm,,
>
> I read the DKIM-BASE specs a few times now and I don't see anything 
> nor do I recall any list discussion about the body content containing 
> here where the two bytes are <CRLF>. This would result in a facsimile 
> of an of empty message which has an exploitable body altering hole.
>

I don't think this accomplishes what you intended.  If you're worried 
about an attacker exploiting a body-less message signed with l=2, the 
attacker could still start their message with a blank line.  It then 
would be up to the verifier to treat this specially.  Expecting the 
verifier to do something special with messages signed with l=2 is an 
unnecessary, and error-prone, rule.

If the signer wants to make sure that messages are not subject to 
"append attacks", they shouldn't use l=.  Use the default.

-Jim

---

From: Hector Santos <[email-masked]>
Date: Wed, 24 Jan 2007 11:26:00 -0500

> "append attacks", they shouldn't use l=.  Use the default.

+1.

In lieu of a proposed KEY attribute "l=w|p", not defining the body limit 
with the DKIM-SIGNATURE: header l= tag, should be noted in the DKIM-BASE 
specs.

Otherwise, you are open to Body Limit Security Attacks.  I'm sure every 
SIGNER would want to avoid any possible security exploit and not 
defining the body limit during the signing practice and if not defining 
the l= tag eliminates this exploit, then it should highlighted in the 
specification.

--
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 24 Jan 2007 12:24:25 -0500

> "append attacks", they shouldn't use l=.  Use the default.
IIRC, every time someone brings up l= problems, the response is don't use it.  
Is there a problem it solves that we need it?  If it's inherently risky and 
should not be used, I'm wondering if it should even be in the RFC?

Scott K

---

From: John Levine <[email-masked]>
Date: 24 Jan 2007 17:57:32 -0000

>should not be used, I'm wondering if it should even be in the RFC?

Personally, I have never thought that l= would be useful, but I was
willing to leave it in the draft for the benefit of people who want to
try it out.  This document is in last call, it is nuts to propose
opening it up to add yet more untried features of at most debatable
utility.

-99 to any proposed new features

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Wed, 24 Jan 2007 10:01:48 -0800

> should not be used, I'm wondering if it should even be in the RFC?

This is a valid concern.  Why allow something that can and most  
likely will be abused?

Even allowing just a URI pointing to what looks like a safe domain  
and path might still contain malware within the URI fragment.

-Doug

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 24 Jan 2007 13:07:42 -0500

On Wednesday 24 January 2007 12:57, John Levine wrote:
> >IIRC, every time someone brings up l= problems, the response is don't use
> > it. Is there a problem it solves that we need it?  If it's inherently
> > risky and should not be used, I'm wondering if it should even be in the
> > RFC?
>
Agreed.  My question was mostly academic (should have said that I guess), but 
if we are going to get into a long discussion about fixing problems with l=, 
then the alternative of removing it seems worth considering (I'm not 
proposing we have the long arguement, but if we do...).

Scott K

---

From: Hector Santos <[email-masked]>
Date: Wed, 24 Jan 2007 14:08:24 -0500

> proposing we have the long arguement, but if we do...).

+101.

I don't claim the have the IETF handbook master, but what is the purpose 
of the last call?

Come on, we spent a few hard fought years on this stuff. Many are 
extremely anal on semantics, and gods knows that we had the battles over 
very sensitive issues.

But if there is something we should all AGREE with is that if there is 
an a SLIGHT HOLE that we can most definitely and concretely remove at 
this point with the mere stroke of a few written keystrokes, then we 
should not allow a "LAST CALL" claim stop what should be done.

Its not like we have production software in the market place.  DKIM is 
still a pipe dream.  Lets at least get what we can out of the way.  This 
is one of them.  The exploit is real very and we don't need to rehash 
the spammer steps to do it.

At the very least, Eric should add a statement about omitting the l= tag 
  to avoid any signer concern about partial hashing body limit replay 
exploits.  This should be the default behavior for production software 
before the RFC status is given.  By then it would be too late.

Come on, this is small potatoes compared to the other debated stuff.

---
HLS

---

From: Jim Fenton <[email-masked]>
Date: Wed, 24 Jan 2007 18:32:07 -0800

Hector Santos wrote:
> In lieu of a proposed KEY attribute "l=w|p", not defining the body 
> limit with the DKIM-SIGNATURE: header l= tag, should be noted in the 
> DKIM-BASE specs.
>
> Otherwise, you are open to Body Limit Security Attacks.  I'm sure 
> every SIGNER would want to avoid any possible security exploit and not 
> defining the body limit during the signing practice and if not 
> defining the l= tag eliminates this exploit, then it should 
> highlighted in the specification.
>

---

From: Jim Fenton <[email-masked]>
Date: Wed, 24 Jan 2007 18:48:45 -0800

> highlighted in the specification.

The followup comments from Hector and several others lead me to believe 
that some people are over-interpreting what I said above.  As with many 
things, there is a tradeoff between security and flexibility; this is 
why we have canonicalization algorithms, for example.  We discussed this 
tradeoff extensively for the l= tag, and decided to retain it.  I don't 
see a good reason to revisit that decision.  Rather, I am saying that 
this specific attack can be avoided by not using the l= flag.

I don't see the value of specific text having to do with l=2 when the 
body starts with CR LF.  Append attacks exist when the body begins with 
other things as well.

-Jim

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 25 Jan 2007 11:19:30 -0000

> This is a valid concern.  Why allow something that can and most likely  
> will be abused?

It all depends on what the sender of the message is trying to achieve, and  
on his level of paranoia. For the most obvious attacks (spoofing the  
source of a message), body signing is not important (since most bad guys  
do not have the ability to interfere with a message in transit), and the  
ability to permit mailing lists to add stuff like:

_______________________________________________
NOTE WELL: This list operates according  
tohttp://mipassoc.org/dkim/ietf-list-
rules.html

is more important. But if the sender is worried about possible Replay  
Attacks, then he has to do a little more (possibly loosing the ability to  
have the message pass smoothly through mailing lists).

But even there, there is a workaround. Simply include, as the last line of  
the signed part of the message, something like:

WARNING! THIS IS THE END OF THE MESSAGE. ANYTHING BELOW THIS LINE WAS  
ADDED IN TRANSIT.
------------------------------------------------------------------------------

If that looks a little alarmist, something more polite might do, such as a  
conventional signature following the customary "-- CRLF" might be good  
enough.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

---

From: Eric Allman <[email-masked]>
Date: Thu, 25 Jan 2007 14:34:59 -0800

--On January 24, 2007 2:08:24 PM -0500 Hector Santos 
<[email-masked]> wrote:

> At the very least, Eric should add a statement about omitting the
> l= tag   to avoid any signer concern about partial hashing body
> limit replay exploits.

There are already several warnings in the draft about the dangers of 
using "l=".  We know that the point of "l=" is to allow appending of 
trailers, as Charles pointed out.  We also know that it creates a 
risk of exploitation, and there are warnings about that in sections 
3.5 and 8.1.

And frankly, I don't see why a leading <CRLF> is a special case. 
Adding a special warning about "l=2" and <CRLF> just seems 
unnecessary, and opens up a whole can of worms.  Suppose the body 
begins with "--" (not unlikely in a MIME message) --- should this be 
specifically mentioned as well?  If it begins with two <CRLF>s and 
has "l=4", it is essentially the same case.  Suppose it only signs to 
the end of the first MIME separator?  Suppose the message begins 
"Dear " and has "l=5", or "<CRLF><CRLF>--On " and "l=9" (as this 
message does)?

eric

---

From: Tony Hansen <[email-masked]>
Date: Thu, 25 Jan 2007 17:43:30 -0500

It's a slippery slope that I think we've already gone down far enough. I
think the current exhortations are sufficient.

	Tony Hansen
	[email-masked]

Eric Allman wrote:
> trailers, as Charles pointed out.  We also know that it creates a risk
> of exploitation, and there are warnings about that in sections 3.5 and 8.1.
> 
> And frankly, I don't see why a leading <CRLF> is a special case. Adding
> a special warning about "l=2" and <CRLF> just seems unnecessary, and
> opens up a whole can of worms.  Suppose the body begins with "--" (not
> unlikely in a MIME message) --- should this be specifically mentioned as
> well?  If it begins with two <CRLF>s and has "l=4", it is essentially
> the same case.  Suppose it only signs to the end of the first MIME
> separator?  Suppose the message begins "Dear " and has "l=5", or
> "<CRLF><CRLF>--On " and "l=9" (as this message does)?

---

From: Jon Callas <[email-masked]>
Date: Thu, 25 Jan 2007 14:59:07 -0800

A quick note to add on to some things others have said.

DKIM has features that are useful in some places but not in others.  
One of those is l=.

It seems to me that some people think that DKIM is going to be used  
uniformly throughout an email system, and that's in my opinion naïve.  
For example, I'm sending this message to you through a security  
gateway that I make -- PGP Universal. My PGP Universal server does  
not presently do DKIM, but it *knows* that I am sending to a mailing  
list. It knows that "[email-masked]" is the address of a  
list, not an individual, and it handles that specially.

It is possible for software to detect mailing lists and perhaps use  
l= on those messages, but not on others. It is even possible for  
software to automatically detect its own signatures that break  
because of trailers put on, and then start using l=. It could happen.  
It's not a computationally infeasible problem.

Similarly, software could take messages coming from some hosts and  
trim the dangling trailers on some messages, and not on others.

I also think that warnings about appropriate lengths is not only  
unnecessary, but inappropriate. It's arrogant for the standard to  
tell the implementer and the deployer how to do their job. Like all  
rules of thumb, it can be carried to an absurd extreme, so I'm not  
interested in hearing about the exception case.

I'm especially uninterested because DKIM is a system that when  
misused, it hurts the signer and no one else. If I start signing  
messages with l=2 and some spammer uses that, guess who's hurt? Me.  
Not you, me. The purpose of DKIM is not to make bad mail actors go  
away, but to *identify* them. If misuse of l= is as bad an idea as  
having an open relay, people will figure it out!

I also expect that someday someone will figure out that it is not  
computationally infeasible for software to say, "Huh. There's an  
awful lot of text appended after the signed portion" or "Wow, that's  
sure a short signed length" and figure out something to do with that.  
An especially clever developer might even already be thinking about  
it because a system that does cool things with DKIM would be a  
competitive advantage. It could happen.

Please, let's stop trying to do the implementor's job. Let's stop  
trying to do the deployer's job. Let's make a standard that permits  
them to do a good job.

	Jon

---

From: "Douglas Otis" <[email-masked]>
Date: Thu, 25 Jan 2007 16:24:38 -0800 (PST)

> messages with l=2 and some spammer uses that, guess who's hurt? Me.

Bad actors will find signatures surviving as a result of the 'l=n'
parameter, can then add their malware which might be a very innocent
looking URI pointing to some provider's AUP.  This message can then be
sent in bulk anywhere.  The innocent URI may still cause an exploit to
occur, and recipients might have thought they were trusting you.  So who
is hurt?

Of course, the DKIM community will then need to explain to these end users
about this wonderful feature that allowed them to be completely confused.

-Doug

---

From: Jon Callas <[email-masked]>
Date: Thu, 25 Jan 2007 16:42:27 -0800

> about this wonderful feature that allowed them to be completely  

My answer is that the ISP who fails to scan a message, is an idiot  
and deserves to go out of business.

Come on, Doug. You're saying that DKIM is this magic thing that  
obviates the need for virus scanning. Pull the other one.

	Jon

---

From: "Douglas Otis" <[email-masked]>
Date: Thu, 25 Jan 2007 17:29:36 -0800 (PST)

> obviates the need for virus scanning. Pull the other one.

Rather than blaming end users or ISP for failing to detect a possible
exploit, especially those that cross domains where a portion of the threat
is not seen (and might even be innocent on its own), the issue is with
DKIM offering a protection scheme where the recipient is _likely_ confused
about who sent what.   The blame MUST be placed on DKIM and no where else.

-Doug

---

From: "Douglas Otis" <[email-masked]>
Date: Fri, 26 Jan 2007 13:48:20 -0800 (PST)

>> [l=n might be very confusing.]

> and deserves to go out of business.

A) Who sent what is not important?

B) Key security?

Limitations placed upon linking headers with the signing-domain also means
hundreds or thousands of private keys might need to reside at the MTAs. 
While CNAME references could allow a common key to be used where the
public key is indirectly published by perhaps thousands of customer's
domains.  This still obscures who signed the message, and ensures
thousands are domains are at risk and may remain unaware of a detected
security breach.

C) Domain security?

Parent signing validation can not be equated to being covered by existing
domain delegation agreements.  Services and keys at high-level domains
create risk without any established arrangements or contracts.

E) Discouraging signature verification by the end user?

Rather than ensuring messages sent to the end user remains protected, this
mode of protection is discouraged?  A case of poor wording?

F) Overlooking DDoS concerns?

Not ensuring linkage between headers on who's behalf the signature is
being applied weakens DDoS preventions.  The base draft also expects known
bad signatures to NOT be removed.

G) Annotation?

Annotation must take place at the MUA or signatures are invalidated.  It
seems MTA vendors wish to retain DKIM completely within their baliwick. 
Without the effort joined by MUA and web client (browser extensions)
vendors, DKIM is likely to increase phishing success rates.

H) EAI related changes?

Ignoring developing changes because it affects visual recognition / policy
blocking strategies many erroneously expect to offer end user protection.

Yes, we need DKIM.  This list was made on reflection of Jon's statement. 
The DKIM WG could have done better.

-Doug

---

From: <[email-masked]>
Date: Fri, 26 Jan 2007 19:07:18 -0500

Doug,
replacement values
*********************************
G) Annotation?

**********************************

with

>G) Annotation?

Annotation should take place at the MUA or entity with access to the addressbook or signatures should not be annotated. Without the effort joined by MUA and web client (browser extensions) vendors, DKIM is not likely to increase phishing catch rates.
thanx,
bill

---

From: "Douglas Otis" <[email-masked]>
Date: Fri, 26 Jan 2007 17:14:00 -0800 (PST)

>>G) Annotation?
>
> Annotation should take place at the MUA or entity with access to the
> addressbook or signatures should not be annotated. Without the effort
> joined by MUA and web client (browser extensions) vendors, DKIM is not
> likely to increase phishing catch rates.

Your statement is less emphatic and better.  Perhaps why could be included
however.

How about:

Annotation applied at the MTA will likely invalidate signatures and
prevent  more accurate annotations from being applied by end user
applications.  Applying annotations should require valid signatures that
are signed on behalf of a _trusted_ entity.

Determination of trust is more accurately accomplished by the end user. 
The basis of end user assessments will likely rely upon out-of-band
methods not available to the MTA.  These lists might be represented by the
recipient's address book, for example.  Without the effort joined by MUA
and web client (browser extensions) vendors, DKIM is not likely to
increase phishing catch rates.

-Doug

---

From: <[email-masked]>
Date: Sat, 27 Jan 2007 16:46:48 -0500

+1

-----Original Message-----
From: Douglas Otis [mailto:[email-masked]]
Sent: Fri 1/26/2007 8:14 PM
To: Oxley, Bill (CCI-Atlanta)
Cc: [email-masked]; [email-masked]
Subject: RE: [ietf-dkim] The DKIM WG is within security?

How about:

-Doug