Re: [dmarc-ietf] An alternative proposal to the known intermediary problem

[Stan Kalisch]

On Fri, Jun 26, 2020, at 9:44 PM, John Levine wrote:
> This makes me wonder how many mailing lists still don't add DKIM
> signatures. Unlike the header rewriting hacks, they don't affect the
> way recipients see or handle the mail in their inboxes.

The HTTPbis list and Full Disclosure immediately come to mind. IIRC, Bugtraq 
didn't use DKIM, either.


Stan

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

Re: [dmarc-ietf] About user notification in the MUA

[Stan Kalisch]

On Mon, Jun 8, 2020, at 2:03 AM, Douglas E. Foster wrote:
> Stan Kalisch asks: And you propose the average user can understand, much less 
> take the time to understand, the substance?
> 
> Yes. I believe users are worried about spam, and want to make intelligent 
> decisions about whether or not email can be trusted. Unfortunately, our 
> present software denies them access to the available information needed to 
> make intelligent decisions.

See, I believe they want to, too, but, anecdotally, I can think of a number of 
intelligent people I can't explain DMARC to in a substantive manner in a short 
period of time. And the research bears these kinds of anecdotes out.

What I've tried to establish here is that you really have to take the 
initiative if you want to come up with a system that can present the kind of 
data you want presented to the users. You're missing the point that a number of 
people with a great deal of experience have tried, and think it's either 
impossible or very unlikely. So simply asking the community to come up with a 
solution won't be enough, because the community has labored to find a solution 
for a very long time.

A good place for you to begin would probably be this paper:
http://www.usablesecurity.org/emperor/


Stan

> 
> Dave Crocker observes: There is no basis for believing that requests about 
> MUA display will achieve meaningful support on the receive side, nevermind 
> whether they would be at all useful. 
> 
> I was not talking about the sender. I was talking entirely about the 
> receiving organization: its spam filter communicating to its MUA to 
> communicate information to the end user based on its local policy.
> 
> Dave Crocker also observes about end-user signaling failures: It's not that 
> it 'seems to be'. It isn't nearly that soft. It is that there have been 
> multiple efforts over the years and none has demonstrated efficacy.
> 
>  Then lets restate that assertion in all its ugly elitism, and put it into an 
> RFC:
> 
> Incontrovertible research shows that humans will always act on malicious 
> email, and cannot be taught to do otherwise. Organizations should deploy 
> email if and only if they have automated tools which provide perfect 
> protection from unwanted email. End user training is useless.
> 
> I have a higher opinion about my users than that.
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
> 
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] About user notification in the MUA

[Stan Kalisch]

On Sun, Jun 7, 2020, at 7:04 PM, Douglas E. Foster wrote:
> The problem with all current notification methods is that they are relatively 
> primitive, often communicating nothing substantive about the suspicious 
> message characteristics.

And you propose the average user can understand, much less take the time to 
understand, the substance?


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

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

[Stan Kalisch]

On Sun, Jun 7, 2020, at 5:40 PM, John Levine wrote:
> I believe the real question is *whether* to show trust data to users
> and the consensus seems to be don't bother, it only confuses them.

I mean, I can't dispute that that's a fair question.  Confusion obviously works 
against the goals behind showing the user the data in the first place.


Stan

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

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

[Stan Kalisch]

On Sun, Jun 7, 2020, at 3:52 PM, John Levine wrote:
> In article <46e045ae-9691-4f5b-86bf-142c06645...@www.fastmail.com> you write:
> >-=-=-=-=-=-
> >
> >On Sun, Jun 7, 2020, at 9:16 AM, Douglas E. Foster wrote:
> >> 3) Some of the discussion has been about how to prevent soclal engineering 
> >> of the recipient user. This is an important
> >topic, but not directly related to the project. IETF would do well to 
> >establish some recommendations about how MUAs should
> >behave, so that trust data can be displayed to the user.
> >
> >Assuming this can be practically done, I would rephrase this, 
> >"...[E]stablish how MUAs should display trust data to users."
> 
> We have decades of experience that tells us that the IETF is hopeless
> at UI design, and our intuition is usually wrong.
> 
> In particular, displaying warnings that "this may be bad" or even
> "this is extremely bad" is known not to work. No matter what you say,
> people will click through any warning to get to their kitten GIFs or
> porn or whatever.

