Re: [Secdispatch] [EXTERNAL]Re: Can Composite sigs move back to LAMPS?

"Markku-Juhani O. Saarinen" <mjos@pqshield.com> Sun, 19 January 2020 19:22 UTC

Return-Path: <mjos@pqshield.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 C8D6D12001E for <secdispatch@ietfa.amsl.com>; Sun, 19 Jan 2020 11:22:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.124
X-Spam-Level:
X-Spam-Status: No, score=-0.124 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_RHS_DOB=1.514] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pqshield-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 ttLfPN0EWK1D for <secdispatch@ietfa.amsl.com>; Sun, 19 Jan 2020 11:22:41 -0800 (PST)
Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) (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 A0A46120018 for <secdispatch@ietf.org>; Sun, 19 Jan 2020 11:22:41 -0800 (PST)
Received: by mail-qt1-x841.google.com with SMTP id k40so26034968qtk.8 for <secdispatch@ietf.org>; Sun, 19 Jan 2020 11:22:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pqshield-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0SM6X5+f16bGr2g9WPuZfYZ4qiB7pRQbwyry+Bvm8GI=; b=m40Z5dc+Z8eKib6btTR5aopG3GxtX9X3xE1BTVLRlcU8MPCcYv/ylSUrEa01OoNzw9 c2ruSx638eTmG1Yt+DL73OxTQ+mUCUZ4tJy+dtRa46395oIwN72MWeO/wWqg3BSJQrED 3IvpNc4OXX+72ph/N/2VZYl6TTJvKBnIW8QDR8EaKcDxh3gyXp8k9lbNQHJHDFfwjR7P dwMCGPIU1+fKV/sU4nNaCWLiDO1rlN16q3BTOl7GoZyfU9lSRsnzf/QlnKybsDVhoxua JOLFDwGPBWfCYvZ3MHrMI/KJBvdQGL87BB6zMKqS9Kk3c9APLnUpZmkUgfwawewXvSZb ic8A==
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=0SM6X5+f16bGr2g9WPuZfYZ4qiB7pRQbwyry+Bvm8GI=; b=t3svZHfDNICUD3+pO/1dhjfIwkHdyBS3IxNopEdTOpnRCTIdxzi3/yFg8Ci0gb/1Ek DPtQXJtcnB9j9XgaHybC3ZJ1UaPJi/7m6KVEwupjZJ3gah1N5GrX5wwOxm7fsQ7oFy0V diXfsYzy15FbmML8F95s3poZJuhOGmsWyCtjfacIf25onmk4veaN3X+Rz4RrrP9xpZVn 1UlxOtgK5mxhgLO7CzzAMu7HP8fDKfQqZcqwRn9Cfg4kOLhEEVihyksNcBCLuLVSKlUk CA+8ED8Atn5vUd8kLPPDSjmCRGBwfPeYVDKRNCI69kbveWGRE5elpfCf3LpNSYLHwKkA GxfQ==
X-Gm-Message-State: APjAAAWYdj40P76nsItoEbPR39HwSeXgLYv9PEd+UcOswSj0R7GwZbXM fb3ku3gQp10eWbD6o0RpQ+tMxYXKuf95BuNq41ymCsa8Oqc=
X-Google-Smtp-Source: APXvYqxGQLvEEq9Bw5cGu/g+z1lU6DKGIXx5lITV7jvGGA3F7NUD8sMVOricW6alLayBL40Ej8RjrPW6sOGiT20GTT8=
X-Received: by 2002:ac8:709a:: with SMTP id y26mr17342918qto.304.1579461760639; Sun, 19 Jan 2020 11:22:40 -0800 (PST)
MIME-Version: 1.0
References: <DM6PR11MB388377406A1AAEDCA397749C9B360@DM6PR11MB3883.namprd11.prod.outlook.com> <70b221bb-bc39-52cc-f9e0-a84261afe473@cs.tcd.ie> <09B0CA53-BAAF-4139-8179-2A70ADE58632@isara.com> <c0f620d7-4e22-18a5-c168-f66b737cae86@cs.tcd.ie> <CAPwdP4PG3i5-_BuVMdH0iMcJCT40xejoM=J3dH=pPO61T-F4Aw@mail.gmail.com> <3f9de00e-85ad-48ed-ba97-e1b5418e3867@cs.tcd.ie> <BYAPR11MB3478E8F964A34EDD232CFB03EE310@BYAPR11MB3478.namprd11.prod.outlook.com> <052d3ee0-41ae-c4f4-7013-6286942c468a@cs.tcd.ie> <DM6PR11MB3883DB8289E4EE1CDEFE7BA89B310@DM6PR11MB3883.namprd11.prod.outlook.com> <3140.1579364674@localhost> <CABcZeBPfGmnkDU-7ot43hC2E7XvB0XeAFFEmsST4S_Hk1GgOFg@mail.gmail.com> <15967.1579382030@localhost> <CABcZeBMWu+Zd_+=gvcc328fm87B1RsxnUaH2HpYbp9Wv_OMUYQ@mail.gmail.com> <24181.1579453158@localhost>
In-Reply-To: <24181.1579453158@localhost>
From: "Markku-Juhani O. Saarinen" <mjos@pqshield.com>
Date: Sun, 19 Jan 2020 19:22:29 +0000
Message-ID: <CAPwdP4PkVfKbg=nCvjDTyGfbc-CiT2PGrdxt-c2b5dDK4903qA@mail.gmail.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: Eric Rescorla <ekr@rtfm.com>, IETF SecDispatch <secdispatch@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002df303059c83196f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/hhOAVEG0PERX-awY0WF7aSbxsnA>
Subject: Re: [Secdispatch] [EXTERNAL]Re: Can Composite sigs move back to LAMPS?
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: Sun, 19 Jan 2020 19:22:44 -0000

On Sun, Jan 19, 2020 at 4:59 PM Michael Richardson <mcr+ietf@sandelman.ca>
wrote:

> Eric Rescorla <ekr@rtfm.com> wrote:
>     mcr> No, it involves two sets of signatures.
>     mcr> The traditional set and the new, yet-to-be-precisely-defined set.
>
>     > Yes, but I had understood these tbe encoded on the wire as if they
>     > were a new signature algorithm, with the result that such a
>     > certificate would not be verifiable by an existing client.
>
>     > Perhaps we should resolve this question first.
>
> I believe that one proposal was to define a new signature type:
>   RSA   -> F { RSA, PQ }
>   ECDSA -> G { ECDSA, PQ }
>
> and then, as you say, that would not interoperate at all.
>
> But, I think that another proposal is to introduce the additional
> signatures
> and related book-keeping as extensions, without disrupting the current
> signature mechanisms.
>

Hi,

As was noted when this draft was introduced, that PQ-in-extension mechanism
is patented and Isara has indicated to IETF that will not allow it to be
used royalty-free. See their IPR  disclosure:
https://datatracker.ietf.org/ipr/3287/   That tech is out there marketplace
and will probably remain proprietary -- see e.g. DigiCert (
https://docs.digicert.com/certificate-tools/post-quantum-cryptography/pqc-toolkit-setup-guide/
 ).

The theory was discussed in "Transitioning to a Quantum-Resistant Public
Key Infrastructure" ( PQCrypto 2017, https://eprint.iacr.org/2017/460.pdf )
which is related to the OQS implementation that works with OpenSSL and TLS
( https://github.com/open-quantum-safe/openssl/tree/OQS-OpenSSL_1_1_1-stable
 ).

There's also a separate Java implementation documented in "X.509-Compliant
Hybrid Certificates for the Post-Quantum Transition" (
https://www.theoj.org/joss-papers/joss.01606/10.21105.joss.01606.pdf  ).
However the Isara-supported qTesla algorithm discussed in that report has
had some problems and I'm not sure of its current status (
https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-Cryptography/documents/round-2/official-comments/qTESLA-round2-official-comment.pdf
).
Their customers are happy if they had a hybrid fall-back because it was
already being shipped out.

