Re: [IPsec] [lamps] New Liaison Statement, "LS on ITU-T SG17 work on quantum-safe PKI"

Alexander Truskovsky <Alexander.Truskovsky@isara.com> Wed, 04 October 2017 14:17 UTC

Return-Path: <Alexander.Truskovsky@isara.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B7F132332; Wed, 4 Oct 2017 07:17:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 yIGLZWJbPHNc; Wed, 4 Oct 2017 07:17:09 -0700 (PDT)
Received: from esa1.isaracorp.com (esa1.isaracorp.com [207.107.152.166]) by ietfa.amsl.com (Postfix) with ESMTP id D516F132403; Wed, 4 Oct 2017 07:17:08 -0700 (PDT)
Received: from 172-1-110-12.lightspeed.sntcca.sbcglobal.net (HELO cas.isaracorp.com) ([172.1.110.12]) by ip1.isaracorp.com with ESMTP; 04 Oct 2017 14:22:47 +0000
Received: from mb.isaracorp.com (2002:ac01:6e0b::ac01:6e0b) by mb.isaracorp.com (2002:ac01:6e0b::ac01:6e0b) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 4 Oct 2017 10:17:02 -0400
Received: from mb.isaracorp.com ([fe80::9056:5d62:46d0:fe1f]) by mb.isaracorp.com ([fe80::9056:5d62:46d0:fe1f%12]) with mapi id 15.00.1044.021; Wed, 4 Oct 2017 10:17:02 -0400
From: Alexander Truskovsky <Alexander.Truskovsky@isara.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "santosh.chokhani@gmail.com" <santosh.chokhani@gmail.com>, "david.waltermire@nist.gov" <david.waltermire@nist.gov>, "kivinen@iki.fi" <kivinen@iki.fi>, "housley@vigilsec.com" <housley@vigilsec.com>
CC: "ipsec@ietf.org" <ipsec@ietf.org>, "ekr@rtfm.com" <ekr@rtfm.com>, "Scott.Mansfield@Ericsson.com" <Scott.Mansfield@Ericsson.com>, "spasm@ietf.org" <spasm@ietf.org>, "Kathleen.Moriarty.ietf@gmail.com" <Kathleen.Moriarty.ietf@gmail.com>, "itu-t-liaison@iab.org" <itu-t-liaison@iab.org>, "jean-paul.lemaire@univ-paris-diderot.fr" <jean-paul.lemaire@univ-paris-diderot.fr>
Thread-Topic: [lamps] [IPsec] New Liaison Statement, "LS on ITU-T SG17 work on quantum-safe PKI"
Thread-Index: AQHTPKv1s08bHgbKA0itrmKJRnAPCqLUAJqA
Date: Wed, 04 Oct 2017 14:17:02 +0000
Message-ID: <679DF703-35EF-4D67-A0FD-EFA75F755A8C@isara.com>
References: <150531630127.30557.5933470261200873062.idtracker@ietfa.amsl.com> <055701d33beb$08b3f0c0$1a1bd240$@gmail.com> <524F46CC-8BBB-41ED-8089-6BFE0776F660@isara.com> <1471E3E6-35F2-4D2E-9085-B6B82BC8536D@isara.com> <d2af8314-753d-26ab-5f5c-e5102ae08a0f@cs.tcd.ie>
In-Reply-To: <d2af8314-753d-26ab-5f5c-e5102ae08a0f@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.25.5.208]
Content-Type: text/plain; charset="utf-8"
Content-ID: <445D1031F11C694C9C28A4941F1A37F2@isaracorp.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/UBs6KigmVG2EP9JvXNuVrffMses>
Subject: Re: [IPsec] [lamps] New Liaison Statement, "LS on ITU-T SG17 work on quantum-safe PKI"
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Oct 2017 14:17:12 -0000

Thank you for your comment. 

We tried it on unmodified Firefox/Chrome/Safari on the front end and unmodified Apache (OpenSSL/NSS) on the back end using a certificate chain containing RSA+LMS keys/signatures.  In all cases a ciphersuited using RSA for authentication was negotiated and the connection was successfully established, even in the case of Chrome/Safari where we had to inject the root certificate in to the OS’s trusted key store (Apple Keychain in this case).  In the classic use case, the extra key and signature is not used.

In the updated server case, upon startup the server checks the certificate and enables xx_RSA_xx and xx_LMS_xx cipher suites.  It negotiates xx_RSA_xx cipher suite with an unmodified client and proceeds just like in the unmodified case above.  With a modified client, it negotiates xx_LMS_xx cipher suite, sends the same certificate chain but signs the DH keys using LMS private key instead of RSA.  The modified client “peels the outer classic signature off” and verified the inner quantum-safe signature (on all the certificate fields minus the classic signature field) all the way up the chain.  It then uses the quantum-safe public key to verify the signature on the DH keys.

Alex


