does DKIM verify that it actually went to Hunter?

[sjpotter]

i.e. we can use DKIM to verify the sender, but can we use DKIM to verify the recepient? i.e. the To: header (which is part of the dkim hash) isn't actually used in delivery. So while, we can have be fairly sure the sender sent it when they did (or at least time boxed), can we really know who it was sent to?

i.e. I'm wondering if this statement is a little bit too absolute "the intended recipient was to the account hbiden@rosemontseneca.com, known to have been used by Hunter Biden". We know that was To: header, but that doesn't actually mean it was the intended recipient, if the rcpt to was to a different address.

[sjpotter]

I don't see how that answers my Q. none of those headers are. verified by the dkim signature. ie. they "could" be faked (not that I actually believe they ar), but hte Q is what can be proven

[sjpotter]

To is not use for delivery by SMTP. To is just a "UI" header. i.e. you can BCC'd on an email, there's no To, the email still gets delivered to you. So I can (and have with gmail) constructed my own messages that I inject via an authenticated login to smtp.googemail.com:587 that gmail deliveries with full DKIM that show whatever To I want (with gmail's DKIM keys signing it) but also get delivered to whatever user I want that is not the person in the To line.

[sjpotter]

If you want to see this in action, I can send you an email via google that will be delivered to you, but the To: line will only be hunter's rosemont email address.

[sjpotter]

sent, it will come from my gmail address (as noted, without authorization can't spoof that), but the Subject/To/body will be the same as this email. Showing how one can spoof the To without it actually going to the supposed recipient.

[sjpotter]

@ValZapod got the email?

[sbosshardt]

And looks like it is not even send to hunter. :clap: :clap: :clap:

I'm not 100% convinced that it didn't actually get sent. I don't have access to Hunter's inbox (and I assume you don't either). But for the moment let's assume that Gmail didn't actually (attempt to) deliver this test email to Hunter's address.

The balance of probability is overwhelmingly that Vadym did not exploit this obscure (zero day?) bug/vulnerability. Gmail's SMTP server ought to not allow this (at least I'm not aware of any reason as to why it should be allowed).

Some reasons to believe Vadym did not exploit this:

• The email was sent 6 years ago (signed by Google's secret key that they stopped using years ago).
• Both the sender and (alleged) recipient had a business relationship with the same company (Burisma).
• Nobody involved in the (alleged) meeting has denied the authenticity of the email.

[sjpotter]

1) I don't see why you think SMTP servers shouldn't allow what I described. It happens every time you BCC someone! its a feature, not a bug. DKIM isn't meant to validate who recieved the email. (one could argue that having DKIM include the To header in general is pointless)

2) I'm not arguing that the e-mail is fraudulent, I'm simply pointing out the limitations of the analysis (which I in general agree with, it does point in a very specific direction). So I think one shouldn't say with absolute certain certain facts.

I see basically 2 possibilities for the people that want to believe its a fraud

1) someone has access to google's old DKIM key (stolen or cracked) and is able to generate valid signatures. Probably not the most likely scenario 2) someone has been planning this for a long time. (probably a bit more plausible than #1, but probably not that much). I've demonstrated how someone who was planning this for a long time could have done it without Biden ever even seeing it, but this would have required the cooperation, witting or unwittingly (as in he was effectively hacked), of the ukranian guy.

as I said, I understand why people would be willing to view it much more plausible that its authentic. that's the direction I strongly lean towards as well. one just has to understand why this is not absolute proof as well.

[sbosshardt]

I don't see why you think SMTP servers shouldn't allow what I described. It happens every time you BCC someone!

I disagree. BCC is a red herring in my opinion. The intent of BCC is to not disclose who else was provided a copy of the email payload. A BCC header is neither signed nor provided to the email's recipients.

I am afraid this is the case of "not a bug but a feature".

Both of you have called this a "feature". But I've yet to find a reason GMail (and other providers) should allow an authenticated user to send an email that has a "TO:" header that has recipients not found in a corresponding SMTP "RCPT TO:" header. If it is a "feature", can someone provide an example of a (legitimate) use case that depends on this quirk?

The PDF wasn't specific so I skimmed. From what I read, the slideshow specifies different vulnerabilities which tend to center around making a message appear to come from another account (e.g. Exploit 5 on page 25). The PDF considers these to be exploits. I'm not sure how old it is, but I assume these have been fixed by now by the providers mentioned on pg 24. So I don't think this supports an argument that this is a previously disclosed "feature".

(one could argue that having DKIM include the To header in general is pointless)

This argument is circular in my opinion. If I may paraphrase the argument:

Current (insecure) implementations don't validate that the "To:" header is consistent with the SMTP "RCPT TO:" headers. Therefore the "To" header is pointless.

