ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

2016-11-17 04:30:09
On Wed 16/Nov/2016 21:12:45 +0100 Murray S. Kucherawy wrote:
On Thu, Nov 17, 2016 at 3:47 AM, Alessandro Vesely <vesely(_at_)tana(_dot_)it> 
wrote:

That way it will stay dormant until someone gets hurt and has to activate
it, at which time it may cause more damage than improvement.  A loose
cannon.

The document makes that risk clear, or so I thought.

You mean Section 5?

Yes.

Well, if its title were *Incompatibility with Current Infrastructure*, I would agree there is a statement on the risk of disrupting how DKIM works.

Finally, if you stick to one recipient per message, why do you rack your
brains about encryption?  I suggest adding a Disclosed-BCC:

I don't follow.  There's no additional encryption going on here.

I mean the SHA transformation.  Cleartext is obviously easier to
understand and debug.

I wouldn't say a salted hash qualifies as "racking my brains".  The idea is
to make it difficult to see who the envelope recipient is simply by
looking.  A one-way transformation forces an interloper to make guesses and
try to confirm, and the salt guarantees that your email address does not
always hash to the same thing.  It's not perfect security by any means, but
it's a cheap way to limit what gets leaked.  This too is spelled out in
Section 7.

"To make guesses" is not the specified implementation. Section 4.2 says envelop recipient must match exactly. This requirement not only forces single-recipient mode, but also rules out verifiers which run after acceptance or after alias expansion. An incredibly narrow scope, overall.

If instead you really allow some guessing, as mentioned in Section 7, you may rehabilitate a range of verifiers, but undoubtedly do so at the cost of full scale brains racking.

Adding a "Disclosed-BCC" field guarantees disclosure, rather than only
disclosing if the MDA adds a Delivered-To.  I don't think we should make
that worse.

So long as you disclose it to the very recipient, there is no worry.  NDNs
customarily report SMTP chit-chat in cleartext, betraying users who attempt
to hide their real address behind a dot-forward.  Log files are plenty of
envelope citations.  Received: fields feature a FOR clause which is not
deprecated for single recipient messages.  We're not worsening anything.

If you hand me a printed copy of a message without the envelope, and the
Received didn't use the (non-standard) "for" clause, I cannot be certain it
was delivered to whatever the To and Cc say, if they're even present.

I don't think I'm with you. You seem to mean you don't know if, say, Terry actually received a copy of this. For example, one might arrange social engineering by adding CC:'s to your boss, the press, the police, et cetera, none of which corresponds to the envelope. Is that concern part of the problem at hand?

It may have gone only to an envelope recipient that isn't visible.  That
is, if there was a Bcc, it's not revealed to me.  If you insist on using
"for" or "Disclosed-Bcc", that information is guaranteed to be exposed, and
I can see who that secret recipient was.

Invisible recipients may come from BCCs or other sources. When you get the message, you may want to know why it was delivered to you, and, yes, "for" or "Disclosed-Bcc" let you know that. Why should that info be kept secret?

By contrast, including these tags at most reveals to me that there was a
Bcc, but I have to do some complex (though these days, cheap) math to guess
whether a specific address was in there.  If I never make the correct
guess, the secret is never revealed.

I fail to see why that would be an advantage:

The address is likely shorter than its hash.

In general, it would be nice to have a standard means to tell recipients on what grounds a message was delivered to their mailboxes. For example, was it a role address or a personal one? If the message body is ambiguous (e.g. short messages) knowing the original recipient address may help.

In the scenario you are proposing, only mailbox providers know the envelope, and can verify if that was what the sending domain signed. Final recipients --the actual subjects-- cannot access that info. That picture looks unfair. Indeed, in some countries providers may seem to be legally bound to reveal the envelope address upon subject request (IANAL).

Ale
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>