I didn't know the history of the IETF's approach to UI, in particular, but I'm 
aware of the research on the nastiness of solving the UI problem.  I mostly 
wanted to clarify that the problem is, indeed, *how* to show that data to 
users, and that no one has actually ever been able to solve that problem.


Thanks,
Stan

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

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

[Stan Kalisch]

On Sun, Jun 7, 2020, at 9:16 AM, Douglas E. Foster wrote:
> 3) Some of the discussion has been about how to prevent soclal engineering of 
> the recipient user. This is an important topic, but not directly related to 
> the project. IETF would do well to establish some recommendations about how 
> MUAs should behave, so that trust data can be displayed to the user.

Assuming this can be practically done, I would rephrase this, "...[E]stablish 
how MUAs should display trust data to users."

Which is a question many have struggled to answer, given the history of users 
understandably wanting to pull their hair out over trust data and warnings.


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

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

[Stan Kalisch]

On Wed, Jun 3, 2020, at 2:30 PM, Alessandro Vesely wrote:
> On Wed 03/Jun/2020 19:27:52 +0200 Dave Crocker wrote:
> > On 6/3/2020 10:20 AM, Alessandro Vesely wrote:
> >> On Wed 03/Jun/2020 18:43:16 +0200 Dave Crocker wrote:
> >>> On 6/3/2020 9:38 AM, Alessandro Vesely wrote:
>  MUAs should be discouraged from displaying or using Author:, unless
>  (verifiably) signed by a trusted domain or otherwise configured by the 
>  user.
> >>> Why?
> >> That avoids the dreaded back-to-square-one path that Brandon conjectured.  
> >> It
> >> prevents attacks based on this field, while maintaining the DMARC paradigm.
> > 
> > The barrier you specified sounds reasonable.  But it isn't.
> > 
> > Any signature put in place when the Author: field is created is likely 
> > broken
> > by the time it gets to the recipient.  That's the entire problem that
> > necessitates rewriting the From: field.
> 
> 
> That depends on who creates the Author: field.  I'd imagine it can be created
> on rewriting From:.  If it exists already at that time, one can still check 
> (by
> ARC?) if it was signed, and, in case, sign it in turn.

I, too, was wondering whether ARC was really the only practical way to attempt 
this, assuming you don't think it deviates enough from ARC's purpose.


Thanks,
Stan

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

Re: [dmarc-ietf] Do is need a new ptype? Was Re: New authentication method, DNSWL

[Stan Kalisch]

On Fri, Aug 2, 2019, at 3:58 PM, Murray S. Kucherawy wrote:
> On Fri, Aug 2, 2019 at 3:00 AM Alessandro Vesely  wrote:
>> Let me note that Section 3 of rfc8601, /The "iprev" Authentication Method/,
>> does not contain the term "policy".
> 
> Wow. I'm amazed I got away with that.
> 
> But it is clear from the things in the registry that that's how you do it.
> 
>> My recollection is that reporting the
>> client IP is immaterial, as for SPF. The term policy.iprev is certainly
>> misleading, since the value is not related to a locally-defined policy, and 
>> is
>> not a reversed ip. To stick with A-R semantics, it should have been named
>> tcp.ip, remote.ip or some such. If a property warrants deprecation, it's
>> policy.iprev.
> 
> The choice of "policy" for "iprev" is rooted in history, because the earlier 
> versions of the document (as you well know) demanded that the things being 
> reported had something to do with the message itself. "iprev" was an 
> exception the community chose to allow. It pre-dated RFC5782 which introduced 
> DNSxLs formally.
> 
> For guidance here, I would rely on anecdotes of implementation. Has anyone 
> implemented something that attaches "iprev" results?

IIRC, Fastmail's Authentication Milter does. But I also have some vague 
recollection that they stopped using policy.iprev, specifically.

Now looking at headers from my Fastmail customer account, it appears to me that 
this is indeed what they did, although I would have to recheck the actual 
distribution they share with everyone else to be sure. I'm sure someone at 
Fastmail can comment on what actually precipitated the move.


Stan

> 
>> Now for dnswl. Knowing which zone was queried is substantial in order to
>> interpret policy.ip, because there is no standard format. Yet, an
>> implementation could just throw a DNS query to a given local IP, instead of a
>> FQDN to the default DNS server. In that case, one would have, for example:
>> 
>>  dnswl=pass policy.ip=127.0.9.2 policy.zone=127.0.0.2
>> 
>> In that case one can hardly tell which is which. A meaningful ptype helps.
> 
> Why would the thing attaching "dnswl=pass" not also interpret "policy.ip"? I 
> would expect it to have that knowledge, not downstream things. Again, I don't 
> know what the value of "dnswl=pass" is if the thing attaching it doesn't even 
> know how to interpret the result it got.___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Reporting DMARC policy in A-R header fields

