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

Eric Rescorla <ekr@rtfm.com> Tue, 19 November 2019 21:49 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 35DCF1208E1 for <secdispatch@ietfa.amsl.com>; Tue, 19 Nov 2019 13:49:00 -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 QD4NiONOEXiP for <secdispatch@ietfa.amsl.com>; Tue, 19 Nov 2019 13:48:57 -0800 (PST)
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 41F051208F0 for <secdispatch@ietf.org>; Tue, 19 Nov 2019 13:48:57 -0800 (PST)
Received: by mail-lj1-x231.google.com with SMTP id k15so25096187lja.3 for <secdispatch@ietf.org>; Tue, 19 Nov 2019 13:48:57 -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=AR/zF3MjdEN8pi+UjbSlDX66sZINppfnlc5o9+h/xyE=; b=U2c80qNU4rwDjoHmWKIsfPG9+qFWgpzujlW7MdDZ9W+avx04MG8CmdZh4Qwp9KWdRx VYekZBrpIu9hHm4yo7FJgIOOlltotixAQ22qNbYIKSyFPUkunZjgUTJYzb/ePR+0QDzJ 7cGly4okZugnMCpEt/8uhbg7NrBkXzYDo3ALgMKdSZZiNnZUWHyq1dbEcUTEfMYWGB/I CRUlWuWWHdapY3QTDgEobn0YxXH+WTqy0jnbpr/l4xCFivigpTBD/Mn0D9gUMgWWgQQb /AOoqTfOMYyqKNZChRWj/nv1OWlp/5yARCVRGlF/kfGN/rzWGatrM25ocM8I2hFUbzMF lqQg==
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=AR/zF3MjdEN8pi+UjbSlDX66sZINppfnlc5o9+h/xyE=; b=Nb2JvdvOnF2pZYpbEID7S8Nbdrg3K57OjzGjBC6SBhb6pi1omTBIslqUun7as8duKQ nft3BUPi2LQzCSatjGHrxIRIgspqhRtFiOmglYk7XLnCMQIT3WY9jPjYKXem8sKg7IR4 MlrgPN97UqHr9L8nvWXbmzIlD6SKXlwUTM3q6MmQZpAl1WF6Eu5DblS0/LZy8bw59fCu tANj8CDIRiQ0DJPFmQCOkgyqJVI3/iGTA4BP5jwTWbF9zoG+saZtfmh+rNl4Q179RMQe 2z5PFp4jzFOMYstuecaKiWwURwsb0D6TucfrFFd+KRlOPh5RqfcSQ7uaqPwEO8xljypA Gg4A==
X-Gm-Message-State: APjAAAXU7roxSiGYfwyyexRwVOgmOUm3Z9WthJCYH71rIVhuJpJvC9Qp jLRnpFaL2l7fgdZjhmf2WHqp9jBJBZsiltszNIb/8g==
X-Google-Smtp-Source: APXvYqzrDkentk5b77p8VXMgGZ/N5vJmV36GdXzuwW4riLjTAndpbCJDbyY1lPtop6d99JybJI7RquNkmTCNqwjMIzI=
X-Received: by 2002:a2e:864f:: with SMTP id i15mr5591758ljj.29.1574200135266; Tue, 19 Nov 2019 13:48:55 -0800 (PST)
MIME-Version: 1.0
References: <12eed4ff-edd2-7f70-9460-fc86dcbab927@openca.org>
In-Reply-To: <12eed4ff-edd2-7f70-9460-fc86dcbab927@openca.org>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 19 Nov 2019 13:48:18 -0800
Message-ID: <CABcZeBPbAgBfC6Et+OKQi2=GwsyeyKEKfW5GG=StUepQwy+f0g@mail.gmail.com>
To: "Dr. Pala" <madwolf@openca.org>
Cc: IETF SecDispatch <secdispatch@ietf.org>
Content-Type: multipart/related; boundary="000000000000de68290597ba0710"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/dQhQ-0UKKtZHtNWSBd74r4tFVy4>
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: Tue, 19 Nov 2019 21:49:00 -0000

Hi Max,

My point is not that it's technically difficult for the clients to add
support for composite crypto. Clearly we could do so.

My point is rather that at a high level there are two kinds of upgrades of
algorithms in an authentication system:

- Upgrading to more secure algorithms
- Upgrading to algorithms which are better in some other way (e.g., speed,
size, etc.)

With the second kind of upgrade, you get immediate benefit because your
signatures are faster or whatever, but with the first kind of upgrade, you
get benefit when you deprecate the old algorithm. As long as you still
trust the old algorithm, then the system isn't getting much benefit from
the existence of the new algorithm because the attacker just attacks the
old one and you'll still accept it. For that reason, you need to do a two
step process:

1. Introduce the new algorithm and try to get it to be ubiquitous.
2. Stop trusting the old algorithm.

In a system like the Web, you can only do (2) once there is almost no use
of the old algorithm, otherwise you cause breakage. This, of course, is
what we did with SHA-1 and it took a really long time. We're currently
doing it with TLS 1.0 and 1.1 and we have to carefully watch the statistics
to cabin the amount of breakage.

So, when we look at composite crypto and the Web, we need to ask: are we
prepared to introduce some specific set of composite algorithms, put them
in the CABF BRs and eventually require that the CAs use them and refuse to
honor their certificates if they do not. I do not believe that we are
anywhere near that stage, both due to the maturity of the algorithms (aside
from hash signatures) and the performance (mostly size) of those
algorithms. But until we are prepared to do that, then defining the
protocol syntax doesn't really help that much.

This isn't to say that I don't think that it's useful to have PQ algorithms
in some other context (e.g., code signing) but for those contexts, I'm not
sure the right move is composite signatures rather than just to transition
wholesale to hash signatures, which we have confidence in.

-Ekr


On Tue, Nov 19, 2019 at 6:18 AM Dr. Pala <madwolf@openca.org> wrote:

> Hi Eric, all,
>
> I am sorry I had quite a hard time to understand the questions/comments
> today, however, I would like to properly address the raised concerns/points.
>
> *Clients / Software Updates Comment:*
>
> I wanted to understand your questions/comments about the need to update
> clients and that would never happen.
>
> Could you please elaborate on this point ?
>
> It is my understanding that we do have to update our crypto libraries when
> we want to support a new algorithm, and that is what we are talking about.
> Any time we add a new algorithm, the software needs to be updated - but I
> do not see why this is a problem specific for this solution. ALL of the
> approaches will need software updates (exactly as we did for TLS 1.3).
>
> Personally, I think that Composite Crypto is also interesting from this
> point of view since updating the crypto layer will enable its use without
> the need to change protocols or application behavior. From an
> application-development point of view, IMHO, it is a very intriguing
> approach.
>
> *SHA-1 Transition:*
>
> One of your comments, if I am not mistaken, was about comparing one of the
> possible solutions to the problem (Composite Crypto) with the SHA-1
> transitioning period - how, in your opinion, is that transition process
> related to the specifics of the proposal ?
>
> Again, I am sorry I could not understand the questions clearly (normal
> language barrier issues :D), but I hope I can address your concerns on the
> list.
>
> Thanks again,
>
> Cheers,
> Max
>
>
> --
> Best Regards,
> Massimiliano Pala, Ph.D.
> OpenCA Labs Director
> [image: OpenCA Logo]
>