[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
- [openpgp] Fwd: Encrypting / Signing the mail subj… David Leon Gil
- Re: [openpgp] Encrypting / Signing the mail subje… Daniel Kahn Gillmor
- Re: [openpgp] Encrypting / Signing the mail subje… Phillip Hallam-Baker
- Re: [openpgp] Encrypting / Signing the mail subje… Daniel Kahn Gillmor
- Re: [openpgp] Encrypting / Signing the mail subje… Werner Koch
- Re: [openpgp] Encrypting / Signing the mail subje… Christoph Anton Mitterer
- Re: [openpgp] Encrypting / Signing the mail subje… Dave Crocker
- Re: [openpgp] Encrypting / Signing the mail subje… Christoph Anton Mitterer
- Re: [openpgp] Encrypting / Signing the mail subje… Daniel Kahn Gillmor