Re: [Secdispatch] Clarification Question for the Comment from Eric Rescorla (

Eric Rescorla <ekr@rtfm.com> Wed, 20 November 2019 07:29 UTC

Return-Path: <ekr@rtfm.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 471EE120871 for <secdispatch@ietfa.amsl.com>; Tue, 19 Nov 2019 23:29:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 ShAys2Eea6ct for <secdispatch@ietfa.amsl.com>; Tue, 19 Nov 2019 23:29:55 -0800 (PST)
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 CBF39120866 for <secdispatch@ietf.org>; Tue, 19 Nov 2019 23:29:54 -0800 (PST)
Received: by mail-lf1-x12c.google.com with SMTP id l14so12636236lfh.10 for <secdispatch@ietf.org>; Tue, 19 Nov 2019 23:29:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GBc9L3bW0wlHMmn9vPNtIz9YlXzbIWguNVYzxBoitP0=; b=ufse8clAHop3zKQNZHZqaldZjMeUs/fQpoNU2cUiChRhlzafkO+axczvSlFSBS2hrN CkZBi7hhRIV5Ppbk5haAgHPqQMW6I9PURvwCHTs/B2OIwIXO0rvqACsEAmY6Bb9m7qB2 YSDieAX9UM2a6XmgGk3FVq5XcRkkmcHME1qrP+nl2Gfilk0GW9k6E/aiNJXpGKC13S9/ 0fo9yqE1xeXZrXOXHJHI+z4cbAff4dGwjc89qGjPFsTL7WjYHpCH/UokKJquvVThnwbh oVon+2zTNxPlu0WZqvdy4Hx6XhtXaA6okH3vJhhOONGh8HqbmtVMZCe9NClFOWa1a3I2 n2bg==
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=GBc9L3bW0wlHMmn9vPNtIz9YlXzbIWguNVYzxBoitP0=; b=f6mhnfsHQgx0QMJdcoH6dh5c+Xpn+P/tZRmJd4R2kFInNBV6oB3OvGxwGkmQaz9SMr DNd4XJgPBXmWf5yXXwcjihbZHuXsJzC1xmFyvK1pLTkLJ6OO+S+osKgsSkC/IMXMabyz kFRLqmDMzOP8Sq2ecfIeFCFWYqqRz6T6jJaYyHUeVLP9cFHo59Z9kMrp5Ip+Gouy8sig BCTzNW91K5uD0nXwt9ZJhCmx8yUrsgjmaHt3Obn6M4eLCg7N8gKz6/t1TRut+3L1M/Rn Y+jK7s7yVAij34T2RUT3JQsQwmiJVzOxEchKLpYgjd8KE1BeN/Bya1/4MMKL445uwqab I1uA==
X-Gm-Message-State: APjAAAXZR1s5m8D8krypwZUlFadsL99rif+kyObSBgNHEBq2eKZPCohG qq7YMECj0e++ShLz09jors+lH7KBTTaNt6VvoV6PzA==
X-Google-Smtp-Source: APXvYqyMkvg7xJw5CT3S6HSa/Ztz3P2jtRuThFIyXn2hEPf+OGUvsRt7khyNuXs+79NpkzE9ZR/0neFrw4mEWBBjPWQ=
X-Received: by 2002:a19:f107:: with SMTP id p7mr1471411lfh.91.1574234993010; Tue, 19 Nov 2019 23:29:53 -0800 (PST)
MIME-Version: 1.0
References: <12eed4ff-edd2-7f70-9460-fc86dcbab927@openca.org> <CABcZeBPbAgBfC6Et+OKQi2=GwsyeyKEKfW5GG=StUepQwy+f0g@mail.gmail.com> <7999ebac-c9c1-eb4f-d9f7-2ba814a3b331@cs.tcd.ie> <78997490-c5ae-c856-6e26-0f79c7733ca3@openca.org>
In-Reply-To: <78997490-c5ae-c856-6e26-0f79c7733ca3@openca.org>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 19 Nov 2019 23:29:16 -0800
Message-ID: <CABcZeBM5WgpcBP4axBvzWaxKU=JA-K-4qiVxhhO1+HzFf246aw@mail.gmail.com>
To: "Dr. Pala" <madwolf@openca.org>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, IETF SecDispatch <secdispatch@ietf.org>
Content-Type: multipart/related; boundary="0000000000008da7fe0597c22560"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/BO6mJY_7RMnYwxDyLhWwYJzC1NM>
Subject: Re: [Secdispatch] Clarification Question for the Comment from Eric Rescorla (
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: Wed, 20 Nov 2019 07:29:57 -0000

Hi Max,

I'm not presently taking a position on whether this work should proceed in
a general matter; I haven't thought it through enough to have an opinion.

What I was trying to say in the meeting is that I don't think this is
probably to be of much use in the WebPKI at this time.

-Ekr


On Tue, Nov 19, 2019 at 11:22 PM Dr. Pala <madwolf@openca.org> wrote:

> Hi Stephen, all,
>
> I just want to add a quick consideration here. We work with hardware that
> is deployed at the customer's homes, offices, etc. When planning for our
> innovation to hit the networks, we need to plan years in advance - this is
> not something we deal with in universities, but, I assure you, it requires
> a lot more planning than you might be used to.
>
> I do disagree with the fact that what we are doing doesn't really help
> that much. The proposed approach does provide a solution that, although it
> might not be optimized, it works.
>
> Other solutions might come afterwards that provide (probably more complex)
> optimized paths (maybe TLS 2.0 will be quite different because its design
> will cover the new design requirements). Another possibility is that
> application specific would define their own code points: the
> "CompositCrypto" algorithm OID will allow to combine any algorithms.
> Applications can then define their own code-points that they accept by
> simply defining the appropriate OID for the algorithm identifer. For
> example, when and if TLS, for example, would like to define its own
> combination of algorithms, a set of specific code-points can be defined for
> that.
>
> Coming back to delaying the work - I think it is wrong and I would like to
> understand why you think it is a good idea.
>
>    - We have the interest of an industry sector
>    - Plus, there has been support on the MLs for not delaying the work
>    any further
>    - Plus, this work is presented by a *committed set of Companies that
>    have real interest in using this technology* to protect the PKIs that
>    secure the internet connectivity for hundreds of millions of users.
>    - Plus, the problem has been already addressed in other institutions
>    (ITU-T) - thus indicating that IETF is falling behind on this topic.
>    - Plus, we are in contact with NIST to possibly collaborate on
>    real-world deployment of QRC by using Composite Crypto.
>
> I think that blocking or stalling this work within the IETF does not make
> any sense. If there are other competing/compelling proposals, please let's
> talk about that and find a common solution we standardize. I personally do
> not think that "Sometimes waiting is a little better" is a valid argument.
>
> If you have technical reasons as to why this work shall not proceed,
> please let us know, we want to deploy the best solution possible.
>
> Thanks,
> Max
>
>
> On 11/20/19 9:33 AM, Stephen Farrell wrote:
>
> On 19/11/2019 21:48, Eric Rescorla wrote:
>
> But until we are prepared to do that, then defining the
> protocol syntax doesn't really help that much.
>
> +1
>
> Sometimes waiting a bit is better:-)
>
> S.
>
> --
> Best Regards,
> Massimiliano Pala, Ph.D.
> OpenCA Labs Director
> [image: OpenCA Logo]
>