[dkim-dev] [ietf-dkim] Authorizing List Domains

[Murray S. Kucherawy]

> -----Original Message-----
> From: Douglas Otis [mailto:dotis at mail-abuse.org]
> Sent: Tuesday, September 28, 2010 7:01 PM
> To: Murray S. Kucherawy
> Cc: dkim-dev at mipassoc.org; ietf-dkim at mipassoc.org
> Subject: Re: [ietf-dkim] Authorizing List Domains
> 
>   On 9/28/10 3:27 PM, Murray S. Kucherawy wrote:
> > >> On Monday, September 27, 2010 4:19 PM, Douglas Otis wrote:
> > >
> > > TPA-Label involves ADSP being discussed on the dkim list.
> >
> >  Unless you're talking about revising ADSP (which it seems you are
> >  specifically not doing since TPA is meant to cover other
> >  technologies as well; plus, ADSP wasn't in your list), we're talking
> >  about something new that is not in the current DKIM WG Charter.
> 
> The TPA-Label draft offers additional ADSP assertions having semantics
> intended to support _existing_ mailing-list and third-party practices.
> The DKIM charter states the following:
> ,---
> Consider issues related to mailing lists, beyond what is
> already documented. ...
> '---

I believe the intent of that item is to document current MLM/DKIM issues vis a vis already-published documents, as is done in the draft that is currently a WG item.  Extending ADSP or creating new protocols doesn't seem to fit within that goal.

> > > Some have expressed strong desires to improve DKIM deliverability
> > > by allowing fallback to other adopted verification methods.
> > > TPA-Label permits such fallback without also requiring the same
> > > domain be used by alternative methods.
> >
> >  The first sentence there seems contradictory to me; if you're
> >  falling back to other methods, we're no longer talking about mere
> >  DKIM deliverability.
> 
> Sorry, should have said DKIM/ADSP deliverability, which is based upon
> DKIM Author Domain Signatures.  The TPA-Label draft offers alternative
> ADSP assertions that indicate the possible availability of domain
> specific exceptions.  When exceptions are not found, non-compliant
> messages are to be rejected, as opposed to being discarded or scored in
> some fashion.

I'm confused.  You say TPA allows fallback to other adopted verification methods, but you also say it refers specifically to DKIM/ADSP deliverability.  I'm not clear on how both can be simultaneously true.

> > >> Since any client can say anything it wants for an EHLO
> > >> parameter, why should it be considered a type of authentication?
> > >
> > > The SMTP client identified by the EHLO might resolve the IP address
> > > used in the exchange. While such resolution is not required by
> > > SMTP protocol, it might offer an opportunistic means to
> > > authenticate the administering domain as a fallback method.
> >
> >  The DNSOP working group has repeatedly advised against use of
> >  reverse DNS as a mechanism for client authentication. Do we claim to
> >  have expertise they are lacking?
> 
> See:
> http://tools.ietf.org/html/draft-otis-dkim-tpa-label-06#section-12.4
> The SMTP EHLO or HELO hostname must resolve the IP address of the SMTP
> client.  Reverse DNS is not used.

I think that's a marginal improvement.  Even if the HELO/EHLO parameter can be resolved to the client IP address, that doesn't tell you anything about the client other than it has control over some portion of the DNS.

> >  For that matter, one could invent a scheme that mandates any piece
> >  of data must match any other piece of data, both of which are
> >  potentially (perhaps even often) under the control of a miscreant.
> >  I'm not sure I see how this is useful.
> 
> Requiring additional header field compliance better ensures different
> mail streams remain recognizable by recipients.  Many MUAs already
> display Sender,

Which ones?  None that I've ever used do.

> and many who subscribe to mailing-lists already sort
> using List-IDs.  Whether or not recipients see the required header
> field, their requirement helps isolate authorizations to specific mail
> streams, such as messages emitted by the authorized domain's
> mailing-list services.  The TPA-Label response includes authentication
> requirements intended to exclude miscreants.  The general premise is
> exceptional authorization is only given to trustworthy services.

Again, I'm not seeing the utility here.  If A can say "You can trust that mail apparently from us and signed by B is authorized by us as long as it bears a Sender: header field containing B", then an intruder compromising B need only meet that requirement to be able to send mail as A and have verifiers improperly trust it.  That you're catering to MUA display or sorting options only makes that worse in my view.  In any case, it's a tiny hurdle to overcome once a penetration has occurred.  Thus, there seems little gain here over simply authorizing B to sign for A regardless of message structure.