Re: [dmarc-ietf] [taugh.com-standards] Benjamin Kaduk's Discuss on draft-ietf-dmarc-eaiauth-04: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

Hi John,

On Fri, Apr 05, 2019 at 01:50:15PM -0400, John R Levine wrote:
> On Fri, 5 Apr 2019, Benjamin Kaduk via Datatracker wrote:
> > 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?
> 
> 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".

> lists a set of things to allow, not to forbid, so that the most that will 
> happen is that an address won't authenticate.
> 
> > 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).
> 
> 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.

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.

> > 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?
> 
> Yes.

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

> > 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"
> 
> > Is there any risk that an intermediary will reencode the domain name and
> > 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.

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

> >   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?
> 
> Good catch, the ref to 6.7 is left over from an earlier version where this 
> draft also updated the Authentication-Results spec.

Ah, that makes sense.

Thanks,

Ben