Re: [Secdispatch] [Lake] LAKE next steps

Rene Struik <rstruik.ext@gmail.com> Tue, 27 August 2019 21:32 UTC

Return-Path: <rstruik.ext@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 91678120145; Tue, 27 Aug 2019 14:32:40 -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 gFho9lI1wJ9G; Tue, 27 Aug 2019 14:32:38 -0700 (PDT)
Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 6AC8A120113; Tue, 27 Aug 2019 14:32:38 -0700 (PDT)
Received: by mail-io1-xd2f.google.com with SMTP id s21so1649316ioa.1; Tue, 27 Aug 2019 14:32:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=7h0HS1hTKGooszKnB/sx9XEHSwTBx/fBlr4sJFVCawI=; b=cO1nrSnZZeQXwu8I57GxLILwSXXjjrtl5nJ243pYZjFu/wTeqkHOSM9c1VIV6wLSKs ZyMag4gQTHtyNEeWlI8LRm6QcPYH/1qnkUjnGmSaxpkF71cudUjGszSGkKKhl81si/2j AFe990zaQQvSGa/pd9VOVF68j8DjSdYz6p3/umHY+Zz7VKa0oMibmOxE4MB9YMtNFFQD VKpNplf3QKQ8LR5nLfZPbLrO4wEPklyUnryxZfyHUkvuH4X0csYiWDg/p2kornP6F2s+ rIRJNNLLU9SLmetDA4WvCry6yTabWk2g/MmQLMnYQQkcVZ5F2lsooO0nF4CbbiklLk2d yWyw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=7h0HS1hTKGooszKnB/sx9XEHSwTBx/fBlr4sJFVCawI=; b=OwqTjtRe17drsaJdP0d96dH2HKrYxYnn11ENUHzi4Ce2sdJ+svI3sBgageB2RvlVe+ qWOTCRSCT28SHUbrICbtiuDnUQUGXhANsZ3SlGSJwnrthpKcT0FJc95c75scGkOfwCs/ q4mJA6mpPYlGBdfEjotaT7dS1rqkuvpNsBPi4S7WA92V90qkrELoNjrE0FPur55kYEr6 oyQKm68McfKSWvdYYXYBse3Vebkw++J9wRTdJwwO9K5RY3VwNC0ut8BPVOiNp3c5FUqv BQgUt1tvmJydR07+zYbFkT6Dj66ixS9QI3fV/d666ATmMOgQLt+TcTh1hd6fcHFsRrvV eBnA==
X-Gm-Message-State: APjAAAVRSMTXPIv4qVB32bN6iHNLCz9V7717We7Wzp6a/uk63PQde0y9 5JnaINMymFbTAHwtUYe+3HGtORa5
X-Google-Smtp-Source: APXvYqzS8ZOFp/XDd3LwyhST6JjyqGEP6kbpH+TRLKyhLFEj7wA+BqVVu8hoTk3ZJlaLfmKL42n1fA==
X-Received: by 2002:a5e:cb0a:: with SMTP id p10mr480474iom.133.1566941557064; Tue, 27 Aug 2019 14:32:37 -0700 (PDT)
Received: from ?IPv6:2607:fea8:69f:f5eb:85d:3155:fbab:8b69? ([2607:fea8:69f:f5eb:85d:3155:fbab:8b69]) by smtp.gmail.com with ESMTPSA id z19sm260299ioh.12.2019.08.27.14.32.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Aug 2019 14:32:36 -0700 (PDT)
To: Yoav Nir <ynir.ietf@gmail.com>
Cc: Benjamin Kaduk <kaduk@mit.edu>, lake@ietf.org, secdispatch@ietf.org
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> <5713907E-48A8-4C6E-A7CC-19D7772ADC11@gmail.com>
From: Rene Struik <rstruik.ext@gmail.com>
Message-ID: <0db24e86-fda9-63f8-feee-d24006252542@gmail.com>
Date: Tue, 27 Aug 2019 17:32:31 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <5713907E-48A8-4C6E-A7CC-19D7772ADC11@gmail.com>
Content-Type: multipart/alternative; boundary="------------72CD670AF6B7C059D6097063"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/pJpsSOgEQGXqvvSeuX-q7__69ew>
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 21:32:41 -0000

Hi Yoav:

To my knowledge, IETF prides itself of acting through the efforts of 
gifted individuals, who contribute their expertise and insights, and 
(hopefully) act in the interest of the [admittedly abstract notion of] 
the common good, and not with malicious intent. Mr. Market (whoever he 
or she is) does not sign blue sheets or stand at the mike; nor does the 
"invisible hand" show up in the authors' list or can it be held 
accountable for its actions. People do.

The point of my comment on agility was not so much that one could not 
end up with a TLS-like protocol (this is indeed possible and it is clear 
that some actors have ideas here), but that it should not be the 
pre-condition, esp. since the characteristics of lightweight 
applications might very well be different than those of TLS (e.g., with 
respect to real-life attacks, privacy, deployment, and control). The 
main point, thus, was to keep an open mind.

I am happy to accept a friendly amendment of my note and remove [for 
IETF] from the phrase "It would be prudent [for IETF] not to put many 
eggs in the same basket". I hope that helps and makes this a statement 
that should be obvious to anyone with technical inclinations (but 
nevertheless worth repeating).

Best regards, Rene

On 8/27/2019 12:44 PM, Yoav Nir wrote:
> Hi, Rene
>
>> On 27 Aug 2019, at 6:21, Rene Struik <rstruik.ext@gmail.com 
>> <mailto: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
>
>

-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363