Subject: [Curdle] New Version Notification for draft-kampanakis-curdle-pq-ssh-00.txt

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Wed, 21 Oct 2020 18:49:50 +0000

Hi all,

This draft introduces post-quantum (PQ) algorithms to SSH. It includes Hybrid 
Key exchange messages for SSH and hybrid key exchange and PQ signature 
methods.

Note that we do not want to standardize anything before NIST has standardized 
the first PQ algorithms. We are following a similar approach to what the TLS 
WG is doing with https://tools.ietf.org/html/draft-ietf-tls-hybrid-design . 
They will not ratify the draft before NIST's PQ Round 3 has concluded (in 18 
months or so) so they can pick an algorithm.

draft-kampanakis-curdle-pq-ssh takes a different approach from 
draft-kario-gss-qr-kex which was submitted recently. Basically I feel that a 
new SSH draft would definitely not be ratified in less than 2 years, so there 
ample time to work on the details and come up with the actual SSH PQ 
identifiers after NIST has the first standardized algorithms.

Note that the industry has done experimental work with SSH performance with PQ 
algorithms (using OQS OpenSSH). Some preliminary results of ours are here 
https://blogs.cisco.com/security/tls-ssh-performance-pq-kem-auth and a 
conference paper will be published in December with more detailed results. So, 
we kind of know which algorithms seem more promising from NIST's Round 3 
algorithm Finalists. In other words, we can start the work now, instead of 
waiting for NIST Round 3 to conclude.

I know PQ algorithms in SSH are not in CURDLE's Charter right now, so this 
work may require re-chartering if the WG thought it is worth to pursue.

Thoughts welcome.

Rgs,
Panos

-----Original Message-----
From: [email-masked] <[email-masked]>
Sent: Wednesday, October 21, 2020 1:57 PM
To: Douglas Stebila <[email-masked]>; Panos Kampanakis (pkampana) 
<[email-masked]>; Dimitrios Sikeridis <[email-masked]>; Douglas Steblia 
<[email-masked]>; Markus Friedl <[email-masked]>; Torben Hansen 
<[email-masked]>
Subject: New Version Notification for draft-kampanakis-curdle-pq-ssh-00.txt

A new version of I-D, draft-kampanakis-curdle-pq-ssh-00.txt
has been successfully submitted by Panos Kampanakis and posted to the IETF 
repository.

Name:		draft-kampanakis-curdle-pq-ssh
Revision:	00
Title:		Post-quantum public key algorithms for the Secure Shell (SSH) protocol
Document date:	2020-10-21
Group:		Individual Submission
Pages:		13
URL: 
https://www.ietf.org/archive/id/draft-kampanakis-curdle-pq-ssh-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-kampanakis-curdle-pq-ssh/
Html: 
https://www.ietf.org/archive/id/draft-kampanakis-curdle-pq-ssh-00.html
Htmlized:       https://tools.ietf.org/html/draft-kampanakis-curdle-pq-ssh-00

Abstract:
   This document defines hybrid key exchange methods based on classical
   ECDH key exchange and post-quantum key encapsulation schemes.  These
   methods are defined for use in the SSH Transport Layer Protocol.  It
   also defines post-quantum public key authentication methods based on
   post-quantum signature schemes.  These methods are defined for use in
   the SSH Authentication Protocol.

Note

   EDNOTE: The goal of this draft is to start the standardization of PQ
   algorithms in SSH early to mitigate the potential record-and-harvest
   later with a quantum computer attacks.  This draft is not expected to
   be finalized before the NIST PQ Project has standardized PQ
   algorithms.  After NIST has standardized then this document will
   replace TBD1, TBD3 with the appropriate algorithms and parameters
   before proceeding to ratification.

   EDNOTE: Discussion of this work is encouraged to happen on the IETF
   WG Mailing List or in the GitHub repository which contains the draft:
   https://github.com/csosto-pk/pq-ssh/issues .

   *Change Log* [EDNOTE: Remove befor publicaton].

   draft-kampanakis-curdle-pq-ssh-00
      *  Initial draft

Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: denis bider <[email-masked]>
Date: Thu, 22 Oct 2020 03:14:38 -0500

I strongly support this work being done as a standardized process, as
opposed to some implementation rushing it, possibly with issues, and
leaving others to decide whether to adopt it (issues included).

2 years to RFC would be realistic if all the information is in, and clear
answers exist to everything anyone might bring up.

When the information is not in, and clear answers do not yet exist, these 2
years are extended indefinitely. The 2 year counter doesn't really start.
When clear answers exist, THEN the counter starts, and from THAT point it
takes the 2 years.

Maybe by starting sooner you can save... half a year? Maybe?

Nevertheless, there is a strong benefit to starting early and making it
KNOWN that a process has started. It would discourage individual
implementations from rushing it. So I support starting the process.

denis

On Wed, Oct 21, 2020 at 1:50 PM Panos Kampanakis (pkampana) <pkampana=
[email-masked]> wrote:

> Htmlized:
> https://tools.ietf.org/html/draft-kampanakis-curdle-pq-ssh-00
>
>
> Abstract:
> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle
>

---

From: Hubert Kario <[email-masked]>
Date: Thu, 22 Oct 2020 11:32:32 +0200

On Wednesday, 21 October 2020 20:49:50 CEST, Panos Kampanakis (pkampana) 
wrote:
> draft-kario-gss-qr-kex which was submitted recently. Basically 

Like I said in my follow-up email, I don't consider my proposal to "be all
end all", but rather something that we can quickly throw together and be
reasonably certain it will stand the test of time.

For one, the use of GSS-API in my proposal imposes serious limitations on
deployability.

At the same time, we will need a GSS-API counterpart once we have a 
community
accepted PQ kex.

> I feel that a 

One of problems is that I don't think we have a clear frontrunner in the
NIST competition (that makes interoperability tests more complex for one).

that being said, I'm for having a draft like this published exactly for 
reasons
voiced by Denis Bider

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic