Subject: [dmarc-ietf] Benjamin Kaduk's Discuss on draft-ietf-dmarc-eaiauth-04: (with DISCUSS and COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Fri, 05 Apr 2019 10:25:57 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-dmarc-eaiauth-04: 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 https://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:
https://datatracker.ietf.org/doc/draft-ietf-dmarc-eaiauth/

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

Thanks for this document; it's good to improve the clarity and precision
of how various pieces of the ecosystem interact.  That said, I do have a
couple of potential issues that need to be addressed prior to
publication:

I'm not sure I fully understand the security consequences of causing
the SPF macros %{s} and %{l} to never match when the local-part contains
non-ASCII characters, but they seem potentially quite bad.  That is, if
the policy is intending to limit allowed senders to a specific list (or
block specific senders), would an attacker be able to avoid the
restriction by using a non-ASCII local-part?

I'd also like to discuss whether we need greater specificity in the
nature of the updates applied to the Updates:'d documents.  For example,
Section 6 (of this document) says that Xection X [of RFC7489] is updated
"to say that all U-labels in domains are converted to A-labels before
further processing", but most of those referenced sections contain
step-by-step listings of a procedure to follow.  It doesn't seem like
much of a burden for us to say "between steps X and X+1, insert the
following step: "[convert domain from U-label to A-label]", and that has
a potentially significant gain in clarity to the reader (and thus,
interoperability).

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 2

That's not the actual boilerplate text from RFC8174; please just
copy/paste the appropriate snippet.

Section 3

   In headers in EAI mail messages, domain names that were restricted to
   ASCII can now be U-labels, and mailbox local parts can be UTF-8.

nit: "can now" implies some previous baseline state, but that reference
for comparison is not especially clear just from context.

Section 5

I'm having a hard time following this paragraph:

   Section 3.5 of [RFC6376] states that IDNs in the d=, i=, and s= tags
   of a DKIM-Signature header MUST be encoded as A-labels.  This rule is
   relaxed only for internationalized messages headers [RFC6532] so IDNs
   SHOULD be represented as U-labels but MAY be A-labels.  This provides
   improved consistency with other headers.  The set of allowable
   characters in the local-part of an i= tag is extended as described in
   [RFC6532].  When computing or verifying the hash in a DKIM signature
   as described in section 3.7, the hash MUST use the domain name in the
   format it occurs in the header.

Is "this rule is relaxed" a new policy as of this document?  RFC 6532
does not mention an "i=" tag anywhere, so I feel like we may need
greater detail on what behavior from 6532 we're pulling in.  (Are we
just intending to add the UTF8-non-ascii block as valid ABNF for the RHS
of the "i=" tag?)

Is there any risk that an intermediary will reencode the domain name and
cause the signature validation to fail?

Section 6

   DMARC [RFC7489] defines a policy language that domain owners can
   specify for the domain of the address in a RFC5322.From header.

nit: the formatting looks weird

   Section 6.6.1 specifies, somewhat imprecisely, how IDNs in the
   RFC5322.From address domain are to be handled.  [...]

(ditto)
Also, a bare "Section 6.6.1" normally refers to the current document, so
repeating RFC 7489 is probably in order.

(Same for the other Section references in this section.)

   A-labels before further processing.  Sections 6.7 and 7.1 are
   similarly updated to say that all U-labels in domains being handled
   are converted to A-labels before further processing.

I don't really see a procedural listing described in Section 6.7 of RFC
7489; can you point me to where this conversion to A-labels is supposed
to happen?

Section 8

(Depending on how the first DISCUSS point is resolved, we may be adding
some new threats that need to be covered.)

---

From: "John R Levine" <[email-masked]>
Date: 5 Apr 2019 13:50:15 -0400

> restriction by using a non-ASCII local-part?

Approximately nobody uses those macros even for ASCII addresses.  SPF 
lists a set of things to allow, not to forbid, so that the most that will 
happen is that an address won't authenticate.

