Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-email-auth-codes-01.txt

From: [email-masked]
Date: Tue, 27 May 2014 11:54:23 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Applications Area Working Group Working Group of the IETF.

        Title           : Email Authentication Status Codes
        Author          : Murray S. Kucherawy
	Filename        : draft-ietf-appsawg-email-auth-codes-01.txt
	Pages           : 6
	Date            : 2014-05-27

Abstract:
   There is at present no way to return a status code to an email client
   that indicates a message is being rejected or deferred specifically
   because of email authentication failures.  This document registers
   codes for this purpose.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-email-auth-codes/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-email-auth-codes-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-email-auth-codes-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 27 May 2014 11:59:59 -0700

>    because of email authentication failures.  This document registers

This addresses Barry's concerns (I hope!).

-MSK

---

From: Barry Leiba <[email-masked]>
Date: Tue, 27 May 2014 15:08:36 -0400

> This addresses Barry's concerns (I hope!).

It does; I can live with this version, and I hope others find those
changes acceptable.

Thanks.

Barry

---

From: Claudio Allocchio <[email-masked]>
Date: Tue, 27 May 2014 21:14:29 +0200 (CEST)

> It does; I can live with this version, and I hope others find those

ok +1

as "rejections because of DKDM or SPF are often "mysterious" for users 
(... and administrators) the clearer we state information, the better it 
is...

  >
> Thanks.
>
> Barry
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca

---

From: Hector Santos <[email-masked]>
Date: Tue, 27 May 2014 16:53:54 -0400

> It does; I can live with this version, and I hope others find those

Why would a SMTP implementator wish to support this guideline for 
applying specific SMTP EXTENDED response codes if it violates DKIM?

What will happen if the server issues the INVALID vs MISSING extended 
response?

Will the client exploit/leverage this in a negative/positive manner?

Is there a security loophole?

In all cases, it is a about a rejection (55x) which all clients MUST 
treat the same (from a SMTP standpoint), so there is no violation.

Now, where its OPTIONALLY applied, can extended codes make clients 
"smarter?" Will it do a bounce with a different result?  Perhaps with 
the DSN reporting which will most likely have the 55x reported 
response.  The drafts needs to take from the DKIM "treat 
invalid/missing" the same philosophy which came from a policy analysis 
where these different conditions were folded.  The semantic became 
ambiguous only when POLICY was pulled from the framework.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 27 May 2014 14:22:27 -0700

On Tue, May 27, 2014 at 1:53 PM, Hector Santos <[email-masked]> wrote:

> Why would a SMTP implementator wish to support this guideline for applying
> specific SMTP EXTENDED response codes if it violates DKIM?
>

Senders of legitimate messages might find it useful to know why their
messages are being rejected.  Automation (list services, for example) might
find it useful to know the difference between a generic policy rejection
and a DKIM-specific one.  This also sets the stage for DMARC-based
rejections, detection of which is something MLMs sorely need, for example.

> What will happen if the server issues the INVALID vs MISSING extended

Both are potentially useful information for SMTP clients or message
generators of any kind.  They're certainly more descriptive than 5.7.0 or
5.7.1, which are generic.

That is the intent, yes.

> Is there a security loophole?

Do you have one in mind that isn't already called out in the document?

> In all cases, it is a about a rejection (55x) which all clients MUST treat
> the same (from a SMTP standpoint), so there is no violation.
>

The violation is one of DKIM's advice, as is already cited in the
document.  Specifically, if you bounce mail because of DKIM failures,
you're violating the SHOULD NOT of DKIM.

> "smarter?"

Nothing compels MTAs to use these codes, so of course they're optional.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Wed, 28 May 2014 08:05:35 -0400

On 5/27/2014 5:22 PM, Murray S. Kucherawy wrote:
> On Tue, May 27, 2014 at 1:53 PM, Hector Santos <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> messages are being rejected.  Automation (list services, for example)
> might find it useful to know the difference between a generic policy
> rejection and a DKIM-specific one.  This also sets the stage for
> DMARC-based rejections, detection of which is something MLMs sorely
> need, for example.

Then say so.  It is not a violation of RFC6376. What the draft should 
just point out is that the client must not treat the rejection any 
different otherwise it could open potential security loopholes.  Also 
we will have non-extended code servers and clients who will react to 
the 55x first as SHOULD all extended code software.   The text part is 
just part of the bounce/DSN, if any.