[Stan Kalisch]

On Thu, Aug 1, 2019, at 11:14 PM, John Levine wrote:
> Catching up on my mail after a laptop disaster, ...
> 
> In article <4600949.rz9u5RyGOV@l5580> you write:
> >I think comments should be free-form. If we want data that can be machine 
> >parsed, we should specify it.
> >
> >I think the above works in ABNF terms. It's:
> >
> >Authentication-Results:" authserv-id; method=result ptype.property=value 
> >ptype.property=value
> 
> I agree. We all put the DKIM stuff in comments but that's silly. If
> it's worth recording, it's worth doing in a way that we all agree
> about and can parse.

Yes please.


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

Re: [dmarc-ietf] Reporting DMARC policy in A-R header fields

[Stan Kalisch]

On Wed, Jul 31, 2019, at 6:46 AM, Scott Kitterman wrote:
> On July 31, 2019 7:11:49 AM UTC, Alessandro Vesely  wrote:
> >On Tue 30/Jul/2019 15:56:16 +0200 Scott Kitterman wrote:
> >
> >> The published policy (that's why I suggest dmarc.policy).
> >
> >
> >Published policy can be ambiguous. Say you have p=quarantine; sp=none.
> > The
> >MTA chooses which to apply based on the domains (publishing and From:).
> > So it
> >makes sense to write the /applied/ published policy.
> >
> >I'm not good at designing A-R stanzas, as you know. However, since
> >dmarc is
> >already the policy method, why not write dns.policy, since that is
> >where it
> >comes from?
> 
> The problem with dns as a ptype is that virtually all this is from DNS.. I 
> haven't had a chance to study your proposal in detail or coordinate with the 
> other designated experts, but speaking for myself my initial thought is that 
> dns is not a good ptype name.

Moreover, given the D in DMARC literally means "Domain-Based", I think this 
nomenclature would be potentially confusing and unfortunate.

> This is specific to DMARC, so I think it's appropriate to say so.

There is that too.


Stan

> >> I'm not sure if disposition belongs in A-R. If it does, it'd be a
> >local
> >> policy override, probably policy.dmarc as described now in RFC 8616..
> >
> >You mean RFC 7489, don't you? I see nothing about A-R in RFC 8616.
> 
> Sorry. I meant RFC 8601.
> 
> >Would it be possible to add a result of "quarantine"? Having
> >dmarc=fail and
> >dns.policy=quarantine leaves a good deal of interpretation to the MDA. 
> >If one
> >could write dmarc=quarantine, a simple string search or regular
> >expression
> >would do.
> 
> That's a great example of why dns.policy= isn't the way to go. It's too 
> generic. If it's dmarc.policy=quarantine, there's no ambiguity. You can't put 
> quarantine as the DMARC result, because that's not what it is. The DMARC 
> result is pass/fail/none.
> 
> >Currently, I use a comment too.
> >
> >Since we're at it, besides the spam folder, is it fine if the MDA sets
> >IMAP
> >keyword $Junk[*] or $Phishing[†] or would we dare registering a new
> >one?
> 
> It's outside my area of expertise, so I don't have a strong opinion, but I'd 
> be inclined not to register a new one. I think the average user can be 
> confused by too many terms for things that to them are the same.
> 
> Scott K
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
> 
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Reporting DMARC policy in A-R header fields

[Stan Kalisch]

On Tue, Jul 30, 2019, at 9:57 AM, Scott Kitterman wrote:
> The published policy (that's why I suggest dmarc.policy). I'm not sure if 
> disposition belongs in A-R. If it does, it'd be a local policy override, 
> probably policy.dmarc as described now in RFC 8616.

In that case, if the downstream were to make use of the upstream's disposition, 
it's extrapolating a meaning from the disposition, but not actually deriving 
meaning from the authentication results themselves, so I'm inclined to agree.


Thanks,
Stan

> Scott K
> 
> On July 30, 2019 1:34:46 PM UTC, "Дилян Палаузов"  
> wrote:
> >Hello Scott,
> >
> >do you want to include in the A-R header the published policy, as
> >obtained from DNS (my first interpretation of your
> >proposal), or the disposition of the message after applying
> >DKIM/SPF/DMARC validation, pct sampling, and the ominous
> >reject→quarantine sampling conversions?
> >
> >With disposition I mean what is called at
> >https://tools.ietf.org/html/rfc6591#section-3.2.2 Delivery-Result.
> >
> >For the disposition on p=reject only the MTA can make the decision
> >based on pct to reject, so it makes sense if the
> >result of disposition is included in the A-R header by the MTA and
> >consumed by the MDA. In turn, including pct and
> >published DMARC policy in the A-R header, so that the MDA can do the
> >sampling, does not make sense.
> >
> >If you want to call the new parameter “policy”, then it shall be
> >articulated that it means disposition, and not
> >published policy.
> >
> >I am in favour of the proposal.
> >
> >It allows for forwarded emails/aliases to indicate in the A-R header,
> >that sampling was already performed by the
> >aliasing server, and the final server that accepts the email can skip
> >performing the sampling again. Performing the
> >sampling again has the disadvantage, that the pct= parameter is
> >misinterpreted, as the parameter is supposed to be
> >applied only once.
> >
> >On the other side, skipping of the second sampling by whatever server
> >is pure theory, and has no practical impact.
> >
> >Greetings
> > Дилян
> >
> >On Tue, 2019-07-30 at 00:54 -0400, Scott Kitterman wrote:
> >> On Monday, July 29, 2019 3:37:55 PM EDT Scott Kitterman wrote:
> >> > I'd like to add the option to record DMARC results in an A-R header
> >field
> >> > for consumption by a downstream processor. I think it would be
> >something
> >> > like this:
> >> > 
> >> > Authentication-Results: mail-router.example.net; dmarc=pass
> >> > header.from=example.com policy.dmarc=none
> >> > 
> >> > That would take adding an entry in the Email Authentication Methods
> >registry
> >> > for:
> >> > 
> >> > method: dmarc
> >> > ptype: policy
> >> > value: dmarc
> >> > 
> >> > Does that make sense as a way to do it? Does anyone have
> >alternative
> >> > suggestions?
> >> 
> >> I think comments should be free-form. If we want data that can be
> >machine 
> >> parsed, we should specify it.
> >> 
> >> I think the above works in ABNF terms. It's:
> >> 
> >> Authentication-Results:" authserv-id; method=result
> >ptype.property=value 
> >> ptype.property=value
> >> 
> >> According to the ABNF, there can be more than one propspec 
> >> (ptype.property=value) per methodspec in resinfo, so I think it's
> >legal. It 
> >> would just need the new registry values for dmarc.
> >> 
> >> Scott K
> >> 
> >> 
> >> ___
> >> dmarc mailing list
> >> dmarc@ietf.org
> >> https://www.ietf.org/mailman/listinfo/dmarc
> >
> >___
> >dmarc mailing list
> >dmarc@ietf.org
> >https://www.ietf.org/mailman/listinfo/dmarc
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
> 
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] draft-ietf-dmarc-psd review

[Stan Kalisch]

Scott, I have two editorial nits that account for a grand total of three 
characters. It seemed less complicated to just send a PR in Github, so I did.


Stan

On Sat, Jul 27, 2019, at 4:45 PM, Scott Kitterman wrote:
> On Monday, July 22, 2019 12:23:15 PM EDT Murray S. Kucherawy wrote:
> > Reviewing as the document shepherd:
> > 
> > Abstract
> > 
> > [...]
> > organization can use to improve mail handling. DMARC policies can be
> > applied at the individual domain level or for a set of domains at the
> > organizational level.
> > 
> > I think the abstract is a bit too abstract. Which set of domains?
> > 
> > 
> > The design of DMARC precludes grouping
> > policies for a set of domains above the organizational level, such as
> > TLDs (Top Level Domains).
> > 
> > Is that the same set?
> 
> I updated the paragraph to start:
> 
>  DMARC (Domain-based Message Authentication, Reporting, and
>  Conformance) is a scalable mechanism by which a mail-originating
>  organization can express domain-level policies and preferences for
>  message validation, disposition, and reporting, that a mail-receiving
>  organization can use to improve mail handling. DMARC policies can be
>  applied to individual domains or to all domains within an
>  organization. The design of DMARC precludes grouping policies for
>  domains based on policy published above the organizational level,
>  such as TLDs (Top Level Domains). 
> 
> Does that clear those comments up?
> 
> 
> > These types of domains (which are not all
> > at the top level of the DNS tree) can be collectively referred to as
> > Public Suffix Domains (PSDs).
> > 
> > What "types" are there?
> 
> Changed to:
> 
>  organization. The design of DMARC precludes grouping policies for
>  domains based on policy published above the organizational level,
>  such as TLDs (Top Level Domains). Domains at this higher level of
>  the DNS tree (but not necessarily at the top of the DNS tree) can be
>  collectively referred to as Public Suffix Domains (PSDs). 
> 
> > For the subset of PSDs that require
> > DMARC usage, this memo describes an extension to DMARC to enable
> > DMARC functionality for such domains.
> >
> > What's the requirement? 
> 
> Given that the document no longer contains such a constraint, I've updated my 
> working copy to say:
> 
> This memo describes an extension to DMARC to enable DMARC functionality PSDs.
> 
> > 1. Introduction
> > 
> > DMARC [RFC7489] provides a mechanism for publishing organizational
> > policy information to email receivers. DMARC [RFC7489] allows policy
> > to be specified for both individual domains and sets of domains
> > 
> > Which sets?
> > 
> Comment is OBE based on previous changes.
> 
> > within a single organization. For domains above the organizational
> > level in the DNS tree, policy can only be published for the exact
> > domain. There is no method available to such domains to express
> > lower level policy or receive feedback reporting for sets of domains.
> > 
> > Still too abstract. I don't know what sort of set groupings you might
> > be after here.
> 
> I think the new text is better. Please check and let me know if it's there 
> yet or not.
> 
> > This prevents policy application to non-existent domains and
> > identification of domain abuse in email, which can be important for
> > brand and consumer protection.
> > 
> > As an example, imagine a country code TLD (ccTLD) which has public
> > subdomains for government and commercial use (.gov.example and
> > .com.example). Within the .gov.example public suffix, use of DMARC
> > [RFC7489] has been mandated and .gov.example has published its own
> > DMARC [RFC7489] record:
> > 
> > "v=DMARC1;p=reject;rua=mailto:dm...@dmarc.service.gov.example;
> > 
> > Can we add spaces after the semicolons? I know this is legal format
> > but it would be more readable.
> 
> Changed.
> 
> > This memo provides a simple extension to DMARC [RFC7489] to allow
> > 
> > s/memo/document/g
> 
> Changed throughout.
> 
> > operators of Public Suffix Domains (PSDs) to express policy for
> > groups of subdomains, extends the DMARC [RFC7489] policy query
> > 
> > "groups of subdomains" suggests the capability of creating a policy
> > that applies to parts of the subtree only, or different policies for
> > different parts of the subtree. If that's not what we're actually
> > defining here, this should be reworded.
> 
> OBE to previous comments.
> 
> > As an additional benefit, the PSD DMARC extension will clarify
> > 
> > s/will clarify/clarifies/
> 
> Changed.
> 
> > existing requirements. Based on the requirements of DMARC [RFC7489],
> > DMARC should function above the organizational level for exact domain
> > matches (i.e. if a DMARC record were published for 'example', then
> > mail from example@example should be subject to DMARC processing).
> > Testing had revealed that this is not consistently applied in
> > different implementations. PSD DMARC will help clarify that DMARC is
> > 
> > s/will help 

Re: [dmarc-ietf] Mention ICANN/operational limitations was: Re: Working Group Last Call: draft-ietf-dmarc-psd

[Stan Kalisch]

On Fri, Jul 12, 2019, at 2:27 PM, Scott Kitterman wrote:
> On Friday, July 12, 2019 1:59:55 PM EDT Stan Kalisch wrote:
> > On Fri, Jul 12, 2019, at 1:41 PM, Scott Kitterman wrote:
> > > On Wednesday, June 26, 2019 5:21:14 PM EDT Seth Blank wrote:
> > > > As Secretary, there are three items that have not yet reached consensus
> > > > that must be resolved during WGLC:
> > > > 
> > > > 2. If explicit call outs to ICANN/limited operator capacity to implement
> > > > are needed
> > > 
> > > There has been feedback in favor of adding this and none against so far.
> > > 
> > > The specific proposal is:
> > > 
> > > "Please note that today's operational and policy reality prevents this
> > > experiment from being deployed globally. If the experiment shows that PSD
> > > solves a real problem at a large scale, the results could prove to be
> > > useful in the development of policies outside of the IETF that would
> > > permit its ubiquitous deployment."
> > > 
> > > Because RFCs are (approximately) forever, I'm concerned about words like
> > > "today's" in protocol documents, even experimental ones.
> > > 
> > > How about this instead:
> > > 
> > > "As of the writing of this document operational and policy constraints
> > > prevent this experiment from being deployed globally. If the experiment
> > > shows that PSD solves a real problem and can be used at a large scale,
> > > the results could prove to be useful in the development of policies
> > > outside of the IETF that would permit broader deployment".
> > 
> > "[D]evelopment of policies outside of the IETF" strikes me as a little odd
> > since IETF isn't setting policy *per se*, although substitute language that
> > is just as succinct is escaping me at the moment.
> 
>  removal of constraints ... ???
> 
> "As of the writing of this document operational and policy constraints 
> prevent 
> this experiment from being deployed globally. If the experiment shows that 
> PSD 
> solves a real problem and can be used at a large scale, the results could 
> prove to be useful in the removal of constraints outside of the IETF that 
> would permit broader deployment".
> 
> Better?

I think so. "[I]n removing constraints" would flow a little better, but yeah.


Thanks,
Stan

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

Re: [dmarc-ietf] Mention ICANN/operational limitations was: Re: Working Group Last Call: draft-ietf-dmarc-psd

[Stan Kalisch]

On Fri, Jul 12, 2019, at 1:41 PM, Scott Kitterman wrote:
> On Wednesday, June 26, 2019 5:21:14 PM EDT Seth Blank wrote:
> > As Secretary, there are three items that have not yet reached consensus
> > that must be resolved during WGLC:
> 
> > 2. If explicit call outs to ICANN/limited operator capacity to implement
> > are needed
> 
> There has been feedback in favor of adding this and none against so far.
> 
> The specific proposal is:
> 
> "Please note that today's operational and policy reality prevents this 
> experiment from being deployed globally. If the experiment shows that PSD 
> solves a real problem at a large scale, the results could prove to be useful 
> in the development of policies outside of the IETF that would permit its 
> ubiquitous deployment."
> 
> Because RFCs are (approximately) forever, I'm concerned about words like 
> "today's" in protocol documents, even experimental ones.
> 
> How about this instead:
> 
> "As of the writing of this document operational and policy constraints 
> prevent 
> this experiment from being deployed globally. If the experiment shows that 
> PSD solves a real problem and can be used at a large scale, the results could 
> prove to be useful in the development of policies outside of the IETF that 
> would permit broader deployment".

"[D]evelopment of policies outside of the IETF" strikes me as a little odd 
since IETF isn't setting policy *per se*, although substitute language that is 
just as succinct is escaping me at the moment.


Thanks,
Stan

> 
> Also, since this is about ephemera and not protocol, I think it should go in 
> Appendix A.
> 
> Comments?
> 
> Scott K
> 
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
> 
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Display address, was Mandatory Sender Authentication

[Stan Kalisch]

On Tue, Jun 11, 2019, at 1:29 PM, Dave Crocker wrote:
> > A user can then arrange her address book so as to make it clear to the MUA 
> > that
> > a class of email addresses are equivalent to one another, in order to avoid
> > meaningless alerts.
> 
> What makes you think users want to do this extra work or that they will.

Yes. Users have to be 1) made aware of an argument in favor of the extra work 
in the first place and, and, 2), after that, convinced of that argument in 
favor of the importance of that extra work. Like it or not, they're not.