The OQS implementation seems to currently treat hybrid keys and signatures
simply as OCTET STRING blobs and assigns an arbitrary OID for each such
pair; I got 1.3.9999.2.2 for a  p256_dilithium2 cert I just created. They
emphasize that this is research code and not for production; the OID is of
course not valid and the key/signature format is not properly documented as
far as I know.

This kind of solution would require n*m OIDs -- perhaps this is manageable,
perhaps not -- the number of ciphersuites we used to have in TLS is an
indication that things may get out of hand, especially if we further
consider different hash functions used for signatures. Anyway, the
additional ASN.1 structure bytes introduced by the draft would essentially
document the structure of such blobs and put them under a single and/or a
small number of OIDs. (Correct me if I'm wrong.)

It would seem that the question of hash functions used in conjunction with
the signature algorithms, and how to identify those, needs to be figured
out. It may be reasonable to use SHA3 also in conjunction with the
classical RSA/ECC sigs here ?

Ultimaco also has a commercial toolkit (
https://hsm.utimaco.com/solutions/applications/post-quantum-crypto-agility/ )
but I'm not 100% which one they're using. It probably interoperates with
the OQS kit at some level since they've worked with Microsoft to get Picnic
(Microsoft's PQ signature proposal) to work with it. This in turn is used
e.g. with Microsoft's PQ VPN ( for details of cert generation, see
https://github.com/microsoft/PQCrypto-VPN/blob/master/openvpn/config/picnic-pki.md
 ).

Sorry if I left someone out. There have been PQ X.509 trials at least for 5
years (strongSwan had Bliss in 2015 --
https://wiki.strongswan.org/projects/strongswan/wiki/Bliss ) but no effort
on serious interop as I am aware.

Cheers,
- markku

Dr. Markku-Juhani O. Saarinen <mjos@pqshield.com> PQShield, Oxford UK.