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

["John R Levine" <[e-mail]>]

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

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

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

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

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