>     What will happen if the server issues the INVALID vs MISSING
>     extended response?
>
>
> generators of any kind.  They're certainly more descriptive than 5.7.0
> or 5.7.1, which are generic.

Its all subjective. Some will not want to offer this level of 
information. But the primary point the end result MUST be the same.

>     Will the client exploit/leverage this in a negative/positive manner?

All it can offer is a reason for a fail. That might help resolve a 
problem but I certainly hope it doesn't move mail into different 
in-boxes.  Ultimately, its a 55x pure SMTP rejection.

> Do you have one in mind that isn't already called out in the document?

If you client treats the responses differently, then there is a 
potential for a loophole.

>     In all cases, it is a about a rejection (55x) which all clients
>     MUST treat the same (from a SMTP standpoint), so there is no
>     violation.
>
>

The statement in DKIM originated when policy was "part of" the 
package.  When we did the truth tables, you can see the folding for 
both conditions as one.  It was also part of the threat analysis.  It 
about making sure there isn't a loophole by allowing the facsimile of 
a "invalid" signature change the perception for something good 
attempted, but failed.   Its ambiguity came when POLICY was pulled. So 
in DKIM, when you are talking about raw signing, it doesn't make any 
sense if POLICY is not discussed because you don't know what the 
intent of the originating, author domain.   You can't treat them 
differently only because of policy.  An invalid signature can include 
a valid but unauthorized 3rd party one and in that vain, per policy, a 
valid authorized 1st party signature is missing.

> Nothing compels MTAs to use these codes, so of course they're optional.

Right, but you have to design for this pure SMTP condition too.  All 
the proposal is doing is providing reasons which you now need to make 
sure that it make sense in updating the DMARC draft. It shouldn't be 
changing how clients react to a primary DKIM failure due to a policy.

I guess, I don't like the two clauses. The new one added regarding 
violation of DKIM. There is none and it doesn't make sense to being 
writing a guideline that purports to potentially violating another 
one.  And the one already there regarding local policy:

     .... contrary to local policy requirements.

Servers won't be (DKIM related) rejecting due to a local policy, but 
an author policy. It won't be based on a raw DKIM processing.  By 
using local policy, you are injecting the idea that its possible for a 
local policy to reject without a "standard" policy system in place 
when it comes to the extended responses you wish to expose.

The local policy requirement is to follow the standard first.  We need 
to stop trying to create different universes of mail systems using 
local policy excuses.  Of course, the local system will do what it 
wants, but it is first expected to follow the standard approach.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Wed, 28 May 2014 16:10:14 -0400

Murray, to be clear in my comment,  it would only be a "violation of 
DKIM" if the client treated any of the two proposed extended response 
codes differently from each other.

       X.7.19
       X.7.20

It is cleaner to remove the parenthetical violation statement, and 
make it a general intro description of both. I can't think of the 
proper wording  but something like:

   2.1. DKIM Failure codes:

   These response codes are possible reasons and conditions for failing
   DKIM verification when augmented with additional signing practices
   (reference Threat Analysis, DKIM overview, DMARC draft if possible)
   for which the local policy MAY support:

     IMPLEMENTATION NOTE:

     Per DKIM, RFC6376, SMTP clients SHOULD NOT treat either of these
     codes differently.  The extended information CAN be leveraged for
     extended purposes, but it MUST process the rejection as a temporary
     45z or permanent 55z response as if the extended information did not
     exist.

   ...

In addition, why not be specific with just 5.7.19 considerations?  If 
you open this to a temporary, then we get into new areas with 
Greylisting like discussion needs.  For example, for missing, it could be:

    450 4.7.19 Add a author domain signature and try again.

But of course, this isn't going to happen for this particular 
transaction. It will remain in the sender's outbound queue until the 
next attempt and it will repeat the temporary error for 3-5 days of 
attempts.

-- 
HLS

---

From: Barry Leiba <[email-masked]>
Date: Wed, 28 May 2014 16:36:51 -0400

> Murray, to be clear in my comment,  it would only be a "violation of DKIM"
> if the client treated any of the two proposed extended response codes
> differently from each other.
>
>       X.7.19
>       X.7.20

