[Cryptography] IAB Statement on Internet Confidentiality

[Roland C. Dowdeswell]

On Mon, Nov 17, 2014 at 11:18:13PM -0500, Jerry Leichter wrote:
>

>                                 But we could think about general
> frameworks and guidelines.  It's tricky, because any attempt to
> deliver the information in-line can be forged.  (E.g., if you try
> to add a "Delivered using STARTTLS" header, an attacker can disable
> STARTTLS, then add the header himself.)  But if you're going to
> say "this helps because it turns passive attacks into active attacks,
> and active attacks will be noticed" - you have to make sure they
> can be noticed.  By large numbers of people, in ordinary operation,
> not just by experts who happen to be looking for exactly such an
> attack.

Depending on your goal, it might be sufficient to simply add a field
to the Received: line that each MTA adds containing a secret obtained
from the TLS exchange used in STARTTLS.

To make it concrete, rather than just adding:

Received: from green.metzdowd.com (green.metzdowd.com [166.84.7.15])
	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mournblade.imrryr.org (Postfix) with ESMTPS id AAF94282B63
	for <elric at imrryr.org>; Tue, 18 Nov 2014 04:31:13 +0000 (UTC)
	(envelope-from cryptography-bounces+elric=imrryr.org at metzdowd.com)

one could add:

Received: from green.metzdowd.com (green.metzdowd.com [166.84.7.15])
	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits) and
	tls-hash XXXXXXXXXXXXXX)
	(No client certificate requested)
	by mournblade.imrryr.org (Postfix) with ESMTPS id AAF94282B63
	for <elric at imrryr.org>; Tue, 18 Nov 2014 04:31:13 +0000 (UTC)
	(envelope-from cryptography-bounces+elric=imrryr.org at metzdowd.com)

where the ``tls-hash'' would be derived from the session key using
SSL_export_keying_material which implements IETF RFC 5705.

By itself, this does not offer any protection as the end-user would
be unlikely to check it.  What it does do, however, is greatly
increase the risk associated with MITMing the STARTTLS because it
becomes possible to check via logs and whatnot to detect that it
happened.

With a bit of imagination, one could likely tie the hashes together
in a reasonable way if the client of an SMTP session would prepend
a Transmitted: header which contains a signature (using the senders
published DANE keys) of the tls-hash that the receiver would
independently generate.  This would be a revival of draft-fanf-dane-smtp-01
Section 4 which looks like it was dropped.

For extra credit, one could propose an MTA extension that would
encode the resultant chains in replies so that both parties would
be likely to notice if anything went awry.

--
    Roland Dowdeswell                      http://Imrryr.ORG/~elric/