I consider "To:" to be important, and so does RFC822 (it is a required field).

Also, the DKIM specification (RFC6376) provides some insight in section 5.4.1 as to one reason why headers (such as "To:") should be signed:

The purpose of the DKIM cryptographic algorithm is to affix an identifier to the message in a way that is both robust against normal transit-related changes and resistant to kinds of replay attacks. An essential aspect of satisfying these requirements is choosing what header fields to include in the hash and what fields to exclude. The basic rule for choosing fields to include is to select those fields that constitute the "core" of the message content. Hence, any replay attack will have to include these in order to have the signature succeed; however, with these included, the core of the message is valid, even if sent on to new recipients.

[sjpotter]

yes, the To is informational (the message content), not an actual instruction to SMTP. i.e. DKIM doesn't protect the smtp transaction instructions just the contents of the message.

[sbosshardt]

DKIM doesn't protect the smtp transaction instructions just the contents of the message.

Obviously DKIM does not sign the user's original SMTP headers.

The user has authenticated to Gmail. The user transmits a payload to Gmail (the "email" including SMTP instructions). At this point, Gmail's servers have custody of the entire message and the user is out of the picture. Afterward, SMTP connections/instructions that Gmail initiates/relays to other servers are Gmail's responsibility. Along with any DKIM signatures and message headers that Gmail generates/transmits. The exact SMTP headers sent to other servers are subject to change (e.g. by not including email addresses that a destination server is not responsible for).

It does not mean that To cannot be absent whatsoever.

You're correct about this detail. What the RFC is saying here is that, at minimum, there must either be "Bcc:" (blank), or "To:" (with at least one recipient). But one of those is required. The only reason I know of to have a blank "Bcc:" with no "To:" is to indicate that the email is being sent only to recipients whom the sender does not want to disclose.

Going back to my question...

Can anyone provide a legitimate use case for allowing such a "To:" header? i.e. is there any benefit that this "feature" provides?

At this point I'm still considering this to be a "vulnerability". Not a "bug", let alone a "feature".

[sjpotter]

because there's functionally no difference between what I see on an email sent to you that I'm BCCd on and an email sent to a false user that I'm BCCd on.

[sbosshardt]

I'm not sure which of my specific remarks your "because" is in response to. You are basically paraphrasing what you'd said previously. I'd previously responded as to why I think BCC is inapplicable here ("a red herring"). The issue I have with your latest statement is the "because" in it. I think it turned a purely factual statement into a circular argument.

Gmail is currently allowing its users to forge "To" headers in ways that most users would not expect (@ValZapod is an example of a savvy user who initially doubted that Google would allow this). As ValZapod put it:

the rcpt to was to a different address.

Why does it matter? I doubt that is possible in Google suite. Again, it is all google the receiver and intermediate.

This kind of forgery opens the door to social engineering attacks, particularly involving fooling a recipient into believing that somebody else was sent an email. I won't ask the question a third time - instead I'll simply claim that there is no (known) legitimate use case for which Gmail should allow its users to forge a false "To" header. I've yet to read a reason why this vulnerability ("feature") should be allowed by Gmail, and at this point I have no reason to believe that one exists.

[sjpotter]

shrug. it's how smtp servers have always worked.

If you want to argue this point, argue with the people that wrote the SMTP RFCs. its pointless to argue that point here.

[sbosshardt]

argue with the people that wrote the SMTP RFCs

I disagree with this (dismissive) recommendation. What I've said has little to do with SMTP RFCs. I never claimed that this is a SMTP vulnerability - I said that it is a Gmail vulnerability.

For example, here is a snippet from RFC 5321 section 7.1:

SMTP mail inherently cannot be authenticated, or integrity checks provided, at the transport level. Real mail security lies only in end-to-end methods involving the message bodies, such as those that use digital signatures (see RFC 1847 [43] and, e.g., Pretty Good Privacy (PGP) in RFC 4880 [44] or Secure/Multipurpose Internet Mail Extensions (S/MIME) in RFC 3851 [45]).

I interpret this to be in full agreement with the point I've been making.

argue with the people

I'll report it to Google and link to this Github issue. I was thinking of reporting it anyway, since it seems to be a responsible thing to do. They don't specify the vulnerability/"feature" we've discussed, but they seem to admit (on their bug bounty page) that this is a problem:

Email spoofing on Gmail and Google Groups. We are aware of the risk presented by spoofed messages and are taking steps to ensure that the Gmail filter can effectively deal with such attacks.

They may already be aware of this particular spoofing vulnerability/"feature", but it's unclear. They can decide on how they want to proceed.

[sjpotter]

I'm dismissive as this discussion is pointless for the point of this issue. this isn't about what smtp is, or what gmail's servers should do, but what they do do. debating what they should do is irrelevant to this issue.