I mean, I'm just imagining a stay-at-home parent with three kids who only knows 
their phone is beeping at them while they're trying to get said kids into the 
car to go to urgent care because one is throwing up. The beeping is just going 
to make them mad and you're not even going to make it past step 1.

> Evidence to date is that they don't and won't.

Indeed.


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

Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion

[Stan Kalisch]

On Fri, May 31, 2019, at 6:59 AM, Douglas E. Foster wrote:
> I cannot speak to IETF consensus, since I am new to that process and I seem 
> to be an outlier already.
> 
> Agency and signatures are well understood legal concepts. 3000 years ago, 
> people sealed their letters with a signet ring stamped in warm clay. Signing 
> technologies have changed in that time, but the principle has not.

It would probably behoove you not to lecture experts in Internet messaging 
about 3000 years of history on a public mailing list. I'm just saying.


Thanks,
Stan

> 
> A courier is responsible for keeping the signed and sealed part of a message 
> unaltered. Envelope marks are acceptable.
> 
> A digital signature is supposed to provide non-repudiation. If I submit a 
> signed message to a list processor, and the list processor voids the 
> signature, it has given me verifiable repudiation, the opposite of what 
> either sender or receiver want. 
> 
> A closed group on a single server can use whatever rules they choose to 
> implement in that community. For example, a web forum operates on the rules 
> of the forum operator. However, an open group using the email infrastructure 
> has to work within the infrastructure it uses. In the email infrastructure, 
> the recipient has to deal with fraud, and any recipient accommodation to 
> "harmless" fraud facilitates the people who are doing "harmful" fraud to that 
> recipient.
> 
> There are some obvious use-cases for MTA changes to a message, and we would 
> do well to document and address them.
> 
> The first that comes to mind is MTA comment fields.
> - A list processor wants to add a comment indicating something about the list 
> that sent it.
> - A spam filter wants to add a tag indicating that the message is suspicious, 
> but not sufficiently suspicious to be blocked.
> 
> IETF would do well to specify a mechanism for MTAs to add information which 
> MUAs present to the user, while identifiying that that the information came 
> from the MTA rather than the original sender.
> 
> Another use-case is related to body sections. IETF only forwards plain text, 
> while most email solutions send messages in HTML+Text. I assume that IETF 
> also drops attachments. DKIM cannot handle this because it hashes the entire 
> body. A signature system that signed each section individually would allow 
> sections to be dropped, with notification to the user, without breaking the 
> signatures on the other MIME types.
> 
> DKIM was supposed to provide sender authentication when SPF was invalidated 
> by forwarding, so DMARC said that the two techniques should be evaluated 
> together. I am realizing that if SPF is invalidated, DKIM is probably 
> invalidated as well, so we have no usable sender authentication technology. 
> This may explain why so many products that I have examined lack support for 
> DMARC or lack good exception mechanisms for SPF, DKIM, and DMARC.
> 
> It seems that email needs something like "DNS Flag Day", where major players 
> announce a date after which certain behaviors that will no longer be 
> tolerated. But as others have said, IETF is not that organization, and the 
> organization may not exist.
> 
> More discouraged than ever,
> 
> Doug Foster
> 
> 
> 
> 
> 
> 
> 
> 
> 
> *From*: "Dave Crocker" 
> *Sent*: Friday, May 31, 2019 12:41 AM
> *To*: fost...@bayviewphysicians.com
> *Cc*: "IETF DMARC WG" 
> *Subject*: Re: [dmarc-ietf] Debugging and preventing DKIM failures- 
> suggestion 
> 
> On 5/30/2019 7:49 PM, Douglas E. Foster wrote:
>  > I rather hoped that IETF would be the poster-boy for list processing
>  > done correctly.
> 
>  "Correctly"?
> 
>  A message to a list is 'delivered' to the list. As in, it goes to the
>  specified addresse... the list. A message from a list has been
>  re-posted by the list.
> 
>  There are no constraints on the changes that are permitted to a message,
>  before it is re-posted. There are no specifications that limit or
>  direct the behaviors of a list processor.
> 
>  Different groups want and probably need different behaviors by a list
>  processor. Periodic efforts to create such constraints have failed.
> 
>  So while it would certainly make things easier to have list processors
>  behave in a simple, consistent manner, there's ample evidence that ain't
>  gonna happen.
> 
>  If you can link the 'correctly' you are suggesting, to some documented,
>  community consensus, please cite it.
> 
> 
>  d/
> 
>  --
>  Dave Crocker
>  Brandenburg InternetWorking
>  bbiw.net
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
> 
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC protocol-15 posted