That is quite incorrect:

   In general, modules that consume DKIM verification output SHOULD NOT
   determine message acceptability based solely on a lack of any
   signature or on an unverifiable signature; such rejection would cause
   severe interoperability problems.

The text that's in this document now makes it clear that (1) this
isn't recommended behaviour and (2) in the end it's a policy thing,
not a DKIM thing.  I believe that text is clear, correct, and useful.

> It is cleaner to remove the parenthetical violation statement, and make it a
> general intro description of both.

I very much don't like the proposed change.

Barry

---

From: Ned Freed <[email-masked]>
Date: Wed, 28 May 2014 13:46:17 -0700 (PDT)

> not a DKIM thing.  I believe that text is clear, correct, and useful.

Mostly agreed. My only hesitation is that we really want people to use
the "rejected due to sender policy" code, and someone might read it as
"if I don't use the code then it's not a violation". But as you say,
the text really is clear that the violation lies in the behavior, not
the code, and I don't see a way to make it any clearer on this point.

> I very much don't like the proposed change.

Neither do I.

				Ned

---

From: Hector Santos <[email-masked]>
Date: Wed, 28 May 2014 17:03:09 -0400

>     severe interoperability problems.

I don't see the difference but its clear this statement came before 
POLICY was pulled from DKIM.  It only made sense under the context of 
policy. An existing but invalid signature was the same as a missing 
signature and most, if not all, there was only a few, the early DKIM 
APIs included that logic.  The whole point was to not generate a 
loophole with a fake signature.

It should be noted that it was highly debated, the statement above. 
The consensus SHOULD NOT suggest the problem goes away, it didn't.

> not a DKIM thing.  I believe that text is clear, correct, and useful.

I don't see how.  Its not clear to me.  It is only applicable to 
DKIM+POLICY frameworks and the reasons can be because the signature is 
missing or it calculated wrong due to author policy.  I won't be 
violating DKIM because both conditions are equal for rejection.

What you are saying that it could be WRONG to report it as two 
different conditions.  So any violation would be on the CLIENT side if 
it treats a 5.7.19 and 5.7.20 differently.  The doc does not say that.

> I very much don't like the proposed change.

Fine, but i don't understand the engineering philosophy here.  You are 
promoting people to use a CODE without the reasons why and saying it 
could be in violation of any another spec.  Maybe it should explain 
HOW it is not an violation and what does it take to be compliant with 
DKIM and still use these codes?

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Wed, 28 May 2014 17:40:24 -0400

> the code, and I don't see a way to make it any clearer on this point.

Its only a problem when a client would treat a 5.7.19 and 5.7.20 
differently.

>> I very much don't like the proposed change.

Then better text is needed.   Why will anyone use these codes that 
could "violate" DKIM?  I don't agree it does and the proof comes in 
the form of legacy support; hide, disable extended responses and just 
issue a 55x in each case:

    550 Missing: Author Domain Signature was missing
    550 Invalid: Author Domain require valid signature. None found
    550 Invalid: Author Domain requires authorized 3rd party 
signature: None found

Unless the client is going to do some intelligent meaning parsing of 
the text, it is expected to treat all 55x responses the same.

I don't think it is necessary to add this DKIM invalid/missing 
violation thing. It doesn't help at all and it certainly further 
contributes to adding confusion to the entire DKIM+POLICY thing the 
IETF needs to overcome.

DKIM-BASE is a raw unprotected signature protocol.  By itself, it 
offers no value. The market has proven this sans policy low payoff. It 
is 100% insecure and unprotected without a policy layer.  So all new 
issues is when applying policy.  We can reduce the confusion by owning 
up the the fact there are going to be many other reasons to report for 
DKIM failure once the receivers enable the POLICY switch in their 
implementations.   For example, these are the possible reasons for 
DKIM signature failures in our implementation. Its part of the 
AUTH-RES reporting too as comments.   Once the handling switch is 
turned on, it could be part of the SMTP responses. The AUTH-RES will 
not be created for these immediate rejections.

