Re: [lamps] HP Issue - Obfuscation of Header Fields

Jonathan Hammell <jfhamme.cccs@gmail.com> Fri, 02 October 2020 18:43 UTC

Return-Path: <jfhamme.cccs@gmail.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF543A1698 for <spasm@ietfa.amsl.com>; Fri, 2 Oct 2020 11:43:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 OcHLk8YbzXnO for <spasm@ietfa.amsl.com>; Fri, 2 Oct 2020 11:43:28 -0700 (PDT)
Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 4BC063A1693 for <spasm@ietf.org>; Fri, 2 Oct 2020 11:43:28 -0700 (PDT)
Received: by mail-ot1-x333.google.com with SMTP id n61so2311037ota.10 for <spasm@ietf.org>; Fri, 02 Oct 2020 11:43:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ZMUJxe+x76gWEknfkRt4nmWqQT7/dbAEmnAEFnxQNBo=; b=tPtrBkQ9Aw0BUEjqIH1bw0xmLkOfYh8RFidY5n2ZJejs+CTe01o5ey6uuJW1kA9UWX xPI8rY8/K00LEY2LtelEI7d1+qhG4xdQ4NEKXPdA32PtoKl7SOhyMVthMSNK0K2Q3onn 3fVtu6FJjPwWxehmHZm9FWsNNzrpIfQzxEhlV3CKv0e5GxflPng62vm36NlXcLam4h51 +bxtAoZXRgaX0qBmvNytpWorsm9N4/IJHzyoPf+ekBZJaga1+v98T6eQ9vX7oBx1QNhO kvCI7jSyobkFEhOh70jLRfTPXEk/Mxt86Pmi+sj5LcrtEdWx/t2gQuKDiwC0xF7PdI/2 NONw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ZMUJxe+x76gWEknfkRt4nmWqQT7/dbAEmnAEFnxQNBo=; b=LD6k60gNoqe8VTBxvxoQwHdLtIBrcQng9no2GB+OHPmeeSqUq1LuaFLYwnw5u8KjLl d6mX5V24crADalGG7mKk+qZTgDBMlKAT+ZRJc/WAM3ddR/Ih6LTunC4JsI4n04OcT+Lv bHDLtROCQKVarFKIN2mvUpfkObDJVFwGdBFZHl6UshrUMKNhRBwSaqk8T1ysKb9h6q6g cZPXXbWy1XtoUJadVUE/TctcublE6tCVtbxy2m3NIYcEjQSDWUq1uHCeFcgDIqMIXdMn b20rvxYxlrXJPyZqaFG9zNF9VPyTHFtQyGOnZBq/WHHk8NzUD/DAcCegW4r8rLHsziK2 eDaw==
X-Gm-Message-State: AOAM531Og/npppgp0O62NC1PR//YhODTWHuV3Vhc8XVIjahSMBi2Gg+R SgS0UZH3qB1gl4YlrF1FmKWM1tGfpOc83kZBeaetmWfRIuo=
X-Google-Smtp-Source: ABdhPJw9tqGbXqWvbRyFN63X6Jb0QIvmkg3yV2So8UpOUPBD1T73kAFT5F1ZO0XMqdZhxQD+BZEXvMzpvK1TMCf25ds=
X-Received: by 2002:a9d:4b18:: with SMTP id q24mr2603736otf.265.1601664207512; Fri, 02 Oct 2020 11:43:27 -0700 (PDT)
MIME-Version: 1.0
References: <alpine.DEB.2.22.394.2009302204580.1283@softronics.hoeneisen.ch> <6874A1B2-AD64-413B-ABEF-765F1231657A@vigilsec.com>
In-Reply-To: <6874A1B2-AD64-413B-ABEF-765F1231657A@vigilsec.com>
From: Jonathan Hammell <jfhamme.cccs@gmail.com>
Date: Fri, 02 Oct 2020 14:43:16 -0400
Message-ID: <CALhKWgihh=HfxDsnTpXSX4L1Kod1oS0fJ6=9TCpWmDYu9fspRA@mail.gmail.com>
To: Russ Housley <housley@vigilsec.com>
Cc: Bernie Hoeneisen <bernie@ietf.hoeneisen.ch>, IETF LAMPS WG <spasm@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/n9pf_cu-ncEp2dVNpAjarXQtPcs>
Subject: Re: [lamps] HP Issue - Obfuscation of Header Fields
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Oct 2020 18:43:30 -0000

I agree with only obfuscating the Subject and only when Encryption is
applied.  I also agree with Russ that it should be optional (at the
sender's discretion) since it does make managing email more difficult.
I prefer "[...]" versus "...".

I support recommending that a new Message-ID is generated if Subject
obfuscation is used.  However, I am curious if any MUAs use the
subject in support of message threading, resulting in unrelated
messages displayed as related.  From a simple test, Gmail does not;
but I believe that the IETF MailArchive might (likely in combination
with matching other HFs) because I have sent message list replies as a
new message with a Subject and Body extracted from the daily digest
and the tool surprisingly threaded it to the original message
correctly.  (A great bit of engineering work there!)

Jonathan

On Wed, Sep 30, 2020 at 5:22 PM Russ Housley <housley@vigilsec.com> wrote:
>
> The thing I recall is that we only want to obfuscate the Subject.  I recall someone suggested "Encrypted Message".  Also, the obfuscation should be at the senders discretion.
>
> Russ
>
>
> > On Sep 30, 2020, at 4:17 PM, Bernie Hoeneisen <bernie@ietf.hoeneisen.ch> wrote:
> >
> > Below a summary of the issue on 'Obfuscation of Header Fields'. If anybody wishes to discuss this topic further or does not agree with the conclusion, please speek up within the next 10 days!
> >
> > cheers,
> > Bernie
> >
> >
> > Text from slide:
> > - Should we recommend any specific format for obfuscation?
> >  e.g.
> >  - Subject: ...
> >  - Subject: [...]
> >  - Date: Thu, 01 Jan 1970 00:00:00 +0000 (UTC)
> >    - Impact to certificate checking?
> >  - Date: <set to Monday 9am of the same week>
> >  - Message-ID: <a new randomly generated Message-ID>
> >  - From: Obfuscated <anonymous@anonymous.invalid>
> >  - To: Obfuscated <anonymous@anonymous.invalid>
> >
> > - Impact to Spam filtering?
> >
> >
> > Conclusion at IETF-108 (as I understood):
> >
> > - Only specify obfuscation if encryption is applied
> > - Only recommend obfuscation for the Subject HF, but not for
> >  Date HF, From HF, To HF
> >
> > We did not discuss about whether or not to recommend a new Message-ID for the Outer Message, as the Message-ID often leaves a trace to the originator host. Unless there are strong reasons not to do so, I'd be in favour of recommending a new randomly generated Messsage-ID. Any opinions on this?
> >
> > _______________________________________________
> > Spasm mailing list
> > Spasm@ietf.org
> > https://www.ietf.org/mailman/listinfo/spasm
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm