Subject: Re: [apps-discuss] draft-ietf-appsawg-rfc7001bis s2.7.1

From: t.petch <[email-masked]>
Date: Thu, 12 Mar 2015 11:47:07 +0000

s2.7.1  is fine for DKIM which is well covered in RFC6376 but I do not
think that the same can be said for DomainKeys and RFC4870.

 I think the gulf too wide and would add a small bridge, such as
OLD
   DomainKeys is defined in [DOMAINKEYS]  and is represented by the
   "domainkeys" method.
NEW
   DomainKeys is defined in [DOMAINKEYS]  and is represented by the
   "domainkeys" method.  The relevant section for this specification is
section 3.3 on the "DomainKey-Signature" header.

[assuming I have understood aright]

Tom Petch

----- Original Message -----
From: "t.petch" <[email-masked]>
To: "Murray S. Kucherawy" <[email-masked]>; "IETF Apps Discuss"
<[email-masked]>
Sent: Thursday, March 12, 2015 11:42 AM
Subject: draft-ietf-appsawg-rfc7001bis s6.2

> Um
>
> s 6.2 contains a lot of good information but I struggle to see an IANA
> Consideration in there.  Is the intention that the reference for
"Email
> Authentication Methods" be updated to this I-D?   If so, I think that
> that needs saying.
> Also, if that is the only action, then again worth saying to stop IANA
> ploughing through this lengthy section to try and find another action.
> Also, registries can be very hard to find if you do not know the group
> so again worth saying.
>
> So I would start with
>
> NEW
> The "Email Authentication Methods" Registry  is part of the "Email
> Authentication Parameters" group.  IANA is requested to update the
> reference for that registry to point to this I-D.  That is the only
> change requested by this section.
>
> Tom Petch
>
>
> ----- Original Message -----
> From: "Murray S. Kucherawy" <[email-masked]>
> To: "IETF Apps Discuss" <[email-masked]>
> Sent: Monday, March 09, 2015 9:34 PM
> Subject: Re: [apps-discuss] I-D Action:
> draft-ietf-appsawg-rfc7001bis-03.txt
>
>
> > On Mon, Mar 9, 2015 at 2:32 PM, <[email-masked]> wrote:
> >
> > >
> > > 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           : Message Header Field for Indicating
> Message
> > > Authentication Status
> > >         Author          : Murray S. Kucherawy
> > >         Filename        : draft-ietf-appsawg-rfc7001bis-03.txt
> > >         Pages           : 46
> > >         Date            : 2015-03-09
> > >
> > > Abstract:
> > >    This document specifies a message header field called
> Authentication-
> > >    Results for use with electronic mail messages to indicate the
> results
> > >    of message authentication efforts.  Any receiver-side software,
> such
> > >    as mail filters or Mail User Agents (MUAs), can use this header
> field
> > >    to relay that information in a convenient and meaningful way to
> users
> > >    or to make sorting and filtering decisions.
> > >
> >
> > This is an attempt to address the concerns expressed, especially by
> John
> > Levine and Tom Petch.  John has seen it and says it resolves his
> concerns.
> > Everyone, and Tom in particular, do you agree that this is how it
> should
> > look?
> >
> > -MSK
> >
>
>
> ----------------------------------------------------------------------
--
> --------
>
>
> > _______________________________________________
> > apps-discuss mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/apps-discuss
> >
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 12 Mar 2015 15:03:26 -0700

> section 3.3 on the "DomainKey-Signature" header.

I think you need to know more than what Section 3.3 of RFC4870 says.  That
section just gives the syntax of a DomainKey-Signature header field, but
doesn't go into how you go about figuring out "pass" vs. "fail", for
example.  I think the more general reference is better.

Also, Section 2.7.1 seems to me to be equally balanced between DKIM and
DomainKeys.

-MSK

---

From: t.petch <[email-masked]>
Date: Fri, 13 Mar 2015 15:40:34 +0000

s2.7.2 I find problematic

Ironically, SPF is described comprehensively, which in a way it does not
need since RFC7208 does a good job, mostly.

sender-id, on the other hand, is poorly served in this context by
RFC4406 and is likewise hard to understand from what is here.

Interleaving the comprehensive description of SPF with the sparse
references to sender-id compounds the problem.  Yes they are closely
related and belong in the same section but interleaving the descrptions
confuses me - I would have all the SPF material first and then the
sender-id, each part complete in itself.

