[openpgp] Fwd: Encrypting / Signing the mail subject?

David Leon Gil <coruus@gmail.com> Mon, 16 March 2015 22:17 UTC

Return-Path: <coruus@gmail.com>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBAE1A8715 for <openpgp@ietfa.amsl.com>; Mon, 16 Mar 2015 15:17:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.301
X-Spam-Level:
X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MANGLED_BACK=2.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBy1oTK2za19 for <openpgp@ietfa.amsl.com>; Mon, 16 Mar 2015 15:17:11 -0700 (PDT)
Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE5401ABD36 for <openpgp@ietf.org>; Mon, 16 Mar 2015 15:17:11 -0700 (PDT)
Received: by yhch68 with SMTP id h68so22477656yhc.1 for <openpgp@ietf.org>; Mon, 16 Mar 2015 15:17:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=woPdnrhlkQetAUZAzAkWhW4vDGPkpX8tdu2XCITd2eg=; b=skVPwWs0N7532lAWXvs5/MQnGLlC+8JO0RsJ/S3ea2nqbXoQHZ8YHAIQMpK2pCynYo ZTu000zLfQ/riezQYYzYJizf9MeYEvfFBuduFWpaqfpso7588ELSCC9PIYVYtFToSy7v uAcZooPEsAS6ldLAKp3ge+/067n3iBxBQkuLVMIwbwJlfq0zfL3TmZVXHqCudlxdGIMU bZmGCm+tZ0PUwPA7IhALx/GsuVcq6HCQW+A94126H4lPtQApUp/TR0idj/BOlSlm0Zhe fxVgR7HfydfEx8EGxD1zvKd49JPbCGrwvSsUPbsMkBBniMZLXYrSHlpEoJwTuQ91Vrhb PgYg==
MIME-Version: 1.0
X-Received: by 10.170.187.5 with SMTP id d5mr70754394yke.20.1426544231027; Mon, 16 Mar 2015 15:17:11 -0700 (PDT)
Received: by 10.170.125.80 with HTTP; Mon, 16 Mar 2015 15:17:10 -0700 (PDT)
In-Reply-To: <87mw5ixyee.fsf@alice.fifthhorseman.net>
References: <20150116134324.6d918b4e@pc> <87mw5ixyee.fsf@alice.fifthhorseman.net>
Date: Mon, 16 Mar 2015 15:17:10 -0700
Message-ID: <CAA7UWsWECCYR5obxA6nFxThO7uQmrNen1qVibMYwYH2EhN-04g@mail.gmail.com>
From: David Leon Gil <coruus@gmail.com>
To: "openpgp@ietf.org" <openpgp@ietf.org>
Content-Type: multipart/mixed; boundary="001a113a678625c34c05116f3696"
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/lnU79yi7fx8gl1wP989O-s48P0o>
Subject: [openpgp] Fwd: Encrypting / Signing the mail subject?
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Mar 2015 22:17:14 -0000

(And, actually, as I assume DKG won't mind me noting his proposal on
gnupg-devel here.)

---------- Forwarded message ----------
From: *Daniel Kahn Gillmor* <dkg@fifthhorseman.net>
Date: Friday, January 16, 2015
Subject: Encrypting / Signing the mail subject?
To: Hanno Böck <hanno@hboeck.de>, gnupg-devel@gnupg.org

despite the fact that the IETF's OpenPGP WG is closed, i think that
openpgp@ietf.org <javascript:;> mailing list is still active.  It may be
worth
discussing issues like this in that forum as well, to get a wider range
of buy-in.

. . .

Embedded Header Proposal
========================

Here's a counter-proposal to consider, which relies on PGP/MIME.
PGP/MIME messages are the only reliably structured mail OpenPGP e-mail
messages anyway [0].

A normal PGP/MIME signed text/plain message structure looks like this
(Content-Type of each part is shown) [1]:

A └┬╴multipart/signed
B  ├─╴text/plain
C  └─╴application/pgp-signature [signature.asc]

I propose sending a message with an additional text/rfc822-headers [2] part
injected as a sub-part in the message, like this:

D └┬╴multipart/signed
E  ├┬╴multipart/mixed
F  │├─╴text/rfc822-headers inline [header]
G  │└─╴text/plain
H  └─╴application/pgp-signature [signature.asc]

the text/rfc822-headers mime type is defined here:


