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

["Murray S. Kucherawy" <[e-mail]>]

On Thu, Nov 17, 2016 at 7:28 PM, Alessandro Vesely <[e-mail]> wrote:

>
> 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.
>

That section talks about some things that are compatible (ignored tags are
harmless, for example) and some that are not.


>
>
>> 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.
>

I'm completely confused about the flow of the conversation here.  The
guessing has to be done by an attacker, not by the true verifier.  See
below.


> 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.
>

Correct.  The -00 version of the document had better text about it that got
lost somehow.  I'll put it or something equivalent back in a future version.


> 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.


A verifier doesn't have to guess.  It has a recipient in hand that either
passes the test or does not.

To illustrate: The value of "rh" is base64(rs + rcpt) and the proposal
asserts that both the signer and the verifier have to arrive at the same
value.  The actual signer and verifier have "rs" and "rcpt", the two
inputs, so they get the same result for "rh"; there is no guessing.  An
attacker, however, has an "rh" and "rs" value, but no "rcpt".  It has to
guess.  The weakness is that the mechanism allows for such guesses to be
confirmed when they're right, and it's often the case that there's
information available to narrow the scope of such guessing.  But I think
the document already discusses that.


>
> 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.


Correct, I don't.  In fact, given a printed copy of this message, I don't
know who actually received it, as I no longer have the envelope.  The To
and Cc don't have to have any relationship with the delivery envelope at
all.


> 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?
>

I wouldn't call it a concern, but yes, it explains this aspect of the
proposal.


>
> 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?
>

Exactly for the reason I gave: If you force a Bcc to be visible by sticking
it in a header field, and then print it, the "B" in "Bcc" is gone; the
secret recipient is fully revealed.  I don't know why that would be
desirable.


>
> 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.
>

Your logic is puzzling here.  I don't know about you, but I'm willing to
trade a few bytes to retain privacy.


> 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.
>

That seems to be a goal wholly outside of the scope of this proposal.


> In the scenario you are proposing, only mailbox providers know the
> envelope, and can verify if that was what the sending domain signed.


Yes.


> 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).
>

Sic semper erat.

There is no standard that says the envelope must or even should be copied
into the header on delivery, nor is there a standard way to do so.  Why is
that suddenly something that needs fixing, either in general or in
particular with this proposal?

-MSK

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