When it says
"  Similarly, the results for Sender ID are listed and described in
   Section 4.2 of [SENDERID], which in turn uses the SPF definitions
   that now appear in [SPF]."
Well no. [SENDERID] is RFC4406 and no way does it use [SPF] which is
RFC7208.  The latter could have updated the former, but it didn't!

For PRA, I would like to see the relevant header fields named, just to
make it easier to find your way around RFC4407, which I think is

Resent-Sender Resent-From Received Return-Path Sender From

And tied to this, I think that s6.4 is asking a lot of IANA.  It is
titled
"Email Authentication Result Names" Registry
but the last paragraph says
" The definitions for the SPF and Sender ID authentication >methods< are
   to be updated using the references found in Section 2.7.2."
and as ever, this is trivial for SPF, a big ask for sender-id.  I think
that sender-id needs the same results table and references in 2.7.2 as
SPF has got

So I would have something like
================================================
The "sender-id" method is described in [SENDERID]

   For Sender ID, the ptype used is "header", and the
   property will be the name of the header field from which the
   Purported Responsible Address (see [PRA]) was extracted, namely
"Resent-Sender" "Resent-From" "Received" "Return-Path" "Sender" "From"

The results for Sender ID are listed and described in
Section 4.2 of [SENDERID], but for the purposes of this specification,
the SPF definitions that now appear in [SPF] should be used instead

Those definitions are included here by reference:

     +-----------+--------------------------------+
     |    Code   | Meaning                        |
     +-----------+--------------------------------+
     | none      | [RFC7208], Section 2.6.1       |
     +-----------+--------------------------------+
     | pass      | [RFC7208], Section 2.6.3       |
     +-----------+--------------------------------+
     | fail      | [RFC7208], Section 2.6.4       |
     +-----------+--------------------------------+
     | softfail  | [RFC7208], Section 2.6.5       |
     +-----------+--------------------------------+
     | policy    | [this RFC], Section 2.4        |
     +-----------+--------------------------------+
     | neutral   | [RFC7208], Section 2.6.2       |
     +-----------+--------------------------------+
     | temperror | [RFC7208], Section 2.6.6       |
     +-----------+--------------------------------+
     | permerror | [RFC7208], Section 2.6.7       |
     +-----------+--------------------------------+

===============================================
with the last two paragraphs as at present.

 If I have got this wrong, well, what more need I say?

Tom Petch

---

From: t.petch <[email-masked]>
Date: Sat, 14 Mar 2015 21:07:13 +0000

----- Original Message -----
From: "Murray S. Kucherawy" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "IETF Apps Discuss" <[email-masked]>
Sent: Thursday, March 12, 2015 10:03 PM
> Also, Section 2.7.1 seems to me to be equally balanced between DKIM
and

True!  It is RFC6376 and RFC4870 that I find unbalanced, that is,
s.2.7.1 plus RFC6376 tells me all I need to know, which s.2.7.1 plus
RFC4870 does not, which is not surprising because RFC4870 was written
without any consideration for an "Authentication-Results:" (naturally
enough).  Which is why I have been looking for more in s.2.7.1. to help
the reader bridge the gap in order to find what they want in RFC4870.

Tom Petch

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 15 Mar 2015 00:47:03 -0700

> the reader bridge the gap in order to find what they want in RFC4870.

OK, but it seems to me the key bits in both are:

- how to verify a signature, and thus what constitutes a "pass"
- the domain that signed it, pulled from the "d" tag (DK doesn't have an
"i" tag)

Those are the key things that go in an Authentication-Results field.  Both
documents do specify that.  So which key details does RFC6376 have that
RFC4870 doesn't?

I realize I'm quite possibly looking at this from too close, so I
appreciate the help in seeing what's deficient here.

-MSK

---

From: t.petch <[email-masked]>
Date: Sun, 15 Mar 2015 09:51:23 +0000

Murray

To flesh out what I mean

- s.2.7.1 says  "Both DKIM and DomainKeys use the same result set" and
goes on to list
  none:     pass:     fail:     policy:    neutral:     temperror:
permerror:
while RFC4870 offers results of
 "good"    "bad"   "no key"   "revoked" "no signature"  "bad format"
"non-participant"
I struggle to see this as the same result set.