On 2017-10-03, 8:58 PM, "Stephen Farrell" <stephen.farrell@cs.tcd.ie> wrote:

    
    Hiya,
    
    On 03/10/17 21:38, Alexander Truskovsky wrote:
    > This allows X.509 certificates to contain two (or more) public keys
    > and issuer signatures.  The goal would be to ease the migration of
    > PKI and dependent protocols to new digital signature algorithms.  The
    > motivation was to make the X.509 more cryptographically agile and
    > simplify the migration to quantum-safe algorithms, but it is
    > algorithm agnostic.  The main benefit of this proposal is that
    > current systems will be able to use these newer X.509 certificates as
    > they do today without any modifications, while systems that were
    > updated to support quantum-safe algorithms can also be updated to
    > understand the newer X.509 format and use quantum-safe algorithm
    > instead.
    
    I don't believe the "without any modifications" claim. If that
    were true, then the additional (hopefully) quantum-safe keys or
    signatures would be mere chaff.
    
    I do wonder though if it could be that the advent of a desire
    for post-quantum signatures is the straw that breaks the X.509
    camel's back. For example, with a view to making X.509-based
    PKI evolution end up sufficiently more expensive compared to
    displacing X.509 entirely. It'll be fun to see what happens
    as things pan out.
    
    One reason that that might be the case is that the
    
    S.
    
    
    > 
    > We are working on a draft that mirrors the ITU-T’s work with a few
    > partners and will publish it for review soon.
    > 
    > Alex
    > 
    > 
    > On 2017-10-02, 9:58 PM, "IPsec on behalf of Santosh Chokhani"
    > <ipsec-bounces@ietf.org on behalf of santosh.chokhani@gmail.com>
    > wrote:
    > 
    > I am not sure I understand what is being said below.  The link to the
    > PDF does not add to the message body.
    > 
    > If there is a concern about what signature algorithm is used for what
    > type of subject key, X.509 already has that flexibility.
    > 
    > If there is a concern about using multiple signatures on an X.509 
    > certificate, one can use the single signature algorithm identifier to
    > define multiple algorithms, parameters, and signatures.
    > 
    > -----Original Message----- From: Spasm
    > [mailto:spasm-bounces@ietf.org] On Behalf Of Liaison Statement 
    > Management Tool Sent: Wednesday, September 13, 2017 11:25 AM To:
    > David Waltermire <david.waltermire@nist.gov>; Tero Kivinen 
    > <kivinen@iki.fi>; Russ Housley <housley@vigilsec.com> Cc: Limited
    > Additional Mechanisms for PKIX and SMIME Discussion List 
    > <spasm@ietf.org>; Eric Rescorla <ekr@rtfm.com>; Russ Housley 
    > <housley@vigilsec.com>; Tero Kivinen <kivinen@iki.fi>; Scott
    > Mansfield <Scott.Mansfield@Ericsson.com>; IP Security Maintenance and
    > Extensions Discussion List <ipsec@ietf.org>; Kathleen Moriarty 
    > <Kathleen.Moriarty.ietf@gmail.com>; David Waltermire 
    > <david.waltermire@nist.gov>; itu-t-liaison@iab.org; 
    > jean-paul.lemaire@univ-paris-diderot.fr Subject: [lamps] New Liaison
    > Statement, "LS on ITU-T SG17 work on quantum-safe PKI"
    > 
    > Title: LS on ITU-T SG17 work on quantum-safe PKI Submission Date:
    > 2017-09-13 URL of the IETF Web page:
    > https://datatracker.ietf.org/liaison/1541/
    > 
    > From: Jean-Paul Lemaire <jean-paul.lemaire@univ-paris-diderot.fr> To:
    > David Waltermire <david.waltermire@nist.gov>,Tero Kivinen 
    > <kivinen@iki.fi>,Russ Housley <housley@vigilsec.com> Cc: David
    > Waltermire <david.waltermire@nist.gov>,IP Security Maintenance and 
    > Extensions Discussion List
    > <ipsec@ietf.org>,itu-t-liaison@iab.org,Limited Additional Mechanisms
    > for PKIX and SMIME Discussion List <spasm@ietf.org>,Russ Housley
    > <housley@vigilsec.com>,Scott Mansfield 
    > <Scott.Mansfield@Ericsson.com>,Kathleen Moriarty 
    > <Kathleen.Moriarty.ietf@gmail.com>,Tero Kivinen
    > <kivinen@iki.fi>,Eric Rescorla <ekr@rtfm.com> Response Contacts: 
    > jean-paul.lemaire@univ-paris-diderot.fr Technical Contacts: Purpose:
    > For information
    > 
    > Body: ITU-T Study Group 17 is pleased to inform you that in our 
    > August/September 2017 meeting we agreed to start work on the
    > inclusion of a proposal to include optional support for multiple
    > public-key algorithms in Recommendation ITU-T X509 | ISO/IEC 9594-8.
    > 
    > The industry is preparing ICT systems to be resistant to attacks by 
    > large-scale quantum computers in addition to more sophisticated
    > attacks by conventional computing resources. Proposed was an optional
    > feature to the X.509 certificate that provides a seamless migration
    > capability to existing PKI systems, and is completely backwardly
    > compatible with existing systems.
    > 
    > While public-key key establishment algorithms are typically
    > negotiated between peers and are generally fairly simple to update,
    > the authentication systems typically rely on a single digital
    > signature algorithm which are more difficult to update. This is
    > because of the circular dependency between PKI-based identity systems
    > and the dependent communication protocols. In order to update a PKI
    > system, one would typically need to create a duplicate PKI system
    > that utilizes a new digital signature algorithm and then migrate all
    > the dependent systems one by one.
    > 
    > This proposal eliminates the need to create such duplicate PKI
    > systems by adding optional extensions to contain alternate public key
    > and alternate signature, and a method for the CA to sign certificates
    > using a layered approach to ensure that every attribute is
    > authenticated by both signatures. The resulting certificate, while
    > containing new quantum safe public key and signature, can still be
    > used by existing systems relying on the classic public key and
    > signature. Attachments:
    > 
    > sp16-sg17-oLS-00068
    > 
    > https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2017-09-13-itu-t-sg-17
    >
    > 
    -ipsecme-lamps-ls-on-itu-t-sg17-work-on-quantum-safe-pki-attachment-1.pdf
    > 
    > _______________________________________________ Spasm mailing list 
    > Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm
    > 
    > _______________________________________________ IPsec mailing list 
    > IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
    > 
    > 
    > 
    > 
    > _______________________________________________ Spasm mailing list 
    > Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm
    >