[woodruffw]

> You can of course still manually add keys, and you can even do automatic or semi-automatic key rotation with some new header (e.g. "X-New-Key: [...]" that's signed with the old).

Headers aren't part of an encrypted or authenticated body, so this is trivial to perform a key replacement attack against.

[arp242]

Or MIME part, or change the spec to include some headers (I thought it did?) – that's not an important detail here.

[mschuster91]

> Headers aren't part of an encrypted or authenticated body, so this is trivial to perform a key replacement attack against.

DKIM can be leveraged for that, although DKIM is one hell of a gun to give someone to shoot themselves.

[morelisp]

DNS records aren't part of the encrypted or authenticated channel, so SSH is trivial to perform a key replacement attack against?

[woodruffw]

Sorry, is this a rhetorical question? I thought the fact that SSH does TOFU was (somewhat) common knowledge, which is why it spits out all kinds of scary MITM warnings when a host fingerprint changes.

If you're connecting to an SSH server for the first time and don't already have a pre-established host fingerprint, then yes: someone who controls your server's DNS records can redirect you to another SSH host, which you'll then (presumably) enter your password into.

[fl0ki]

> which you'll then (presumably) enter your password into.

One of the many arguments for using pubkeys so that's all they'll get. Neverthless, the rest of the session could still be anything, and agent forwarding should never be used for untrusted hosts.