Subject: [apps-discuss] Pete Resnick's Discuss on draft-ietf-appsawg-email-auth-codes-05: (with DISCUSS)

From: "Pete Resnick" <[email-masked]>
Date: Mon, 04 Aug 2014 18:35:10 -0700

Pete Resnick has entered the following ballot position for
draft-ietf-appsawg-email-auth-codes-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-appsawg-email-auth-codes/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

We might be able to clear this up with an explanation rather than a
change of the text, but I wanted to make sure:

I was comparing the descriptions in section 3.1 to the descriptions in
RFC 7001 section 2.6.1 and I'm left a bit confused.

- When is X.7.20 expected to be returned? Would you use it for "none",
"fail", "neutral", "temperror", "permerror", or more than one of those?
The way it is worded, you could read it as saying this is only for the
"neutral" case (i.e., the signature is there but not valid), but I could
also see sending it back for "none". What was the intention?

- X.7.21 says it's for the author not matching case, but I would think
that this should be generalized for *any* of the RFC 7001 "policy" cases.
Do you really intend it only to be used for the particular policy case of
no author match? If so, are we going to need other error codes later for
other policy cases?

Perhaps this could be cleared up with some specific discussion of the
2.6.1 cases in regard to the use of these codes. But as-is, I'm not sure
they are going to be used interoperably without further explanation.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 4 Aug 2014 19:54:39 -0700

> also see sending it back for "none". What was the intention?

x.7.20 is for the situation where the message contained no valid signature
at all.  In terms of RFC 7001, it could be used for "none" (the message
wasn't signed), "fail" (there was a valid signature but it failed to
verify), "policy" (there was a valid signature but, for example, it didn't
cover some header field the verifier requires to be covered per local
policy; for example, there's at least one verifier implementation that
considers Subject mandatory), "neutral" (there was a signature, but it was
syntactically invalid), or "permerror" (there was a signature, but the
public key to which it referred was malformed, or it didn't cover the From
field as required by RFC 6376).

> no author match? If so, are we going to need other error codes later for

x.7.21 is intended to reflect the vaguely more specific and common case
that there was no valid signature for which the "d=" tag (signing domain)
matched the From field domain(s).  Put another way, you would see this if
it the message was signed only by some third party, or where the verifier
actually wants to reveal that this is a specific local policy requirement.
Ever since early DKIM implementations, some operators have chosen to make
this a requirement, so it's called out specifically here.  For any other
policy case, the intent is to use x.7.20.

> they are going to be used interoperably without further explanation.

How's that?  :-)

-MSK

---

From: Pete Resnick <[email-masked]>
Date: Mon, 4 Aug 2014 23:20:10 -0500