In this case, only select headers would be embedded (those headers that
are to be signed/encrypted.  The embedded header part (F, above) should
be Content-Disposition: inline, and should be subject to all the usual
rules of parsing mail message headers.

This allows senders to sign arbitrary headers (not just Subject:), and
it works for both signing and encryption.

For sending and receiving MUAs unaware of this convention, no changes
need to be made; at worst, a receiving MUA can simply ignore the
text/rfc822-headers MIME part.  But since it's of type text/* and
Content-Disposition: inline, they may choose to just render it directly
at the top of the message, which would look very similar to your
proposal.

This e-mail message contains a signed set of embedded headers in the way
i've proposed.  How does it render in your unaware MUA?  feel free to
send me a private report if you like.



for aware MUAs, we'd need to spec out the detailed rules:

Message handling guidelines for embedded-header-aware MUAs
==========================================================


composing (sending) MUAs (signed messages)
------------------------------------------

the composing MUA, when crafting a signed message, needs to know which
header fields should be included.  By default, this might just be
Subject:, though maybe it's worth including Date: as well.

This could be represented in MUA configuration as a simple list of
headers:

signed_headers:
 * Subject
 * Date
 * From
 * To
 * Cc

composing (sending) MUAs (encrypted messages)
---------------------------------------------

the composing MUA, when crafting an encrypted message, needs to know
which header fields should be encrypted, and what the default
replacement for that field should be.

This could be represented in MUA configuration as a list of
(header,value) pairs:

Some headers may have a value marked as <omit>, to indicate that the
header should not be exposed publicly at all, but should only be present
in the embedded header.

encrypted_headers:
 * (Subject,"ENCRYPTED SUBJECT")
 * (In-Reply-To,<omit>)
 * (References,<omit>)

Ideally, these lists would be shared across clients and would have sane
defaults, since shared configuration increases ambiguity to an attacker.

(note that the choices described above would hide threading information
>From an attacker)


composing (sending) MUAs (encrypted+signed messages)
----------------------------------------------------

some messages are both signed and encrypted.  an MUA which composes such
a message should craft the embedded headers using the union of all
headers in both signed_headers and encrypted_headers, sign and encrypt
the message, and only then replace or omit the external header fields as
directed by the encrypted_headers configuration.


receiving MUAs (encrypted messages)
-----------------------------------

An MUA that receives an encrypted message with a text/rfc822-headers
part should loop through the embedded headers.  for each embedded
header, it should compare it with the external header of the same label.

If they differ, the MUA should treat the message as though the embedded
header is the correct value.

receiving MUAs (signed messages)
--------------------------------

An MUA that receives a signed message with a text/rfc822-headers part
should loop through the embedded headers.  for each embedded header, it
should compare it with the external header of the same label.

If they differ, the MUA should treat the message as though the embedded
header is the correct value.  The MUA may want to expose the unsigned
value of that header to the user with a warning that it is unsigned.

Whether they differ or not, the MUA should indicate to the user that the
signed parts are signed, and should make a visible distinction between
signed and unsigned headers.


-------

open questions
==============

redundant header parts?
-----------------------

We'd also need to define what happens if more than one
text/rfc822-headers part shows up in a multipart message -- most simply,
we could say that we only process text/rfc822-headers if it happens to
be the first non-multipart part within the multipart/signed or
multipart/encrypted part.  This prevents the receiving MUA from
applying text/rfc822-headers from a forwarded (attached)
signed/encrypted message.


disallowed headers?
-------------------

Are there any headers that *should not* be permitted to be rewritten in
this way?  For example, what would it mean if someone were to embed a
Received: header?  a Message-ID header?

If some are unacceptable, should we have a blocklist (allow arbitrary
headers by default, only reject certain ones) or an allowlist (block
arbitrary headers by default, only accept certain ones like Subject and
date)?


redundant headers
-----------------

within a single header block, there could still be more than one
instance of a given header.  The message itself could also have multiple
copies of a given header (e.g. the Comments and Keywords fields [3]).
If multiple copies of a given header appear in either the exposed header
or the embedded header, and their values differ, how should we resolve
the difference?

-------

[0] https://dkg.fifthhorseman.net/notes/inline-pgp-harmful/

[1] MIME message structure representations shown here are generated from
    actual messages via devel/printmimestructure from the notmuch git
    repository at git://notmuchmail.org/git/notmuch

[2] text/rfc822-headers:   https://tools.ietf.org/html/rfc6522#section-4

[3] Comments and Keywords: https://tools.ietf.org/html/rfc5322#section-3.6.5