- the value field in the IANA registry for dkim-adsp mentions 'From:'
and I note the trailing colon and appreciate its significance.  The
value field for domainkeys has 'From' and 'Sender' without that colon.
Significant?  I don't know whether the colon-less version is meant to be
the e-mail header field or something else related to it.  Which leads
me on to RFC4870 s3.1 which has a discussion on what to do when 'From'
and/or 'Sender' appear as e-mail header fields.  If s3.1 deems 'From:'
(and it always uses colons) unacceptable, can it still appear as part of
an 'E-mail Authentication Method'or is it barred from that?

- and then the IANA registry only lists a property of 'd' with a ptype
of  'header' whereas rfc7001 bis has 'DKIM-style values (e.g., "d"
represents  ...)'.  e.g. means an example to me, one of many, RFC4870
lists other values, the IANA registry only lists one.  Is 'd' the only
valid value?  If so, I think that that 'e.g.' is wrong.

- ditto for a property of  'From' or 'Sender' with a ptype of 'header'.
Again, rfc7001bis has 'e.g.' implying other values are possible, and
RFC4870 has other values, but the IANA registry just has those two.
I would like that clarified.

- and then there is
'DomainKeys results are reported using the "header" ptype, but a
   mixture of DKIM-style values (...) and typical uses
   (........). '
which does not parse in my grammar (your grammar may be different:-)

As I say, I see a gulf between the IANA registry and RFC4870 which needs
more of a bridge than rfc7001bis currently provides.

Tom Petch

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 16 Mar 2015 14:19:19 -0700

> I struggle to see this as the same result set.

-04 now makes it clear that the result set in RFC4870 is plainly not used
in the context of this header field.

> an 'E-mail Authentication Method'or is it barred from that?

This seems like a stylistic distinction rather than a semantic one.  What,
for example, is the difference between "From header field" and "From:
header field"?

Are you just looking to have the registry entries for domainkeys changed
such that they look like the DKIM ones?  They read pretty much the same to
me, but I can certainly do that if it would help.

> valid value?  If so, I think that that 'e.g.' is wrong.

Removed "e.g.".

> I would like that clarified.

Removed "e.g.".

>    mixture of DKIM-style values (...) and typical uses

Reworded to:

DomainKeys results are reported using the "header" ptype, but the property
can be either the name of a DKIM tag ("d" represents the value of the "d"
tag from the DomainKey-Signature header field) or the name of a relevant
header field ("from" or "sender, containing those header fields' values,
per Section 3.1 of [DOMAINKEYS]).  In the latter case, [MAIL]-style
comments are removed, leaving only the address; moreover, the local-part of
the address is removed if it has not been authenticated in some way.

> more of a bridge than rfc7001bis currently provides.

Does this clarify sufficiently?

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 16 Mar 2015 17:23:03 -0400

> the address is removed if it has not been authenticated in some way.

Shouldn't that be a DK tag vice DKIM since we're on DK, not DKIM here?

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 16 Mar 2015 14:59:22 -0700

> Shouldn't that be a DK tag vice DKIM since we're on DK, not DKIM here?

Quite right, fixed.

-MSK

---

From: t.petch <[email-masked]>
Date: Tue, 17 Mar 2015 10:19:30 +0000

----- Original Message -----
From: "Murray S. Kucherawy" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "IETF Apps Discuss" <[email-masked]>
Sent: Monday, March 16, 2015 9:19 PM
> Does this clarify sufficiently?

Much clearer, with those colons added please to the entries in the IANA
Registry..

The one lingering doubt is RFC4870 s3.1 which has a discussion on what
to do when 'From' and/or 'Sender' appear as e-mail header fields.  If
s3.1 deems 'From:' unacceptable, can it still appear as part of an
'E-mail Authentication Method'?  Or is the idea that 'From:' can only
appear if it passes the tests in RFC4870 s3.1?

I don't know what the answer it to that one.

Tom Petch

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 17 Mar 2015 23:12:33 -0700

> I don't know what the answer it to that one.

3.1 explains how to select the message sender (as the term is used in
RFC4870) from one of two header fields.  The intent with A-R is to report
the sender address and which header field it came from.  I've update the
text to say so.

While I'm at it, I also cleaned up the Result Names registry which seems to
have gotten into a confused state, and marked the ADSP and DomainKeys
entries in both registries as "deprecated" since their defining RFCs are
also in that state.

I'll post -04 once the embargo lifts on Monday.

-MSK