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

"Dr. Pala" <> Wed, 20 November 2019 07:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3709112085C for <>; Tue, 19 Nov 2019 23:22:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.437
X-Spam-Level: *
X-Spam-Status: No, score=1.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5gU_U-O1Wl8y for <>; Tue, 19 Nov 2019 23:22:25 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id DB2A7120856 for <>; Tue, 19 Nov 2019 23:22:25 -0800 (PST)
Received: from localhost (unknown []) by (Postfix) with ESMTP id 8905F37413DF; Wed, 20 Nov 2019 07:22:25 +0000 (UTC)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id y0b1brM-RDlT; Wed, 20 Nov 2019 02:22:24 -0500 (EST)
Received: from Maxs-MacBook-Pro-2.local (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id E48A737408D6; Wed, 20 Nov 2019 02:22:23 -0500 (EST)
To: Stephen Farrell <>, Eric Rescorla <>
Cc: IETF SecDispatch <>
References: <> <> <>
From: "Dr. Pala" <>
Message-ID: <>
Date: Wed, 20 Nov 2019 15:22:22 +0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------1791D35CBED82C14CAB1F794"
Content-Language: en-US
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:22:27 -0000

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.


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
OpenCA Logo