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

[Alessandro Vesely <[e-mail]>]

On Wed 16/Nov/2016 21:12:45 +0100 Murray S. Kucherawy wrote:
> On Thu, Nov 17, 2016 at 3:47 AM, Alessandro Vesely <[e-mail]> 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