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.
- More mail madness? Phillip Hallam-Baker
- Re: More mail madness? Russ Housley
- Re: More mail madness? Paul Wouters
- Re: More mail madness? Russ Housley
- Re: [lamps] More mail madness? Richard Barnes
- Re: More mail madness? Viktor Dukhovni
- Re: [lamps] More mail madness? Phillip Hallam-Baker
- Re: More mail madness? Sam Hartman
- Re: More mail madness? Russ Housley