Re: [dmarc-ietf] draft-kucherawy-dmarc-base

[Stephen J. Turnbull]

Douglas Otis writes:

 > After all, DMARC permits the weakest authorization as a basis for
 > acceptance, so it would be misleading to describe DMARC results as
 > having been *authenticated*.

Well, no, it isn't necessarily misleading.  According to RFC 4949,
authentication = identification + verification, while authorization is
a permission to do something.  For example, in DKIM "d=" identifies
the Signing Domain and "b=" + a DNS lookup provides the data needed
for verification.  At that point you have in fact authenticated the
Signing Domain, and with From alignment (and the additional
assumptions that the key is available only to the Author/Signing
Domain and that the Author Domain authenticates users) you have
authenticated the "authorization to use that mailbox in From."  (You
could add a lot more caveats -- there is a lot of attack surface in
email. :-( )  Some similar statement is true for SPF (at least under
favorable conditions :-).  AFAICS authenticating that particular
authorization is precisely what DMARC claims to do, although the I-D
uses different words to say that.

Anyway, AIUI, the question we're trying to address in Milestone One is
how does that affect third parties on the assumptions that (1) mail
receivers are satisfied that DMARC does what they think it does and
(2) such mail receivers respect "p=reject".

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] draft-kucherawy-dmarc-base-05

[Douglas Otis]

https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/

Dear Murray,

Based on yours and Stephen's feedback, a few modifications have been made to 
the proposed edits:

Starting with the acronym.
Was:
  Domain-based Message Authentication, Reporting and Conformance (DMARC)
Change to:
  Domain-based Message Authorization, Reporting and Conformance (DMARC)

This change affects the title, the abstract, and various defined terms.

Justification for this change includes RFC7001 Section 1.5.2. that states the 
following:

 o  "Authorization" is the establishment of permission to use a
  resource or represent an identity.  In this context, authorization
  indicates that a message from a particular ADMD arrived via a
  route the ADMD has explicitly approved.

 o  "Authentication" is the assertion of validity of a piece of data
  about a message (such as the sender's identity) or the message in
  its entirety.

Neither SPF nor DKIM can claim to authenticate the sending domain of any 
particular message.  A DKIM signature is independent of both the domain sending 
the message and its intended recipient by design.  While a DKIM reference to a 
public key in its signature produces a cryptographically strong association 
with signed portions of a message, many message elements are excluded.  This 
exclusion permits unlimited message variability independent of the actual 
sending domains or intended message recipients by design.  As such, DKIM alone 
is unable to authenticate a domain publishing a referenced public key actually 
generated any specific message.  At best it might be claimed that by signing 
the message, it has authorized various related functions, such as delivery 
status notifications and specific use of some header fields, particularly the 
From header field. 

In addition, the identifier purportedly verified in Authentication-Results 
header fields as specified by RFC7001 suffers from these DKIM related 
uncertainties caused by exclusion of portions of the message.  In addition, 
DKIM permits header obfuscation by failing to detect invalid header field 
structures.  SMTP makes no assurance of message structure, and most DKIM 
signatures circumvent the overhead necessary to patch DKIM's non-detection of 
invalid header structures.  It took a large provider several years to discover 
this particular oversight, even after being warned in appeals and technical 
publications making specific reference to their service.  Others remain unaware 
DKIM still permits header spoofing, especially when deployment suggests a valid 
DKIM signature of a trusted domain can be allowed to bypass subsequent checks.  

In addition, DKIM's lack of header stack validation permits errant results to 
be conveyed when maliciously changed.  Suggesting a DKIM signature 
authenticates the source domain places anyone depending on this identity having 
been authenticated in respect to any particular message at risk.

The introduction properly states the function of DKIM or SPF is to detect and 
block unauthorized email.

Neither DKIM nor SPF determines:
1) valid RFC5322 structure
2) intended message recipient
3) sending domain  (not related to signing domain and may have a one of many 
relationship)
4) From header field content
5) Subject header field content

Of course points 4 and 5 might be repaired, but when such a repair has occurred 
can not be determined using the present protocol as intended.  Just as most 
senders avoid the overhead needed to ensure against invalid header field 
structures, most receivers have similar sensibilities related to subsequent 
handling necessary to detect these deceptions.

As such, using the terms authenticates and authentication should not be used 
when referring to DKIM or SPF results.  Nothing is being authenticated.  The 
real function is the confirmation of an authorization.  It is dangerously 
misleading to overstate DMARC/SPF/DKIM mechanisms, especially since DMARC 
permits the weakest mechanism (simple authorization) as a basis for acceptance.

Section 2,
Was:
   However, there has been
   no single widely accepted or publicly available mechanism to
   communicate domain-specific message authentication policies, or to
   request reporting of authentication and disposition of received mail.
Should be:
   However, there has been
   no single widely accepted or publicly available mechanism to
   communicate domain-specific message authorization policies, or to
   request reporting of authorization and disposition of received mail.

Was:
   As a result, senders who have implemented email authentication have
   had difficulty determining how effective their authentication is, and
   use of authentication failures to filter mail has not been a success
Should be:
   As a result, senders implementing email authorization schemes have
   had difficulty determining how effective their authorization is, and
   use of authorization failures to filter mail has not been a su

Re: [dmarc-ietf] draft-kucherawy-dmarc-base

[Murray S. Kucherawy]

On Sun, Nov 2, 2014 at 6:28 AM, Scott Kitterman 
wrote:

> On Sunday, November 02, 2014 01:42:49 Murray S. Kucherawy wrote:
> ...
> > As was done with the DKIM deployment RFCs, the same has been done for
> > DMARC. It seems neither DKIM nor DMARC follow the path of least
> > astonishment.


> Not quite.  There was an actual DKIM working group that produced standards
> track documents that, due to an actual technical issue they found, broke
> backward compatibility with existing DK key records.  DMARC was developed
> outside the IETF and submitted via the ISE.  Not at all the same (nor the
> least astonishing from my PoV).
>
> Not that it's going to change at this point, but let's not overdo the
> claims
> of business as usual.
>

Just to get the citation right, it was Doug who said this, not me.

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] draft-kucherawy-dmarc-base

[Douglas Otis]

On Nov 1, 2014, at 2:09 AM, Stephen J. Turnbull  wrote:

> Douglas Otis writes:
> 
>> As such, using the terms authenticates and authentication should
>> not be used when referring to DKIM or SPF results.  Nothing is
>> being authenticated.
> 
> I'm confused.  The sending domain is being authenticated, as well as
> as much content as is signed (none for SPF, at least the From and
> DKIM-Signature fields for DKIM).  Otherwise there's no point to either
> protocol.  Of course, DKIM does NOT ensure that the use of the Author
> Domain is *authorized* (unless the author domain is the signing
> domain, it which case it seems reasonable to presume authorization),
> but it is *authentic* in the sense of being used as the sending domain
> intended.
> 
> Or are you referring to the fact that these protocols don't put any
> requirements on the security of the DNS?

Dear Stephen,

With SPF, it is fairly common to find authorizations from hundreds or even 
thousands of different domains.  Nothing based on SPF confirms a purported 
domain is not being spoofed by one of the other authorized IP addresses of 
other domains.  A Botnet spoofing technique seeing increased use, such as by 
the Kelios Botnet.  After all, DMARC permits the weakest authorization as a 
basis for acceptance, so it would be misleading to describe DMARC results as 
having been *authenticated*.  It seems this is the motivation for attempting to 
promote SPF as being an Authentication method when in fact it is clearly only 
Authorization, especially with EHLO confirmation described as a null return 
path fallback.  With a high percentage of compromised systems, overstating 
authorization as authentication only benefits malefactors with this document's 
effort to oversell DMARC's functionality.

While DKIM should be able to actually authenticate a signing domain, it does 
not authenticate either the actual sending domain nor intended recipient.  In 
addition, the Authentication-Results header fields can not be trusted on the 
basis of DKIM and SPF alone.  Valid results are premised on unreported checks 
of the From header structure, while ignoring others, such as that of the 
Subject which is able to include clickable links and carry enticing messages.  
It seems few domains bother to implement DKIM's Section 8.15 fixes intended to 
compensate for an oversight of not checking the header stack structure within 
DKIM's signature algorithm that must traverse the entire header stack in 
reverse.

Your comments offer convincing support for changing the DMARC acronym to mean 
Domain-based Message Authorization, Reporting and Compliance (DMARC),
 
>> The real function is verification of an authorization.
> 
> I think you are overcomplicating things here, and I don't understand
> why.

Both recipients and administrators are being misled into accepting malicious 
content while forgoing other safety checks!

> We *identify* a terminal of a channel (here by using the IP address
> for SPF and the DKIM-Signature for DKIM), then *authenticate* that
> identity, and finally accept its communications as *authorized* when
> accompanied by an appropriate (secure) token from an "authority".  In
> many cases the identity is the token (as when a user is authorized to
> access a file because she is the owner).

It is not using SPF AND DKIM, it is using SPF OR DKIM.  SPF can't identify the 
domain owner (without using unscalable and unused macros).  When based on 
header results as suggested by the DKIM deployment RFC and perhaps soon the 
DMARC BCP draft, nor can DKIM.  Both SPF and DKIM still permit significant 
security exposures.  The intent of DMARC is to block a large portion of abuse 
to better retain email as a transactional signaling media.  Since neither of 
these mechanisms identify the domain involved, it would be safer to describe 
them as an authorization process to better convey DMARC's underlying 
limitations.

> In the case of a domain publishing an SPF "policy", the nature of the
> protocol is essentially that "anything from these hosts is authentic
> and authorized" (the identity == sending IP is the authorization
> token).  If you don't want to say that, don't publish any hosts with
> your restrictive SPF policy.

Any message emitted by an authorized IP address is SPF authorized.  SPF says 
nothing about the use of a domain being authentic, as would DNSsec and to a 
lesser degree DNS for example.

> Analogously for DKIM, as far as I can see.  The signed part of a
> message is similarly self-authorizing if the signature is valid, and
> if you don't like that, don't sign anything and use some other
> protocol.  I suppose here you also need DMARC or other policy protocol
> to actually announce that you aren't sending any authentic mail with
> DKIM signatures.

DKIM indicates the signing domain handled the signed portion of the message.  
DKIM failed to provide a practical means to signal its results, especially when 
modified by receiving MTAs. Domain alignme

[dmarc-ietf] draft IETF 91 WG agenda up for review & input

[Tim Draegen]

Hi, this WG’s IETF91 agenda is up for review:

  http://www.ietf.org/proceedings/91/agenda/agenda-91-dmarc 


If you have comments, suggestions, or modifications, please feel free to reply 
here or if you're shy, reply privately.

1/2 of this WG's chair,
=- Tim

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc