Re: [Secdispatch] [Lake] LAKE next steps

Yoav Nir <ynir.ietf@gmail.com> Tue, 27 August 2019 16:46 UTC

Return-Path: <ynir.ietf@gmail.com>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875171208F6; Tue, 27 Aug 2019 09:46:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 CyRYYOfHEUHo; Tue, 27 Aug 2019 09:46:08 -0700 (PDT)
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 20C1D120937; Tue, 27 Aug 2019 09:46:08 -0700 (PDT)
Received: by mail-wr1-x433.google.com with SMTP id z11so19527315wrt.4; Tue, 27 Aug 2019 09:46:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=AWjNH+nrWkkDWz+5UXFZ0HcHA+LhnY8XLo7JUz8h03w=; b=IajDV8nInaE27U3glYPWmpB+M0HhOhPaw6uOfQdJoeuvKe3cErTmnHIYncU7ooE6wy bTaEsODa6Yc/6U0fB42SNpMFJE1PEnsTNDYfdURfMgleE5LjIDUXXvLzjR445Jpkr4Hc xjgV4nTNP9VSuVulaAQuMP/xWB4sJK+DXB7vu/V8i+2AIqLTZT0uEgd7ne9K2p1R4UgR Hz3zVdkxh/TkA21XKV3I/ObY6TK+adWQv7eN9nN4G8KQZ6uE65PJ2tUozdbzjlVcwDIP Z5XcZfSEkEGVPzqGUN9HkTe4KCor20HhpSuguqbVUCBkGpS2OfHNSeFx/9H1S/On0Hd3 q9bg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=AWjNH+nrWkkDWz+5UXFZ0HcHA+LhnY8XLo7JUz8h03w=; b=IJnR7C2mGko3xYOZs+6MIIP8FiezWHlvnWB1aP7nWs1QasLVHjOJ3zK3dGUEbtcn1C Q+Vd5pY/LLi53C7Xmmbva8/WvCyRiNoVLb0IWzi5z527id+Kmad+alg3niyIBs+N8D+T w08pNKb4eyU44O+WVNyOOuTpxDQ1S35CKrSgE5yhZ6fA4jwMa+pnn84lnnyuPrO3GXAj eKlrOFkS/tPoCIl6oNiyk9/bbFii+cELT3J+c2vF44dUuFRtLEWj+07bf79DGiw9OtuY qzsm/v+azBcTGpoAoFiWgHTq7ZsSLgqH+HVB3gr44WEe2dlZ2ZoA7rfo0tZCYC9l1/tz ZVZA==
X-Gm-Message-State: APjAAAXMRjks/HI+AOFrCyMvVIskJomtU5ibOsF2meZyxF3rka/scSXU CNXtl4f817QwoILZDGWE+/4=
X-Google-Smtp-Source: APXvYqy7AZEeXBDcECJLAoXd89nk0s16tRTGwYF255Kwmcs27Le+hKupXNTHR11nhnwgVUm9FYe/JA==
X-Received: by 2002:a05:6000:148:: with SMTP id r8mr31474706wrx.312.1566924366545; Tue, 27 Aug 2019 09:46:06 -0700 (PDT)
Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id a141sm5301800wmd.0.2019.08.27.09.44.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Aug 2019 09:44:38 -0700 (PDT)
From: Yoav Nir <ynir.ietf@gmail.com>
Message-Id: <5713907E-48A8-4C6E-A7CC-19D7772ADC11@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D109DE3D-3300-4376-B50B-62527A89871E"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 27 Aug 2019 19:44:32 +0300
In-Reply-To: <1ffee1b1-7cd5-67ea-e411-90dc2c72bfb4@gmail.com>
Cc: Benjamin Kaduk <kaduk@mit.edu>, lake@ietf.org, secdispatch@ietf.org
To: Rene Struik <rstruik.ext@gmail.com>
References: <20190820155006.GE60855@kduck.mit.edu> <161a5af2-b357-e1bf-44dc-cc3198e3b939@gmail.com> <20190826202430.GL84368@kduck.mit.edu> <1ffee1b1-7cd5-67ea-e411-90dc2c72bfb4@gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/WK3gCO34_o2Vy5znL5ijei-Isck>
Subject: Re: [Secdispatch] [Lake] LAKE next steps
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Aug 2019 16:46:11 -0000

Hi, Rene

> On 27 Aug 2019, at 6:21, Rene Struik <rstruik.ext@gmail.com> wrote:
> 
> 
> RS>> (Technical.) It would be prudent for IETF not to put too many eggs in the same basket and, thereby, not have most protocols share the same crypto design philosophy, protocol flow framework, and instantiation. While arguably convenient, this is contrary to algorithm agility requirements (since results in in-tandem vulnerabilities and easily ossified code). 

I disagree with this.  It is not the IETF that is putting many eggs in one basket, but the market. It is the market that is protecting every piece of privacy-sensitive information using TLS: financial transaction, bank statements, credit cards, school transcripts, medical appointments and test results, email in transit to name but a few.

If TLS is compromised, all of that is compromised, and the fact that SSH or IPsec or some new OSCORE thing exist does not help me or anyone else whose personal information is now exposed.  If TLS is compromised we’ll have to fix TLS.  So regardless of what we decide at the IETF, a whole lot of our eggs are already in one basket. It’s a better use of our resources to make sure that basket is protected than to spend them on making a new basket that hardly anyone will use.

Yoav