// DKIM Error codes
#define DKIM_SUCCESS						 0		// operation successful
#define DKIM_FAIL							-1		// verify error: message is suspicious
#define DKIM_BAD_SYNTAX					-2		// signature error: DKIM-Signature 
could not parse or has bad tags/values
#define DKIM_SIGNATURE_BAD					-3		// signature error: RSA verify failed
#define DKIM_SIGNATURE_BAD_BUT_TESTING		-4		// signature error: RSA 
verify failed but testing
#define DKIM_SIGNATURE_EXPIRED				-5		// signature error: x= is old
#define DKIM_SELECTOR_INVALID				-6		// signature error: selector 
doesn't parse or contains invalid values
#define DKIM_SELECTOR_GRANULARITY_MISMATCH	-7		// signature error: 
selector g= doesn't match i=
#define DKIM_SELECTOR_KEY_REVOKED			-8		// signature error: selector 
p= empty
#define DKIM_SELECTOR_DOMAIN_NAME_TOO_LONG	-9		// signature error: 
selector domain name too long to request
#define DKIM_SELECTOR_DNS_TEMP_FAILURE		-10		// signature error: 
temporary dns failure requesting selector
#define DKIM_SELECTOR_DNS_PERM_FAILURE		-11		// signature error: 
permanent dns failure requesting selector
#define DKIM_SELECTOR_PUBLIC_KEY_INVALID	-12		// signature error: 
selector p= value invalid or wrong format
#define DKIM_NO_SIGNATURES					-13		// process error, no sigs
#define DKIM_NO_VALID_SIGNATURES			-14		// process error, no valid sigs
#define DKIM_BODY_HASH_MISMATCH				-15		// sigature verify error: 
message body does not hash to bh value
#define DKIM_SELECTOR_ALGORITHM_MISMATCH	-16		// signature error: 
selector h= doesn't match signature a=
#define DKIM_STAT_INCOMPAT					-17		// signature error: incompatible v=
#define DKIM_UNSIGNED_FROM					-18		// signature error: not all 
message's From headers in signature
#define DKIM_OUT_OF_MEMORY					-20		// memory allocation failed
#define DKIM_INVALID_CONTEXT				-21		// DKIMContext structure invalid 
for this operation
#define DKIM_NO_SENDER						-22		// signing error: Could not find 
From: or Sender: header in message
#define DKIM_BAD_PRIVATE_KEY				-23		// signing error: Could not parse 
private key
#define DKIM_BUFFER_TOO_SMALL				-24		// signing error: Buffer passed 
in is not large enough
#define DKIM_POLICY_FAILURE      		    -25		// ADSP policy failure  // 
1.0.21.SSI.1

-- 
HLS

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 28 May 2014 23:48:07 +0200

>    severe interoperability problems.

So not solely. But I can base it on that and something else? Ie. I can't 
demand a signature in general and reject solely based on its lack, but I 
can demand a signature if the From field matches a manually configured 
list?

If I can do that, then x.7.19/20 are sensible ways to report that I do.

Arnt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 28 May 2014 15:22:46 -0700

> Its only a problem when a client would treat a 5.7.19 and 5.7.20
Why would they?  The SMTP reply code is unchanged.  Enhanced status codes
simply provide additional information; they don't change the state
machine.  Moreover, there's an opportunity to provide more precise
information to end users who want to know why their mail was not allowed to
go through.

> Then better text is needed.   Why will anyone use these codes that could
> "violate" DKIM?

For better or worse, some people do violate DKIM in the way described, be
it in conjunction with ADSP or DMARC, or as a local policy decision totally
independent of any protocol.  For those that do, it's helpful to clients
(and especially to users) to indicate the cause of the failure more
specifically than just 550 5.7.1 or something like that.   That's the
purpose of this.

It's pretty obvious that this sort of information, namely the distinction
between an authentication-related bounce and other bounces, is going to be
very useful as things like DMARC get rolled out, and reducing unpleasant
side effects becomes important.

>  I don't agree it does and the proof comes in the form of legacy support;
> hide, disable extended responses and just issue a 55x in each case:
>
>    550 Invalid: Author Domain requires authorized 3rd party signature:
> None found
>
> Unless the client is going to do some intelligent meaning parsing of the
> text, it is expected to treat all 55x responses the same.
>

Nobody's advocating for different client treatment, as far as I can tell.

-MSK

---

From: Barry Leiba <[email-masked]>
Date: Wed, 28 May 2014 18:36:00 -0400

> demand a signature in general and reject solely based on its lack, but I can
> demand a signature if the From field matches a manually configured list?
>

Indeed, which is why I think the current version of the document (-01) works.

Barry