Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE47130F02 for ; Thu, 20 Sep 2018 05:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.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 zFOXLZ7d6LY8 for ; Thu, 20 Sep 2018 05:02:48 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 E9E47130EAE for ; Thu, 20 Sep 2018 05:02:42 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id 13-v6so8126776ois.1 for ; Thu, 20 Sep 2018 05:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Nn4ky4KviwSrZ5pmN0sNVp9Z+Hf5FvJPUUV54+JDLSA=; b=1Ew7RFXFLEQKtqOHcCprWb3W+Lwz1l8W8U4avZYVNWbgPh+Eu3vphvEozpHQSIwwca 9n/Vws07JdHO7ZolxuLXmIjecrIOtcsDttyp6U94vVDy9AIpxD9Ub4eQbfvDm8RVUt+l LydAc3KKzoJYe52OR1TXhFDClwzyAVw2LG/IujamGwPSOrsvz16cXvD/7EIzVvq4DvvN dczSpShWYNKYmElrHq7OSVa9/FbgQtlJwbXnj9hvRokKNdyNcDvaFjMqGuML1vxaRfTd K/KTvYuXEUxYhtsyv2Th9QCxZ09s+beeHRFuwCrW3UlZlPTt6+qtJDOVvx6CUrtOK5hS /r4Q== 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; bh=Nn4ky4KviwSrZ5pmN0sNVp9Z+Hf5FvJPUUV54+JDLSA=; b=eIbIKOaE+XRcRK1uWu6a5ewlGmfA4xjtuk8yrIt9A8j8Qst+K4wvooGkwO9LFLVdTU FJ2Q+1KWfzS6sxm5Iobhxs7nBzJymqvaO25HGptHZGDL/V+iKa32EfhiTmUfGxmIbIZ1 KkmyPVmNR0Bnt8k/igdgf46poUkSnM1BCiMEeVd7SaQcWFF6SV3a59um04+XSpvM/y+d ZvVRsLxRXjTxevW4QZXm4Hy24BhfG8bQTOx28f6JeT3tGjGYSzmhhNAfuyt8F9t09vGj LNZjgSWy0sY+T2hh9i2Udpwo8qs2DFNhHTklDIRwpGPURo+dT9bJ+lavcQDcDAfWZsiD do4A== X-Gm-Message-State: APzg51C+h5TkCJKI9bDpORp9Fa2GIsVH/BRIknHxGBugVSBilnlvvqwZ IGgq+BEOChsVvVCtrNofwfMFp1EE5d2EnaUVhUPNKsKOUhU= X-Google-Smtp-Source: ANB0VdYJgNEhxjQxnI7oDBXuXkqjACTcF+jO7TAcdR0na78NUCxzKQVAzFQvRe5X65shf26oC5LTJqKJoNuMgdmxRZ0= X-Received: by 2002:aca:40d6:: with SMTP id n205-v6mr1305057oia.35.1537444961797; Thu, 20 Sep 2018 05:02:41 -0700 (PDT) MIME-Version: 1.0 References: <7397E576-521F-4198-9232-C59530877E19@wire.com> <911130F4-8B46-45C9-A4A6-8359A950DD48@wire.com> In-Reply-To: From: Richard Barnes Date: Thu, 20 Sep 2018 08:02:29 -0400 Message-ID: To: "Salz, Rich" Cc: Raphael Robert , mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000cf603905764c4ca8" Archived-At: Subject: Re: [MLS] Substitute AES-128-GCM with AES-256-GCM for TreeKEM X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2018 12:03:02 -0000 --000000000000cf603905764c4ca8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As I understand it: The parts of a ciphersuite work together, so the idea is roughly that there's no point in adding one super strong link to the chain if the others are weak. Following the TreeKEM / ECIES example below, if you generate a key for AES-256 off of a P-256 ECDH operation, then the whole thing can still be broken with 2^128 effort, by attacking the ECDH instead of the AES. On Thu, Sep 20, 2018, 07:55 Salz, Rich wrote: > Is there a good rationale, perhaps a link, explaining why all parts of a > cipher-suite need to be at the same strength? I tend to call those things > =E2=80=9Ccrypto numerology=E2=80=9D but perhaps (not being a cryptographe= r) I=E2=80=99m just > biased. Yes, I understand that it might be no better than the weakest > link. > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --000000000000cf603905764c4ca8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As I understand it:

The parts of a ciphersuite work together, so the idea is roug= hly that there's no point in adding one super strong link to the chain = if the others are weak.=C2=A0=C2=A0

Following the TreeKEM / ECIES example below, if you generate a key fo= r AES-256 off of a P-256 ECDH operation, then the whole thing can still be = broken with 2^128 effort, by attacking the ECDH instead of the AES.



On Thu, Sep 20, 2018, 07:55 Salz, Rich &l= t;rsalz=3D40akamai.com@dmarc= .ietf.org> wrote:

Is there a good rationale, perhaps a link, explainin= g why all parts of a cipher-suite need to be at the same strength? I tend t= o call those things =E2=80=9Ccrypto numerology=E2=80=9D but perhaps (not be= ing a cryptographer) I=E2=80=99m just biased.=C2=A0 Yes, I understand that it might be no better than the weakest link. =C2=A0

=C2=A0

_______________________________________________
MLS mailing list
MLS@ie= tf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000cf603905764c4ca8--