On 8/4/14 9:54 PM, Murray S. Kucherawy wrote:
> On Mon, Aug 4, 2014 at 6:35 PM, Pete Resnick 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
> x.7.20 is for the situation where the message contained no valid 
> signature at all.  In terms of RFC 7001, it could be used for "none" 
> (the message wasn't signed), "fail" (there was a valid signature but 
> it failed to verify), "policy" (there was a valid signature but, for 
> example, it didn't cover some header field the verifier requires to be 
> covered per local policy; for example, there's at least one verifier 
> implementation that considers Subject mandatory), "neutral" (there was 
> a signature, but it was syntactically invalid), or "permerror" (there 
> was a signature, but the public key to which it referred was 
> malformed, or it didn't cover the From field as required by RFC 6376).
>
> x.7.21 is intended to reflect the vaguely more specific and common 
> case that there was no valid signature for which the "d=" tag (signing 
> domain) matched the From field domain(s).  Put another way, you would 
> see this if it the message was signed only by some third party, or 
> where the verifier actually wants to reveal that this is a specific 
> local policy requirement.  Ever since early DKIM implementations, some 
> operators have chosen to make this a requirement, so it's called out 
> specifically here.  For any other policy case, the intent is to use 
> x.7.20.
>

Aha. That wasn't clear to me from the current text. I took "valid" to 
only be referring to passing the basic DKIM verification algorithms. I 
didn't realize that not passing local policies was a reason to send back 
X.7.20. Perhaps you could clarify the text?

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 4 Aug 2014 21:22:14 -0700

On Mon, Aug 4, 2014 at 9:20 PM, Pete Resnick <[email-masked]>
wrote:

>
> Aha. That wasn't clear to me from the current text. I took "valid" to only
> be referring to passing the basic DKIM verification algorithms. I didn't
> realize that not passing local policies was a reason to send back X.7.20.
> Perhaps you could clarify the text?
>
>
How's this for a new Section 3.1?:

3.1.  DKIM Failure Codes

   In the code point definitions below, the term "acceptable" means both
   of the following:

   a.  The signature passed the basic DKIM verification algorithm as
       defined in [RFC6376]; and

   b.  The signature satisfied any local policy requirements in addition
       to the basic algorithm (e.g., certain header fields included in
       the signed content, no partial signatures, etc.).

      Code:               X.7.20
      Sample Text:        No valid DKIM signature found
      Associated basic status code:  550
      Description:        This status code is returned when a message
                          did not contain any acceptable DKIM
                          signatures.  (Note that this violates the
                          advice of Section 6.1 of RFC6376.)
      Reference:          [this document]; RFC6376
      Submitter:          M. Kucherawy
      Change controller:  IESG

      Code:               X.7.21
      Sample Text:        No valid author-matched DKIM signature found
      Associated basic status code:  550
      Description:        This status code is returned when a message
                          did not contain any acceptable DKIM
                          signatures whose identifier(s) match the
                          author address(es) found in the From header
                          field.  (Note that this violates the advice
                          of Section 6.1 of RFC6376.)  This is a
                          special case of the X.7.20 status code.
      Reference:          [this document]; RFC6376
      Submitter:          M. Kucherawy
      Change controller:  IESG

---

From: Pete Resnick <[email-masked]>
Date: Mon, 4 Aug 2014 23:26:25 -0500

On 8/4/14 11:22 PM, Murray S. Kucherawy wrote:
> On Mon, Aug 4, 2014 at 9:20 PM, Pete Resnick 
>     Aha. That wasn't clear to me from the current text. I took "valid"
>     to only be referring to passing the basic DKIM verification
>     algorithms. I didn't realize that not passing local policies was a
>     reason to send back X.7.20. Perhaps you could clarify the text?
>
>
> How's this for a new Section 3.1?

Much clearer. I'll remove my DISCUSS in the morning, unless Barry wants 
me to leave it for housekeeping purposes; I'll assume that you all can 
decide on the specifics. Thanks for DISCUSSing it.

pr

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 4 Aug 2014 21:28:47 -0700

On Mon, Aug 4, 2014 at 9:26 PM, Pete Resnick <[email-masked]>
wrote:

>
> Much clearer. I'll remove my DISCUSS in the morning, unless Barry wants me
> to leave it for housekeeping purposes; I'll assume that you all can decide
> on the specifics. Thanks for DISCUSSing it.
>
>
Likewise, I'm happy to post the update to the tracker now or wait until
after the telechat.  I'll assume the latter unless directed otherwise.

-MSK

---

From: Barry Leiba <[email-masked]>
Date: Tue, 5 Aug 2014 09:30:46 -0400

Go ahead and post: we're big girls and boys, and can deal with I-D versions.

Barry

On Tuesday, August 5, 2014, Murray S. Kucherawy <[email-masked]> wrote:

> On Mon, Aug 4, 2014 at 9:26 PM, Pete Resnick <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>>

---

From: Terry Zink <[email-masked]>
Date: Tue, 5 Aug 2014 16:35:41 +0000

This is a style nitpick and you can feel free to ignore. I have one complaint/suggestion regarding this text:

The first two words of the phrases "Note that this violates the advice..." is redundant and superfluous [1]. In writing, if you have something to note, then note it; don't say "Note that..." In other words, I propose the shorter text "This violates the advice...".

-- Terry

[1] Note that the words "and superfluous" is redundant in that sentence.

From: apps-discuss [mailto:[email-masked]] On Behalf Of Pete Resnick
Sent: Monday, August 4, 2014 9:26 PM
To: Murray S. Kucherawy
Cc: [email-masked]; [email-masked]; The IESG; IETF Apps Discuss
Subject: Re: [apps-discuss] Pete Resnick's Discuss on draft-ietf-appsawg-email-auth-codes-05: (with DISCUSS)

On 8/4/14 11:22 PM, Murray S. Kucherawy wrote:
On Mon, Aug 4, 2014 at 9:20 PM, Pete Resnick <[email-masked]<mailto:[email-masked]>> wrote:

Aha. That wasn't clear to me from the current text. I took "valid" to only be referring to passing the basic DKIM verification algorithms. I didn't realize that not passing local policies was a reason to send back X.7.20. Perhaps you could clarify the text?

Much clearer. I'll remove my DISCUSS in the morning, unless Barry wants me to leave it for housekeeping purposes; I'll assume that you all can decide on the specifics. Thanks for DISCUSSing it.

pr

3.1.  DKIM Failure Codes

      Code:               X.7.20

      Code:               X.7.21

[email-masked]<mailto:[email-masked]>

--

Pete Resnick <http://www.qualcomm.com/~presnick/><http://www.qualcomm.com/~presnick/>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 5 Aug 2014 11:15:18 -0700

On Tue, Aug 5, 2014 at 9:35 AM, Terry Zink <[email-masked]>
wrote:

>  This is a style nitpick and you can feel free to ignore. I have one
> complaint/suggestion regarding this text:
>
>
>
>  The first two words of the phrases “Note that this violates the advice…”
> is redundant and superfluous [1]. In writing, if you have something to
> note, then note it; don’t say “Note that…” In other words, I propose the
> shorter text “This violates the advice…”.
>

Thanks for the suggestion.  If there's another version of the draft, I'll
remove it.  There's adequate discussion of what's going on in the following
section anyway.  If there's no new version, Barry can have the RFC Editor
make that adjustment if he's so inclined.

-MSK

---

From: S Moonesamy <[email-masked]>
Date: Wed, 06 Aug 2014 17:51:08 -0700

Hi Murray,
At 19:54 04-08-2014, Murray S. Kucherawy wrote:
>example, it didn't cover some header field the verifier requires to 
>be covered per local policy; for example, there's at least one 
>verifier implementation that considers Subject mandatory), "neutral" 
>(there was a signature, but it was syntactically invalid), or 
>"permerror" (there was a signature, but the public key to which it 
>referred was malformed, or it didn't cover the From field as 
>required by RFC 6376).

This is an individual comment.

I read Section 3.1 of draft-ietf-appsawg-email-auth-codes-06 again 
and I found it a little confusing.  The sample text says: "No valid 
DKIM signature found".  This is where I read Section 6.1 of RFC 6376 
to find out what is valid.  Note that there is only one DKIM 
verification algorithm.  The change between -05 and -06 is the 
emphasis on the term "acceptable" and introduces "basic DKIM 
verification algorithm".  The definitions (a) and (b) defines 
"acceptable" and the code says "anything that is not that".

My quick suggestion would be to change "valid" to "acceptable" in the 
"Sample Text" and avoid introducing "basic algorithm" in (a) and (b).

Regards,
S. Moonesamy