Re: More mail madness?

Sam Hartman <hartmans-ietf@mit.edu> Mon, 14 May 2018 17:17 UTC

Return-Path: <hartmans-ietf@mit.edu>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A7B1242EA for <ietf@ietfa.amsl.com>; Mon, 14 May 2018 10:17:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.253
X-Spam-Level:
X-Spam-Status: No, score=-0.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 itKOYy2KkJ2d for <ietf@ietfa.amsl.com>; Mon, 14 May 2018 10:17:15 -0700 (PDT)
Received: from mail.suchdamage.org (ec2-52-9-186-167.us-west-1.compute.amazonaws.com [52.9.186.167]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC467124217 for <ietf@ietf.org>; Mon, 14 May 2018 10:17:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.suchdamage.org (Postfix) with ESMTP id 56FD32A0FB; Mon, 14 May 2018 13:17:15 -0400 (EDT)
Received: from mail.suchdamage.org ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkz5FPi2dpWO; Mon, 14 May 2018 13:17:14 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org (c-24-60-138-12.hsd1.ma.comcast.net [24.60.138.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) (Authenticated sender: hartmans-laptop) by mail.suchdamage.org (Postfix) with ESMTPSA; Mon, 14 May 2018 13:17:14 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 80C01C5CA1; Mon, 14 May 2018 13:17:12 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: Viktor Dukhovni <ietf-dane@dukhovni.org>
Cc: "ietf@ietf.org Discussion" <ietf@ietf.org>
Subject: Re: More mail madness?
References: <CAMm+LwiOfdptL6u=SyCtQnz7xKrJD6HTDkKs+JGeHf54CSiv8A@mail.gmail.com> <B0CE44DF-DC7C-4411-B1CC-30B87E38D3F6@vigilsec.com> <51B631EC-78B3-4FF4-A82C-725A029F3DB3@nohats.ca> <BB6B9ACA-6894-4C88-92FC-100E8B4BD20A@dukhovni.org>
Date: Mon, 14 May 2018 13:17:12 -0400
In-Reply-To: <BB6B9ACA-6894-4C88-92FC-100E8B4BD20A@dukhovni.org> (Viktor Dukhovni's message of "Mon, 14 May 2018 13:02:32 -0400")
Message-ID: <tsld0xyf97r.fsf@suchdamage.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/0WxDEAN9B8q5pPmEiMzUprOAZm8>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 May 2018 17:17:17 -0000

>>>>> "Viktor" == Viktor Dukhovni <ietf-dane@dukhovni.org> writes:

    >> On May 14, 2018, at 12:35 PM, Paul Wouters <paul@nohats.ca> wrote:
    >> 
    >> 
    >> So that’s the bandaid. What and where will work be done on a
    >> solution?

    Viktor> A CBC-MAC (or some other suitable ciphertext MAC) would
    Viktor> probably help to defeat tampering with the CBC ciphertext.
    Viktor> As would encrypt-then-sign (rather than the more typical for
    Viktor> S/MIME sign-then-encrypt), but S/MIME signatures are
    Viktor> optional, so a ciphertext MAC seems appropriate.

More generally, I'd strongly suggest that even for confidentiality
without security, you want the security property of semantic security,
and you want some non-malleability property.

My point is that S/MIME seems to want some properties of its underlying
bulk encryption service that CBC clearly doesn't provide.
I think that in addition to recommending new ciphers, it's worth clearly
articulating what security properties you need.  Doing so helps make
analysis of the system easier.  I've found that doing similar work has
saved me from some attacks like this in my own work both inside and
outside the IETF.
It's possible that some or all of this has already been done: it's been
a while since I've read the S/MIME specs.