[Stan Kalisch]

> On Jun 29, 2018, at 11:16 PM, John R Levine  wrote:
> 
> Perhaps we should try and figure out the least bad way of allowing new 
> signature algorithms, since that's the most likely change to happen soon.

Yes.  Especially because this spec is intended to be experimental.


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

Re: [dmarc-ietf] ARC draft-10 protocol elements section and question about reducing section 8

[Stan Kalisch]

> On Dec 29, 2017, at 12:29 PM, Murray S. Kucherawy  wrote:
> 
> Chairs, should we start using the WG's issue tracker for this stuff?

Speaking as an observer, I personally would find that helpful.


Thanks,
Stan

>> On Thu, Dec 28, 2017 at 4:44 PM, Seth Blank  wrote:
>> Sections 4.7 and 4.8 from my proposal 
>> (https://mailarchive.ietf.org/arch/msg/dmarc/yl1HWdNbmQR1wHlCvG3eRl9ph5E) 
>> were not moved into the protocol elements section of the latest draft 
>> (https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-4)
>> 
>> I spoke with Kurt, and this appears to have been an oversight.
>> 
>> To be clear about the protocol elements section, I've cribbed it from DKIM 
>> and proposed it to:
>> a) provide context for the entire ARC Chain
>> b) define protocol components that are not specific to only sealing or 
>> validating the chain
>> 
>> As such, I believe both the concept of chain validation status and the 
>> ordering of hops belong in protocol elements.
> 
> +1.
> 
>> This also opens the question of where Section 8 
>> (https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-8) 
>> belongs. This section now feels more like a kitchen sink and implementation 
>> guidance.
>> 
>> I would suggest:
>> 
>> 8.1 be stricken as it's a normative modification of DKIM, or replaced with 
>> language to the effect of "ARC MUST be the last signer of the message; 
>> otherwise it cannot be validated on receipt." which can go in signer actions
>> 
>> 8.2 should be moved to protocol elements
>> 
>> 8.3 to signer actions
>> 
>> 8.4 to verifier actions
> 
> +1 to all of those.
> 
>> 8.5 should be stricken (this is bad advice that could result in backscatter, 
>> and I'm unsure where it came from, I can find no working group conversation 
>> around this)
> 
> It is a reasonable choice, however.  That is: If you're going to give an SMTP 
> reply, this is the right one to use, but maybe warn that backscatter (and 
> provide or reference a definition of that term) can result.
> 
> -MSK
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Lenient DKIM (new Internet Draft)

[Stan Kalisch]

I apologize for this post.  I was in a car accident, and it's affecting me more 
than I thought—you're obviously talking about MIME *bodies*.  Again, my 
apologies to the list.


Stan

> On Sep 25, 2017, at 2:19 PM, Stan Kalisch <s...@glyphein.mailforce.net> wrote:
> 
> 
>> On Sep 25, 2017, at 12:00 PM, Brandon Long <bl...@fiction.net> wrote:
>> 
>> 
>> The mime body canonicalization is odd, what percentage of mail isn't 
>> multipart at this point?
> 
> iOS Mail (before 11, at least) does 7-bit text/plain mail by default.  (If 
> memory serves, this has something to do with Japanese SMS providers, although 
> Japanese obviously isn't 7-bit.)  I don't know enough to hazard a guess at 
> what percentage of mail this is.
> 
> 
> Stan

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

Re: [dmarc-ietf] Lenient DKIM (new Internet Draft)

[Stan Kalisch]

> On Sep 25, 2017, at 12:00 PM, Brandon Long  wrote:
> 
> 
> The mime body canonicalization is odd, what percentage of mail isn't 
> multipart at this point?

iOS Mail (before 11, at least) does 7-bit text/plain mail by default.  (If 
memory serves, this has something to do with Japanese SMS providers, although 
Japanese obviously isn't 7-bit.)  I don't know enough to hazard a guess at what 
percentage of mail this is.


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

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-09.txt

[Stan Kalisch]

One nit:  Section 13.1, line 730:  there's space between "Method" and the colon.


Thanks,
Stan

> On Sep 7, 2017, at 11:20 AM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain-based Message Authentication, 
> Reporting & Conformance WG of the IETF.
> 
>Title   : Authenticated Received Chain (ARC) Protocol
>Authors : Kurt Andersen
>  Brandon Long
>  Steven Jones
>  Murray Kucherawy
>Filename: draft-ietf-dmarc-arc-protocol-09.txt
>Pages   : 46
>Date: 2017-09-07
> 
> Abstract:
>   The Authenticated Received Chain (ARC) protocol creates a mechanism
>   whereby a series of handlers of an email message can conduct
>   authentication of the email message as it passes among them on the
>   way to its destination, and record the status of that authentication
>   at each step along the handling path, for use by the final recipient
>   in making choices about the disposition of the message.  Changes in
>   the message that might break DKIM or DMARC can be identified through
>   the ARC set of header fields.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-09
> https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-protocol-09
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-09
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc

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