> a potentially significant gain in clarity to the reader (and thus,

There are a fair number of people in the WG who implement this stuff and 
nobody has said it's hard to follow.  I'm not inclined to add verbiage 
just for the sake of doing so.

> Is "this rule is relaxed" a new policy as of this document?

Yes.

> RFC 6532 does not mention an "i=" tag anywhere, ...

I suppose I could say "as in the description of local parts of e-mail 
addresses as in RFC 6532"

> cause the signature validation to fail?

No more than there has been all along.  Intermediaries can do all sorts of 
bad stuff to mail messages althrough for the most part they don't.

> 7489; can you point me to where this conversion to A-labels is supposed

Good catch, the ref to 6.7 is left over from an earlier version where this 
draft also updated the Authentication-Results spec.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 5 Apr 2019 13:09:45 -0500

Hi John,

> Approximately nobody uses those macros even for ASCII addresses.  SPF 

I gathered that.  But if they're still in the spec, we need to properly
document their behavior (and any security consequences of the choices we
made).  I would probably be okay with a generic recommendation to not use
these and an acknowledgment in the security considerations that there are
extra considerations if they are used.  But I don't think you can hand-wave
away the potential risk just by saying "no one really uses these so we'll
ignore them".

> just for the sake of doing so.

With all due respect, if the only people we cared about were people in the
WG, why would we need to publish this as an RFC?

The whole premise of rigorous specifications is that anyone can jump in to
the ecosystem and implement something that interoperates, and in my opinion
the current presentation is not very accomodating to such a participant.
I'm happy to continue having a discussion, including with my fellow IESG
members, about what standards of clarity we expect for IETF-stream
documents.

> > Is "this rule is relaxed" a new policy as of this document?

Maybe "hereby relaxed" or "this document relaxes this rule" or similar
would help me be confident in that as the correct interpretation.

> bad stuff to mail messages althrough for the most part they don't.

Right.  But we don't, say, know of any current implementations that try to
canonicalize the representation of the domain name, for example?

> draft also updated the Authentication-Results spec.

Ah, that makes sense.

Thanks,

Ben

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 05 Apr 2019 14:20:23 -0400

> restriction by using a non-ASCII local-part?

For the working group's consideration:

I think this part of the discuss is a result of the draft appearing to specify 
a change in behavior for SPF, when all it's really doing is documenting the 
consequences of how EAI, SPF, and DNS interact.

There's no change in security considerations because there's no change in the 
protocol.  We're merely more clearly documenting the interaction.  I'll leave 
it to the chairs/author/shepherd to decide how to respond to the discuss, but 
I think "we're just documenting how it implicitly works" is a more likely road 
to success than "meh, no one really uses that".

Scott K

---

From: "John R Levine" <[email-masked]>
Date: 5 Apr 2019 14:45:33 -0400

> the current presentation is not very accomodating to such a participant.

We seem to have a fairly basic disagreement of who "anyone" would be. 
I'm assuming, and I think the WG is assuming, that the audience for this 
document is people who are already somewhat familiar with SPF or DKIM or 
DMARC.  It appears that you believe it is possible to add enough 
mechanical detail that even someone who knows nothing about them could 
make these changes.  That seems awfully optimistic.

I don't fault you for not being an SPF or DKIM expert but I really don't 
think it is useful to add a lot of stuff that any plausible reader already 
knows.

Regards,

---

From: Barry Leiba <[email-masked]>
Date: Fri, 5 Apr 2019 15:54:28 -0400

I had this discussion many times in my previous time as AD.  The
bottom line is that we can't explicitly specify everything, and need
to strike a reasonable balance between making things clear to *anyone*
and making things clear only to experts, or those who were around when
the document was written.  The balance is usually to aim the text to
someone reasonably well versed in the area we're talking about --
short of an expert, but farther along than a beginner.

Ben, I really do think the text you're talking about is fine, given
that balance.  One can't implement this without implementing the other
related technology first: SPF, DKIM, DMARC, SMTP....  If this text is
beyond one, one would never have gotten this far anyway, because one
would have been stumped by knottier questions one doesn't have the
background to deal with.

So, yeah, we can insist on tweaking that text to make a few things
more explicit, but it would not actually improve the document in a
meaningful way.

(One thing I'll pick at that I missed before, John:  The phrasing
"SHOULD do X but MAY do Y" doesn't really work: taken strictly, the
MAY weakens the SHOULD.  I would take the second key word out, and say
"SHOULD do X but Y is permitted <some brief explanation of what
circumstances>.")

Barry

---

From: "John R Levine" <[email-masked]>
Date: 5 Apr 2019 18:05:36 -0400

> "SHOULD do X but Y is permitted <some brief explanation of what

OK, fixed that and Ben's catch of a dangling section ref in -05.

Regards,

---

From: "John Levine" <[email-masked]>
Date: 5 Apr 2019 20:21:50 -0400

>to success than "meh, no one really uses that".

Oh, of course.  What I was trying to say was that's why we didn't try
to invent a way to make it work with EAI mailboxes.

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 11 Apr 2019 12:52:07 -0500

[consolidating the postscript back in]

> make these changes.  That seems awfully optimistic.

Well, that wasn't really my intent in making the comment.  Rather, that it
feels sloppy to be so informal.  It may not cause problems here, but on
the other hand, even people who know things can have off days; sloppiness
can also become a habit and creep into places where it does have a real
impact.  I've seen plenty of those even in just one year on the IESG, and
try to exert some general backpressure, though I hope that I limit the
blocking backpressure to cases where it does actually matter.

In this particular case, I said "I would like to discuss" the topic, and we
have had a discussion.  Your and Barry's arguments have convinced me that
no change is needed here, so I will reballot and remove that point, since
the discussion has occurred.

On Fri, Apr 05, 2019 at 02:57:55PM -0400, John R. Levine wrote:
> PS:
> Sure we do, some still replace CNAMEs with the target as described in RFC 
> 1123.  But what does that have to do with internationalized mail?  It 
> sounds like you're thinking that an intermediary will turn U-labels into 
> A-labels or the like, which would require an extremely perverse misreading 
> of the EAI RFCs.
> 
> Again, I don't fault you for not being an EAI expert, but again, this is 
> stuff that anyone working in the area would know.

Well, that's why I am asking questions instead of telling you how to write
the document.  And when you keep making that sort of response to my
questions, it starts to come across like you're asking me to abdicate my
responsibility as an AD to apply faithful review to the documents in front
of the IESG, and instead just trust the experts in the WG to have done the
right thing.  I intend to continue to do my job, and I hope that the
community will support me in that, including by filling the gaps in my
knowledge as relevant.

-Ben