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

Eric Rescorla <> Wed, 20 November 2019 07:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 471EE120871 for <>; Tue, 19 Nov 2019 23:29:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ShAys2Eea6ct for <>; Tue, 19 Nov 2019 23:29:55 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CBF39120866 for <>; Tue, 19 Nov 2019 23:29:54 -0800 (PST)
Received: by with SMTP id l14so12636236lfh.10 for <>; Tue, 19 Nov 2019 23:29:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <> <> <> <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Tue, 19 Nov 2019 23:29:16 -0800
Message-ID: <>
To: "Dr. Pala" <>
Cc: Stephen Farrell <>, IETF SecDispatch <>
Content-Type: multipart/related; boundary="0000000000008da7fe0597c22560"
Archived-At: <>
Subject: Re: [Secdispatch] Clarification Question for the Comment from Eric Rescorla (
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


On Tue, Nov 19, 2019 at 11:22 PM Dr. Pala <> 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]