From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Nov 1 13:03:37 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE2561A8A74 for ; Sun, 1 Nov 2015 13:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 XDfp_cg37Xek for ; Sun, 1 Nov 2015 13:03:35 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B720C1A8A6E for ; Sun, 1 Nov 2015 13:03:35 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id B1A4414A246; Sun, 1 Nov 2015 21:03:32 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 55BDF14A244; Sun, 1 Nov 2015 21:03:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id C698E14A1E3 for ; Sat, 31 Oct 2015 20:49:47 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id rF6MIxAq3aE0 for ; Sat, 31 Oct 2015 20:49:46 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id B2FCD14A0CB for ; Sat, 31 Oct 2015 20:49:46 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for ietf-ssh@NetBSD.org; Sat, 31 Oct 2015 20:49:42 +0000 Date: Sat, 31 Oct 2015 20:49:42 +0000 Subject: Re: SSH key algorithm updates / Proposal and intent to implement "dsa-sha2-256" SSH key algorithm X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0 Message-ID: <1447353595-320@skroderider.denisbider.com> X-Priority: 3 Importance: Normal In-Reply-To: <1399504453-896@skroderider.denisbider.com> MIME-Version: 1.0 From: denis bider To: ietf-ssh@NetBSD.org Cc: jhutz@cmu.edu, nisse@lysator.liu.se, stephen.farrell@cs.tcd.ie, mdb@juniper.net, jon@siliconcircus.com Content-Type: multipart/alternative; boundary="=-N7weGE4qGtIFLR0J4Jjz" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-N7weGE4qGtIFLR0J4Jjz Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I have made another update to this draft which replaces the padding method = RSASSA-PKCS1-v1_5 with RSASSA-PSS (also defined in RFC 3447). Same URL: http://www.denisbider.com/draft-rsa-dsa-sha2-256.txt There appear to be reasonable arguments (Hans Boeck in particular has studi= ed this) that PSS is safer to implement (no parsing trap to fall into) and = backed by stronger theory (provably secure under reasonable assumptions). S= upport now seems to be sufficiently widespread, whereas it wasn't earlier (= support was added to OpenSSL in version 1.0.1 in March 2012); so it now see= ms like a good opportunity to do this. denis denis bider , 10/31/2015 7:20 AM: I have uploaded a new draft here: http://www.denisbider.com/draft-rsa-dsa-sha2-256.txt This now specifies both "rsa-sha2-256" and "dsa-sha2-256". denis bider , 10/31/2015 5:17 AM: Mark D. Baushke: > Should this Draft RFC also be the one that moves the "ssh-dss" > public key algorithm from a "REQUIRED" and "MUST" implement > algorithm to an "OPTIONAL" and "SHOULD NOT" implement algorithm? I very much agree this should be done. However, it seems to me a separate p= urpose which may require a different type of consensus. It seems we could very much use Stephen's (offered) help with this. > Perhaps moving the Ed25519 algorithm FIPS does not approve of it, so there's a huge swath of products aimed for= government that can't use the supposed "required" method. It's also not easily available everywhere. Crypto++ doesn't have it. Window= s CNG doesn't have it. There's DJB's original code, which is native code, a= nd is not the most user friendly. I think RSA might fit the "required" role better. It's old, solid, universa= lly available, and acceptable to everyone. All it needs is an update to use= SHA-2 as the hash. Jeffrey Hutzelman: > I don't understand. The issue with ssh-dss was that we _didn't_ > allow for larger key sizes.=20 The issue is that there was no standard for larger key sizes at the time "s= sh-dss" was defined. Consequently, few implementations existed that could h= andle them. None existed that were completely general. If we "allow for" larger key sizes, then ALL implementations must be able t= o straightforwardly and correctly support them in advance. If they do not -= and they will not, because they don't perceive the need at this time - the= n this creates future compatibility problems. For example, if I use Windows CNG to implement this algorithm, I can only i= mplement 2048-bit and 3072-bit key sizes. I can't provide an implementation= compliant with a requirement to support larger keys. Any future users that= might use larger sizes will run into compatibility issues with software I = create now. This software may very well be still in use in 2020, even 2025.= We still hear from users running 9 year old versions of our software. User= s running 5 year old versions are common (perhaps even a majority). >=C2=A0 In fact, now that I think about it, we probably should have > defined an rsa-sha256 public key algorithm. There's no time like today. We can define "rsa-sha2-256" right now. Since RSA keys aren't themselves hash-dependent, we could grandfather in ex= isting RSA keys, and keep "ssh-rsa" in the public key format. This retains = existing host key fingerprints, and allows the same keys to be used for bot= h "ssh-rsa" and "rsa-sha2-256". This vastly simplifies migration. We change= the signature specification to use the new name, and to use SHA-2 256. I believe this would further provide a credible signature algorithm that we= could suggest "recommended" or "required". It seems to me that none of the= other candidates are good matches: - without deterministic signatures, DSA has its weakness to anything but pe= rfect RNG - EdDSA is not FIPS acceptable - ECDSA over NIST curves is not acceptable to others - The existing "ssh-rsa" uses SHA-1 However, if we define "rsa-sha2-256", however, we could mandate it as at "r= ecommended" (or even "required"). > - Upgrade ssh-rsa to REQUIRED Not sure about that. It uses SHA-1. We should probably define "rsa-sha2-256= ". = --=-N7weGE4qGtIFLR0J4Jjz Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable I have made another update to this draft which rep= laces the padding method RSASSA-PKCS1-v1_5 with RSASSA-PSS (also defined in= RFC 3447).

Same URL:

http://www.denisbider.com/draft-rsa-dsa= -sha2-256.txt

There appear to be reasonable arguments (Hans Boeck in= particular has studied this) that PSS is safer to implement (no parsing tr= ap to fall into) and backed by stronger theory (provably secure under reaso= nable assumptions). Support now seems to be sufficiently widespread, wherea= s it wasn't earlier (support was added to OpenSSL in version 1.0.1 in March= 2012); so it now seems like a good opportunity to do this.

denis

denis bider <ietf-ssh3@denisbide= r.com> , 10/31/2015 7:20 AM:
<= div>I have uploaded a new draft here:

http://www.denisbider.com/draft-rs= a-dsa-sha2-256.txt

This now specifies both "rsa-sha2-256" and "d= sa-sha2-256".


denis bider <= ;ietf-ssh3@denisbider.com>= , 10/31/2015 5:17 AM:
Mark D. Baushke= :

> Should this Draft RFC also be the one that moves the "ssh-dss= "
> public key algorithm from a "REQUIRED" and "MUST" implement
&g= t; algorithm to an "OPTIONAL" and "SHOULD NOT" implement algorithm?

= I very much agree this should be done. However, it seems to me a separate p= urpose which may require a different type of consensus.

It seems we = could very much use Stephen's (offered) help with this.


> Per= haps moving the Ed25519 algorithm

FIPS does not approve of it, so th= ere's a huge swath of=20 products aimed for government that can't use the supposed "required"=20 method.

It's also not easily available everywhere. Crypto++ doesn't = have it. Windows CNG doesn't have it. There's DJB's original code, which is= native code, and is not the most user friendly.

I think RSA might f= it the "required" role better. It's old, solid, universally available, and = acceptable to everyone. All it needs is an update to use SHA-2 as the hash.=


Jeffrey Hutzelman:

> I don't understand. The issue wi= th ssh-dss was that we _didn't_
> allow for larger key sizes.
The issue is that there was no standard for larger key sizes at the time "= ssh-dss" was defined. Consequently, few implementations existed that could = handle them. None existed that were completely general.

If we "allow= for" larger key sizes, then ALL implementations must be able to straightfo= rwardly and correctly support them in advance. If they do not - and they wi= ll not, because they don't perceive the need at this time - then this creat= es future compatibility problems.

For example, if I use Windows CNG = to implement this algorithm, I can only implement 2048-bit and 3072-bit key= sizes. I can't provide an implementation compliant with a requirement to s= upport larger keys. Any future users that might use larger sizes will run i= nto compatibility issues with software I create now. This software may very= well be still in use in 2020, even 2025. We still hear from users running = 9 year old versions of our software. Users running 5 year old versions are = common (perhaps even a majority).


>  In fact, now that I= think about it, we probably should have
> defined an rsa-sha256 publ= ic key algorithm.

There's no time like today. We can define "rsa-sha= 2-256" right now.

Since RSA keys aren't themselves hash-dependent, w= e could grandfather in existing RSA keys, and keep "ssh-rsa" in the public = key format. This retains existing host key fingerprints, and allows the sam= e keys to be used for both "ssh-rsa" and "rsa-sha2-256". This vastly simpli= fies migration. We change the signature specification to use the new name, = and to use SHA-2 256.

I believe this would further provide a credibl= e signature algorithm that we could suggest "recommended" or "required". It= seems to me that none of the other candidates are good matches:

- w= ithout deterministic signatures, DSA has its weakness to anything but perfe= ct RNG
- EdDSA is not FIPS acceptable
- ECDSA over NIST curves is not= acceptable to others
- The existing "ssh-rsa" uses SHA-1

However= , if we define "rsa-sha2-256", however, we could mandate it as at "recommen= ded" (or even "required").


> - Upgrade ssh-rsa to REQUIRED
Not sure about that. It uses SHA-1. We should probably define "rsa-sha= 2-256".

= --=-N7weGE4qGtIFLR0J4Jjz-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Nov 1 13:05:03 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D23411A8A98 for ; Sun, 1 Nov 2015 13:05:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 FnBk0qnT9Z9v for ; Sun, 1 Nov 2015 13:05:02 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45D311A8A95 for ; Sun, 1 Nov 2015 13:05:02 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id EFC0614A203; Sun, 1 Nov 2015 21:05:01 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 9210314A202; Sun, 1 Nov 2015 21:05:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id F2BA914A1C5 for ; Sun, 1 Nov 2015 08:56:21 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id fjZe9ZDcYE1G for ; Sun, 1 Nov 2015 08:56:21 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 2E21314A1B5 for ; Sun, 1 Nov 2015 08:56:21 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for ietf-ssh@NetBSD.org; Sun, 1 Nov 2015 08:56:19 +0000 Date: Sun, 1 Nov 2015 08:56:19 +0000 Subject: RE: SSH key algorithm updates X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0 Message-ID: <1490391868-320@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: ietf-ssh@NetBSD.org Cc: pgut001@cs.auckland.ac.nz, nisse@lysator.liu.se, stephen.farrell@cs.tcd.ie, jon@siliconcircus.com, mdb@juniper.net Content-Type: multipart/alternative; boundary="=-VFs7llGhzIpHCz+VlAWZ" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-VFs7llGhzIpHCz+VlAWZ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > I'm strongly opposed to keeping DSA, for the reasons given earlier. On the CFRG mailing list, there was one (!) good reason provided. That is D= SA's susceptibility to PRNG mismanagement. This argument is completely coun= tered by deterministic signatures, which have an RFC (RFC 6979), which incl= udes test vectors directly applicable to the discussed dsa-sha2-256. All the tools and specs are there to implement DSA securely. Besides this, there has been no argument other than "it's no better than RS= A". But it is better in this aspect: a 3072-bit DSA signature is 4x faster = than 3072-bit RSA. This means potentially 4x as many connections that can b= e served by busy servers.=20 Of course, if you are looking for performance, today you would use ECDSA. B= ut if there is a problem with elliptic crypto; DSA provides a backstop that= 's a 5x slowdown compared to 256-bit ECDSA, providing equivalent security. = In comparison, 3072-bit RSA is a 20x slowdown, or a security downgrade. I definitely think dsa-sha2-256 should be OPTIONAL, not RECOMMENDED. I thin= k instead rsa-sha2-256 should be RECOMMENDED or REQUIRED, since it's the le= ast objectionable of all algorithms. Every other algorithm has someone who = hates it, RSA is just... kinda slow. > Since neither the PGP nor the X.509 formats as used in SSH were > ever defined, I'd just remove them. I agree. I've never implemented the PGP ones, or seen them used. Someone wh= o knows those algorithms should do a writeup - if there is someone. ----- Original Message ----- From: Peter Gutmann=20 Sent: Saturday, October 31, 2015 19:02 To: Jeffrey Hutzelman ; Mark D. Baushke=20 Cc: denis bider ; ietf-ssh@NetBSD.org ; nisse@lysator.liu.se ; stephen.farr= ell@cs.tcd.ie ; jon@siliconcircus.com=20 Subject: RE: SSH key algorithm updates Jeffrey Hutzelman writes: >- Add dsa-sha2-256 as RECOMMENDED I'm strongly opposed to keeping DSA, for the reasons given earlier.=C2=A0 I= t's dead everywhere except SSH, it'd be nice to get rid of this one holdout as well. >Perhaps Denis wants to add pgp-sign-dsa-sha2-256 and/or x509v3-dsa-sha2-25= 6 >to his document. Since neither the PGP nor the X.509 formats as used in SSH were ever define= d, I'd just remove them.=C2=A0 Short of reverse-engineering someone else's implementation to see what they do, I can't see how you'd create an interoperable implementation of either of these. Peter. = --=-VFs7llGhzIpHCz+VlAWZ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable > I'm strongly opposed to keeping DSA, for the = reasons given earlier.

On the CFRG mailing list, there was one (!) good reason provided. That is DSA's susceptibility to PRNG mismanagem= ent. This argument is completely countered by deterministic signatures, whi= ch have an RFC (RFC 6979), which includes test vectors directly appl= icable to the discussed dsa-sha2-256.

All the tools and specs are th= ere to implement DSA securely.

Besides this, there has been no argum= ent other than "it's no better than RSA". But it is better in this a= spect: a 3072-bit DSA signature is 4x faster than 3072-bit RSA. This means = potentially 4x as many connections that can be served by busy servers.
=
Of course, if you are looking for performance, today you would use ECDS= A. But if there is a problem with elliptic crypto; DSA provides a ba= ckstop that's a 5x slowdown compared to 256-bit ECDSA, providing equivalent= security. In comparison, 3072-bit RSA is a 20x slowdown, or a secur= ity downgrade.

I definitely think dsa-sha2-256 should be OPTIONAL, n= ot RECOMMENDED. I think instead rsa-sha2-256 should be RECOMMENDED or REQUI= RED, since it's the least objectionable of all algorithms. Every other algo= rithm has someone who hates it, RSA is just... kinda slow.


> = Since neither the PGP nor the X.509 formats as used in SSH were
> eve= r defined, I'd just remove them.

I agree. I've never implemented the= PGP ones, or seen them used. Someone who knows those algorithms should do = a writeup - if there is someone.


----- Original Message -----From: Peter Gutmann
Sent: Saturday, October 31, 2015 19:02
To: Jeff= rey Hutzelman ; Mark D. Baushke
Cc: denis bider ; ietf-ssh@NetBSD.org ;= nisse@lysator.liu.se ; stephen.farrell@cs.tcd.ie ; jon@siliconcircus.com <= br>Subject: RE: SSH key algorithm updates

Jeffrey Hutzelman <jhut= z@cmu.edu> writes:

>- Add dsa-sha2-256 as RECOMMENDED

I= 'm strongly opposed to keeping DSA, for the reasons given earlier.  It= 's dead
everywhere except SSH, it'd be nice to get rid of this one holdo= ut as well.

>Perhaps Denis wants to add pgp-sign-dsa-sha2-256 and= /or x509v3-dsa-sha2-256
>to his document.

Since neither the PG= P nor the X.509 formats as used in SSH were ever defined,
I'd just remov= e them.  Short of reverse-engineering someone else's
implementation= to see what they do, I can't see how you'd create an
interoperable impl= ementation of either of these.

Peter.

= --=-VFs7llGhzIpHCz+VlAWZ-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 2 09:07:54 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC851B49DA for ; Mon, 2 Nov 2015 09:07:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 X9b4zERoQrP4 for ; Mon, 2 Nov 2015 09:07:47 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77A811B49D8 for ; Mon, 2 Nov 2015 09:07:47 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 801C514A26C; Mon, 2 Nov 2015 17:07:44 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 2A57F14A265; Mon, 2 Nov 2015 17:07:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id F081E14A21D for ; Mon, 2 Nov 2015 05:34:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 4bIGZNeiYeAu for ; Mon, 2 Nov 2015 05:34:31 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 6708314A21C for ; Mon, 2 Nov 2015 05:34:31 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for ietf-ssh@netbsd.org; Mon, 2 Nov 2015 05:34:25 +0000 Date: Mon, 2 Nov 2015 05:34:25 +0000 Subject: draft-rsa-dsa-sha2-256 posted X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0 Message-ID: <1565779757-2044@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: ietf-ssh@netbsd.org Cc: jhutz@cmu.edu, nisse@lysator.liu.se, stephen.farrell@cs.tcd.ie, mdb@juniper.net, jon@siliconcircus.com Content-Type: multipart/alternative; boundary="=-0kms0jy59QiaB8S2qw5e" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-0kms0jy59QiaB8S2qw5e Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I have posted the draft at IETF. Info here: ----- Original Message ----- A new version of I-D, draft-rsa-dsa-sha2-256-00.txt has been successfully submitted by Denis Bider and posted to the IETF repository. Name: draft-rsa-dsa-sha2-256 Revision: 00 Title: Use of RSA and DSA Keys with SHA-2 256 in Secure Shell (SSH) Document date: 2015-11-01 Group: Individual Submission Pages: 6 URL:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http= s://www.ietf.org/internet-drafts/draft-rsa-dsa-sha2-256-00.txt Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://datatracker= .ietf.org/doc/draft-rsa-dsa-sha2-256/ Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://tools.ietf.org/html/d= raft-rsa-dsa-sha2-256-00 Abstract: =C2=A0 This memo defines algorithm names, public key formats, and signature =C2=A0 formats for use of RSA and DSA keys with SHA-2 256 for server and =C2=A0 client authentication in SSH connections. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat = --=-0kms0jy59QiaB8S2qw5e Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable I have posted the draft at IETF. Info here:

----- Original Message -----

A new version of I-D, draft-rsa-ds= a-sha2-256-00.txt
has been successfully submitted by Denis Bider and pos= ted to the
IETF repository.

Name: draft-rsa-dsa-sha2-256
Revis= ion: 00
Title: Use of RSA and DSA Keys with SHA-2 256 in Secure Shell (S= SH)
Document date: 2015-11-01
Group: Individual Submission
Pages: = 6
URL:           = https://www.ietf.org/internet-drafts/draft-rsa-dsa-sha2-256-00.txt
Stat= us:         https://datatracker.iet= f.org/doc/draft-rsa-dsa-sha2-256/
Htmlized:     = ;  https://tools.ietf.org/html/draft-rsa-dsa-sha2-256-00

Abstra= ct:
  This memo defines algorithm names, public key formats, and si= gnature
  formats for use of RSA and DSA keys with SHA-2 256 for se= rver and
  client authentication in SSH connections.

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

T= he IETF Secretariat

= --=-0kms0jy59QiaB8S2qw5e-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 2 16:27:37 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B05C81A92FE for ; Mon, 2 Nov 2015 16:27:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=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 zJkuigfiCpIs for ; Mon, 2 Nov 2015 16:27:36 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57E651A92FC for ; Mon, 2 Nov 2015 16:27:36 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 3A97A14A2E4; Tue, 3 Nov 2015 00:27:35 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id E5D9114A2E2 for ; Tue, 3 Nov 2015 00:27:28 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id FL1iQo66NfcW for ; Tue, 3 Nov 2015 00:27:28 +0000 (UTC) Received: from newmailhub.uq.edu.au (mailhub2.soe.uq.edu.au [130.102.132.209]) by mail.netbsd.org (Postfix) with ESMTP id 7D14C14A2E0 for ; Tue, 3 Nov 2015 00:27:27 +0000 (UTC) Received: from smtp1.soe.uq.edu.au (smtp1.soe.uq.edu.au [10.138.113.40]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id tA2NLjO5033675; Tue, 3 Nov 2015 09:21:45 +1000 Received: from mailhub.eait.uq.edu.au (hazel.eait.uq.edu.au [130.102.60.17]) by smtp1.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id tA2NLjO5026329 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 3 Nov 2015 09:21:45 +1000 Received: from natsu.mindrot.org (natsu.mindrot.org [130.102.96.2]) by mailhub.eait.uq.edu.au (8.15.1/8.15.1) with ESMTP id tA2NLfQ1017307; Tue, 3 Nov 2015 09:21:41 +1000 (AEST) Received: by natsu.mindrot.org (Postfix, from userid 1000) id 1173AA4F36; Tue, 3 Nov 2015 10:21:41 +1100 (AEDT) Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id 10AD6A4F35; Tue, 3 Nov 2015 10:21:41 +1100 (AEDT) Date: Tue, 3 Nov 2015 10:21:41 +1100 (AEDT) From: Damien Miller To: "Mark D. Baushke" cc: Jeffrey Hutzelman , denis bider , ietf-ssh@NetBSD.org, nisse@lysator.liu.se, stephen.farrell@cs.tcd.ie, jon@siliconcircus.com Subject: Re: SSH key algorithm updates In-Reply-To: <26715.1446310356@eng-mail01.juniper.net> Message-ID: References: <1297540000-2044@skroderider.denisbider.com> <51845.1446188002@eng-mail01.juniper.net> <1446228753.32676.1.camel@destiny.pc.cs.cmu.edu> <26715.1446310356@eng-mail01.juniper.net> User-Agent: Alpine 2.20 (BSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub X-Scanned-By: MIMEDefang 2.75 on 130.102.60.17 X-UQ-FilterTime: 1446506506 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Sat, 31 Oct 2015, Mark D. Baushke wrote: > > That's an unfinished, -00 version internet draft from CFRG. It's > > probably too soon to use it as the basis for an SSH public key algorithm > > at all, let alone make such an algorithm mandatory to implement. Once > > the document is ready, we can start with OPTIONAL, and consider > > upgrading when the algorithm has proven itself and is reasonably widely > > implemented in SSH. > > Hmmm.... OpenSSH has implemented an ssh-ed25519 and B. Harris has > written: > > https://tools.ietf.org/html/draft-bjh21-ssh-ed25519-02 > > I am not sure how closely the IRTF Ed25519 an ssh-ed25519 > implementations match, but I suspect it may be relevant to discuss > both drafts and the SSH protocol sooner rather than later. AFAIK ssh-ed25519 is compatible with CFRG consensus on new signature schemes, but it's not yet become an I-D. > OpenSSH has implemented chacha20-poly1305@openssh.com Since we did that there has been an RFC on using this combination https://tools.ietf.org/html/rfc7539 which is incompatible with ours. The OpenSSH one, among other less-notable differences, maintains a second chacha20 instance to encrypt packet lengths. AFAIK a couple of other implementation support the openssh version. > The way that RFC5647 was written seems to not have been widely adopted > although OpenSSH did implement aes128-gcm@openssh.com and > aes256-gcm@openssh.com which are very similar. It might be nice to > actually come up with a 'standards' track document dealing with AEAD > ciphers and SSH and see if there is a better way to negotiate it within > the existing framework of SSH's separation of MAC and Cipher. For > example, maybe MAC=AEAD and Cipher=aes-gcm,chacha20-poly1305 would make > more sense in the negotiation? The situation wrt aes-gcm is frustrating. A draft was posted by a NSA employee here a few years ago, and there was quite a bit of feedback that the negotiation method that it proposed effectively broke negotiation of non-AEAD ciphers. The NSA/IETF standardised it anyway. The only difference between the NSA/IETF RFC and the openssh implementation is that we fixed the negotiation in kex. > It would be useful to see what other protocols various SSH implementers > have been adding and see if there is a desire to move any of them into a > recommended or optional standard. > > There is also the possibility of a encrypt-then-mac kinds of MAC choices > to try to avoid attacks against block ciphers which are either > mac-then-encrypt or AEAD. OpenSSH has had encrypt-then-MAC modes as the default for some time. One other thing worth mentioning is the curve25519-sha256@libssh.org key exchange method. It's supported by a few implementations and is AFAIK compatible with the CFRG curves draft. We'll probably do curve448 KEX and public key schemes in the near future, with the NSA's recent de-recommendation of 256 bit EC. With regard to recommended options, my take is something like: kex: curve25519-sha256, with ecdh-sha2-nistp* as a second choice pubkey: ed25519, with ecdsa-sha2-nistp* as a second choice cipher: chacha20-poly1305, with aes*-gcm@openssh.com as second choice (second choices for people who suffer under the yoke of FIPS compliance) -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 2 21:06:51 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B87A1B2E2D for ; Mon, 2 Nov 2015 21:06:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ef4IRx9WNs-d for ; Mon, 2 Nov 2015 21:06:49 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 641D21B2E04 for ; Mon, 2 Nov 2015 21:06:49 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 8C9D514A301; Tue, 3 Nov 2015 05:06:48 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 26CDF14A2F9; Tue, 3 Nov 2015 05:06:48 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 07F2E14A2FC for ; Tue, 3 Nov 2015 00:08:01 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id crx4vof0B3K5 for ; Tue, 3 Nov 2015 00:08:00 +0000 (UTC) Received: from newmailhub.uq.edu.au (mailhub1.soe.uq.edu.au [130.102.132.208]) by mail.netbsd.org (Postfix) with ESMTP id F162614A2E7 for ; Tue, 3 Nov 2015 00:07:57 +0000 (UTC) Received: from smtp2.soe.uq.edu.au (smtp2.soe.uq.edu.au [10.138.113.41]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id tA2N59C0019454; Tue, 3 Nov 2015 09:05:10 +1000 Received: from mailhub.eait.uq.edu.au (holly.eait.uq.edu.au [130.102.79.58]) by smtp2.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id tA2N59nZ004950 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 3 Nov 2015 09:05:09 +1000 Received: from natsu.mindrot.org (natsu.mindrot.org [130.102.96.2]) by mailhub.eait.uq.edu.au (8.15.1/8.15.1) with ESMTP id tA2N4v22017740; Tue, 3 Nov 2015 09:04:58 +1000 (AEST) Received: by natsu.mindrot.org (Postfix, from userid 1000) id 341E4A4F2F; Tue, 3 Nov 2015 10:05:06 +1100 (AEDT) Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id 2F4EFA4F2E; Tue, 3 Nov 2015 10:05:06 +1100 (AEDT) Date: Tue, 3 Nov 2015 10:05:06 +1100 (AEDT) From: Damien Miller To: denis bider cc: ietf-ssh@netbsd.org, jhutz@cmu.edu, nisse@lysator.liu.se, stephen.farrell@cs.tcd.ie, mdb@juniper.net, jon@siliconcircus.com Subject: Re: draft-rsa-dsa-sha2-256 posted In-Reply-To: <1565779757-2044@skroderider.denisbider.com> Message-ID: References: <1565779757-2044@skroderider.denisbider.com> User-Agent: Alpine 2.20 (BSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="27350351740928-879605546-1446505506=:9984" X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub X-Scanned-By: MIMEDefang 2.75 on 130.102.79.58 X-UQ-FilterTime: 1446505513 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --27350351740928-879605546-1446505506=:9984 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Hi, Thanks for starting this discussion. I'm against further use of DSA. Its weaknesses are well documented and IMO we should deprecate it rather than attempting to renovate it. The bit in your draft about deterministic k is nice, but it's not a MUST and many developers will just do the expedient thing and use whatever their crypto library provides. You might want to specify rsa-sha512 too. -d On Mon, 2 Nov 2015, denis bider wrote: > I have posted the draft at IETF. Info here: > > > ----- Original Message ----- > > A new version of I-D, draft-rsa-dsa-sha2-256-00.txt > has been successfully submitted by Denis Bider and posted to the > IETF repository. > > Name: draft-rsa-dsa-sha2-256 > Revision: 00 > Title: Use of RSA and DSA Keys with SHA-2 256 in Secure Shell (SSH) > Document date: 2015-11-01 > Group: Individual Submission > Pages: 6 > URL:            > https://www.ietf.org/internet-drafts/draft-rsa-dsa-sha2-256-00.txt > Status:         https://datatracker.ietf.org/doc/draft-rsa-dsa-sha2-256/ > Htmlized:       https://tools.ietf.org/html/draft-rsa-dsa-sha2-256-00 > > Abstract: >   This memo defines algorithm names, public key formats, and signature >   formats for use of RSA and DSA keys with SHA-2 256 for server and >   client authentication in SSH connections. > > 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 > > > --27350351740928-879605546-1446505506=:9984-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Nov 5 09:46:00 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C3F1B2A28 for ; Thu, 5 Nov 2015 09:46:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Es_J4Q29naSS for ; Thu, 5 Nov 2015 09:45:59 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 161671B31BB for ; Thu, 5 Nov 2015 09:45:58 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 141D514A31C; Thu, 5 Nov 2015 17:45:55 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id B255014A319; Thu, 5 Nov 2015 17:45:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 0C92F14A2DC for ; Thu, 5 Nov 2015 03:25:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id mjVG24Bee6L9 for ; Thu, 5 Nov 2015 03:25:38 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 7017314A2DB for ; Thu, 5 Nov 2015 03:25:38 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for ietf-ssh@netbsd.org; Thu, 5 Nov 2015 03:25:36 +0000 Date: Thu, 5 Nov 2015 03:25:36 +0000 Subject: OpenSSH sabotages protocol extension X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <1817171671-604@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-utS+QFInThHapca93hYY" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-utS+QFInThHapca93hYY Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Well, I'm slightly pissed. Why does OpenSSL do stupid shit like this? =C2=A0=C2=A0=C2=A0 type =3D packet_read(); =C2=A0=C2=A0=C2=A0 if (type !=3D SSH2_MSG_SERVICE_ACCEPT) =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 fatal("Server denied authentication r= equest: %d", type); =C2=A0=C2=A0=C2=A0 if (packet_remaining() > 0) { =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 char *reply =3D packet_get_string(NUL= L); =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 debug2("service_accept: %s", reply); =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 free(reply); =C2=A0=C2=A0=C2=A0 } else { =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 debug2("buggy server: service_accept = w/o service"); =C2=A0=C2=A0=C2=A0 } =C2=A0=C2=A0=C2=A0 packet_check_eom(); =C2=A0=C2=A0=C2=A0 debug("SSH2_MSG_SERVICE_ACCEPT received"); Note the genius inclusion of packet_check_eom() after decoding SERVICE_ACCE= PT. Guess what this line does? =C2=A0=C2=A0=C2=A0 #define ssh_packet_check_eom(ssh) \ =C2=A0=C2=A0=C2=A0 do { \ =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 int _len =3D ssh_packet_remaining(ssh= ); \ =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 if (_len > 0) { \ =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 logit("Packet inte= grity error (%d bytes remaining) at %s:%d", \ =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0= _len ,__FILE__, __LINE__); \ =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 ssh_packet_disconn= ect(ssh, \ =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0= "Packet integrity error."); \ =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 } \ =C2=A0=C2=A0=C2=A0 } while (0) =C2=A0=C2=A0=C2=A0 #define packet_check_eom() \ =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ssh_packet_check_eom(active_stat= e) Yes. It disconnects if there's any extra data after the recognized field in= SERVICE_ACCEPT. What possible purpose does this serve? What possible purpose at all, other than to sabotage future extension? Thanks to this, we cannot add a field to SERVICE_ACCEPT so that the server = could advertise what signature algorithms it accepts for user authenticatio= n. Thank you, OpenSSH. /s Again. = --=-utS+QFInThHapca93hYY Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Well, I'm slightly pissed.

Why does OpenSSL= do stupid shit like this?


    type =3D packet_re= ad();
    if (type !=3D SSH2_MSG_SERVICE_ACCEPT)
 = ;       fatal("Server denied authentication reques= t: %d", type);
    if (packet_remaining() > 0) {
&n= bsp;       char *reply =3D packet_get_string(NULL)= ;
        debug2("service_accept: %s", rep= ly);
        free(reply);
  &= nbsp; } else {
        debug2("buggy serve= r: service_accept w/o service");
    }
  &nb= sp; packet_check_eom();
    debug("SSH2_MSG_SERVIC= E_ACCEPT received");


Note the genius inclusion of packet_check_e= om() after decoding SERVICE_ACCEPT. Guess what this line does?


&= nbsp;   #define ssh_packet_check_eom(ssh) \
   = do { \
        int _len =3D ssh_packet_re= maining(ssh); \
        if (_len > 0) {= \
            logit("Packe= t integrity error (%d bytes remaining) at %s:%d", \
    &= nbsp;           _len ,__FILE__, __L= INE__); \
            ssh_p= acket_disconnect(ssh, \
         &nbs= p;      "Packet integrity error."); \
  &n= bsp;     } \
    } while (0)

 =    #define packet_check_eom() \
     =    ssh_packet_check_eom(active_state)


Yes. It disconne= cts if there's any extra data after the recognized field in SERVICE_ACCEPT.=

What possible purpose does this serve?

What possible purpose= at all, other than to sabotage future extension?

Thanks to this, we= cannot add a field to SERVICE_ACCEPT so that the server could advertise wh= at signature algorithms it accepts for user authentication.

Thank yo= u, OpenSSH. /s

Again.


= --=-utS+QFInThHapca93hYY-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Nov 5 09:47:05 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 339EC1B31D4 for ; Thu, 5 Nov 2015 09:47:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 QwAnX0pf_A8t for ; Thu, 5 Nov 2015 09:47:03 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44C8C1B31D1 for ; Thu, 5 Nov 2015 09:47:03 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id D2B6614A337; Thu, 5 Nov 2015 17:47:02 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 7B9DC14A31E; Thu, 5 Nov 2015 17:47:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id DCC7D14A323 for ; Thu, 5 Nov 2015 09:13:28 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id Z_yig4BEz3N3 for ; Thu, 5 Nov 2015 09:13:28 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 0F1E714A322 for ; Thu, 5 Nov 2015 09:13:27 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for ietf-ssh@netbsd.org; Thu, 5 Nov 2015 09:13:25 +0000 Date: Thu, 5 Nov 2015 09:13:25 +0000 Subject: New version of rsa-sha2-512 draft posted: no more DSA X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <1837603091-896@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-ycSwRMBYULa9Ob1uvd47" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-ycSwRMBYULa9Ob1uvd47 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I have posted a new version of the draft: see details below. As per multiple requests (Hanno Boeck, Peter Gutmann, Damien Miller), I hav= e removed DSA. I have taken into account Damien's suggestion for rsa-sha2-512, and observe= d that there appears to be no reason to have rsa-sha2-256, if we have rsa-s= ha2-512. As far as I can tell, SHA-2 512 should be reasonably available eve= rywhere that SHA-2 256 is available. It is slower on 32-bit platforms, but = the performance impact of hashing is negligible compared to the signing ope= ration. It produces a larger digest than SHA-2 256, but this digest easily = fits into all reasonable RSA key sizes. Therefore, this new version of the draft removes both rsa-sha2-256 and dsa-= sha2-256, and replaces them with only rsa-sha2-512. In addition, this version adds a mechanism which the server can use to noti= fy the client of signature algorithms supported, so that the client does no= t have to guess with authentication requests. Clients will still need to im= plement guessing due to servers that might not support this, but if the ser= ver cares to send this info, this can speed up authentication by one or mor= e round trips. Unfortunately, since: - SSH does not have a proper extension negotiation; and since - clients of at least one ubiquitous implementation will disconnect if any = new fields are added to SSH_MSG_SERVICE_REQUEST, SSH_MSG_SERVICE_ACCEPT, or= SSH_MSG_USERAUTH_FAILURE; there seems to be little choice but to send this information in a specially= crafted SSH_MSG_IGNORE message. Let us congratulate ourselves on that succ= ess. ;) Let's think things through better with the next protocol. ----- Original Message ----- A new version of I-D, draft-rsa-dsa-sha2-256-01.txt has been successfully submitted by Denis Bider and posted to the IETF repository. Name: draft-rsa-dsa-sha2-256 Revision: 01 Title: Use of RSA Keys with SHA-2 512 in Secure Shell (SSH) Document date: 2015-11-05 Group: Individual Submission Pages: 6 URL:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http= s://www.ietf.org/internet-drafts/draft-rsa-dsa-sha2-256-01.txt Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://datatracker= .ietf.org/doc/draft-rsa-dsa-sha2-256/ Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://tools.ietf.org/html/d= raft-rsa-dsa-sha2-256-01 Diff:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://w= ww.ietf.org/rfcdiff?url2=3Ddraft-rsa-dsa-sha2-256-01 Abstract: =C2=A0 This memo defines an algorithm name, public key format, and signatur= e =C2=A0 format for use of RSA keys with SHA-2 512 for server and client =C2=A0 authentication in SSH connections. A new mechanism is also defined =C2=A0 for servers to inform clients of supported signature algorithms duri= ng =C2=A0 client authentication. = --=-ycSwRMBYULa9Ob1uvd47 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable I have posted a new version of the draft: see deta= ils below.

As per multiple requests (Hanno Boeck, Peter Gutmann, Dam= ien Miller), I have removed DSA.

I have taken into account Damien's = suggestion for rsa-sha2-512, and observed that there appears to be no reaso= n to have rsa-sha2-256, if we have rsa-sha2-512. As far as I can tell, SHA-= 2 512 should be reasonably available everywhere that SHA-2 256 is available= . It is slower on 32-bit platforms, but the performance impact of hashing i= s negligible compared to the signing operation. It produces a larger digest= than SHA-2 256, but this digest easily fits into all reasonable RSA key si= zes.

Therefore, this new version of the draft removes both rsa-sha2-= 256 and dsa-sha2-256, and replaces them with only rsa-sha2-512.

In a= ddition, this version adds a mechanism which the server can use to notify t= he client of signature algorithms supported, so that the client does not ha= ve to guess with authentication requests. Clients will still need to implem= ent guessing due to servers that might not support this, but if the server = cares to send this info, this can speed up authentication by one or more ro= und trips.

Unfortunately, since:

- SSH does not have a proper= extension negotiation; and since

- clients of at least one ubiquito= us implementation will disconnect if any new fields are added to SSH_MSG_SE= RVICE_REQUEST, SSH_MSG_SERVICE_ACCEPT, or SSH_MSG_USERAUTH_FAILURE;

= there seems to be little choice but to send this information in a specially= crafted SSH_MSG_IGNORE message. Let us congratulate ourselves on that succ= ess. ;)

Let's think things through better with the next protocol.

----- Original Message -----

A new version of I-D, draft-rs= a-dsa-sha2-256-01.txt
has been successfully submitted by Denis Bider and= posted to the
IETF repository.

Name: draft-rsa-dsa-sha2-256
R= evision: 01
Title: Use of RSA Keys with SHA-2 512 in Secure Shell (SSH)<= br>Document date: 2015-11-05
Group: Individual Submission
Pages: 6URL:            htt= ps://www.ietf.org/internet-drafts/draft-rsa-dsa-sha2-256-01.txt
Status:&= nbsp;        https://datatracker.ietf.or= g/doc/draft-rsa-dsa-sha2-256/
Htmlized:     &nb= sp; https://tools.ietf.org/html/draft-rsa-dsa-sha2-256-01
Diff: &nb= sp;         https://www.ietf.org/rf= cdiff?url2=3Ddraft-rsa-dsa-sha2-256-01

Abstract:
  This memo= defines an algorithm name, public key format, and signature
  form= at for use of RSA keys with SHA-2 512 for server and client
  authe= ntication in SSH connections. A new mechanism is also defined
  for= servers to inform clients of supported signature algorithms during
&nbs= p; client authentication.

= --=-ycSwRMBYULa9Ob1uvd47-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Nov 5 09:47:37 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F171B31D7 for ; Thu, 5 Nov 2015 09:47:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 7YDeRN9dgYjZ for ; Thu, 5 Nov 2015 09:47:36 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B1E41B31D5 for ; Thu, 5 Nov 2015 09:47:36 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id B60E914A340; Thu, 5 Nov 2015 17:47:35 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 5E4F314A338; Thu, 5 Nov 2015 17:47:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id ABA3314A25F for ; Thu, 5 Nov 2015 03:36:12 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id gNUHrNPzLdVV for ; Thu, 5 Nov 2015 03:36:12 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 0555B14A25D for ; Thu, 5 Nov 2015 03:36:11 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for ietf-ssh@netbsd.org; Thu, 5 Nov 2015 03:36:11 +0000 Date: Thu, 5 Nov 2015 03:36:11 +0000 Subject: Re: OpenSSH sabotages protocol extension X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <1817847842-896@skroderider.denisbider.com> X-Priority: 3 Importance: Normal In-Reply-To: <1817171671-604@skroderider.denisbider.com> MIME-Version: 1.0 From: denis bider To: ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-UQ9wgG0zJKxg8yXbxGkh" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-UQ9wgG0zJKxg8yXbxGkh Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Obviously, same thing for SSH2_MSG_USERAUTH_FAILURE: =C2=A0=C2=A0=C2=A0 authlist =3D packet_get_string(NULL); =C2=A0=C2=A0=C2=A0 partial =3D packet_get_char(); =C2=A0=C2=A0=C2=A0 packet_check_eom(); Awesome work, guys! You have locked down every possible clean way that the = protocol could be extended, so as to spare the client several round-trips t= o discover which signing algorithms it can use for RSA keys. You've made it so that the only way to convey such information, and not ris= k a client disconnect, is to use a specially crafted SSH_MSG_IGNORE. Tremendous, just tremendous. denis bider , 11/5/2015 3:21 AM: Well, I'm slightly pissed. Why does OpenSSL do stupid shit like this? =C2=A0=C2=A0=C2=A0 type =3D packet_read(); =C2=A0=C2=A0=C2=A0 if (type !=3D SSH2_MSG_SERVICE_ACCEPT) =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 fatal("Server denied authentication r= equest: %d", type); =C2=A0=C2=A0=C2=A0 if (packet_remaining() > 0) { =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 char *reply =3D packet_get_string(NUL= L); =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 debug2("service_accept: %s", reply); =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 free(reply); =C2=A0=C2=A0=C2=A0 } else { =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 debug2("buggy server: service_accept = w/o service"); =C2=A0=C2=A0=C2=A0 } =C2=A0=C2=A0=C2=A0 packet_check_eom(); =C2=A0=C2=A0=C2=A0 debug("SSH2_MSG_SERVICE_ACCEPT received"); Note the genius inclusion of packet_check_eom() after decoding SERVICE_ACCE= PT. Guess what this line does? =C2=A0=C2=A0=C2=A0 #define ssh_packet_check_eom(ssh) \ =C2=A0=C2=A0=C2=A0 do { \ =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 int _len =3D ssh_packet_remaining(ssh= ); \ =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 if (_len > 0) { \ =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 logit("Packet inte= grity error (%d bytes remaining) at %s:%d", \ =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0= _len ,__FILE__, __LINE__); \ =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 ssh_packet_disconn= ect(ssh, \ =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0= "Packet integrity error."); \ =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 } \ =C2=A0=C2=A0=C2=A0 } while (0) =C2=A0=C2=A0=C2=A0 #define packet_check_eom() \ =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ssh_packet_check_eom(active_stat= e) Yes. It disconnects if there's any extra data after the recognized field in= SERVICE_ACCEPT. What possible purpose does this serve? What possible purpose at all, other than to sabotage future extension? Thanks to this, we cannot add a field to SERVICE_ACCEPT so that the server = could advertise what signature algorithms it accepts for user authenticatio= n. Thank you, OpenSSH. /s Again. = --=-UQ9wgG0zJKxg8yXbxGkh Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Obviously, same thing for SSH2_MSG_USERAUTH_FAILUR= E:


    authlist =3D packet_get_string(NULL);
&= nbsp;   partial =3D packet_get_char();
    p= acket_check_eom();


Awesome work, guys! You have locked down = every possible clean way that the protocol could be extended, so as = to spare the client several round-trips to discover which signing algorithm= s it can use for RSA keys.

You've made it so that the only way to co= nvey such information, and not risk a client disconnect, is to use a specia= lly crafted SSH_MSG_IGNORE.

Tremendous, just tremendous.


=
denis bider <ietf-ssh3@denisbider.com&g= t; , 11/5/2015 3:21 AM:
We= ll, I'm slightly pissed.

Why does OpenSSL do stupid shit like this?<= br>

    type =3D packet_read();
   = if (type !=3D SSH2_MSG_SERVICE_ACCEPT)
      &= nbsp; fatal("Server denied authentication request: %d", type);
 &nb= sp;  if (packet_remaining() > 0) {
     &nbs= p;  char *reply =3D packet_get_string(NULL);
    &nb= sp;   debug2("service_accept: %s", reply);
    =     free(reply);
    } else {
 &nb= sp;      debug2("buggy server: service_accept w/o servi= ce");
    }
    packet_check_eom();<= /b>
    debug("SSH2_MSG_SERVICE_ACCEPT received");

Note the genius inclusion of packet_check_eom() after decoding SERVICE= _ACCEPT. Guess what this line does?


    #define s= sh_packet_check_eom(ssh) \
    do { \
  &nbs= p;     int _len =3D ssh_packet_remaining(ssh); \
 &n= bsp;      if (_len > 0) { \
    &n= bsp;       logit("Packet integrity error (%d bytes= remaining) at %s:%d", \
         &nb= sp;      _len ,__FILE__, __LINE__); \
  &n= bsp;         ssh_packet_disconnect(ssh, \
=                = "Packet integrity error."); \
        } \=
    } while (0)

    #define packet= _check_eom() \
        ssh_packet_che= ck_eom(active_state)


Yes. It disconnects if there's any extra da= ta after the recognized field in SERVICE_ACCEPT.

What possible purpo= se does this serve?

What possible purpose at all, other than to sabo= tage future extension?

Thanks to this, we cannot add a field to SERV= ICE_ACCEPT so that the server could advertise what signature algorithms it = accepts for user authentication.

Thank you, OpenSSH. /s

Again.


= --=-UQ9wgG0zJKxg8yXbxGkh-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Nov 5 21:16:33 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C35311B35F7 for ; Thu, 5 Nov 2015 21:16:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 44h9jX4uDm5P for ; Thu, 5 Nov 2015 21:16:32 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16FC81B35F5 for ; Thu, 5 Nov 2015 21:16:32 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id E551214A1DE; Fri, 6 Nov 2015 05:16:30 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id D8EDC14A1DC for ; Fri, 6 Nov 2015 05:16:21 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id ynWg3T4viDTa for ; Fri, 6 Nov 2015 05:16:20 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 9A33114A1D5 for ; Fri, 6 Nov 2015 05:16:20 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 50AC740057; Fri, 6 Nov 2015 06:16:11 +0100 (CET) Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id 6F1D940005; Fri, 6 Nov 2015 06:16:09 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Fri, 06 Nov 2015 06:16:09 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: Jeffrey Hutzelman Cc: "Mark D. Baushke" , denis bider , ietf-ssh@NetBSD.org, stephen.farrell@cs.tcd.ie, jon@siliconcircus.com Subject: Re: SSH key algorithm updates References: <1297540000-2044@skroderider.denisbider.com> <51845.1446188002@eng-mail01.juniper.net> <1446228753.32676.1.camel@destiny.pc.cs.cmu.edu> Date: Fri, 06 Nov 2015 06:16:09 +0100 In-Reply-To: <1446228753.32676.1.camel@destiny.pc.cs.cmu.edu> (Jeffrey Hutzelman's message of "Fri, 30 Oct 2015 14:12:33 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Jeffrey Hutzelman writes: > To summarize the changes, I propose: I think this makes sense. I've been a bit out of the loop for this, wit lsh being a mostly dormant project, but I'd like to offer my comments. My apologies if I misremember some relevant details. > For public key algorithms: > - Downgrade ssh-dss, pgp-sign-dss, and x509v3-ssh-dss to NOT > RECOMMENDED. > - Upgrade ssh-rsa to REQUIRED ssh-rsa is sha1 only, right? It's still stronger than ssh-dss (since it allows larger keys), so if we want a widely deployed algorithm to replace ssh-dss as REQUIRED, it makes sense. But defining ssh-sha256-rsa as RECOMMENDED would make sense too. And when it comes to sha1 weaknesses, using sha1 with a signature algorithm seems more dangerous than using it for hmac or for key expansion. > - Upgrade ecdsa-sha2-* to RECOMMENDED > - Add dsa-sha2-256 as RECOMMENDED I have no strong opinion on whether these should be recommended or optional. I think there are quite strong reasons to prefer deterministic algorithms, but that's more a question of a recommendation for the implementation, since it's not really visible on the wire what method was used to produce the nonce. > For MAC algorithms: > - Upgrade hmac-sha2-256 to REQUIRED > - Consider upgrading hmac-sha2-512 to RECOMMENDED > - Downgrade hmac-md5 and hmac-md5-96 to NOT RECOMMENDED > - Downgrade hmac-sha1-96 to NOT RECOMMENDED > - Consider downgrading hmac-sha1 to RECOMMENDED > > HMAC-SHA1 is not (yet) considered insecure, it has been SSHv2's only > required algorithm since RFC 425x were published, and it is probably the > most widely deployed. So, we should not downgrade it below RECOMMENDED. > However, I think a case can be made for hmac-sha2-256 replacing it as > the REQUIRED algorithm, if we think that has gained enough traction. My understanding is that there are no known attacks on hmac-sha1, and that the attacks on non-keyed hashfunctions in the family don't apply. Is there any likely harm in keeping it as required for another decade? > For encryption algorithms: > - Upgrade aes128-ctr to REQUIRED > - Consider downgrading 3des-cbc to RECOMMENDED > - Downgrade all other *-cbc algorithms to NOT RECOMMENDED > - Do we want to say anything about IDEA, CAST, or RC4? The last 3 seem fairly irrelevant now. We could specify salsa20 or chacha, to replace rc4 for high-performance use-cases. > I chose aes128-ctr because RFC4253 listed aes128-cbc as > RECOMMENDED while leaving the other sizes OPTIONAL. I suspect this was > done because at the time, some folks did not want to ship AES256 due to > export restrictions and/or lack of utility. What about the key-setup problems in aes256? I seem to recall that it's not as much better than aes128 as was intended. > We may wish to consider leaving 3des-cbc at SHOULD, I think that makes sense, if the main problem with 3des is performance rather than security. > Finally, for key exchange algorithms: > - Upgrade diffie-hellman-group-exchange-sha256 to REQUIRED > - Upgrade ecdh-sha2-* to RECOMMENDED > - Consider downgrading diffie-hellman-group14-sha1 to RECOMMENDED > - Downgrade other diffie-hellman-*-sha1 to NOT RECOMMENDED > - Downgrade rsa1024-sha1 to NOT RECOMMENDED > Again, eliminating the SHA1-based DH algorithms in favor of GEX SHA256 > should be obvious, I don't think choosing group-exchange is obvious; using a fixed group is an obvious gain in terms of simplicity. Personally, I don't quite like the complexity and validation issues with group-exchange (but maybe I could be convinced it's no problem). So I hesitate to make it the reqiured algorithm. Why don't you like diffie-hellman-group14-sha1 as required? Is that group considered too small these days, or is sha1 considered too weak for this use? To me it would make sense to also define diffie-hellman-group14-sha256 and/= or diffie-hellman-curve25519, but they can't be candidates for required at this time. >> Or, is this better left to another RFC? Perhaps moving the Ed25519 >> algorithm created by >>=20 >> https://tools.ietf.org/html/draft-irtf-cfrg-eddsa-00=20 >>=20 >> into a MUST algorithm while deprecating "ssh-dss" for SSH? > > That's an unfinished, -00 version internet draft from CFRG.=20 Is that related to the (now expireed, I think) draft I and Simon wrote some time ago? I'm not following the cfrg work. I think it would also be highly desirable to standardize use of aead-algorithms. But as far as I remember, from last time this was discussed, it was tricky to extend the algorithm negotiation in a clean way. (And I'd like to do chacha-poly1305 sligthly different from the way openssh does it, but we can get to that in due time). So specifying AEAD is a different and harder problem than just updating the list of recommended algorithms. Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Nov 5 21:30:56 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD7101A0117 for ; Thu, 5 Nov 2015 21:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 nklqA4JkzWLh for ; Thu, 5 Nov 2015 21:30:56 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAD1A1A010E for ; Thu, 5 Nov 2015 21:30:55 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id C6CAF14A391; Fri, 6 Nov 2015 05:30:52 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 25A6A14A38C for ; Fri, 6 Nov 2015 05:30:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id PPqAW1rfbeCE for ; Fri, 6 Nov 2015 05:30:49 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 5130414A382 for ; Fri, 6 Nov 2015 05:30:48 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 0C58D40057; Fri, 6 Nov 2015 06:30:47 +0100 (CET) Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id C342740005; Fri, 6 Nov 2015 06:30:45 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Fri, 06 Nov 2015 06:30:45 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: denis bider Cc: ietf-ssh@netbsd.org Subject: Re: OpenSSH sabotages protocol extension References: <1817171671-604@skroderider.denisbider.com> Date: Fri, 06 Nov 2015 06:30:45 +0100 In-Reply-To: <1817171671-604@skroderider.denisbider.com> (denis bider's message of "Thu, 5 Nov 2015 03:25:36 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list denis bider writes: > Yes. It disconnects if there's any extra data after the recognized field = in SERVICE_ACCEPT. > > What possible purpose does this serve? > > What possible purpose at all, other than to sabotage future extension? FYI, my implementation does the same. To me, the spec is pretty clear that a SSH_MSG_SERVICE_ACCEPT can't include any extra data (unlike, e.g., SSH_MSG_REQUEST_SUCCESS, SSH_MSG_CHANNEL_OPEN, and SSH_MSG_CHANNEL_OPEN_CONFIRMATION). There's the liberal tradition in protocol implementation to allow random garbage at the end of messages. This has it's merit in some cases, but in security protocols I tend to require that the protcol is adhered to to the last bit. Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Nov 5 22:50:35 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D00121A9165 for ; Thu, 5 Nov 2015 22:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 vNxFyNHoVSdB for ; Thu, 5 Nov 2015 22:50:34 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E71E1A9175 for ; Thu, 5 Nov 2015 22:50:31 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 3A30614A39E; Fri, 6 Nov 2015 06:50:28 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 52AB714A39D for ; Fri, 6 Nov 2015 06:50:17 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 1YW0GjqlRbh5 for ; Fri, 6 Nov 2015 06:50:16 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 4A19814A399 for ; Fri, 6 Nov 2015 06:50:14 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 3A3074005A; Fri, 6 Nov 2015 07:50:12 +0100 (CET) Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id B197C40058; Fri, 6 Nov 2015 07:50:10 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Fri, 06 Nov 2015 07:50:10 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: Jeffrey Hutzelman Cc: "Mark D. Baushke" , denis bider , ietf-ssh@NetBSD.org, stephen.farrell@cs.tcd.ie, jon@siliconcircus.com Subject: Re: SSH key algorithm updates References: <1297540000-2044@skroderider.denisbider.com> <51845.1446188002@eng-mail01.juniper.net> <1446228753.32676.1.camel@destiny.pc.cs.cmu.edu> <1446789400.4752.33.camel@destiny.pc.cs.cmu.edu> Date: Fri, 06 Nov 2015 07:50:10 +0100 In-Reply-To: <1446789400.4752.33.camel@destiny.pc.cs.cmu.edu> (Jeffrey Hutzelman's message of "Fri, 06 Nov 2015 00:56:40 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Jeffrey Hutzelman writes: > On Fri, 2015-11-06 at 06:16 +0100, Niels M=C3=B6ller wrote: [about hmac-sha1] > Your understanding matches mine. However, it's still only a 160-bit > hash, and eventually that just stops being strong enough. I'd like to > have something stronger implemented and reasonably widely deployed > before then. Reasonable. We need to specify a new REQUIRED algorithm. Demoting HMAC-SHA1 to recommended lets implementations drop support in due time without formally departing from the standard. It would kind-of make sense to specify a flag day "algothithm X is REQUIRED until date Y, after which is is only RECOMMENDED", but not worth the effort to formalize. > SSH's 3des-cbc is three-key EDE 3DES. It has an effective key length of > 112 bits, and so is weaker than AES128. But the "effective key bits" attack is a time/memory-tradeoff which requires a huge table, right? So in practice I'm not sure a brute force attack on 3DES really can be expected to be 16 times faster than a brute force attack on aes128. > It's also a CBC mode and AFAIK has the same problems as all of SSH's > other CBC-mode ciphers. Right, reprecating CBC makes sense. What's the status of 3des-ctr mode? Not at all as widely deployed as 3des-cbc, I imagine. > Group exchange doesn't have to mean live, dynamic group generation. It > can work fine with a set of fixed groups, either manually configured or > compiled in.=20=20 Hmm. I was thinking of the receiver of the group list, it has to be prepared to handle any group, and make an intelligent choice. My gut feeling is that there may be some subtleties there. But maybe there's no issue to trust the server and just choose the largest group you think you can afford to compute with. > I'd have to go back and look, but I think the sense of the > group at the time was that there was no reason to define more variations > with the group baked into the algorithm names. I can see that argument. Perhaps we shouldn't get into that now, but I could see scenarious where client might have a preference like 1. Large Z_p group (preferred option) 2. curve25519 (acceptable) 3. Small Z_p group (not acceptable) Then negotiation fails in the case that they agree on group exchange, but the server offers only small Z_p groups. While with named groups, they might have agreed to use curve25519. Feel free to ignore this discussion if you find in untimely or distracting. There's a spec for it and noone on the list have raised any serious security concerns. >> Is that related to the (now expireed, I think) draft I and Simon wrote >> some time ago? I'm not following the cfrg work. > > I'm not sure. It's only a month old, and does have Simon's name on it. Hmm. It looks like like it's based on our earlier version. I think the pyth= on reference implementation of ed25519 is the same. Nice. Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Nov 6 00:58:11 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4321AD0CB for ; Fri, 6 Nov 2015 00:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 iNygq-h0DpMD for ; Fri, 6 Nov 2015 00:58:05 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC6791ACE8C for ; Fri, 6 Nov 2015 00:58:05 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 998A814A3AE; Fri, 6 Nov 2015 08:58:02 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id F3D7C14A3AD for ; Fri, 6 Nov 2015 08:57:58 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id OFO9HLO6g6TU for ; Fri, 6 Nov 2015 08:57:58 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id AB05614A3AA for ; Fri, 6 Nov 2015 08:57:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1446800277; x=1478336277; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=pQO/dWvmyAwTRtv3238hCAXgGtAGFs2YvRTHIxQZKN0=; b=hcGOoZE6VweaoHHM6sXoRZlnJX72rrOBEnuS8SdtLSoiBAY1wCxtQXN7 4o4H4p0p/68912CjheW0tvvGi/Kw6lDHwpcicUntrWO8YeAmI3L9Yy9a1 WArkkgB5deZodYDamEixEThPkpdKmnfjtiH/GrjxYIM4X7MYAVR/WsiEN MF75MeMlpZk+5mfpl9WAhuP9/4Nle1qCKnmcabZcFF0SCFlFj60YNiKaW EaTfnAlN+DfzsANVZYN8tVGSAvUU8GJiykulx+ay4lgmGHbjkiD4WnV1/ iVe7z3DSpA0egJtb8tEFAPy5FigKEzTMBQ3qxT4SNekEeGMAXOeKs7GGF g==; X-IronPort-AV: E=Sophos;i="5.20,251,1444647600"; d="scan'208";a="52902201" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe1.UoA.auckland.ac.nz) ([130.216.4.112]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 06 Nov 2015 21:57:52 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Fri, 6 Nov 2015 21:57:52 +1300 From: Peter Gutmann To: denis bider , "ietf-ssh@netbsd.org" Subject: RE: New version of rsa-sha2-512 draft posted: no more DSA Thread-Topic: New version of rsa-sha2-512 draft posted: no more DSA Thread-Index: AQHRF/ILEdK76i2qrUycWMyswUrF1J6Osjsb Date: Fri, 6 Nov 2015 08:57:50 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B56EBA@uxcn10-5.UoA.auckland.ac.nz> References: <1837603091-896@skroderider.denisbider.com> In-Reply-To: <1837603091-896@skroderider.denisbider.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list denis bider writes:=0A= =0A= >I have taken into account Damien's suggestion for rsa-sha2-512, and observ= ed=0A= >that there appears to be no reason to have rsa-sha2-256, if we have rsa-= =0A= >sha2-512. As far as I can tell, SHA-2 512 should be reasonably available= =0A= >everywhere that SHA-2 256 is available.=0A= =0A= Uhh, that's more or less the opposite of the actual situation: SHA2-256 is= =0A= fast becoming the universal replacement for SHA-1, while SHA2-512 is the "o= h,=0A= there's another one alongside -256?" alternative. For example Mozilla just= =0A= posted the following discussion item:=0A= =0A= In item #8 of the Maintenance Policy recommend that CAs avoid SHA-512 and= =0A= P-521, especially in their CA certificates. This is to ensure=0A= interoperability, as SHA-512 and (especially) P-521 are less well-support= ed=0A= than the other algorithms.=0A= =0A= So it should be MUST -256, MAY -512, at most.=0A= =0A= (I can't see any good reason to have -512, it has little support, it's a pa= in=0A= to do on 32-bit CPUs, it's slow, and it offers little to no practical secur= ity=0A= advantage over -256).=0A= =0A= Peter.=0A= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Nov 6 01:02:18 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B67091ADEB6 for ; Fri, 6 Nov 2015 01:02:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 05uOQmi7_U6p for ; Fri, 6 Nov 2015 01:02:17 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD69D1AD34E for ; Fri, 6 Nov 2015 01:02:17 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 579F314A3AF; Fri, 6 Nov 2015 09:02:16 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 9EBB514A3AD for ; Fri, 6 Nov 2015 09:02:13 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id kQeFR1W4iZbr for ; Fri, 6 Nov 2015 09:02:13 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 8A33714A2F3 for ; Fri, 6 Nov 2015 09:02:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1446800532; x=1478336532; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=/X8OezbSu7Rn/qDRVF2r4WKa4HCVJyy7f0JenmaqXds=; b=J3epcMEbu6JJ9u4RS6sNjgTnup7wcAfM2J6Cmy/hrab5aXkmpmA9F/Mz hkdybHw7KE/WolNuRM/8/p3TcPgoeVJEtMlW1H7e6DcAvUtMkF5RDYF57 fE/fVa+1bqmBwPDY8luS97B7TqEufBaHqAhnN9PwkYW2CKkYxqeC+mU0Z R5RoN+Br8gycH+O3i1fPai5vkwExRQ0ER8DXcI+oc1mKndQoHEsTJEh1B jjPcyt4HJHr5v4u+QbpseyyoUUSGiUIMxHXPbfZtREPJ1WPXODAp73Nbd SWTHrCObL85sfgwUXwUDGP/H/g69ddw0udiYVvHGXzh20QgSCS8WvLRnk Q==; X-IronPort-AV: E=Sophos;i="5.20,251,1444647600"; d="scan'208";a="52903300" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 06 Nov 2015 22:02:10 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Fri, 6 Nov 2015 22:02:10 +1300 From: Peter Gutmann To: denis bider , "ietf-ssh@netbsd.org" Subject: RE: OpenSSH sabotages protocol extension Thread-Topic: OpenSSH sabotages protocol extension Thread-Index: AQHRF/HZY5vpC99gA0OXaLug+at5Op6Os41z Date: Fri, 6 Nov 2015 09:02:09 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B56EDD@uxcn10-5.UoA.auckland.ac.nz> References: <1817171671-604@skroderider.denisbider.com> In-Reply-To: <1817171671-604@skroderider.denisbider.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list denis bider writes:=0A= =0A= >What possible purpose does this serve?=0A= =0A= It's perfectly sensible, if the spec requires that a packet be x, y, z then= =0A= getting a packet containing x, y, z, extra garbage is at best a sign of dat= a=0A= corruption, at worst a sign of an active attack. Rejecting the packet and= =0A= closing the connection is good practice, it makes it harder for an attacker= to=0A= use you as an oracle.=0A= =0A= For an example of what happens if you do ignore extra garbage at the end of= =0A= your data, look at the padding attacks on PKCS #1...=0A= =0A= Peter.= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Nov 6 01:08:10 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68DA61B2FAA for ; Fri, 6 Nov 2015 01:08:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 2e7_ptsOB6jC for ; Fri, 6 Nov 2015 01:08:08 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B51CA1B2F11 for ; Fri, 6 Nov 2015 01:08:08 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 14D5014A3B3; Fri, 6 Nov 2015 09:08:07 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 1026914A3B2 for ; Fri, 6 Nov 2015 09:08:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id JJ5TnzClOgYw for ; Fri, 6 Nov 2015 09:08:03 +0000 (UTC) Received: from wp256.webpack.hosteurope.de (wp256.webpack.hosteurope.de [80.237.133.25]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 4CDB114A3B1 for ; Fri, 6 Nov 2015 09:08:01 +0000 (UTC) Received: from fb07-alg-gast1.math.uni-giessen.de ([134.176.24.161]); authenticated by wp256.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) id 1Zud03-0005O5-8O; Fri, 06 Nov 2015 10:07:59 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: SSH key algorithm updates From: Max Horn In-Reply-To: Date: Fri, 6 Nov 2015 10:08:06 +0100 Cc: "Mark D. Baushke" Content-Transfer-Encoding: 7bit Message-Id: References: <1297540000-2044@skroderider.denisbider.com> <51845.1446188002@eng-mail01.juniper.net> <1446228753.32676.1.camel@destiny.pc.cs.cmu.edu> <1446789400.4752.33.camel@destiny.pc.cs.cmu.edu> To: ietf-ssh@NetBSD.org X-Mailer: Apple Mail (2.3096.5) X-bounce-key: webpack.hosteurope.de;postbox@quendi.de;1446800883;39fa3c7f; Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hi there, just joined the list, but saw on the list archive that a few days ago, Mark D. Baushke wrote on this thread: > It would be useful to see what other protocols various SSH implementers > have been adding and see if there is a desire to move any of them into a > recommended or optional standard. As a matter of fact, I started such a page some time ago: http://ssh-comparison.quendi.de/ http://ssh-comparison.quendi.de/comparison.html I tried my best to make it accurate, but of course cannot exclude mistakes. Also, of course there are implementations missing (one notable is Bitvise's; I started work on that, but had a hard time finding reliable a source for what they actually support and what not). Anyway, issue reports and pull request (also with info on additional implementations) are most welcome: https://github.com/fingolfin/ssh-comparison The comparison page shows for example that hmac-sha2-256 and hmac-sha2-512 support is quite good now; one notable SSH library not implementing it yet in a released version is libssh2, but they will have it in the next release (the code is in their repository already), which in turn should allow various clients based on it to support it. Another exception is lsh. Cheers, max From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Nov 6 10:50:04 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51BB41B2EC8 for ; Fri, 6 Nov 2015 10:50:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Vp39IVwi1QBJ for ; Fri, 6 Nov 2015 10:50:02 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9E271B2ED7 for ; Fri, 6 Nov 2015 10:50:01 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id F1AB514A364; Fri, 6 Nov 2015 18:49:58 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id ACC3214A35B for ; Fri, 6 Nov 2015 18:49:54 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id K2I7cQr5g-_s for ; Fri, 6 Nov 2015 18:49:54 +0000 (UTC) Received: from wp256.webpack.hosteurope.de (wp256.webpack.hosteurope.de [80.237.133.25]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id E483F14A34C for ; Fri, 6 Nov 2015 18:49:51 +0000 (UTC) Received: from fb07-alg-gast1.math.uni-giessen.de ([134.176.24.161]); authenticated by wp256.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) id 1Zum56-0004Rg-Iw; Fri, 06 Nov 2015 19:49:48 +0100 Subject: Re: SSH key algorithm updates Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Content-Type: text/plain; charset=us-ascii From: Max Horn X-Priority: 3 In-Reply-To: <1955912751-3064@skroderider.denisbider.com> Date: Fri, 6 Nov 2015 19:49:55 +0100 Cc: ietf-ssh@NetBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: <4540741F-5789-49AA-B917-C822782D0881@quendi.de> References: <1955912751-3064@skroderider.denisbider.com> To: denis bider X-Mailer: Apple Mail (2.3096.5) X-bounce-key: webpack.hosteurope.de;postbox@quendi.de;1446835794;02d6a8ab; Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hi denis, > On 06.11.2015, at 18:59, denis bider wrote: >=20 > > Also, of course there are implementations missing (one notable > > is Bitvise's; I started work on that, but had a hard time finding > > reliable a source for what they actually support and what not). >=20 > If you can run a Windows executable, That's the rub, I can't really (don't have access to any Windows = machine). Though I'll try whether wine can do it. I'll try to setup a = Windows VM for this one of these days. >=20 > Both the client and the server are free for use that is both personal = and non-commercial. The client goes further than that, and is also free = for individual use in organizations. >=20 > The following is what a default SSH Server installation (latest = version 6.43) supports and enables at the moment. All algorithms listed = are supported. Only the "true" ones are enabled by default: OK, that more or less matches what I had "guessed" based on FlowSSH = (which already was on my page). Though I do not yet have a way to show on the page when an algorithm is = supported but disabled by default. This is on my TODO list, though. = Amongst other things (e.g. "supported since version x.y" would be nice = to have, too) [...] > Algorithms supported by our client mirror those in the server. OK, so for now I'll keep a single entry for the two. Thanks for your help, I now added Bitwise SSH to my page. One last question: Right now I only list these user auth methods: userauth: # the following is a guess, based on what FlowSsh = supports - publickey - password - keyboard-interactive - none But since you mention gss in your kex list, I am wondering whether this = is incomplete...? Cheers, Max= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Nov 6 16:44:22 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 194791B315E for ; Fri, 6 Nov 2015 16:44:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 pgpBEg__4ein for ; Fri, 6 Nov 2015 16:44:20 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFB851B3156 for ; Fri, 6 Nov 2015 16:44:20 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 6411F14A3FC; Sat, 7 Nov 2015 00:44:17 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 25C1814A3FB for ; Sat, 7 Nov 2015 00:44:14 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 9vTey9AuVnU8 for ; Sat, 7 Nov 2015 00:44:13 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id D252614A3F9 for ; Sat, 7 Nov 2015 00:44:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1446857053; x=1478393053; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=cCJleB6JF7Q8fB/+TSTBnvbOj+kfcl32YQ8RQwm9HwI=; b=joicBXHSxrzyJf9SsR9GPZpnlq2cp5dRdNsz0IDTeXpd+YxDWtTGv7ZM lduROQonbyiQ957SL188kDU2e90CieW11q7HBmDBCCL7gy0rqdC6zNG8+ aUR+x5gRJrLB3g3lb3u0pjiNTcKUWeLlt6FUb3TNZQZGEJu6F2t2HHN7H UeWzH2AAJp7IZ7G8AeQWFax8E9Fz0ztBhAOMQEpBjlZ1gGdXnQ/5zdwmI 6beKPyIuF83g1i1NHqqENfUSQiqmVSuzw7X/HZiwPVZN4a8+oL77hpXXR f76vxqZ5una5ilhwFB5pAKpaHfUwguqRq/BvtK0gv3PBGQ1nWZTchsRWi g==; X-IronPort-AV: E=Sophos;i="5.20,254,1444647600"; d="scan'208";a="52973579" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 07 Nov 2015 13:43:45 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Sat, 7 Nov 2015 13:43:45 +1300 From: Peter Gutmann To: Max Horn , denis bider CC: "ietf-ssh@NetBSD.org" Subject: RE: SSH key algorithm updates Thread-Topic: SSH key algorithm updates Thread-Index: AQHRGMPtBkokXX9VnEy0Wo+WRjNjMZ6PuN8L Date: Sat, 7 Nov 2015 00:43:43 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B58910@uxcn10-5.UoA.auckland.ac.nz> References: <1955912751-3064@skroderider.denisbider.com>,<4540741F-5789-49AA-B917-C822782D0881@quendi.de> In-Reply-To: <4540741F-5789-49AA-B917-C822782D0881@quendi.de> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Max Horn writes:=0A= =0A= >That's the rub, I can't really (don't have access to any Windows machine).= =0A= =0A= 'strings ssh-app-name.exe'? Since the identifiers are text strings, you do= n't=0A= really need to run the binary.=0A= =0A= >One last question: Right now I only list these user auth methods:=0A= =0A= 'none' is actually a bit of a problem since it's two different things, an a= uth=0A= mode and a mode-query-mechanism. I support 'none' as a query mechanism sin= ce=0A= some clients don't work without it, but not as an auth mechanism, and I=0A= suspect a number of other implementions listed as supporting 'none' wouldn'= t=0A= actually let you in without a password either. So perhaps this could be sp= lit=0A= into 'none-as-auth' and 'none-as-query'. I'd certainly be nervous about us= ing=0A= an implementation that had 'none-as-auth' enabled by default.=0A= =0A= Peter.= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Nov 6 16:51:19 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5CA41B316F for ; Fri, 6 Nov 2015 16:51:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 QtqALuXcjwaQ for ; Fri, 6 Nov 2015 16:51:18 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16EA41B316E for ; Fri, 6 Nov 2015 16:51:18 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 7073614A309; Sat, 7 Nov 2015 00:51:16 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 39A6814A2E1 for ; Sat, 7 Nov 2015 00:51:12 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 4_clu5WisiRM for ; Sat, 7 Nov 2015 00:51:11 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 0475414A2CF for ; Sat, 7 Nov 2015 00:51:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1446857471; x=1478393471; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CYjUFfSq3Yhelp/kpL50/V7uX9Ujgp7pRsljjmNmMy0=; b=KCFuA9hFsESdNOjwb9e4VNH38qirHhgE1MHGTkDCIY8g7pcRhlWsJa9k hp294CChYSSs5XpXZ8UgJfTSORUiZ94nnS1rWTDqKOuhQJK/gJPfBgyAa wMaI94K6YhUvNzIRKjpcmjvRT36OaZpEssKbWqmddnkyYuRNTdGBD4saa jqgDlA1Adm3rnHSTIeiRYtJ9DOprSOnMe6uCppHgDJDSfDP+4gB1WVTBX d0FQGItcFcqfNkQe82Z9M/jbQIVeV+lKd9jGpFCHtSA1SW32LAVlE65Ob KEi5Fyn8NwtZHZ1u/uqsZa8sLK24Yv9C/QB38i+E5PFEj1YZksWTSeBfc A==; X-IronPort-AV: E=Sophos;i="5.20,254,1444647600"; d="scan'208";a="52974415" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 07 Nov 2015 13:51:09 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Sat, 7 Nov 2015 13:51:09 +1300 From: Peter Gutmann To: denis bider CC: "ietf-ssh@netbsd.org" Subject: RE: New version of rsa-sha2-512 draft posted: no more DSA Thread-Topic: New version of rsa-sha2-512 draft posted: no more DSA Thread-Index: AQHRGLtWEdK76i2qrUycWMyswUrF1J6PuuGr Date: Sat, 7 Nov 2015 00:51:08 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B58932@uxcn10-5.UoA.auckland.ac.nz> References: <1955072546-964@skroderider.denisbider.com> In-Reply-To: <1955072546-964@skroderider.denisbider.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list denis bider writes:=0A= =0A= >From my perspective, SHA-2 512 seems like the clear winner in the RSA=0A= >situation, due to 64-bit CPUs being destined for ubiquity (already ubiquit= ous=0A= >on desktops, a few years away on mobile), =0A= =0A= ... and decades away on embedded. Most of my users are running SSH on=0A= embedded platforms, for which the presence of 64-bit is close to zero, and = no=0A= plan to move to that. I probably have more SSH running on 16-bit embedded= =0A= than 64-bit embedded.=0A= =0A= >why not have a larger hash output at no additional cost (it's embedded in = the=0A= >signature, anyway).=0A= =0A= Not if you're using P-256 rather than RSA. Only SHA-256 will work with P-2= 56=0A= which (again from the Mozilla discussion) is the most widely-used parameter= =0A= set, with P-521 (needed for -512) being barely used:=0A= =0A= lots of products can (and, it seems, are planning to, or already are)=0A= omitting support for P-521.=0A= (Comment from https://mozillians.org/en-US/u/briansmith/)=0A= =0A= (You can truncate -512 to make it work with P-256, but I wouldn't want to t= ake=0A= any bets on how well-supported that will be in practice).=0A= =0A= >However, if there are platforms where availability is a problem, then okay= ,=0A= >let's have both versions. I'll update the draft to re-add rsa-sha2-256, an= d=0A= >make that recommended, and -512 optional.=0A= =0A= Thanks!=0A= =0A= Peter.=0A= =0A= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Nov 6 19:46:18 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAEF01ACE96 for ; Fri, 6 Nov 2015 19:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 JXgExfSzDMxJ for ; Fri, 6 Nov 2015 19:46:17 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57A1A1ACE8E for ; Fri, 6 Nov 2015 19:46:17 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 6311714A245; Sat, 7 Nov 2015 03:46:14 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id BFBD714A23F for ; Sat, 7 Nov 2015 03:46:10 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id dJtuEaCviHnM for ; Sat, 7 Nov 2015 03:46:10 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 9A6D514A23E for ; Sat, 7 Nov 2015 03:46:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1446867970; x=1478403970; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4av5H1BGaSTC5KYi7eccRQjzBrvg8xCii0+oH2vAaGQ=; b=aWUWUpGOR6zexKLlRle4wjQcJZJOoTpQ0+YyE3vifjKrwD8vxD0d2E6d EwG3EthEKJksyMDFG2NzfwEO1MUMF4MJTzZmxyzWc7W2TPCJ2CealBmfs HGAPOjswBdN/3ys923SRGUlw9sKuNKphymjRIL1+v66A1+Pvq5GtzU67F cqdSbbW/TvqpGSxmLx7aZ38pGBd6vlGnVFKMfpI1XBH3wILQCI3EUro3y aaPM10LHK2BtbYkJWF1kyP2GAYo2WfptFN9B1UsqX6cSeBReME5hIk27V pRLG7Sd6+yFA4qRM8+zJAPFOYvX30qbiWOiA2zvf1KVWEIIuooE7VkhQ+ A==; X-IronPort-AV: E=Sophos;i="5.20,255,1444647600"; d="scan'208";a="52987315" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe3.UoA.auckland.ac.nz) ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 07 Nov 2015 16:46:05 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Sat, 7 Nov 2015 16:46:04 +1300 From: Peter Gutmann To: denis bider CC: "ietf-ssh@netbsd.org" Subject: RE: New version of rsa-sha2-512 draft posted: no more DSA Thread-Topic: New version of rsa-sha2-512 draft posted: no more DSA Thread-Index: AQHRGQMdEdK76i2qrUycWMyswUrF1J6P6trr Date: Sat, 7 Nov 2015 03:46:03 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B58ACD@uxcn10-5.UoA.auckland.ac.nz> References: <1985908046-756@skroderider.denisbider.com> In-Reply-To: <1985908046-756@skroderider.denisbider.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list denis bider writes:=0A= =0A= >I was wondering how much SSH there is on embedded devices. I'm glad to hea= r=0A= >you have that covered. :-)=0A= =0A= A surprising amount, a lot of stuff that used to be done via a serial conso= le=0A= just got wrapped in SSH when the devices were Internet-enabled. It means y= ou=0A= can keep using the same tools you've always used (TLS-protected web interfa= ces=0A= may look cool on consumer devices, and there's some use coming in SCADA, bu= t=0A= you can't script them or manage them easily with standard tools).=0A= =0A= The downside is that I've got workarounds for 15-year-old implementation bu= gs=0A= still active in my code, because the software gets updated as infrequently = as=0A= the hardware, and the standards-conformance test for any SSH implementation= is=0A= "will putty connect to it?".=0A= =0A= OK, drifting off-topic there :-).=0A= =0A= Hmm, I wonder if it'd be worth doing a profile of SSH for embedded use? It= 'd=0A= certainly help clear some interop headaches, and give the SCADA folks a tar= get=0A= to aim for.=0A= =0A= Peter.= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Nov 7 01:27:27 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF441B2E7D for ; Sat, 7 Nov 2015 01:27:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 5xWRb7qoD1nO for ; Sat, 7 Nov 2015 01:27:26 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B12941B2E7B for ; Sat, 7 Nov 2015 01:27:24 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 4C9E914A1F2; Sat, 7 Nov 2015 09:27:23 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id DE50414A1ED; Sat, 7 Nov 2015 09:27:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id B449114A37F for ; Fri, 6 Nov 2015 02:20:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id jabU6zUThI0L for ; Fri, 6 Nov 2015 02:20:04 +0000 (UTC) Received: from newmailhub.uq.edu.au (mailhub1.soe.uq.edu.au [130.102.132.208]) by mail.netbsd.org (Postfix) with ESMTP id ADDE114A37E for ; Fri, 6 Nov 2015 02:20:03 +0000 (UTC) Received: from smtp2.soe.uq.edu.au (smtp2.soe.uq.edu.au [10.138.113.41]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id tA62K1JV021703; Fri, 6 Nov 2015 12:20:01 +1000 Received: from mailhub.eait.uq.edu.au (hazel.eait.uq.edu.au [130.102.60.17]) by smtp2.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id tA62K0Ft028156 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 6 Nov 2015 12:20:01 +1000 Received: from natsu.mindrot.org (natsu.mindrot.org [130.102.96.2]) by mailhub.eait.uq.edu.au (8.15.1/8.15.1) with ESMTP id tA62JxwP008736; Fri, 6 Nov 2015 12:20:00 +1000 (AEST) Received: by natsu.mindrot.org (Postfix, from userid 1000) id EA878A4F31; Fri, 6 Nov 2015 13:19:59 +1100 (AEDT) Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id E9E82A4F2F; Fri, 6 Nov 2015 13:19:59 +1100 (AEDT) Date: Fri, 6 Nov 2015 13:19:59 +1100 (AEDT) From: Damien Miller To: denis bider cc: ietf-ssh@netbsd.org Subject: Re: OpenSSH sabotages protocol extension In-Reply-To: <1817847842-896@skroderider.denisbider.com> Message-ID: References: <1817847842-896@skroderider.denisbider.com> User-Agent: Alpine 2.20 (BSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="33152852557824-1441090768-1446776009=:27760" Content-ID: X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub X-Scanned-By: MIMEDefang 2.75 on 130.102.60.17 X-UQ-FilterTime: 1446776401 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --33152852557824-1441090768-1446776009=:27760 Content-Type: text/plain; CHARSET=ISO-8859-15 Content-Transfer-Encoding: 8BIT Content-ID: On Thu, 5 Nov 2015, denis bider wrote: > Obviously, same thing for SSH2_MSG_USERAUTH_FAILURE: > > >     authlist = packet_get_string(NULL); >     partial = packet_get_char(); >     packet_check_eom(); RFC4242 section 5.1. I'll quote it for you: > 5.1. Responses to Authentication Requests > > If the server rejects the authentication request, it MUST respond > with the following: > > byte SSH_MSG_USERAUTH_FAILURE > name-list authentications that can continue > boolean partial success Note the lack of extension fields and the "MUST". > Awesome work, guys! You have locked down every possible clean way that the > protocol could be extended, so as to spare the client several round-trips to > discover which signing algorithms it can use for RSA keys. It sounds like you want to redefine the information flow of public key authentication. If you want to do this (and I don't think it is a good idea - I'll comment separately on the draft), then the right way to do it is to design a new authentication method that can be negotiated by implementations that support it. By implementing a new "publickey2" (or whatever) method, you get to define new SSH_MSG_USERAUTH messages, which is basically what you are trying to do here. > You've made it so that the only way to convey such information, and not risk > a client disconnect, is to use a specially crafted SSH_MSG_IGNORE. Again, RFC4252 made it this way. We just implemented it as it was written. -d --33152852557824-1441090768-1446776009=:27760-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Nov 7 01:28:04 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56FC21B2E7D for ; Sat, 7 Nov 2015 01:28:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 afPzFkZKsess for ; Sat, 7 Nov 2015 01:28:03 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F27EA1B2E7C for ; Sat, 7 Nov 2015 01:28:02 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 75C5814A1F4; Sat, 7 Nov 2015 09:28:02 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 0F5CB14A1F3; Sat, 7 Nov 2015 09:28:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id D9A2E14A381 for ; Fri, 6 Nov 2015 02:19:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id ENFA4YQS6GJG for ; Fri, 6 Nov 2015 02:19:50 +0000 (UTC) Received: from newmailhub.uq.edu.au (mailhub2.soe.uq.edu.au [130.102.132.209]) by mail.netbsd.org (Postfix) with ESMTP id 7EEF814A37E for ; Fri, 6 Nov 2015 02:19:46 +0000 (UTC) Received: from smtp1.soe.uq.edu.au (smtp1.soe.uq.edu.au [10.138.113.40]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id tA62Jh82048389; Fri, 6 Nov 2015 12:19:43 +1000 Received: from mailhub.eait.uq.edu.au (holly.eait.uq.edu.au [130.102.79.58]) by smtp1.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id tA62Jh1c048345 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 6 Nov 2015 12:19:43 +1000 Received: from natsu.mindrot.org (natsu.mindrot.org [130.102.96.2]) by mailhub.eait.uq.edu.au (8.15.1/8.15.1) with ESMTP id tA62JgZZ016345; Fri, 6 Nov 2015 12:19:42 +1000 (AEST) Received: by natsu.mindrot.org (Postfix, from userid 1000) id 1BF69A4F2E; Fri, 6 Nov 2015 13:19:42 +1100 (AEDT) Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id 1B1BDA4F07; Fri, 6 Nov 2015 13:19:42 +1100 (AEDT) Date: Fri, 6 Nov 2015 13:19:42 +1100 (AEDT) From: Damien Miller To: denis bider cc: ietf-ssh@netbsd.org Subject: Re: OpenSSH sabotages protocol extension In-Reply-To: <1817171671-604@skroderider.denisbider.com> Message-ID: References: <1817171671-604@skroderider.denisbider.com> User-Agent: Alpine 2.20 (BSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="33152852557824-1949322310-1446775851=:27760" Content-ID: X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub X-Scanned-By: MIMEDefang 2.75 on 130.102.79.58 X-UQ-FilterTime: 1446776383 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --33152852557824-1949322310-1446775851=:27760 Content-Type: text/plain; CHARSET=ISO-8859-15 Content-Transfer-Encoding: 8BIT Content-ID: On Thu, 5 Nov 2015, denis bider wrote: > Well, I'm slightly pissed. > > Why does OpenSSL do stupid shit like this? [snip] > Note the genius inclusion of packet_check_eom() after decoding > SERVICE_ACCEPT. Guess what this line does? > >     #define ssh_packet_check_eom(ssh) \ ... >             logit("Packet integrity error (%d bytes remaining) at %s:%d", \ >                 _len ,__FILE__, __LINE__); \ >             ssh_packet_disconnect(ssh, \ >                 "Packet integrity error."); \ ... > Yes. It disconnects if there's any extra data after the recognized field in > SERVICE_ACCEPT. > > What possible purpose does this serve? It verifies that the message is conformant to RFC4253 section 10 (which specifies only a single string in a SSH_MSG_SERVICE_REQUEST) and not gibberish. > What possible purpose at all, other than to sabotage future extension? ... because an implementation of a security protocol that runs with high privilege should strongly validate well-formedness. > Thanks to this, we cannot add a field to SERVICE_ACCEPT so that the server > could advertise what signature algorithms it accepts for user > authentication. No, you can't add one because RFC4253 specified it differently and you don't get to retcon protocols by hoping that implementations don't validate their input. -d --33152852557824-1949322310-1446775851=:27760-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Nov 7 01:29:41 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 387171B2E8A for ; Sat, 7 Nov 2015 01:29:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 ZapH-D7TrVAe for ; Sat, 7 Nov 2015 01:29:39 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A172F1B2E91 for ; Sat, 7 Nov 2015 01:29:39 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 29A4E14A2F7; Sat, 7 Nov 2015 09:29:39 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id BF2E514A2D5; Sat, 7 Nov 2015 09:29:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 472C914A336 for ; Fri, 6 Nov 2015 05:56:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id IzH2B8E4Bn0J for ; Fri, 6 Nov 2015 05:56:58 +0000 (UTC) Received: from smtp03.srv.cs.cmu.edu (smtp03.srv.cs.cmu.edu [128.2.217.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 2721F14A2E8 for ; Fri, 6 Nov 2015 05:56:56 +0000 (UTC) Received-SPF: none (cmu.edu: No applicable sender policy available) receiver=smtp03.srv.cs.cmu.edu; identity=mailfrom; envelope-from="jhutz@cmu.edu"; helo="[192.168.202.98]"; client-ip=74.109.252.206 Received: from [192.168.202.98] (pool-74-109-252-206.pitbpa.fios.verizon.net [74.109.252.206]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id tA65ueBS015319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 6 Nov 2015 00:56:42 -0500 (EST) Message-ID: <1446789400.4752.33.camel@destiny.pc.cs.cmu.edu> Subject: Re: SSH key algorithm updates From: Jeffrey Hutzelman To: Niels =?ISO-8859-1?Q?M=F6ller?= Cc: jhutz@cmu.edu, "Mark D. Baushke" , denis bider , ietf-ssh@NetBSD.org, stephen.farrell@cs.tcd.ie, jon@siliconcircus.com Date: Fri, 06 Nov 2015 00:56:40 -0500 In-Reply-To: References: <1297540000-2044@skroderider.denisbider.com> <51845.1446188002@eng-mail01.juniper.net> <1446228753.32676.1.camel@destiny.pc.cs.cmu.edu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.202 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Fri, 2015-11-06 at 06:16 +0100, Niels Möller wrote: > And when it comes to sha1 weaknesses, using sha1 with a signature > algorithm seems more dangerous than using it for hmac or for key > expansion. Agreed. > > For MAC algorithms: > > - Upgrade hmac-sha2-256 to REQUIRED > > - Consider upgrading hmac-sha2-512 to RECOMMENDED > > - Downgrade hmac-md5 and hmac-md5-96 to NOT RECOMMENDED > > - Downgrade hmac-sha1-96 to NOT RECOMMENDED > > - Consider downgrading hmac-sha1 to RECOMMENDED > > > > HMAC-SHA1 is not (yet) considered insecure, it has been SSHv2's only > > required algorithm since RFC 425x were published, and it is probably the > > most widely deployed. So, we should not downgrade it below RECOMMENDED. > > However, I think a case can be made for hmac-sha2-256 replacing it as > > the REQUIRED algorithm, if we think that has gained enough traction. > > My understanding is that there are no known attacks on hmac-sha1, and > that the attacks on non-keyed hashfunctions in the family don't apply. > Is there any likely harm in keeping it as required for another decade? Your understanding matches mine. However, it's still only a 160-bit hash, and eventually that just stops being strong enough. I'd like to have something stronger implemented and reasonably widely deployed before then. > > I chose aes128-ctr because RFC4253 listed aes128-cbc as > > RECOMMENDED while leaving the other sizes OPTIONAL. I suspect this was > > done because at the time, some folks did not want to ship AES256 due to > > export restrictions and/or lack of utility. > > What about the key-setup problems in aes256? I seem to recall that it's > not as much better than aes128 as was intended. Oh, hm; that may be the case. > > We may wish to consider leaving 3des-cbc at SHOULD, > > I think that makes sense, if the main problem with 3des is performance > rather than security. SSH's 3des-cbc is three-key EDE 3DES. It has an effective key length of 112 bits, and so is weaker than AES128. It's also a CBC mode and AFAIK has the same problems as all of SSH's other CBC-mode ciphers. So, the main reason to deprecate it is indeed security. The main reason _not_ to do so is interop, particularly with old things. > > Finally, for key exchange algorithms: > > - Upgrade diffie-hellman-group-exchange-sha256 to REQUIRED > > - Upgrade ecdh-sha2-* to RECOMMENDED > > - Consider downgrading diffie-hellman-group14-sha1 to RECOMMENDED > > - Downgrade other diffie-hellman-*-sha1 to NOT RECOMMENDED > > - Downgrade rsa1024-sha1 to NOT RECOMMENDED > > > Again, eliminating the SHA1-based DH algorithms in favor of GEX SHA256 > > should be obvious, > > I don't think choosing group-exchange is obvious; using a fixed group is > an obvious gain in terms of simplicity. Personally, I don't quite like > the complexity and validation issues with group-exchange (but maybe I > could be convinced it's no problem). So I hesitate to make it the > reqiured algorithm. Group exchange doesn't have to mean live, dynamic group generation. It can work fine with a set of fixed groups, either manually configured or compiled in. I'd have to go back and look, but I think the sense of the group at the time was that there was no reason to define more variations with the group baked into the algorithm names. In any case, there's a spec for SHA256 with group exchange, but not with fixed groups. So if we want to go that route, we have to specify new algorithms and wait for them to be supported. > Why don't you like diffie-hellman-group14-sha1 as required? Is that group > considered too small these days, or is sha1 considered too weak for this > use? The latter, at least. The SHA1 here is used to compute the exchange hash, which is signed to authenticate the key exchange process and bind it to the host's public key. It's also used to derive the session keys. I'm not sure what current thinking is about use of SHA1 for key derivation, but for non-HMAC authentication it's definitely no longer sufficient. > >> Or, is this better left to another RFC? Perhaps moving the Ed25519 > >> algorithm created by > >> > >> https://tools.ietf.org/html/draft-irtf-cfrg-eddsa-00 > >> > >> into a MUST algorithm while deprecating "ssh-dss" for SSH? > > > > That's an unfinished, -00 version internet draft from CFRG. > > Is that related to the (now expireed, I think) draft I and Simon wrote > some time ago? I'm not following the cfrg work. I'm not sure. It's only a month old, and does have Simon's name on it. > I think it would also be highly desirable to standardize use of > aead-algorithms. But as far as I remember, from last time this was > discussed, it was tricky to extend the algorithm negotiation in a clean > way. (And I'd like to do chacha-poly1305 sligthly different from the way > openssh does it, but we can get to that in due time). > > So specifying AEAD is a different and harder problem than just updating > the list of recommended algorithms. Yup. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Nov 7 01:29:55 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 059FF1B2E8A for ; Sat, 7 Nov 2015 01:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 aEwAoTrk2v7g for ; Sat, 7 Nov 2015 01:29:54 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47EA31B2E95 for ; Sat, 7 Nov 2015 01:29:53 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id C312014A2F8; Sat, 7 Nov 2015 09:29:52 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 671EB14A2D5; Sat, 7 Nov 2015 09:29:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 1C5DC14A257 for ; Sat, 7 Nov 2015 03:50:56 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id m0y7n5ep4Tvl for ; Sat, 7 Nov 2015 03:50:55 +0000 (UTC) Received: from smtp02.srv.cs.cmu.edu (smtp02.srv.cs.cmu.edu [128.2.217.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 6F62A14A258 for ; Sat, 7 Nov 2015 03:50:53 +0000 (UTC) Received-SPF: none (cmu.edu: No applicable sender policy available) receiver=smtp02.srv.cs.cmu.edu; identity=mailfrom; envelope-from="jhutz@cmu.edu"; helo="[192.168.202.98]"; client-ip=74.109.252.206 Received: from [192.168.202.98] (pool-74-109-252-206.pitbpa.fios.verizon.net [74.109.252.206]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id tA73oci3021336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 6 Nov 2015 22:50:39 -0500 (EST) Message-ID: <1446868237.5945.12.camel@destiny.pc.cs.cmu.edu> Subject: Re: DH group exchange (Re: SSH key algorithm updates) From: Jeffrey Hutzelman To: denis bider Cc: jhutz@cmu.edu, Niels =?ISO-8859-1?Q?M=F6ller?= , "Mark D. Baushke" , ietf-ssh@NetBSD.org, stephen.farrell@cs.tcd.ie, jon@siliconcircus.com Date: Fri, 06 Nov 2015 22:50:37 -0500 In-Reply-To: <1990286542-756@skroderider.denisbider.com> References: <1990286542-756@skroderider.denisbider.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.201 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Sat, 2015-11-07 at 03:33 +0000, denis bider wrote: > It is a fairly substantial problem that most dynamically generated > groups aren't usable with our FIPS module. What's broken about the groups that don't work? From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Nov 7 01:30:41 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC0A1B2E95 for ; Sat, 7 Nov 2015 01:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 tsJhu__T-KUE for ; Sat, 7 Nov 2015 01:30:39 -0800 (PST) Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D2F91B2E5D for ; Sat, 7 Nov 2015 01:30:39 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id D0CDD14A36C; Sat, 7 Nov 2015 09:30:38 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 6C0DA14A35E; Sat, 7 Nov 2015 09:30:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id D377514A37A for ; Fri, 6 Nov 2015 03:30:44 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 0SIEA8aaJjjA for ; Fri, 6 Nov 2015 03:30:44 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id DFCED14A378 for ; Fri, 6 Nov 2015 03:30:43 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for ietf-ssh@netbsd.org; Fri, 6 Nov 2015 03:30:37 +0000 Date: Fri, 6 Nov 2015 03:30:37 +0000 Subject: Protocol extension / signaling supported signature algorithms X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <1903447103-896@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: ietf-ssh@netbsd.org Cc: djm@mindrot.org Content-Type: multipart/alternative; boundary="=-jye0Fj+ocvPbqJdTOkwP" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-jye0Fj+ocvPbqJdTOkwP Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I'm not sure that any part of RFC 4253 specifies that you must disconnect i= f a message contains additional info that you don't recognize. The security= benefits of doing so are dubious. If there's any way that this could be ex= ploited, it means you (or the other party) have much bigger issues.=C2=A0 O= n the other hand, by implementing this, you absolutely guarantee that futur= e extensibility is impossible without additional signaling. That being said, my anger is misplaced because if you didn't pull this, som= eone else would, and god knows there's any number of implementations out th= ere that do... things. The flaw is really in the protocol, which doesn't provide room for this add= itional signaling. In hindsight, the SERVICE_REQUEST and SERVICE_ACCEPT mes= sages are useless. They waste an entire roundtrip on the idea that there mi= ght be other services for the client to request than user authentication. A= decade later, there aren't any such services. The very least that these messages could have done was add a simple name-li= st of extensions supported. In that case, at least, this extra round trip w= ould be useful for extension signaling. You propose signaling via a "publickey2" method. Unfortunately, this still = requires the client to waste a round-trip: either by requesting "none" auth= entication to discover methods supported, or by requesting "publickey2" aut= hentication and finding that it isn't supported. I think the SSH_MSG_IGNORE strategy is superior - it allows the client to i= mmediately fire the correct public key authentication request with signatur= e. =C2=A0 ----- Original Message ----- From: Damien Miller Sent: Thursday, No= vember 5, 2015 20:19 To: denis bider Cc: ietf-ssh@netbsd.org Subject: Re:= OpenSSH sabotages protocol extension =C2=A0 On Thu, 5 Nov 2015, denis bide= r wrote: =C2=A0 > Obviously, same thing for SSH2_MSG_USERAUTH_FAILURE: > >= >=C2=A0=C2=A0=C2=A0=C2=A0 authlist =3D packet_get_string(NULL); >=C2=A0= =C2=A0=C2=A0=C2=A0 partial =3D packet_get_char(); >=C2=A0=C2=A0=C2=A0=C2=A0= packet_check_eom(); =C2=A0 RFC4242 section 5.1. I'll quote it for you: =C2= =A0 > 5.1.=C2=A0 Responses to Authentication Requests > >=C2=A0=C2=A0=C2= =A0 If the server rejects the authentication request, it MUST respond >=C2= =A0=C2=A0=C2=A0 with the following: > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 byte=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SSH_MSG_USERAUTH_F= AILURE >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 name-list=C2=A0=C2=A0=C2=A0 au= thentications that can continue >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 boole= an=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 partial success =C2=A0 Note the lack of ex= tension fields and the "MUST". =C2=A0 > Awesome work, guys! You have locked= down every possible clean way that the > protocol could be extended, so a= s to spare the client several round-trips to > discover which signing algo= rithms it can use for RSA keys. =C2=A0 It sounds like you want to redefine = the information flow of public key authentication. If you want to do this = (and I don't think it is a good idea - I'll comment separately on the draf= t), then the right way to do it is to design a new authentication method t= hat can be negotiated by implementations that support it. =C2=A0 By impleme= nting a new "publickey2" (or whatever) method, you get to define new SSH_MS= G_USERAUTH messages, which is basically what you are trying to do here. =C2= =A0 > You've made it so that the only way to convey such information, and = not risk > a client disconnect, is to use a specially crafted SSH_MSG_IGNO= RE. =C2=A0 Again, RFC4252 made it this way. We just implemented it as it wa= s written. =C2=A0 -d = --=-jye0Fj+ocvPbqJdTOkwP Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
I'm not sure that any part of RFC 4253 specif= ies that you must disconnect if a message contains additional info that you= don't recognize. The security benefits of doing so are dubious. If there's= any way that this could be exploited, it means you (or the other party) ha= ve much bigger issues.  On the other hand, by implementing this, you a= bsolutely guarantee that future extensibility is impossible without additio= nal signaling.

That being said, my anger is misplaced because if you= didn't pull this, someone else would, and god knows there's any number of = implementations out there that do... things.

The flaw is really in t= he protocol, which doesn't provide room for this additional signaling. In h= indsight, the SERVICE_REQUEST and SERVICE_ACCEPT messages are useless. They= waste an entire roundtrip on the idea that there might be other services f= or the client to request than user authentication. A decade later, there ar= en't any such services.

The very least that these messages could<= /i> have done was add a simple name-list of extensions supported. In that c= ase, at least, this extra round trip would be useful for extension signalin= g.

You propose signaling via a "publickey2" method. Unfortunately, t= his still requires the client to waste a round-trip: either by requesting "= none" authentication to discover methods supported, or by requesting "publi= ckey2" authentication and finding that it isn't supported.

I think t= he SSH_MSG_IGNORE strategy is superior - it allows the client to immediatel= y fire the correct public key authentication request with signature.
 
----- Original Message -----
From: Damien Miller
Sent: Thursday, November 5, 2015 20:19
To: denis bider
Cc: ietf-ssh@netbsd.org
Subject: Re: OpenSSH sabotages protocol extension
 
On Thu, 5 Nov 2015, denis bider wrote:
 
> Obviously, same thing for SSH2_MSG_USERAUTH_FAILURE:
>
>
>     authlist =3D packet_get_string(NULL);
>     partial =3D packet_get_char();
>     packet_check_eom();
 
RFC4242 section 5.1. I'll quote it for you:
 
> 5.1.  Responses to Authentication Requests
>
>    If the server rejects the authentication reques= t, it MUST=20 respond
>    with the following:
>
>       byte    &= nbsp;    SSH_MSG_USERAUTH_FAILURE
>       name-list    a= uthentications that can continue
>       boolean   &nbs= p;  partial success
 
Note the lack of extension fields and the "MUST".
 
> Awesome work, guys! You have locked down every possible clean way= that=20 the
> protocol could be extended, so as to spare the client several=20 round-trips to
> discover which signing algorithms it can use for RSA keys.
 
It sounds like you want to redefine the information flow of public=20 key
authentication. If you want to do this (and I don't think it is a=20 good
idea - I'll comment separately on the draft), then the right way to=20 do
it is to design a new authentication method that can be negotiated by<= /div>
implementations that support it.
 
By implementing a new "publickey2" (or whatever) method, you get to
define new SSH_MSG_USERAUTH messages, which is basically what you are<= /div>
trying to do here.
 
> You've made it so that the only way to convey such information, a= nd=20 not risk
> a client disconnect, is to use a specially crafted=20 SSH_MSG_IGNORE.
 
Again, RFC4252 made it this way. We just implemented it as it was=20 written.
 
-d

= --=-jye0Fj+ocvPbqJdTOkwP-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Nov 7 01:30:58 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D296A1B2E95 for ; Sat, 7 Nov 2015 01:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 DS3qPHlx8pnC for ; Sat, 7 Nov 2015 01:30:56 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA86D1B2E5D for ; Sat, 7 Nov 2015 01:30:56 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 1C04214A378; Sat, 7 Nov 2015 09:30:56 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id AC48514A374; Sat, 7 Nov 2015 09:30:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 7EF6814A37F for ; Fri, 6 Nov 2015 03:43:03 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 6LtBPkNqN9dF for ; Fri, 6 Nov 2015 03:43:02 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 675F614A382 for ; Fri, 6 Nov 2015 03:43:02 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for ietf-ssh@netbsd.org; Fri, 6 Nov 2015 03:42:58 +0000 Date: Fri, 6 Nov 2015 03:42:58 +0000 Subject: Re: Protocol extension / signaling supported signature algorithms X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <1904682943-964@skroderider.denisbider.com> X-Priority: 3 Importance: Normal In-Reply-To: <1903447103-896@skroderider.denisbider.com> MIME-Version: 1.0 From: denis bider To: ietf-ssh@netbsd.org Cc: djm@mindrot.org Content-Type: multipart/alternative; boundary="=-FRoW+wFoZwJ9VE/eFjmq" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-FRoW+wFoZwJ9VE/eFjmq Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable In general, your trigger-happy approach to disconnects creates much more tr= ouble than it benefits. For another example, our SSH Server cannot use acti= ve keep-alives (based on fake global-requests that require a response) beca= use old clients of yours disconnected when they received a global request f= rom the server. Surely someone thought this was a wise choice, based on the= exact reasoning you've now presented. "Let's disconnect - just to be safe.= " Implementing a security protocol doesn't mean you get to be a lunatic and m= ake decisions that are really stupid from a compatibility perspective. denis bider , 11/6/2015 3:19 AM: I'm not sure that any part of RFC 4253 specifies that you must disconnect i= f a message contains additional info that you don't recognize. The security= benefits of doing so are dubious. If there's any way that this could be ex= ploited, it means you (or the other party) have much bigger issues.=C2=A0 O= n the other hand, by implementing this, you absolutely guarantee that futur= e extensibility is impossible without additional signaling. That being said, my anger is misplaced because if you didn't pull this, som= eone else would, and god knows there's any number of implementations out th= ere that do... things. The flaw is really in the protocol, which doesn't provide room for this add= itional signaling. In hindsight, the SERVICE_REQUEST and SERVICE_ACCEPT mes= sages are useless. They waste an entire roundtrip on the idea that there mi= ght be other services for the client to request than user authentication. A= decade later, there aren't any such services. The very least that these messages could have done was add a simple name-li= st of extensions supported. In that case, at least, this extra round trip w= ould be useful for extension signaling. You propose signaling via a "publickey2" method. Unfortunately, this still = requires the client to waste a round-trip: either by requesting "none" auth= entication to discover methods supported, or by requesting "publickey2" aut= hentication and finding that it isn't supported. I think the SSH_MSG_IGNORE strategy is superior - it allows the client to i= mmediately fire the correct public key authentication request with signatur= e. =C2=A0 ----- Original Message ----- From: Damien Miller Sent: Thursday, No= vember 5, 2015 20:19 To: denis bider Cc: ietf-ssh@netbsd.org Subject: Re:= OpenSSH sabotages protocol extension =C2=A0 On Thu, 5 Nov 2015, denis bide= r wrote: =C2=A0 > Obviously, same thing for SSH2_MSG_USERAUTH_FAILURE: > >= >=C2=A0=C2=A0=C2=A0=C2=A0 authlist =3D packet_get_string(NULL); >=C2=A0= =C2=A0=C2=A0=C2=A0 partial =3D packet_get_char(); >=C2=A0=C2=A0=C2=A0=C2=A0= packet_check_eom(); =C2=A0 RFC4242 section 5.1. I'll quote it for you: =C2= =A0 > 5.1.=C2=A0 Responses to Authentication Requests > >=C2=A0=C2=A0=C2= =A0 If the server rejects the authentication request, it MUST respond >=C2= =A0=C2=A0=C2=A0 with the following: > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 byte=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SSH_MSG_USERAUTH_F= AILURE >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 name-list=C2=A0=C2=A0=C2=A0 au= thentications that can continue >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 boole= an=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 partial success =C2=A0 Note the lack of ex= tension fields and the "MUST". =C2=A0 > Awesome work, guys! You have locked= down every possible clean way that the > protocol could be extended, so a= s to spare the client several round-trips to > discover which signing algo= rithms it can use for RSA keys. =C2=A0 It sounds like you want to redefine = the information flow of public key authentication. If you want to do this = (and I don't think it is a good idea - I'll comment separately on the draf= t), then the right way to do it is to design a new authentication method t= hat can be negotiated by implementations that support it. =C2=A0 By impleme= nting a new "publickey2" (or whatever) method, you get to define new SSH_MS= G_USERAUTH messages, which is basically what you are trying to do here. =C2= =A0 > You've made it so that the only way to convey such information, and = not risk > a client disconnect, is to use a specially crafted SSH_MSG_IGNO= RE. =C2=A0 Again, RFC4252 made it this way. We just implemented it as it wa= s written. =C2=A0 -d = --=-FRoW+wFoZwJ9VE/eFjmq Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable In general, your trigger-happy approach to disconn= ects creates much more trouble than it benefits. For another example, our S= SH Server cannot use active keep-alives (based on fake global-requests that= require a response) because old clients of yours disconnected when they re= ceived a global request from the server. Surely someone thought this was a = wise choice, based on the exact reasoning you've now presented. "Let's disc= onnect - just to be safe."

Implementing a security protocol doesn't = mean you get to be a lunatic and make decisions that are really stupid from= a compatibility perspective.


denis bider <ietf-ssh3@denisbider.com> , 11/6/2015 3:19 AM= :
I'm not sure that any part of RFC 4= 253 specifies that you must disconnect if a message contains additional inf= o that you don't recognize. The security benefits of doing so are dubious. = If there's any way that this could be exploited, it means you (or the other= party) have much bigger issues.  On the other hand, by implementing t= his, you absolutely guarantee that future extensibility is impossible witho= ut additional signaling.

That being said, my anger is misplaced beca= use if you didn't pull this, someone else would, and god knows there's any = number of implementations out there that do... things.

The flaw is r= eally in the protocol, which doesn't provide room for this additional signa= ling. In hindsight, the SERVICE_REQUEST and SERVICE_ACCEPT messages are use= less. They waste an entire roundtrip on the idea that there might be other = services for the client to request than user authentication. A decade later= , there aren't any such services.

The very least that these messages= could have done was add a simple name-list of extensions supported.= In that case, at least, this extra round trip would be useful for extensio= n signaling.

You propose signaling via a "publickey2" method. Unfort= unately, this still requires the client to waste a round-trip: either by re= questing "none" authentication to discover methods supported, or by request= ing "publickey2" authentication and finding that it isn't supported.
I think the SSH_MSG_IGNORE strategy is superior - it allows the client to = immediately fire the correct public key authentication request with signatu= re.

 
----- Original Message -----
From: Damien Miller
Sent: Thursday, November 5, 2015 20:19
To: denis bider
Subject: Re: OpenSSH sabotages protocol extension
 
On Thu, 5 Nov 2015, denis bider wrote:
 
> Obviously, same thing for SSH2_MSG_USERAUTH_FAILURE:
>
>
>     authlist =3D packet_get_string(NULL);
>     partial =3D packet_get_char();
>     packet_check_eom();
 
RFC4242 section 5.1. I'll quote it for you:
 
> 5.1.  Responses to Authentication Requests
>
>    If the server rejects the authentication reques= t, it MUST=20 respond
>    with the following:
>
>       byte    &= nbsp;    SSH_MSG_USERAUTH_FAILURE
>       name-list    a= uthentications that can continue
>       boolean   &nbs= p;  partial success
 
Note the lack of extension fields and the "MUST".
 
> Awesome work, guys! You have locked down every possible clean way= that=20 the
> protocol could be extended, so as to spare the client several=20 round-trips to
> discover which signing algorithms it can use for RSA keys.
 
It sounds like you want to redefine the information flow of public=20 key
authentication. If you want to do this (and I don't think it is a=20 good
idea - I'll comment separately on the draft), then the right way to=20 do
it is to design a new authentication method that can be negotiated by<= /div>
implementations that support it.
 
By implementing a new "publickey2" (or whatever) method, you get to
define new SSH_MSG_USERAUTH messages, which is basically what you are<= /div>
trying to do here.
 
> You've made it so that the only way to convey such information, a= nd=20 not risk
> a client disconnect, is to use a specially crafted=20 SSH_MSG_IGNORE.
 
Again, RFC4252 made it this way. We just implemented it as it was=20 written.
 
-d

= --=-FRoW+wFoZwJ9VE/eFjmq-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Nov 7 01:31:09 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 380611B2E95 for ; Sat, 7 Nov 2015 01:31:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 4ANb-yL_0VEA for ; Sat, 7 Nov 2015 01:31:06 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FE221B2E5D for ; Sat, 7 Nov 2015 01:31:06 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id DADB614A201; Sat, 7 Nov 2015 09:31:05 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 6E2AB14A1CD; Sat, 7 Nov 2015 09:31:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id A755414A1E9 for ; Sat, 7 Nov 2015 02:22:20 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id O9ZqOuUp1mGF for ; Sat, 7 Nov 2015 02:22:20 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id E31BA14A1E7 for ; Sat, 7 Nov 2015 02:22:19 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for pgut001@cs.auckland.ac.nz; Sat, 7 Nov 2015 02:22:14 +0000 Date: Sat, 7 Nov 2015 02:22:14 +0000 Subject: Re: New version of rsa-sha2-512 draft posted: no more DSA X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <1985908046-756@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: Peter Gutmann Cc: ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-zSk8JTppaAJBkxs3hRU8" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-zSk8JTppaAJBkxs3hRU8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Apologies for my ignorance about the embedded situation. That's interesting= to know. I was wondering how much SSH there is on embedded devices. I'm glad to hear= you have that covered. :-) I understand SHA-2 512 won't fit into P-256. It does fit into RSA, though, = and I was figuring it would not be a problem for applications to support bo= th hash types. No problem if it's impractical, though. I appreciate the information! I'll prepare new stuff hopefully tomorrow. ----- Original Message ----- From: Peter Gutmann=20 Sent: Friday, November 6, 2015 18:51 To: denis bider=20 Cc: ietf-ssh@netbsd.org=20 Subject: RE: New version of rsa-sha2-512 draft posted: no more DSA denis bider writes: >From my perspective, SHA-2 512 seems like the clear winner in the RSA >situation, due to 64-bit CPUs being destined for ubiquity (already ubiquit= ous >on desktops, a few years away on mobile),=20 ... and decades away on embedded.=C2=A0 Most of my users are running SSH on embedded platforms, for which the presence of 64-bit is close to zero, and = no plan to move to that.=C2=A0 I probably have more SSH running on 16-bit embe= dded than 64-bit embedded. >why not have a larger hash output at no additional cost (it's embedded in = the >signature, anyway). Not if you're using P-256 rather than RSA.=C2=A0 Only SHA-256 will work wit= h P-256 which (again from the Mozilla discussion) is the most widely-used parameter set, with P-521 (needed for -512) being barely used: =C2=A0 lots of products can (and, it seems, are planning to, or already are= ) =C2=A0 omitting support for P-521. =C2=A0=C2=A0=C2=A0 (Comment from https://mozillians.org/en-US/u/briansmith/= ) (You can truncate -512 to make it work with P-256, but I wouldn't want to t= ake any bets on how well-supported that will be in practice). >However, if there are platforms where availability is a problem, then okay= , >let's have both versions. I'll update the draft to re-add rsa-sha2-256, an= d >make that recommended, and -512 optional. Thanks! Peter. = --=-zSk8JTppaAJBkxs3hRU8 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Apologies for my ignorance about the embedded situ= ation. That's interesting to know.

I was wondering how much SSH ther= e is on embedded devices. I'm glad to hear you have that covered. :-)
I understand SHA-2 512 won't fit into P-256. It does fit into RSA, though= , and I was figuring it would not be a problem for applications to support = both hash types.

No problem if it's impractical, though. I appreciat= e the information!

I'll prepare new stuff hopefully tomorrow.

----- Original Message -----
From: Peter Gutmann
Sent: Friday, = November 6, 2015 18:51
To: denis bider
Cc: ietf-ssh@netbsd.org
S= ubject: RE: New version of rsa-sha2-512 draft posted: no more DSA

de= nis bider <ietf-ssh3@denisbider.com> writes:

>From my persp= ective, SHA-2 512 seems like the clear winner in the RSA
>situation, = due to 64-bit CPUs being destined for ubiquity (already ubiquitous
>o= n desktops, a few years away on mobile),

... and decades away on em= bedded.  Most of my users are running SSH on
embedded platforms, fo= r which the presence of 64-bit is close to zero, and no
plan to move to = that.  I probably have more SSH running on 16-bit embedded
than 64-= bit embedded.

>why not have a larger hash output at no additional= cost (it's embedded in the
>signature, anyway).

Not if you're= using P-256 rather than RSA.  Only SHA-256 will work with P-256
wh= ich (again from the Mozilla discussion) is the most widely-used parameterset, with P-521 (needed for -512) being barely used:

  lots o= f products can (and, it seems, are planning to, or already are)
  o= mitting support for P-521.
    (Comment from https://mozi= llians.org/en-US/u/briansmith/)

(You can truncate -512 to make it wo= rk with P-256, but I wouldn't want to take
any bets on how well-supporte= d that will be in practice).

>However, if there are platforms whe= re availability is a problem, then okay,
>let's have both versions. I= 'll update the draft to re-add rsa-sha2-256, and
>make that recommend= ed, and -512 optional.

Thanks!

Peter.

= --=-zSk8JTppaAJBkxs3hRU8-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Nov 7 01:31:34 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7AD21B2E95 for ; Sat, 7 Nov 2015 01:31:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.909 X-Spam-Level: X-Spam-Status: No, score=-3.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 FGTeVsvwQ6P5 for ; Sat, 7 Nov 2015 01:31:32 -0800 (PST) Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 815A21B2E5D for ; Sat, 7 Nov 2015 01:31:32 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 08FF114A2E1; Sat, 7 Nov 2015 09:31:32 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id A0E6614A20E; Sat, 7 Nov 2015 09:31:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 6216414A1EC for ; Sat, 7 Nov 2015 03:33:17 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id s82DMtDsxKgD for ; Sat, 7 Nov 2015 03:33:16 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 391C714A1EB for ; Sat, 7 Nov 2015 03:33:16 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for nisse@lysator.liu.se; Sat, 7 Nov 2015 03:33:14 +0000 Date: Sat, 7 Nov 2015 03:33:14 +0000 Subject: DH group exchange (Re: SSH key algorithm updates) X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <1990286542-756@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: =?UTF-8?q?Niels_M=C3=B6ller?= , Jeffrey Hutzelman Cc: "Mark D. Baushke" , ietf-ssh@NetBSD.org, stephen.farrell@cs.tcd.ie, jon@siliconcircus.com Content-Type: multipart/alternative; boundary="=-1IF1pMIhT2ifq7HRhxTs" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-1IF1pMIhT2ifq7HRhxTs Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Some info on DH group exchange that one might find useful: - Our SSH Server does not generate groups. It just gives the client group14= , or else group1 if client=E2=80=99s max size is below group14. - Our SSH Client cannot reliably digest broken groups generated by most imp= lementations that actually generate groups on the fly. The Client (and Server, but this is not a problem in the Server) uses a FIP= S-compliant crypto provider (Crypto++ 5.3.0) which performs DH parameter va= lidation that cannot be disabled. This validation fails on DH parameters wi= th groups generated by most server implementations (including but not limit= ed to OpenSSH). It is possible to connect, but with something like 50% chan= ce of failure. Since we cannot disable the DH parameter validation without compromising th= e FIPS module, the Client de-prioritizes DH-gex methods in favor of any oth= er enabled key exchange method (by default ecdh, dh-group14). So, yes. From our point of view: > I was thinking of the receiver of the group list, > it has to be prepared to handle any group, > and make an intelligent choice. My gut > feeling is that there may be some subtleties there. ... there are indeed such "subtleties". :) It is a fairly substantial problem that most dynamically generated groups a= ren't usable with our FIPS module. ----- Original Message ----- From: Niels "M=C3=B6ller"=20 Sent: Friday, November 6, 2015 00:50 To: Jeffrey Hutzelman=20 Cc: Mark D. Baushke ; denis bider ; ietf-ssh@NetBSD.org ; stephen.farrell@c= s.tcd.ie ; jon@siliconcircus.com=20 Subject: Re: SSH key algorithm updates Jeffrey Hutzelman writes: > On Fri, 2015-11-06 at 06:16 +0100, Niels M=C3=B6ller wrote: [about hmac-sha1] > Your understanding matches mine.=C2=A0 However, it's still only a 160-bit > hash, and eventually that just stops being strong enough.=C2=A0 I'd like = to > have something stronger implemented and reasonably widely deployed > before then. Reasonable. We need to specify a new REQUIRED algorithm. Demoting HMAC-SHA1 to recommended lets implementations drop support in due time without formally departing from the standard. It would kind-of make sense to specify a flag day "algothithm X is REQUIRED until date Y, after which is is only RECOMMENDED", but not worth the effort to formalize. > SSH's 3des-cbc is three-key EDE 3DES.=C2=A0 It has an effective key lengt= h of > 112 bits, and so is weaker than AES128. But the "effective key bits" attack is a time/memory-tradeoff which requires a huge table, right? So in practice I'm not sure a brute force attack on 3DES really can be expected to be 16 times faster than a brute force attack on aes128. > It's also a CBC mode and AFAIK has the same problems as all of SSH's > other CBC-mode ciphers. Right, reprecating CBC makes sense. What's the status of 3des-ctr mode? Not at all as widely deployed as 3des-cbc, I imagine. > Group exchange doesn't have to mean live, dynamic group generation.=C2=A0= It > can work fine with a set of fixed groups, either manually configured or > compiled in. =C2=A0 Hmm. I was thinking of the receiver of the group list, it has to be prepared to handle any group, and make an intelligent choice. My gut feeling is that there may be some subtleties there. But maybe there's no issue to trust the server and just choose the largest group you think you can afford to compute with. > I'd have to go back and look, but I think the sense of the > group at the time was that there was no reason to define more variations > with the group baked into the algorithm names. I can see that argument. Perhaps we shouldn't get into that now, but I could see scenarious where client might have a preference like =C2=A0 1. Large Z_p group (preferred option) =C2=A0 2. curve25519=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (acceptable) =C2=A0 3. Small Z_p group (not acceptable) Then negotiation fails in the case that they agree on group exchange, but the server offers only small Z_p groups. While with named groups, they might have agreed to use curve25519. Feel free to ignore this discussion if you find in untimely or distracting. There's a spec for it and noone on the list have raised any serious security concerns. >> Is that related to the (now expireed, I think) draft I and Simon wrote >> some time ago? I'm not following the cfrg work. > > I'm not sure.=C2=A0 It's only a month old, and does have Simon's name on = it. Hmm. It looks like like it's based on our earlier version. I think the pyth= on reference implementation of ed25519 is the same. Nice. Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.= --=-1IF1pMIhT2ifq7HRhxTs Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Some info on DH group exchange that one might find= useful:

- Our SSH Server does not generate groups. It just gives th= e client group14, or else group1 if client=E2=80=99s max size is below grou= p14.

- Our SSH Client cannot reliably digest broken groups generated= by most implementations that actually generate groups on the fly.

T= he Client (and Server, but this is not a problem in the Server) uses a FIPS= -compliant crypto provider (Crypto++ 5.3.0) which performs DH parameter val= idation that cannot be disabled. This validation fails on DH parameters wit= h groups generated by most server implementations (including but not limite= d to OpenSSH). It is possible to connect, but with something like 50% chanc= e of failure.

Since we cannot disable the DH parameter validation wi= thout compromising the FIPS module, the Client de-prioritizes DH-gex method= s in favor of any other enabled key exchange method (by default ecdh, dh-gr= oup14).

So, yes. From our point of view:

> I was thinking= of the receiver of the group list,
> it has to be prepared to handle= any group,
> and make an intelligent choice. My gut
> feeling = is that there may be some subtleties there.

... there are indeed suc= h "subtleties". :)

It is a fairly substantial problem that most dyna= mically generated groups aren't usable with our FIPS module.


---= -- Original Message -----
From: Niels "M=C3=B6ller"
Sent: Friday, No= vember 6, 2015 00:50
To: Jeffrey Hutzelman
Cc: Mark D. Baushke ; den= is bider ; ietf-ssh@NetBSD.org ; stephen.farrell@cs.tcd.ie ; jon@siliconcir= cus.com
Subject: Re: SSH key algorithm updates

Jeffrey Hutzelman= <jhutz@cmu.edu> writes:

> On Fri, 2015-11-06 at 06:16 +010= 0, Niels M=C3=B6ller wrote:

[about hmac-sha1]

> Your under= standing matches mine.  However, it's still only a 160-bit
> has= h, and eventually that just stops being strong enough.  I'd like to> have something stronger implemented and reasonably widely deployed> before then.

Reasonable. We need to specify a new REQUIRED alg= orithm. Demoting
HMAC-SHA1 to recommended lets implementations drop supp= ort in due time
without formally departing from the standard. It would k= ind-of make
sense to specify a flag day "algothithm X is REQUIRED until = date Y,
after which is is only RECOMMENDED", but not worth the effort to=
formalize.

> SSH's 3des-cbc is three-key EDE 3DES.  It h= as an effective key length of
> 112 bits, and so is weaker than AES12= 8.

But the "effective key bits" attack is a time/memory-tradeoff whi= ch
requires a huge table, right? So in practice I'm not sure a brute for= ce
attack on 3DES really can be expected to be 16 times faster than a br= ute
force attack on aes128.

> It's also a CBC mode and AFAIK h= as the same problems as all of SSH's
> other CBC-mode ciphers.
Right, reprecating CBC makes sense. What's the status of 3des-ctr mode?Not at all as widely deployed as 3des-cbc, I imagine.

> Group ex= change doesn't have to mean live, dynamic group generation.  It
>= ; can work fine with a set of fixed groups, either manually configured or> compiled in.  

Hmm. I was thinking of the receiver of th= e group list, it has to be
prepared to handle any group, and make an int= elligent choice. My gut
feeling is that there may be some subtleties the= re. But maybe there's no
issue to trust the server and just choose the l= argest group you think
you can afford to compute with.

> I'd h= ave to go back and look, but I think the sense of the
> group at the = time was that there was no reason to define more variations
> with th= e group baked into the algorithm names.

I can see that argument. Per= haps we shouldn't get into that now, but I
could see scenarious where cl= ient might have a preference like

  1. Large Z_p group (preferr= ed option)
  2. curve25519      (acceptabl= e)
  3. Small Z_p group (not acceptable)

Then negotiation fa= ils in the case that they agree on group exchange,
but the server offers= only small Z_p groups. While with named groups,
they might have agreed = to use curve25519.

Feel free to ignore this discussion if you find i= n untimely or
distracting. There's a spec for it and noone on the list h= ave raised any
serious security concerns.

>> Is that relate= d to the (now expireed, I think) draft I and Simon wrote
>> some t= ime ago? I'm not following the cfrg work.
>
> I'm not sure.&nbs= p; It's only a month old, and does have Simon's name on it.

Hmm. It = looks like like it's based on our earlier version. I think the python
re= ference implementation of ed25519 is the same. Nice.

Regards,
/Ni= els


--
Niels M=C3=B6ller. PGP-encrypted email is preferred. = Keyid C0B98E26.
Internet email is subject to wholesale government survei= llance.= --=-1IF1pMIhT2ifq7HRhxTs-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Nov 7 01:31:47 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F121B2E9F for ; Sat, 7 Nov 2015 01:31:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 S9u0MRLkqV6P for ; Sat, 7 Nov 2015 01:31:45 -0800 (PST) Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C43F11B2E5D for ; Sat, 7 Nov 2015 01:31:45 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 60B6514A204; Sat, 7 Nov 2015 09:31:45 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 081EF14A200; Sat, 7 Nov 2015 09:31:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id AE15B14A3AA for ; Fri, 6 Nov 2015 17:59:03 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id zCFYTTMsfTIX for ; Fri, 6 Nov 2015 17:59:02 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id D149214A3A5 for ; Fri, 6 Nov 2015 17:59:02 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for postbox@quendi.de; Fri, 6 Nov 2015 17:59:00 +0000 Date: Fri, 6 Nov 2015 17:59:00 +0000 Subject: Re: SSH key algorithm updates X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <1955912751-3064@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: Max Horn Cc: ietf-ssh@NetBSD.org Content-Type: multipart/alternative; boundary="=-avInWg/uR2pp+a3aQ7cR" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-avInWg/uR2pp+a3aQ7cR Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > Also, of course there are implementations missing (one notable > is Bitvise's; I started work on that, but had a hard time finding > reliable a source for what they actually support and what not). If you can run a Windows executable, you can simply download our stuff from= our website: https://www.bitvise.com/ Both the client and the server are free for use that is both personal and n= on-commercial. The client goes further than that, and is also free for indi= vidual use in organizations. The following is what a default SSH Server installation (latest version 6.4= 3) supports and enables at the moment. All algorithms listed are supported.= Only the "true" ones are enabled by default: > q algs.* With kex { =C2=A0 ecdhSecp256k1 true =C2=A0 ecdhNistp256 true =C2=A0 ecdhNistp384 true =C2=A0 ecdhNistp521 true =C2=A0 dhGexSha256 true =C2=A0 dhGexSha1 true =C2=A0 dhG1Sha1 false =C2=A0 dhG14Sha1 true =C2=A0 gssG1Sha1Krb5 false =C2=A0 gssG14Sha1Krb5 true =C2=A0 gssGexSha1Krb5 true } With encr { =C2=A0 aes256-ctr true =C2=A0 aes192-ctr true =C2=A0 aes128-ctr true =C2=A0 3des-ctr true =C2=A0 aes256-cbc false =C2=A0 aes192-cbc false =C2=A0 aes128-cbc false =C2=A0 3des-cbc false =C2=A0 none false } With mac { =C2=A0 hmac-sha2-256 true =C2=A0 hmac-sha1 true =C2=A0 hmac-md5 false =C2=A0 hmac-sha2-256-96 false =C2=A0 hmac-sha1-96 false =C2=A0 hmac-md5-96 false =C2=A0 none false } With cmpr { =C2=A0 zlib true =C2=A0 none true =C2=A0 delayCompression false } Supported host key algorithms are: ssh-rsa ssh-dss ecdsa-sha2 over secp256k1 ecdsa-sha2 over nistp256 ecdsa-sha2 over nistp384 ecdsa-sha2 over nistp521 Algorithms supported by our client mirror those in the server. denis ----- Original Message ----- From: Max Horn=20 Sent: Friday, November 6, 2015 03:08 To: ietf-ssh@NetBSD.org=20 Cc: Mark D. Baushke=20 Subject: Re: SSH key algorithm updates Hi there, just joined the list, but saw on the list archive that a few days ago, Mark D. Baushke wrote on this thread: > It would be useful to see what other protocols various SSH implementers > have been adding and see if there is a desire to move any of them into a > recommended or optional standard. As a matter of fact, I started such a page some time ago: =C2=A0 http://ssh-comparison.quendi.de/ =C2=A0 http://ssh-comparison.quendi.de/comparison.html I tried my best to make it accurate, but of course cannot exclude mistakes. Also, of course there are implementations missing (one notable is Bitvise's= ; I started work on that, but had a hard time finding reliable a source for what they actually support and what not). Anyway, issue reports and pull request (also with info on additional implementations) are most welcome: =C2=A0 https://github.com/fingolfin/ssh-comparison The comparison page shows for example that hmac-sha2-256 and hmac-sha2-512 support is quite good now; one notable SSH library not implementing it yet in a released version is libssh2, but they will have it in the next release (the code is in their repository already), which in turn should allow various clients based on it to support it. Another exception is lsh. Cheers, max = --=-avInWg/uR2pp+a3aQ7cR Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable > Also, of course there are implementations mis= sing (one notable
> is Bitvise's; I started work on that, but had a h= ard time finding
> reliable a source for what they actually support a= nd what not).

If you can run a Windows executable, you can simply do= wnload our stuff from our website:

https://www.bitvise.com/

B= oth the client and the server are free for use that is both personal and no= n-commercial. The client goes further than that, and is also free for indiv= idual use in organizations.

The following is what a default SSH Serv= er installation (latest version 6.43) supports and enables at the moment. A= ll algorithms listed are supported. Only the "true" ones are enabled by def= ault:

> q algs.*
With kex {
  ecdhSecp256k1 true
&n= bsp; ecdhNistp256 true
  ecdhNistp384 true
  ecdhNistp521 t= rue
  dhGexSha256 true
  dhGexSha1 true
  dhG1Sha1 = false
  dhG14Sha1 true
  gssG1Sha1Krb5 false
  gssG= 14Sha1Krb5 true
  gssGexSha1Krb5 true
}
With encr {
 = aes256-ctr true
  aes192-ctr true
  aes128-ctr true
&nb= sp; 3des-ctr true
  aes256-cbc false
  aes192-cbc false
=   aes128-cbc false
  3des-cbc false
  none false
}<= br>With mac {
  hmac-sha2-256 true
  hmac-sha1 true
&nbs= p; hmac-md5 false
  hmac-sha2-256-96 false
  hmac-sha1-96 f= alse
  hmac-md5-96 false
  none false
}
With cmpr {  zlib true
  none true
  delayCompression false
= }

Supported host key algorithms are:

ssh-rsa
ssh-dss
ec= dsa-sha2 over secp256k1
ecdsa-sha2 over nistp256
ecdsa-sha2 over nist= p384
ecdsa-sha2 over nistp521

Algorithms supported by our client = mirror those in the server.

denis


----- Original Message = -----
From: Max Horn
Sent: Friday, November 6, 2015 03:08
To: iet= f-ssh@NetBSD.org
Cc: Mark D. Baushke
Subject: Re: SSH key algorithm= updates

Hi there,

just joined the list, but saw on the list = archive that a few days ago,
Mark D. Baushke wrote on this thread:
> It would be useful to see what other protocols various SSH implement= ers
> have been adding and see if there is a desire to move any of th= em into a
> recommended or optional standard.

As a matter of f= act, I started such a page some time ago:

  http://ssh-comparis= on.quendi.de/
  http://ssh-comparison.quendi.de/comparison.html
=
I tried my best to make it accurate, but of course cannot exclude mista= kes.
Also, of course there are implementations missing (one notable is B= itvise's;
I started work on that, but had a hard time finding reliable a= source for
what they actually support and what not).

Anyway, iss= ue reports and pull request (also with info on additional
implementation= s) are most welcome:

  https://github.com/fingolfin/ssh-compari= son

The comparison page shows for example that hmac-sha2-256 and hma= c-sha2-512
support is quite good now; one notable SSH library not implem= enting it yet
in a released version is libssh2, but they will have it in= the next release
(the code is in their repository already), which in tu= rn should allow
various clients based on it to support it. Another excep= tion is lsh.


Cheers,
max

= --=-avInWg/uR2pp+a3aQ7cR-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Nov 7 01:32:07 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 536301B2EA2 for ; Sat, 7 Nov 2015 01:32:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 yJAvDr11rFoO for ; Sat, 7 Nov 2015 01:32:05 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A4741B2E9F for ; Sat, 7 Nov 2015 01:32:05 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id F36BC14A38C; Sat, 7 Nov 2015 09:32:04 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 9B24E14A383; Sat, 7 Nov 2015 09:32:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id C7CB314A38C for ; Sat, 7 Nov 2015 05:03:32 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id nss5am7xYb0L for ; Sat, 7 Nov 2015 05:03:32 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 38C6114A29D for ; Sat, 7 Nov 2015 05:03:32 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for jhutz@cmu.edu; Sat, 7 Nov 2015 05:03:30 +0000 Date: Sat, 7 Nov 2015 05:03:30 +0000 Subject: Re: DH group exchange (Re: SSH key algorithm updates) X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <1995820131-1900@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: Jeffrey Hutzelman Cc: =?UTF-8?q?NielsM=C3=B6ller?= , "Mark D. Baushke" , ietf-ssh@NetBSD.org, stephen.farrell@cs.tcd.ie, jon@siliconcircus.com Content-Type: multipart/alternative; boundary="=-AoGHZl1dj743Uw6tLIMg" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-AoGHZl1dj743Uw6tLIMg Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Half the time - or even more often - the parameters sent by the server fail= a pairwise consistency test that Crypto++ performs in FIPS mode. I believe these tests are required by FIPS to use the crypto parameters. I believe this has been recognized as a shortcoming of these dynamically ge= nerated groups, and has been deemed an acceptable level of risk because the= y are short-lived. The issue is that FIPS (probably correctly, given its intent to prevent sus= picious-looking crypto use) does not make this accommodation. ----- Original Message ----- From: Jeffrey Hutzelman=20 Sent: Friday, November 6, 2015 21:50 To: denis bider=20 Cc: jhutz@cmu.edu ; NielsM=C3=B6ller ; Mark D. Baushke ; ietf-ssh@NetBSD.or= g ; stephen.farrell@cs.tcd.ie ; jon@siliconcircus.com=20 Subject: Re: DH group exchange (Re: SSH key algorithm updates) On Sat, 2015-11-07 at 03:33 +0000, denis bider wrote: > It is a fairly substantial problem that most dynamically generated > groups aren't usable with our FIPS module. What's broken about the groups that don't work? = --=-AoGHZl1dj743Uw6tLIMg Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Half the time - or even more often - the parameter= s sent by the server fail a pairwise consistency test that Crypto++ perform= s in FIPS mode.

I believe these tests are required by FIPS to use th= e crypto parameters.

I believe this has been recognized as a shortco= ming of these dynamically generated groups, and has been deemed an acceptab= le level of risk because they are short-lived.

The issue is that FIP= S (probably correctly, given its intent to prevent suspicious-looking crypt= o use) does not make this accommodation.


----- Original Message = -----
From: Jeffrey Hutzelman
Sent: Friday, November 6, 2015 21:50To: denis bider
Cc: jhutz@cmu.edu ; NielsM=C3=B6ller ; Mark D. Baushk= e ; ietf-ssh@NetBSD.org ; stephen.farrell@cs.tcd.ie ; jon@siliconcircus.com=
Subject: Re: DH group exchange (Re: SSH key algorithm updates)

= On Sat, 2015-11-07 at 03:33 +0000, denis bider wrote:

> It is a f= airly substantial problem that most dynamically generated
> groups ar= en't usable with our FIPS module.

What's broken about the groups tha= t don't work?

= --=-AoGHZl1dj743Uw6tLIMg-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Nov 7 01:32:24 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B700C1B2EA2 for ; Sat, 7 Nov 2015 01:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ZeFQsXy2vFDD for ; Sat, 7 Nov 2015 01:32:23 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FF921B2E9F for ; Sat, 7 Nov 2015 01:32:23 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 126E714A39C; Sat, 7 Nov 2015 09:32:22 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id B015C14A383; Sat, 7 Nov 2015 09:32:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id F037E14A35E for ; Fri, 6 Nov 2015 17:34:48 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id jqoJHwHJeVR8 for ; Fri, 6 Nov 2015 17:34:48 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 3BEFD14A35B for ; Fri, 6 Nov 2015 17:34:48 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for ietf-ssh@netbsd.org; Fri, 6 Nov 2015 17:34:43 +0000 Date: Fri, 6 Nov 2015 17:34:43 +0000 Subject: The (de)merits ot making checks you don't have to make X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <1953858093-896@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: ietf-ssh@netbsd.org Cc: Peter Gutmann Content-Type: multipart/alternative; boundary="=-JotDSz3deSOLxiDtAOv1" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-JotDSz3deSOLxiDtAOv1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable It seems reasonable, but it's a misplacement of responsibility. A necessary= condition for the crypto layer to be correct is that it solves padding pro= blems 100%, without leakage. If the crypto layer has a problem where paddin= g problems leak onto the application layer, then the crypto layer has a pro= blem. There's just one situation where I can perceive these checks to be possibly= useful: if you're communicating with an implementation that has some kind = of bug, where it's going to write over its own buffers and allow an attacke= r to tweak the packet that is sent. But this is another misplacement of res= ponsibility. The responsibility to not be compromised lies with each progra= m; not with applications that communicate with it. And it doesn't cover all= compromise. Even if you make these checks, a fully compromised program wou= ld not trigger this type of check. So you're going out of your way to make sure things are "right" that are no= t your responsibility to make right, and you don't even have a way to know = your judgment was appropriate. It's like being a neighborhood busybody. Like people who are inclined to ca= ll the police on their neighbors for anything that looks "slightly fishy". = Except they don't have information, and it's always something innocent, and= their completely normal neighbors must repeatedly deal with police. And th= e police shoot the family dog for no reason. ----- Original Message ----- From: Peter Gutmann=20 Sent: Friday, November 6, 2015 03:02 To: denis bider ; ietf-ssh@netbsd.org=20 Subject: RE: OpenSSH sabotages protocol extension denis bider writes: >What possible purpose does this serve? It's perfectly sensible, if the spec requires that a packet be x, y, z then getting a packet containing x, y, z, extra garbage is at best a sign of dat= a corruption, at worst a sign of an active attack.=C2=A0 Rejecting the packet= and closing the connection is good practice, it makes it harder for an attacker= to use you as an oracle. For an example of what happens if you do ignore extra garbage at the end of your data, look at the padding attacks on PKCS #1... Peter. = --=-JotDSz3deSOLxiDtAOv1 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable It seems reasonable, but it's a misplacemen= t of responsibility. A necessary condition for the crypto layer to be corre= ct is that it solves padding problems 100%, without leakage. If the crypto = layer has a problem where padding problems leak onto the application layer,= then the crypto layer has a problem.

There's just one situation whe= re I can perceive these checks to be possibly useful: if you're comm= unicating with an implementation that has some kind of bug, where it's goin= g to write over its own buffers and allow an attacker to tweak the packet t= hat is sent. But this is another misplacement of responsibility. The respon= sibility to not be compromised lies with each program; not with appl= ications that communicate with it. And it doesn't cover all compromise. Eve= n if you make these checks, a fully compromised program would not trigge= r this type of check.

So you're going out of your way to make su= re things are "right" that are not your responsibility to make right, and y= ou don't even have a way to know your judgment was appropriate.

It's= like being a neighborhood busybody. Like people who are inclined to call t= he police on their neighbors for anything that looks "slightly fishy". Exce= pt they don't have information, and it's always something innocent, and the= ir completely normal neighbors must repeatedly deal with police. And the po= lice shoot the family dog for no reason.


----- Original Message = -----
From: Peter Gutmann
Sent: Friday, November 6, 2015 03:02
To= : denis bider ; ietf-ssh@netbsd.org
Subject: RE: OpenSSH sabotages prot= ocol extension

denis bider <ietf-ssh3@denisbider.com> writes:<= br>
>What possible purpose does this serve?

It's perfectly sen= sible, if the spec requires that a packet be x, y, z then
getting a pack= et containing x, y, z, extra garbage is at best a sign of data
corruptio= n, at worst a sign of an active attack.  Rejecting the packet and
c= losing the connection is good practice, it makes it harder for an attacker = to
use you as an oracle.

For an example of what happens if you do= ignore extra garbage at the end of
your data, look at the padding attac= ks on PKCS #1...

Peter.

= --=-JotDSz3deSOLxiDtAOv1-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Nov 7 01:32:36 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F27161B2EA2 for ; Sat, 7 Nov 2015 01:32:35 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, MIME error: error: part did not end with expected boundary; ; error: unexpected end of parts before epilogue X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 RAL6St2eBG62 for ; Sat, 7 Nov 2015 01:32:35 -0800 (PST) Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C5561B2E9F for ; Sat, 7 Nov 2015 01:32:33 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id BD57F14A3A3; Sat, 7 Nov 2015 09:32:32 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 6937414A39D; Sat, 7 Nov 2015 09:32:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 38FB914A38C for ; Fri, 6 Nov 2015 17:48:34 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id aDZDzM786hM6 for ; Fri, 6 Nov 2015 17:48:33 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 7E66C14A383 for ; Fri, 6 Nov 2015 17:48:33 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for pgut001@cs.auckland.ac.nz; Fri, 6 Nov 2015 17:48:26 +0000 Date: Fri, 6 Nov 2015 17:48:26 +0000 Subject: Re: New version of rsa-sha2-512 draft posted: no more DSA X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <1955072546-964@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: pgut001@cs.auckland.ac.nz Cc: ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-01p9+KRiw/TvdscES8zJ" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-01p9+KRiw/TvdscES8zJ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >From my perspective, SHA-2 512 seems like the clear winner in the RSA situa= tion, due to 64-bit CPUs being destined for ubiquity (already ubiquitous on= desktops, a few years away on mobile), and because - why not have a larger= hash output at no additional cost (it's embedded in the signature, anyway)= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Nov 7 01:52:13 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD72F1A86DF for ; Sat, 7 Nov 2015 01:52:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 N_Vyp4GjU0g5 for ; Sat, 7 Nov 2015 01:52:12 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1153C1A6F71 for ; Sat, 7 Nov 2015 01:52:12 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 485FA14A374; Sat, 7 Nov 2015 09:52:10 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id EBAF414A258 for ; Sat, 7 Nov 2015 09:52:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id V8p6pbdpT2Cn for ; Sat, 7 Nov 2015 09:52:04 +0000 (UTC) Received: from wp256.webpack.hosteurope.de (wp256.webpack.hosteurope.de [80.237.133.25]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id E2E0C14A257 for ; Sat, 7 Nov 2015 09:52:02 +0000 (UTC) Received: from ip-178-201-28-152.hsi08.unitymediagroup.de ([178.201.28.152] helo=zanovar.fritz.box); authenticated by wp256.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) id 1Zv0AB-0006u2-G8; Sat, 07 Nov 2015 10:51:59 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: SSH key algorithm updates From: Max Horn In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B58910@uxcn10-5.UoA.auckland.ac.nz> Date: Sat, 7 Nov 2015 10:51:59 +0100 Cc: denis bider , "ietf-ssh@NetBSD.org" Content-Transfer-Encoding: quoted-printable Message-Id: <6740AD14-6E81-49A5-AC2B-5CA8CF2F9F3D@quendi.de> References: <1955912751-3064@skroderider.denisbider.com> <4540741F-5789-49AA-B917-C822782D0881@quendi.de> <9A043F3CF02CD34C8E74AC1594475C73F4B58910@uxcn10-5.UoA.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.3096.5) X-bounce-key: webpack.hosteurope.de;postbox@quendi.de;1446889924;fb4218ad; Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list > On 07.11.2015, at 01:43, Peter Gutmann = wrote: >=20 > Max Horn writes: >=20 >> That's the rub, I can't really (don't have access to any Windows = machine). >=20 > 'strings ssh-app-name.exe'? Since the identifiers are text strings, = you don't > really need to run the binary. That's what I've been doing for multiple entries in my list already; but it has limitation, e.g. if the binaries are wrapped in = an installer, which contains only a compressed version of the actual executable. It also can lead to inaccurate results, and does not reveal which methods are enabled/disabled by default, etc. So in the end, initiating an actual connection seems like the best way = to do this. But I also take information from user manuals, config files, or direct info from vendors. Anyway, I will try to get a VM with Windows up and running for this. Of course this doesn't help with other platforms I don't have access to, such as Android, nor with solutions that don't offer any free downloads. >=20 >> One last question: Right now I only list these user auth methods: >=20 > 'none' is actually a bit of a problem since it's two different things, = an auth > mode and a mode-query-mechanism. I support 'none' as a query = mechanism since > some clients don't work without it, but not as an auth mechanism, and = I > suspect a number of other implementions listed as supporting 'none' = wouldn't > actually let you in without a password either. So perhaps this could = be split > into 'none-as-auth' and 'none-as-query'. I'd certainly be nervous = about using > an implementation that had 'none-as-auth' enabled by default. Yes, I was (and am) having precisely the same concern. But now I am wondering whether I should just omit the "none" entry completely. After = all, it either leaves an incorrect bad impression (if people read it as = meaning that a server supports "non-as-auth" by default), and otherwise is = useless, as it doesn't tell you whether it actually means it works as = "none-as-query". Also note that to find out which it is, I can't rely on running = "strings" on an executable, and would need to rig a test setup... I guess in the end it would be kind of cool if there was a big inter-op test setup which tries to match tons of SSH implementations with each other, and sees what actually works and what doesn't... But that would a HUGE effort (I certainly don't have the resources for it). Cheers, Max From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Nov 7 11:33:17 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9F81ACEFB for ; Sat, 7 Nov 2015 11:33:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 G31aV8F9d2-8 for ; Sat, 7 Nov 2015 11:33:15 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 744901ACE91 for ; Sat, 7 Nov 2015 11:33:15 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id A6DA014A3FE; Sat, 7 Nov 2015 19:33:12 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id D1B2114A3F9 for ; Sat, 7 Nov 2015 19:32:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id nQ2T4XeluoAW for ; Sat, 7 Nov 2015 19:32:58 +0000 (UTC) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0710.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc0c::710]) by mail.netbsd.org (Postfix) with ESMTP id 314B414A3F4 for ; Sat, 7 Nov 2015 19:32:57 +0000 (UTC) Received: from CO2PR05CA025.namprd05.prod.outlook.com (10.141.241.153) by BN1PR05MB059.namprd05.prod.outlook.com (10.255.202.149) with Microsoft SMTP Server (TLS) id 15.1.312.18; Sat, 7 Nov 2015 19:32:55 +0000 Received: from BN1BFFO11FD001.protection.gbl (2a01:111:f400:7c10::1:107) by CO2PR05CA025.outlook.office365.com (2a01:111:e400:1429::25) with Microsoft SMTP Server (TLS) id 15.1.318.15 via Frontend Transport; Sat, 7 Nov 2015 19:32:54 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=juniper.net; denisbider.com; dkim=none (message not signed) header.d=none;denisbider.com; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.17) by BN1BFFO11FD001.mail.protection.outlook.com (10.58.144.64) with Microsoft SMTP Server (TLS) id 15.1.325.5 via Frontend Transport; Sat, 7 Nov 2015 19:32:53 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 7 Nov 2015 11:32:52 -0800 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id tA7JWnD84610; Sat, 7 Nov 2015 11:32:50 -0800 (PST) (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 421891141B; Sat, 7 Nov 2015 11:32:49 -0800 (PST) To: Jeffrey Hutzelman CC: denis bider , Niels =?ISO-8859-1?Q?M=F6ller?= , , , Subject: Re: DH group exchange (Re: SSH key algorithm updates) In-Reply-To: <1446868237.5945.12.camel@destiny.pc.cs.cmu.edu> References: <1990286542-756@skroderider.denisbider.com> <1446868237.5945.12.camel@destiny.pc.cs.cmu.edu> Comments: In-reply-to: Jeffrey Hutzelman message dated "Fri, 06 Nov 2015 22:50:37 -0500." From: "Mark D. Baushke" X-Mailer: MH-E 8.5; nmh 1.2; GNU Emacs 24.3.1 X-Face: #8D_6URD2G%vC.hzU MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1;BN1BFFO11FD001;1:ImwYdDvRqAvuPOYDA1CV4l+pi/xR5HvK9/fdCtVGwe0KTn5a6Hz1pOigemBQaOw6OtmrNv7z/0/mGvCGE+ixoodxXprpEW+WMj6/pXdZR4He6F1/Nm/kdHebkaiGbx00KIJf2Dg7/IYNyUjhI2xfyNSBtjuSet8KWV3dzIHRRQx7R2inrpwWe+Oy8lN9aElqPHmP7U7rd+A+Gdg6ZixL7YT82YH7NIfIKu0rXxi6ULb2SUbHH1LQoPEwOK1ebt3OBadWwUN3AdgDgV0vmuHGBWDPR4oNu19myrDa8OyL/dfQhhH4zy+4NGOuzrbPVn/Tjl6KZ8SEPAbqVTLPNiIP3sqX4YagaLeHiNmU5P24YYoD1Jh0nvRLTFXBVz+XdDkFHzPpa+wmZ5qg3kpyUalUPA== X-Forefront-Antispam-Report: CIP:66.129.239.17;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(2980300002)(377424004)(24454002)(243025005)(189002)(199003)(50466002)(5007970100001)(2171001)(10710500006)(87936001)(50226001)(48376002)(117636001)(53416004)(92566002)(189998001)(110136002)(5001960100002)(97736004)(7110500001)(81156007)(76176999)(50986999)(76506005)(106466001)(105596002)(77096005)(19580395003)(69596002)(5003600100002)(19580405001)(86362001)(15975445007)(47776003)(5003940100001)(2420400006)(6806005)(2950100001)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:BN1PR05MB059;H:p-emfe01a-sac.jnpr.net;FPR:;SPF:SoftFail;PTR:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BN1PR05MB059;2:1u85FZB7fAJIyggEJ8zD3suchOMXNCRwO9NffYX1F0q9Ksg1e6KXZni/7cNJ9HLwimjUzP+Nhn7RoApEL/hKPpJMk7TJo9kKX+ktKrotW5og6RXZ6zzg3xHDCtYmmXpx6gAr3zVIaikojLuNfmTr7I89yWEc7SgHti/kRyFDoI4=;3:nmzw1lZwlfPXrh0mMLCPAtasjcQWJb0Hc5er5pD/VryPXhEXEVZU61skJFFkaSInUSlak6nCYiedlctwHjqvaCr3GqcH4hot8mbTkURwEtRZCo4ZxDWNMnFJxetlKkhsCwmjxP2luXEtkFudogAyEBkW2jC5RqFyyodfJngGtcbwwJX0jYo8oFqA069ollJbgD8T4HzUSxW7obNOpeCN2JSvrR9tVEIVwzaUTk4eF54=;25:xOLxptnKjaVhNqjn8jQg2q/M3zPEfdIzI7gwpnvAUTCkQRpmZ/u9gCy79YJ+PF+lJJpWE9+vyjiyUQUOUut9dI4sijMK8rhAhUEv5t0wUC6SB8q20H5lBsaPcoFbn6rCh4WTlYRZPP+TJUQgG2/NjdwIzkTwnc0NZw8CzIHnArWWYEfW0gjfoa5J9Wwt9tdnOukoxI0awTgqDZPSzRk6Dkl6FxcvO0psVTySwg72o0jBc6U8bMCMQNxebAQ3fTEpw5Oe3N11HbCrufejs8HUOg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB059; X-Microsoft-Exchange-Diagnostics: 1;BN1PR05MB059;20:7n6MQsXgIlsuORzkUJOYJgSb1MX4X2VBB1VmLh5YC6ZrGQJ+DjPzKQN6k6pEdAjZw/FAOVl+NmWBd/al4hl/SU6EVhf+jwBtBaVr0q1M+4+J+5frym0uP27qREnRN11PpEdK96v6lG/MGpWv3yBKHi3s0Mm78IPq1rVu1IlkI4rRdyn8fcqci6lvWMfwrBYENToXLhI3GZAU3qLGDYTfZ5qfEUxW/wY4Fqenu3Fa1mdf9lNWd6GSXBoZcYgiLgeouepr/Tn2idzo5VCRJScNi7jqAlUSTd+SHablcS8LTrp8B9XVzWrPGLfUtDNmGAuo2RFPy0guf8SaFDr2ZgvW2GPwL7Q0uVfPuz/KOTApSDd9R4O1gWa0x4HrCOEbyb7im7Z9JqPb3gCf2mrlNxslZHPCAySvTFoVUoEHLS5y8T4XgJNskVEGs8tJMvlT5eBnTpTMrwy7zB1Nl6YEFMhdOFkq9RmhEtYp2VPj9j2G/kIKs65jX06cozf4KNIhPI23;4:Hxq/TLbOPkg3CWPK4y30tUVCtTHPuKegnu9yDMLFsHCYTC35ga0+tcbGpL0JNqLAjj96pEWom2UB6CXVQHGz+hefWSKQoXPlpo+0DbnpKjRRTGrmIGojQ36GzHVP+hcDlriTulZoZ1j49uLVJmwzWcBdQohwyCfEZH4TGnvEMt5RplIBrokcaa2IGjruxUq2mfBABM2eRjHgJRkmZdOKrsmmeRmrjQnxOOXcb7EbtlmGK3aBOiAx2wlYmgTZSE29O5UVSqUtW6RLEntLiRXb/4tewQgo6CSrHpvDPFoFVT4SQKNw9y22BBP7oVQ+ryLWZAYDT2FHNEmfL2smzbI5s97oMLVv2kIoEWEN1hDuS5g4px8mtgLEALQz02IjuVrn X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(65766998875637); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001);SRVR:BN1PR05MB059;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB059; X-Forefront-PRVS: 0753EA505A X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;BN1PR05MB059;23:oIvwNRwOVkS2r46dWSaxNH0ucXK5QqlhFWvMAK7Tc9?= =?us-ascii?Q?wI/sag1BIaG6DhU+UXZJ4y9RN+NVFZkLB7VTpdPaej3dwUk+dYbpVLaDAeuD?= =?us-ascii?Q?PzLbUw7mkLFWqcLazEAOd2bgjc1/2PtCpBo+R1oZMO+6fbCrzlz9VD8fQ5ie?= =?us-ascii?Q?JOL7jPZRWVPHOVMoCcDEq10ij2lS095sWwweSjcNudMl8F+xOUuYpbYpp/Rz?= =?us-ascii?Q?j5VwGUSpWHjfPVPn1q5hJ8G3zXWGy+vZKDVF3affOf+6Qo/fYd6x64ZqDaUD?= =?us-ascii?Q?zz+U0ARSzgoJIPEodK4P9ZfDh1L41arraTVAuZXof4UYMiX6MW+hf54vflRN?= =?us-ascii?Q?OFCElJE0zozAltduMK9prejisQypj2aNxEg8iAnARlECjXqoaOWN3gw6R7WO?= =?us-ascii?Q?Fw17Q9Awec86RkshYRImiBu1Xl9/CphUsp/6yTSVsMQyxzBOLME74Ot5M9V0?= =?us-ascii?Q?NybEYzQuoYC7vQbEPvnp45sIQmap4Aeiw3d3D1PxJIYPwvdiGfmP3P+hIkqS?= =?us-ascii?Q?cR20CJyldIRWQOf0zu/MX1lnVxWYuwGLdkn1K4kkctEPm0hj7ih7D6EETt86?= =?us-ascii?Q?/g+DC843qVggxaEgrde74tMeTKWurmQGjZpwb99/dudYeMMLPhFHihZSUTTT?= =?us-ascii?Q?w9r9cDla0A0x5N3qnWwSpRSnOKGlKenxIReE9sz4pihU0wpzm4tsawk2CRYp?= =?us-ascii?Q?tJ/V4j91KTPDUwvgDRtf52xKT37yhCosTusissLkaQB2aNRO+QMSNa+it+v2?= =?us-ascii?Q?NiiFnLJINXlMRIDnKHr+c7BDzO5tnG7ZY9R8I6j/z7oDOjoMQgtVeeMOoF44?= =?us-ascii?Q?DGMsb/B2l3KsLD4I75ii1KheGJkXFfOimWC0WUzeVVyQhfwQeMb+P0fGu6fv?= =?us-ascii?Q?NHSXa5dXoGZCIvd1PuWRjNIx3TneJ0HsbIgV4CEzcgj62FwKjKVSVVsU369Q?= =?us-ascii?Q?5ZqZT18bG8lsvjSPVSJUQaOW0crFD2z2OQVb/vUJVL1weHazwXau1I6+V5SJ?= =?us-ascii?Q?EmIZsQ5JF48r1EQnoNf/AFFWvZL8KHmleK61qcq/2azv+mdJmmILaJa4ipcR?= =?us-ascii?Q?vxJhE4FeOs5+qoXIJeHgjr4RpL00Glc3jsIJWLh+qEjYn9JbCASgwgI4KXzH?= =?us-ascii?Q?U7AvR22u0=3D?= X-Microsoft-Exchange-Diagnostics: 1;BN1PR05MB059;5:eqyO6L89wehxmMKYSAc4vBFZxob7GITWS8/dsRkE7s7VJpypspFds6YbS1QBPVfGMem2gulRWJfOX/bvfHOXeYiXunxW8ZQwy5+vSoqD30Wz91kR3TRLUxgjr398myRpahdtGMReYBCyG1afW2b21A==;24:VHm5dBmlXFLLfPIcZYHcaRNJBcuIIb3Lav3lYclXw0gV4VdPVOBlRHldmlvkkVBUpSlcr2lrfLdbsQYqcR+ziGp+KKAd0hFZZQA53g1nBeQ=;20:zK8qHKoOHJhcsuGI0zmh/gvfTjrq6FjTdiYao+hbRul+8HbNpTkicaEFvp8YMUWAffnKZ7nbzPYdrpfVFjCkgA== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Nov 2015 19:32:53.4520 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.17];Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB059 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Jeffrey Hutzelman writes: > On Sat, 2015-11-07 at 03:33 +0000, denis bider wrote: > > > It is a fairly substantial problem that most dynamically generated > > groups aren't usable with our FIPS module. > > What's broken about the groups that don't work? The root case is the selection of the generator g in RFC 4419 is not sufficient to meet FIPS requirements. Start here: http://dx.doi.org/10.6028/NIST.SP.800-56Ar2 in section 5.6.2.3.1 "FFC Full Public-Key Validation Routine" you will see the tests that must be run during DH negotiation. Given the public value y sent from the client, validate 2 <= y <= p-2 and 1=y^q mod p. Of course, if a generator g has been selected incorrectly, then the public key y will not have the correct order and will therefore have the incorrect subgroup. So, we really need to take a look at how g is to be selected. This is specified in section 5.5.1.1 "FFC Domain Parameter Generation" which in turn specified "FFC Domain parameters shall be generated using a method specified in [FIPS 186]," and so we move to the latest FIPS 186 here: http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf Read section A.2 and note that a simple test for g is 2 <= g <= (p-1) g^q = 1 mod p The above two tests are mandatory in FIPS approved diffie-hellman. For non-FIPS users, a g which is not a valid generator means that the g^(ab) operation may be leaking one bit of the key (ab). You may wish to read the thread here: https://lists.mindrot.org/pipermail/openssh-unix-dev/2015-June/034060.html For our implementation of the /etc/moduli file, * find prime candidates p and q where q=(p-1)/2 * (because we are not sure if all RFC 4419 implementations will accept a generator g which is not either g=2 or g=5), check g=2 and g=5 using the steps in A.2.2 "Assurance of the Validity of the Generator g" - if g=2 or g=5 meets the PARTIALLY VALID test, then use Elliptic Curve Primality Proving to validate that both p and q are provably prime rather than just probably prime. (The use of ECPP is not required, but does not hurt.) else throw away p and q and start over. If we were guaranteed that all RFC 4419 implementations were able to accept any small prime for g, then we could walk up the list of primes until we found one that meets the PARTIALLY VALID test. However, that might also be very slow for some embedded ssh processors to implement, so choosing a g=2 is a good idea in any case. * an alternative would be to populate the /etc/moduli file for RFC 4419 with the MODP groups that are well constructed for generating q=(p-1)/2 So, adding RFC 3526 group15 (3072-bit MODP Group) and/or group16 (4096-bit MODP Group)... I do not see a good reason to add group17 (6144-bit MODP Group), but do it if you wish. Because the SSH server is the one who provides the g and p values, if it is using valid RFC 4419 moduli, the client will just work. If the SSH server is NOT FIPS-compliant, then if the SSH client implements the older test like A.2 where the provided g^x=1 (mod p) test which was in older of testing the 'random' value of x as being one that lets the g^(xy) = 1 (mod p) have a 50% of being wrong as the y^q mod p operation will return either 1 or p-1 and all of the p-1 values are wrong for FIPS. I hope that you find this information useful. ----------%<----------%<----------%<----------%<----------%<---------- From: "Roginsky, Allen" Subject: RE: Question on SP 800-56A rev2 The reason the y^q=1 (mod p) tests exists is to verify that y is in the required subgroup. In general, for any y mutually prime with p, it is true that y^(p-1) = 1 mod p. (The Fermat's Little Theorem.) Of course, when taking an arbitrary y into the power smaller than (p-1) the above equality does not necessarily hold. Suppose, however, that y is a generator of a cyclic subgroup that has q elements. This is subgroup of a larger group that has (p-1) elements; (p-1) is a multiple of q). The way y was selected was by taking an arbitrary number w into the power of (p-1)/q mod p (to be sure that it is in the subgroup of order q) and checking that the result is not 1 (mod p) (otherwise, it is in the right subgroup but is a unit element there - not a useful case.) Now, to test that y is in a subgroup of order q one has to check that y^q = 1 mod p. This would indeed hold if, as designed, y=w^(p-1)/q) mod p and therefore, y^q = [w^(p-1)/q]^q ] = w^(p-1) = 1 mod p. This is why this test (y^q = 1 mod p) exists in FIPS 186-4. \ My guess is that the value of 5 in your vendor's example, does not satisfy this test, so it is not a generator of a subgroup of order q. This value 5 could not have then been generated using w^[(p-1)q] (mod p) method. I do not know why some other standards appear to impose the additional requirements on g. To find a generator of the entire cyclic group of the order of (p-1) one usually has to make many tries, so some specific methods or restrictions may apply there, but any g not equal to 1 and such that g = w^[(p-1)q] (mod p) is good to be a generator of the smaller subgroup (size q), as far as I can tell. Please do not hesitate to call me or let your vendor call if they have any additional questions. Regards, Allen ----------%<----------%<----------%<----------%<----------%<---------- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Nov 7 18:23:00 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6DD1A8A90 for ; Sat, 7 Nov 2015 18:23:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 0hVd8Qy19f69 for ; Sat, 7 Nov 2015 18:22:58 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88DB61A8A8F for ; Sat, 7 Nov 2015 18:22:58 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id E217C14A4BF; Sun, 8 Nov 2015 02:22:55 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id CA16B14A4BD for ; Sun, 8 Nov 2015 02:22:52 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 2Uj0GW46AucC for ; Sun, 8 Nov 2015 02:22:52 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 6901A14A4BA for ; Sun, 8 Nov 2015 02:22:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1446949371; x=1478485371; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=swdNPxexjB4rURdNa9elCdN6VwQj4rtXYUSRJwud4Ko=; b=GoswBEwf6LIRS8T/tkcnzTWEcS7rL7ZDUajcftMMOk71qn8OVqBv1L8K nahjC0cAslvt+Wbo64TgWWL0e2n+apkHc509gs7gE2tyoJzsQeBnVHXmZ bO574JJ7p1d17oBEAfE6FaNkpitT0L7guLJnNhgOfmKHAIPwNfCGw2zGs 0PGa+Ok8OXrLfE/Zm6eH/S1Rh1ZtbekaxpV6ZMffBqfs7hjRxU2ueD7uo M8CARPhA0lq3mPIq+oUiu5tIUnDsA9VhZKmTiQhaysKDOpn770GDROHkE s9F5SAEAITfcwAL474m7D7dQEeumwoI7Uwn7N4zssyJQYpzoMA76HlAGr A==; X-IronPort-AV: E=Sophos;i="5.20,260,1444647600"; d="scan'208";a="53074316" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe4.UoA.auckland.ac.nz) ([130.216.4.171]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 08 Nov 2015 15:22:45 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Sun, 8 Nov 2015 15:22:45 +1300 From: Peter Gutmann To: denis bider , "ietf-ssh@netbsd.org" CC: Jeffrey Hutzelman , =?iso-8859-1?Q?NielsM=F6ller?= , "Mark D. Baushke" , "stephen.farrell@cs.tcd.ie" , "jon@siliconcircus.com" , "djm@mindrot.org" , Max Horn Subject: RE: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation Thread-Topic: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation Thread-Index: AQHRGctAhOUdZ9Oj4Ee4+Vj0CybFfp6RYxoL Date: Sun, 8 Nov 2015 02:22:44 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B59673@uxcn10-5.UoA.auckland.ac.nz> References: <2070897157-568@skroderider.denisbider.com> In-Reply-To: <2070897157-568@skroderider.denisbider.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list denis bider writes:=0A= =0A= >(1) I have uploaded a new version of the RSA SHA-2 draft:=0A= >=0A= >https://tools.ietf.org/html/draft-rsa-dsa-sha2-256-02=0A= =0A= Has anyone else implemented this? I've dropped in some quick partial suppo= rt=0A= for it, and I can't see why it wouldn't work transparently to replace the= =0A= existing form, but being able to test against someone else would be good.= =0A= =0A= Hmm, just saw an issue, I used "ssh-rsa-sha2..." instead of rsa-..., should= =0A= the new names also have the "ssh-" prefix to match existing usage? As I se= e=0A= it the name has to identify the format used, "ssh-", and the signature=0A= algorithm, "rsa-sha...", having just the latter makes it difficult to speci= fy=0A= other signature formats.=0A= =0A= Peter.=0A= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Nov 7 18:41:30 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16E761AD0B6 for ; Sat, 7 Nov 2015 18:41:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 AhHi9lNwCday for ; Sat, 7 Nov 2015 18:41:29 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EB271AD09A for ; Sat, 7 Nov 2015 18:41:29 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 5496214A44F; Sun, 8 Nov 2015 02:41:27 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id E81C714A44C for ; Sun, 8 Nov 2015 02:41:24 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id VZ4EY9xpkZ3e for ; Sun, 8 Nov 2015 02:41:24 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id CCB1514A444 for ; Sun, 8 Nov 2015 02:41:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1446950483; x=1478486483; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8C2os3+l18/HM0deXx66SeSUqfMN9K8i93tPhI2a1pE=; b=kzVnf6GSJ2C7I2PwNeA7AfcqrvLBNRJ7go2j7qmUDYuhZ3T8IGAMJOGz vKBbLHZ5NpWLmAKIjp9zRpLGhZTsQmOra0DQymiEUps6VB8zV1L5NCr4k cIfzQrhDld+w1AXPoZ7zJaHVVznrNhg7ffYaG9P/hKN8fDR6OafaeDTKj cltFvrF+aFCwYEXGdCqglh0BULUZsw4hj7woF2ahv8bO8cLQPgMly58fW GchCrFvfk91DzUF6BX+8icYygY8aSBXuIIPWoKvd6Gf3tjC+30YRtCLzF yfbN21Ve67WARqyC/+adCX9LJC+6lVBb564/wnF4/uEEuNERE5x7QOkaC g==; X-IronPort-AV: E=Sophos;i="5.20,260,1444647600"; d="scan'208";a="53075248" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 08 Nov 2015 15:41:22 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Sun, 8 Nov 2015 15:41:21 +1300 From: Peter Gutmann To: denis bider , "ietf-ssh@netbsd.org" CC: Jeffrey Hutzelman , =?iso-8859-1?Q?NielsM=F6ller?= , "Mark D. Baushke" , "stephen.farrell@cs.tcd.ie" , "jon@siliconcircus.com" , "djm@mindrot.org" , Max Horn Subject: RE: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation Thread-Topic: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation Thread-Index: AQHRGctAhOUdZ9Oj4Ee4+Vj0CybFfp6RYxoL//8qMgCAAAG1gIAA2vBr Date: Sun, 8 Nov 2015 02:41:20 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B596BB@uxcn10-5.UoA.auckland.ac.nz> References: <2072949147-896@skroderider.denisbider.com>,<2073638188-720@skroderider.denisbider.com> In-Reply-To: <2073638188-720@skroderider.denisbider.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list denis bider writes:=0A= =0A= >I can make available an experimental build of our SSH Server that will imp= lement these algorithms.=0A= >=0A= >Might need to give me a few hours.=0A= =0A= No hurry, I'm in the middle of hacking my code to pieces with a static sour= ce=0A= analyser, which could take days...=0A= =0A= Peter.=0A= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Nov 7 19:01:42 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1A21B2C04 for ; Sat, 7 Nov 2015 19:01:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_I_LETTER=-2, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 zYFV6V9CVM1D for ; Sat, 7 Nov 2015 19:01:41 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72BED1B2BEC for ; Sat, 7 Nov 2015 19:01:41 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id E65D114A37F; Sun, 8 Nov 2015 03:01:40 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 4288F14A2D2 for ; Sun, 8 Nov 2015 03:01:34 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id M7zJv07ekAJL for ; Sun, 8 Nov 2015 03:01:33 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 946B014A297 for ; Sun, 8 Nov 2015 03:01:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1446951693; x=1478487693; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ytZ8ueINzPLk4PDMNXNNb9nj3h9rpRKWqwNWuqZmkeg=; b=FGnxTKaRpEYGpLAl0PlXBWnAJmfASL3Cuh2aYATrqF3to8ZuaVgkJ4O1 fHGsvgOi3H0IpTTjS32zExh00PvlzT3Fr7yaeJoAxoaLbI6Di8hYik/ir Lun3n7dkxqDr6lQpvDnNHc/EfedGSBWTWKQ2+MGZ5S+H+I8uLpWmQd7T/ lNb94UXV3KrsNOlqIzsNYuTbHrkwZXX62Emf/g4PyI5VJp75CM7CwY4FJ mT/gxKrGWxwWPVJLAhHc16jdYW2OMpUJV45L5eAYmvzDN3HRZFLnphIfM elNOEnvDn9EkksghA5Rv0Ky2pk4ISl1bXJAVDfEwYqQgs8Ux4hUFdIIdt Q==; X-IronPort-AV: E=Sophos;i="5.20,260,1444647600"; d="scan'208";a="53076402" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 08 Nov 2015 16:01:31 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Sun, 8 Nov 2015 16:01:30 +1300 From: Peter Gutmann To: "Mark D. Baushke" , Jeffrey Hutzelman CC: denis bider , =?iso-8859-1?Q?Niels_M=F6ller?= , "ietf-ssh@NetBSD.org" , "stephen.farrell@cs.tcd.ie" , "jon@siliconcircus.com" Subject: RE: DH group exchange (Re: SSH key algorithm updates) Thread-Topic: DH group exchange (Re: SSH key algorithm updates) Thread-Index: AQHRGZMpddlrPutqm0y/LG2cXIPgg56RbqML Date: Sun, 8 Nov 2015 03:01:30 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B59709@uxcn10-5.UoA.auckland.ac.nz> References: <1990286542-756@skroderider.denisbider.com> <1446868237.5945.12.camel@destiny.pc.cs.cmu.edu>,<87436.1446924769@eng-mail01.juniper.net> In-Reply-To: <87436.1446924769@eng-mail01.juniper.net> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Mark D. Baushke writes:=0A= =0A= >The root case is the selection of the generator g in RFC 4419 is not=0A= >sufficient to meet FIPS requirements.=0A= =0A= Since RFC 4419 doesn't specify that q is included in the DH keying material= ,=0A= how do you even verify that it meets FIPS requirements? You can't actually= =0A= perform the FIPS tests on it because one of the parameters is missing. At= =0A= best you can do a test on... well, I'll post my source code comment:=0A= =0A= /* There is a further check that we can perform on p, but it's rather=0A= problematic because it only works for "safe" primes (primes of the form = p =3D=0A= 2p' + 1), and even then the checks depend on your religious inclinations= ,=0A= you've got the choice of either choosing a value where the generated DH= =0A= secret is limited to half the possible values, or one where you leak a b= it=0A= of the secret exponent. For example for g=3D2, if p is congruent to 11 = mod=0A= 24 then g is a quadratic nonresidue and the DH secret covers all possibl= e=0A= values but you leak the LSB of the secret exponent, but if p is congruen= t=0A= to 11 mod 23 then g is a quadratic residue and the DH secret only covers= =0A= half the possible values, but you don't leak any bits of the exponent (f= or=0A= OpenSSH's g=3D5, the values are 3 and 7).=0A= =0A= Once you go to more general values of g, or FIPS 186 primes which should= be=0A= easily verifiable but aren't because the PKCS #3 form discards the q val= ue=0A= that you need for the verification, there isn't really any checking that= =0A= can be done. The result is an ugly yes-biased test that can say=0A= "definitely safe" but only "possibly unsafe" (unless we're willing to de= al=0A= with lots of false positives).=0A= =0A= Because of this we only complain about problems in debug mode, if we=0A= enabled the rejection of unverifiable primes in release code we'd Get=0A= Letters... */=0A= switch( BN_get_word( g ) )=0A= {=0A= case 2:=0A= /* Oakley primes, congruent to 11 mod 24 =3D leaks LSB, =0A= congruent to 23 mod 24 =3D only covers half the possible =0A= values */=0A= modWord =3D BN_mod_word( p, 24 );=0A= assert_nofuzz( modWord =3D=3D 11 || modWord =3D=3D 23 );=0A= break;=0A= =0A= case 5:=0A= /* Used by OpenSSH for no known reason */=0A= modWord =3D BN_mod_word( p, 10 );=0A= assert_nofuzz( modWord =3D=3D 3 || modWord =3D=3D 7 );=0A= break;=0A= =0A= default:=0A= assert_nofuzz( DEBUG_WARN );=0A= }=0A= =0A= Oh, if anyone knows of any other commonly-used magic values I'm missing the= re,=0A= let me know.=0A= =0A= The real fix though would be to publish a quick update to '4419 specifying = a=0A= SSH_MSG_KEX_DH_GEX2_GROUP which includes the full set of DH parameters so t= hat=0A= the DH values could be fully verified.=0A= =0A= Peter.= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Nov 7 19:07:06 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01BAE1B2C9F for ; Sat, 7 Nov 2015 19:07:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 jyWTo6YT_LYc for ; Sat, 7 Nov 2015 19:07:01 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A14F1B2C94 for ; Sat, 7 Nov 2015 19:07:01 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 70DA914A4A0; Sun, 8 Nov 2015 03:06:59 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 1FEF114A421 for ; Sun, 8 Nov 2015 03:06:55 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id PXY_KOANBWc1 for ; Sun, 8 Nov 2015 03:06:54 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id E72B814A402 for ; Sun, 8 Nov 2015 03:06:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1446952015; x=1478488015; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Q2IprKLSbofPRrJmadQ5IEP6t79A4XHGkx0FUq0oKWg=; b=S841Ei9T7erfWUGJEpdrmkFA6FyQ0VQvsQMOAXeBLJnxCndVnGdXMN4s qnk0ZuM3JI4K7wkcaxvsuVjAprjpRuy++D8ejOr7whql+wNHR9fi25qkg 1qyU/0JviUTAqTd3CLwN/2jiFcUVpX8dpaGR2W/BLu27idmWOZ5fV3SaR Y9T4EGYlg1+iBt1evnNoXbYWtuZ73LfVlS73Ru5jUUkVjHYieYe789br4 /nzZEbGiP8CJtghw39DAi2Z8CyhIMYcQdv4WG+8aPMSkdYAOHG8byf48V 6gr0ZsUHFSyeNJA+iO/ICy6p5qIyjHxt+dIF/IG8Yle3Fn72NiRXY3nyc A==; X-IronPort-AV: E=Sophos;i="5.20,260,1444647600"; d="scan'208";a="53076898" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 08 Nov 2015 16:06:53 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Sun, 8 Nov 2015 16:06:52 +1300 From: Peter Gutmann To: Max Horn CC: denis bider , "ietf-ssh@NetBSD.org" Subject: RE: SSH key algorithm updates Thread-Topic: SSH key algorithm updates Thread-Index: AQHRGMPtBkokXX9VnEy0Wo+WRjNjMZ6PuN8L//+/joCAAfrgSw== Date: Sun, 8 Nov 2015 03:06:50 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B59718@uxcn10-5.UoA.auckland.ac.nz> References: <1955912751-3064@skroderider.denisbider.com> <4540741F-5789-49AA-B917-C822782D0881@quendi.de> <9A043F3CF02CD34C8E74AC1594475C73F4B58910@uxcn10-5.UoA.auckland.ac.nz>,<6740AD14-6E81-49A5-AC2B-5CA8CF2F9F3D@quendi.de> In-Reply-To: <6740AD14-6E81-49A5-AC2B-5CA8CF2F9F3D@quendi.de> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Max Horn writes:=0A= =0A= >That's what I've been doing for multiple entries in my list already; but i= t=0A= >has limitation, e.g. if the binaries are wrapped in an installer, which=0A= >contains only a compressed version of the actual executable. =0A= =0A= There are a bunch of universal extractors that will bypass the need to=0A= install, google "windows installer unpacker", so you don't need to install= =0A= random binaries on your system.=0A= =0A= >It also can lead to inaccurate results, and does not reveal which methods = are=0A= >enabled/disabled by default, etc.=0A= =0A= Yeah, that's a good point. OTOH you then need to do test runs on the app t= o=0A= try and probe what's present and what isn't. It depends on how much time y= ou=0A= want to sink into it :-).=0A= =0A= >Yes, I was (and am) having precisely the same concern. But now I am wonder= ing=0A= >whether I should just omit the "none" entry completely. After all, it eith= er=0A= >leaves an incorrect bad impression (if people read it as meaning that a=0A= >server supports "non-as-auth" by default), and otherwise is useless, as it= =0A= >doesn't tell you whether it actually means it works as "none-as-query".=0A= =0A= That sounds like a good idea. You more or less have to support none-as-que= ry=0A= in order to be able to communicate with some clients, so in theory every=0A= implementation would have to have support for "none". OTOH I would imagine= =0A= few implementations allow you in without authentication, so few would supor= t=0A= the other "none".=0A= =0A= Oh, and you'll need to add columns for the SHA-2 forms of signatures soon := -).=0A= =0A= Peter.=0A= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Nov 7 20:34:25 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD011B3177 for ; Sat, 7 Nov 2015 20:34:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 q0K3azfn2CQT for ; Sat, 7 Nov 2015 20:34:24 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45EC81B3179 for ; Sat, 7 Nov 2015 20:34:24 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id AE1CF14A4CF; Sun, 8 Nov 2015 04:34:20 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id AD06214A4CE for ; Sun, 8 Nov 2015 04:34:13 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id ubLs4XJkW3ug for ; Sun, 8 Nov 2015 04:34:12 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0774.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:774]) by mail.netbsd.org (Postfix) with ESMTP id 5E84E14A4CD for ; Sun, 8 Nov 2015 04:34:11 +0000 (UTC) Received: from SN1PR05CA0008.namprd05.prod.outlook.com (10.163.68.146) by BN1PR05MB058.namprd05.prod.outlook.com (10.255.202.145) with Microsoft SMTP Server (TLS) id 15.1.312.18; Sun, 8 Nov 2015 04:34:09 +0000 Received: from BN1BFFO11FD054.protection.gbl (2a01:111:f400:7c10::1:135) by SN1PR05CA0008.outlook.office365.com (2a01:111:e400:5197::18) with Microsoft SMTP Server (TLS) id 15.1.318.15 via Frontend Transport; Sun, 8 Nov 2015 04:34:08 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=juniper.net; cs.tcd.ie; dkim=none (message not signed) header.d=none;cs.tcd.ie; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.17) by BN1BFFO11FD054.mail.protection.outlook.com (10.58.145.9) with Microsoft SMTP Server (TLS) id 15.1.325.5 via Frontend Transport; Sun, 8 Nov 2015 04:34:08 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 7 Nov 2015 20:34:07 -0800 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id tA84Y5D19031; Sat, 7 Nov 2015 20:34:05 -0800 (PST) (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 91F6F1141B; Sat, 7 Nov 2015 20:34:04 -0800 (PST) To: Peter Gutmann CC: Jeffrey Hutzelman , denis bider , =?iso-8859-1?Q?Niels_M=F6ller?= , "ietf-ssh@NetBSD.org" , "stephen.farrell@cs.tcd.ie" , "jon@siliconcircus.com" Subject: Re: DH group exchange (Re: SSH key algorithm updates) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B59709@uxcn10-5.UoA.auckland.ac.nz> References: <1990286542-756@skroderider.denisbider.com> <1446868237.5945.12.camel@destiny.pc.cs.cmu.edu>,<87436.1446924769@eng-mail01.juniper.net> <9A043F3CF02CD34C8E74AC1594475C73F4B59709@uxcn10-5.UoA.auckland.ac.nz> Comments: In-reply-to: Peter Gutmann message dated "Sun, 08 Nov 2015 03:01:30 +0000." From: "Mark D. Baushke" X-Mailer: MH-E 8.5; nmh 1.2; GNU Emacs 24.3.1 X-Face: #8D_6URD2G%vC.hzU MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1;BN1BFFO11FD054;1:xKJOmXuYMPLr96kYTblSj8Was5guIGS6PGXHFflOX/F85Ujon3IRPGewfM5zQoLjS2hxf5FKgXVDkX8N4wTKEemS1jrAruTkaltXbYFnUvzF1k1SdL6FUw0bJKLsdePibeIvAAVlxUG7n+vWky1iENIUOg8kzatY1XpkkjjZaNYiwxSJW7qoYOxmZa8xe+E7Ingb+/dWX8pN4f7zxcLLZDzv0p1QAbafZTV63cR+UBp4N2uPPwx5ixsSkRRlZVSf+AkBMIyQFSQvuY+pScYNU3/FkPtIP6+BiIvh4IrzFIhu9ysfH8PxCQ+fvpNk5XY3VPEJzjwBZfGRBFNSmKGVAAw5rcBm3EmP/4A19/ZhPnLZdCBCSj32kP4G59GcV1ydM/1iOxQdHF/QooMZF19yag== X-Forefront-Antispam-Report: CIP:66.129.239.17;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(2980300002)(189002)(199003)(164054003)(86362001)(5003940100001)(189998001)(19580395003)(69596002)(97736004)(19580405001)(105596002)(92566002)(50226001)(47776003)(11100500001)(93886004)(6806005)(117636001)(81156007)(50466002)(5003600100002)(110136002)(5001960100002)(5007970100001)(48376002)(106466001)(2950100001)(87936001)(53416004)(76506005)(50986999)(76176999)(77096005)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:BN1PR05MB058;H:p-emfe01a-sac.jnpr.net;FPR:;SPF:SoftFail;PTR:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BN1PR05MB058;2:mDaqdwbjP71mQMUSxDRPZ0nX2FOpZ2nroRfO7xo3VYtzFKrp5uVHqyuVJfrxyO1OGuTrCDN4VOZgTO06g76oi+FTx0HDckr/Td0mzBd4s7SiqhvuQ7cLhnbRzvenh1wBeuS1M1IWS+sQYuyng5QKZ+Hr3+nfr24UZ+ygsjc+bgw=;3:BUopbQUdABeBW+PzyZoJP5RK7Nj57xxtQ2XSbrdyc9oJ3GED8QpJm9JPjHGT/7x7NO+CTRh3kBinUlJ4kEwF7LdFCaV7TQIQ1i8VovCeZm9glajD/2RHRhR4SPmuUQgjrBnfzIJl0dzqB7SyH7+R1NQv/VsE5HfLMhuJqC8p7OALwPpOGUJrTyR8srs5JLt0Rg/V5hd6tlD7GRe79gRxnp4rd/KPaie/rtPDt48a+Io=;25:XcR60nRsa4N3BwsKMfW4zUkY0qipuXRaIeBsdWm1khM02RO3Z7bx819i9gwyKdl31tTxbUdLGaOygqvhM+jwBtVk4A70Y9cbC+2AJMA4C2eQs+jf2hJYL6r/ZNp3Vj8jlTZIPubxI/iAq8HBnHCvFk74ppOpGbuWn8BWFFF68BLyZVRANZCdqLfZTHJltA59huxJ5xzWL2W10zYVbSTrzMpzkmAiwBmQhNKG48ZadRywR8IT67/Fkhs2UZETBzHKa0lNbthbTwYMr+uL1u2ZsQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB058; X-Microsoft-Exchange-Diagnostics: 1;BN1PR05MB058;20:+vvW5fHD42eFK4jxOs9QoUkDOOUSz4g3rVa3SRt00HXabWtp5JD/M21ZcVSs/5QvLWbCQaPM2VB1VR9hU8MOy4clFDasBiCJnrNOebecFyrg0q+8VMtgsBd6o/hgzx47PHXoxdJ3uuWxzOBGSC1je6CYDhlI1l9LkNk1GGKT9gPauD5uOJ/SIlfke6A1ZUZ1mSt+LHXB5ki7FTS6ZiQJew/FPB/PTbMbnQBqB7mYk2YLw4rpcDht0WDLGUj+ORP69Q1a93HVaE60t3tPJYDNgONE+6YKTzs8XxLNDUsK2T6V2IYJrzEzOcdatQd72gBRDNyTvOinXTbhXDH0YCGsXX8aflthLNS2dTIBPZ/37ad7XaTIShfD7LGN01CiVU3M5C1RCWlKAyuCn/6z2/NBS3+hvSXtG1MDJd2JNKR5YKDNDnw5wn0bNWrqp3+vGY2k2dZvZFP+ALJHhHba7EkeYwoCGaa4LaP2T2QvUlMhUac1001OfCzNROgdDuKst3OM;4:pESWJWunNLIWMf8ubI3F3fvWMgl26zKaIlektXjeHvLlZ62PqxbdY/BUvNoTVAxp9z3wK4L43rwHGt+ESzsv5RhYnVDqFxzBmiRs+i2iT+RvXHg+oNYBXSPKjlbIaMuRgyJWcoOXUo0SPly0CWBQ+jzUvlEDkQs3g2A2I+nU64Ew7PyNFlZXRH0GsG76VH2cgkgKgTXCBEgKGDibLA2PCO8AcqpD5KJFl7nJIRbXTN4HSgD88jxsZJi9LCtOcV64P5W9eEOYCtvim1HVECCwCVigpEMYhuwMZ4yJQhz/des864SczYrCfFjQBGEfHwAblNUcS0XrWUjVMfSJwsAqYKUn4O0yYRjR7CRajxlVz4yUyyKBJsLzsGnrSX85xW7p X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001);SRVR:BN1PR05MB058;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB058; X-Forefront-PRVS: 0754F7E325 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;BN1PR05MB058;23:88ydHyhhtOrf/qYp3LKNp9096I5X67N6iShddzWECw?= =?us-ascii?Q?pZXyECjF758Q4UWFbyPWpS+mI56wZr3a2So7FgwrIT1hPavxbLVbzO6QgQdl?= =?us-ascii?Q?S6TVwSBa9AVEJ31UPqlPmTNzaLsok8xBlvdfq3pX5mG+G+xnfZCsK7R+Iqbz?= =?us-ascii?Q?FyHN4I9t2Awf1uwjKgxkluxoK2pKL3c6Mm4rJ+GZPes5XK7KfuNa5aXAKzlg?= =?us-ascii?Q?Yz9hFHMvSR9q2uyeis9Nwkll4+IgJlbv0cHFxd6rvd7SNITYDARijVbYGEkX?= =?us-ascii?Q?teftBHlzDS3ckZOGiYi5a9+q6zsQtIz4J4iYAjBdLp9LgnollsJjLjq6vdJ4?= =?us-ascii?Q?sS30qS5DSVU82CP01KozErLtlBGiEvMUy5OQFLaG9Sq6ToqiKph9CFbGJRjV?= =?us-ascii?Q?ViXRHDwhKmgw/OAlLNNnYNrWtzjzxru+cG/c2OuL165NVq6+WfbqXit5byzd?= =?us-ascii?Q?rdIYC2xarJCXBP3Gkq80QM9tFWE7ghUiTeUkLBX9tTwrG7tDDsGO4JJL8Oj5?= =?us-ascii?Q?tavhr3r1gySPCa9fwRbVkjZt0qCswiS4ej06OJDCnUikexLyCCQ2Fv5K8UjH?= =?us-ascii?Q?uCbpIltqdL5Hfh1NDW2GpXzGwyWI6tqfC4xPr+/AVQTbAUMFx0cTn72UMco/?= =?us-ascii?Q?c5okkp5ld4qZVK+DPF9P42Naoqw+oQyGbKlXhVNnHKHUl2laeM62xvBvDHAk?= =?us-ascii?Q?moE5B08zTB7LFyx7ZSgKPeQFUMktCW75WDCVi6duLL17Xm/ht028+lehVJhv?= =?us-ascii?Q?B5m9ubpvnkj8KzZZLjCag6ZiTtde7xJjdzm7VvmI19oF4xgjGrn9v2kJYHqX?= =?us-ascii?Q?W1YZAYnqmYtTi1tJ+c+aEWog84K9dMO3WAhc/moJ1IeSU0Lk3vQVOojjDgzM?= =?us-ascii?Q?S/IcC57NC89siyhAtgF7VzkunklWe53lLANQpXVB0wBOXjp085ARMAT28xY6?= =?us-ascii?Q?hwsYe5bXXTgCUuIQts+oGw7AZdPEtO674IE7z1YLLkf/GTeu6WiZztiGS4kj?= =?us-ascii?Q?E=3D?= X-Microsoft-Exchange-Diagnostics: 1;BN1PR05MB058;5:MqjAMWdjkajbxWtBsnj9Voi8s5PeWmoGbAkVZ76WFQnV3TM3wzxKBIzT5oRq1oL6go/9TTIHTgyAzj5JMLSJM0ccTKG8seC5rmC/mNImiVGnUH0Sxe/fjYGEDqDt94hD1Fy+97cVaSvWUNiO6L4m+w==;24:BAWbSt72zFfae+3XRPX+t0plcA1f2p+yRvSGJjvUGMAmxSAzWttQsxagEQsz4CVi0g/6srGUph4OYTqavLfLdrmCgHixle6pn8z/9ujgVRo=;20:9THvsjZjnyE0MT1J6kVQfrahNfHshv29VJQSXFX4gbEb75bVOivtf6qVKwf0h6stmTYdQg3G8chhCvmjPK0ing== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Nov 2015 04:34:08.0800 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.17];Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB058 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Peter Gutmann writes: > Mark D. Baushke writes: > > >The root case is the selection of the generator g in RFC 4419 is not > >sufficient to meet FIPS requirements. > > Since RFC 4419 doesn't specify that q is included in the DH keying material, > how do you even verify that it meets FIPS requirements? Perhaps I am misreading RFC 4419... | 3. Diffie-Hellman Group and Key Exchange | | The server keeps a list of safe primes and corresponding generators | that it can select from. A prime p is safe if p = 2q + 1 and q is | prime. New primes can be generated in the background. | | The generator g should be chosen such that the order of the generated | subgroup does not factor into small primes; that is, with p = 2q + 1, | the order has to be either q or p - 1. If the order is p - 1, then | the exponents generate all possible public values, evenly distributed | throughout the range of the modulus p, without cycling through a | smaller subset. Such a generator is called a "primitive root" (which | is trivial to find when p is "safe"). | ... | 3. C generates a random number x, where 1 < x < (p-1)/2. It | computes e = g^x mod p, and sends "e" to S. To me, the term '(p-1)/2' implies that we are calculating a value for 'q' ... in other words, I thought that q was a Sophie Germain prime and an p was the safe prime. Otherwise, I would have expected us to worry about 1 < x < (p-1)/r for the case were p = qr + 1 ... and we have no way to make that calculation without knowning either q or r in the first place. > You can't actually perform the FIPS tests on it because one of the > parameters is missing. True, which also means that you would be unable to ensure that the random number x is within the proper range for DH which wants 'p = rq + 1' and '1 < x < q' NOT '1 < x < rq' ... so, if the math in RFC 4419 is using r=2, then we can calculae q as (p-1)/2 ... > Oh, if anyone knows of any other commonly-used magic values I'm > missing there, let me know. I would also like this information. > The real fix though would be to publish a quick update to '4419 > specifying a SSH_MSG_KEX_DH_GEX2_GROUP which includes the full set of > DH parameters so that the DH values could be fully verified. Sure. If you want to allow for things like group25 (RFC 5114), then having all of the group parameters g,p,q would make it possible. I would have no problems with that addition. So far, we have FIPS certified our system with ssh a number of times with RFC 4419 extensions being available, but assuming that q is derived from (p-1)/2. I still think that the update to RFC 4419 should deal with the selection of the parameters and runtime validation checks per FIPS 186 and NIST SP 800-56A. Thanks, -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Nov 8 00:16:57 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E001A8A9B for ; Sun, 8 Nov 2015 00:16:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 PzinjHczNMuw for ; Sun, 8 Nov 2015 00:16:55 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77B7A1A8A99 for ; Sun, 8 Nov 2015 00:16:55 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 190CB14A47A; Sun, 8 Nov 2015 08:16:53 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id E226A14A46D for ; Sun, 8 Nov 2015 08:16:48 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 88VDfsMFT3Ga for ; Sun, 8 Nov 2015 08:16:48 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 7BDB614A46B for ; Sun, 8 Nov 2015 08:16:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1446970607; x=1478506607; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=64voaqEm74+swmOfNi0gxoIyKeM/9FoieF1bWAL6gvY=; b=O6zhzdfVU5oe7a09cS8OfiQejT9wiJilBUNlLGNR1DMUBL4u4symVEfO CP+PGAnsjLPUTdIbFtpm7i3hGy1yxvWwvLbeR9A4sTGlKuFL52IIKtA38 +mRxKbXBPCTXhU5X0iS37ws4iFnLj9AIQ6M0yJoD6mp8d5cev6VB5rlgK kHj07zYHsVBU58prKux5OWGYH6smcJKECuS69x1hJMFhCCfBYuWZ6MeQx +CISCiY8njjUAz7n70rXIIhjIukWZvAsIP8mAlOVXc6De1UX22ba2X0vd QQahjvccGGJyno/p/n/XenXgFPrssFj0pzCKci2trtI05PsVRmRBGrKGw A==; X-IronPort-AV: E=Sophos;i="5.20,261,1444647600"; d="scan'208";a="53092914" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe1.UoA.auckland.ac.nz) ([130.216.4.112]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 08 Nov 2015 21:16:41 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Sun, 8 Nov 2015 21:16:41 +1300 From: Peter Gutmann To: "Mark D. Baushke" CC: Jeffrey Hutzelman , denis bider , =?iso-8859-1?Q?Niels_M=F6ller?= , "ietf-ssh@NetBSD.org" , "stephen.farrell@cs.tcd.ie" , "jon@siliconcircus.com" Subject: RE: DH group exchange (Re: SSH key algorithm updates) Thread-Topic: DH group exchange (Re: SSH key algorithm updates) Thread-Index: AQHRGZMpddlrPutqm0y/LG2cXIPgg56RbqMLgAAbqO6AAD3b6w== Date: Sun, 8 Nov 2015 08:16:40 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B5993D@uxcn10-5.UoA.auckland.ac.nz> References: <1990286542-756@skroderider.denisbider.com> <1446868237.5945.12.camel@destiny.pc.cs.cmu.edu>,<87436.1446924769@eng-mail01.juniper.net> <9A043F3CF02CD34C8E74AC1594475C73F4B59709@uxcn10-5.UoA.auckland.ac.nz>,<49920.1446957244@eng-mail01.juniper.net> In-Reply-To: <49920.1446957244@eng-mail01.juniper.net> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list mdb@juniper.net writes:=0A= =0A= >To me, the term '(p-1)/2' implies that we are calculating a value for 'q' = ...=0A= >in other words, I thought that q was a Sophie Germain prime and an p was t= he=0A= >safe prime.=0A= =0A= Ah, yeah, it works if you're using safe primes and can assume that form. I= =0A= use Lim-Lee primes (p =3D 2q * ( prime[1] * ... prime[n] ) + 1 rather than = p =3D=0A= 2q + 1), for which an attempt to back-derive q from p will lead to funny=0A= results.=0A= =0A= >If you want to allow for things like group25 (RFC 5114), then having all o= f=0A= >the group parameters g,p,q would make it possible. I would have no problem= s=0A= >with that addition.=0A= =0A= That would be a considerable help, particularly given the recent attacks on= =0A= PKCS #3 DH values in TLS (SSH uses the same form, but so far hasn't been fo= und=0A= vulnerable).=0A= =0A= If no-one else has any objections, I'll work on a quick draft, all it'll do= is=0A= update '4419 to define a SSH_MSG_KEX_DH_GEX2_GROUP and a new identifier,=0A= "diffie-hellman-group-exchange2-sha256" (I assume there's no demand for a= =0A= sha-1 version any more...). The impact on an implemention should be no mor= e=0A= than a few lines of code changed, a new entry in an algorithm table for the= ID=0A= string and a call to read the extra q value.=0A= =0A= Peter.=0A= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Nov 8 01:42:43 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B36F1AD0A0 for ; Sun, 8 Nov 2015 01:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Yp9pfHGbUIfU for ; Sun, 8 Nov 2015 01:42:41 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4212B1AD09D for ; Sun, 8 Nov 2015 01:42:41 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 7F8FD14A4A9; Sun, 8 Nov 2015 09:42:38 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id F2B3D14A49A for ; Sun, 8 Nov 2015 09:42:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id vPJPGlwX3ypL for ; Sun, 8 Nov 2015 09:42:33 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id C3A7114A497 for ; Sun, 8 Nov 2015 09:42:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1446975752; x=1478511752; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=6GfB2KeXanMmOgp1Or6BY5bq7NDK7cuM7djBtPKtYP0=; b=HizTCnDxiqRFq/RZS6uDsfUdbX51iKgzlfMx2nf/xxoHbG/7Njj4gAVz cmw0XXRfsoU6UI/77Y/7fQV3lbyB3wszOmBGAngJPZchcUT5sqtGEsGgz wmKaR8pvXG+dF6lkhLesmGyf8q+lMzKwhcoodPhn89PPcm/P9Zd6lapP4 FafP+7PSismhFEeK/fDihxrC48MhkwlqTVjG+/Y62n/uscVIPD5XyQgXe qIr5cSBVpe86NV+twB4ZAErw28s/bUWYcesfjcovPn2rsh6ouLLJH8/G1 gF5f8lETuULCIzGIbjCRvnaxAoVP2LitlmX7vOD5aLyNDB9/BxYau9VBw A==; X-IronPort-AV: E=Sophos;i="5.20,261,1444647600"; d="scan'208";a="53097850" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe2.UoA.auckland.ac.nz) ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 08 Nov 2015 22:42:30 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Sun, 8 Nov 2015 22:42:30 +1300 From: Peter Gutmann To: denis bider , "Mark D. Baushke" CC: Jeffrey Hutzelman , =?iso-8859-1?Q?Niels_M=F6ller?= , "ietf-ssh@NetBSD.org" , "stephen.farrell@cs.tcd.ie" , "jon@siliconcircus.com" Subject: RE: DH group exchange (Re: SSH key algorithm updates) Thread-Topic: DH group exchange (Re: SSH key algorithm updates) Thread-Index: AQHRGgOcq51zpHEwR0KblpfSUHdPHJ6R3h7L Date: Sun, 8 Nov 2015 09:42:29 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B599ED@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4B5993D@uxcn10-5.UoA.auckland.ac.nz>,<2096379125-720@skroderider.denisbider.com> In-Reply-To: <2096379125-720@skroderider.denisbider.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list denis bider writes:=0A= =0A= >If this new draft could specify group generation such that:=0A= >=0A= >- Windows built-in crypto (CNG) running under FIPS mode=0A= >=0A= >- and possibly, but not as critically, the Crypto++ 5.3.0 FIPS-certified m= odule=0A= >=0A= >could reliably use parameters sent by servers that implement the new spec = -=0A= >that would be quite awesome.=0A= =0A= I don't know if you need to specify the exact generation method, only the= =0A= verification checks to perform, which are given in FIPS 186. The intent is= to=0A= create verifiable DH parameters, so the important thing is the verification= =0A= mechanism, not the generation one (both safe primes and Lim-Lee primes, for= =0A= example, will produce verifiable values). It would certainly make sense, i= f=0A= you're using { p, q, g } primes, to require that they be verified as per th= e=0A= FIPS 186 checks, since that's the point to using them.=0A= =0A= The annoying thing about this change is that it's going to take me about 20= x=0A= as long to do the spec describing it as it will to make the code changes,= =0A= sigh.=0A= =0A= One other thing that'd be good to have, based on the Logjam paper, is to=0A= specify some means of distinguishing g from q, since Logjam mentions that= =0A= there are implementations that confuse the two. Does anyone have problems= =0A= with requiring that g =3D ? This both makes the DH op much = more=0A= efficient, and makes it easy to quickly distinguish g from q without requir= ing=0A= complex bignum ops.=0A= =0A= Peter.= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Nov 8 07:35:57 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15EE21B30A5 for ; Sun, 8 Nov 2015 07:35:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 RgSJD5AkrC8v for ; Sun, 8 Nov 2015 07:35:55 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B598A1B30A3 for ; Sun, 8 Nov 2015 07:35:55 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id DE3C114A2AF; Sun, 8 Nov 2015 15:35:52 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 8013A14A298; Sun, 8 Nov 2015 15:35:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 9CF9D14A4D0 for ; Sun, 8 Nov 2015 03:10:00 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id MlDEmn2IOlx8 for ; Sun, 8 Nov 2015 03:10:00 +0000 (UTC) Received: from smtp02.srv.cs.cmu.edu (smtp02.srv.cs.cmu.edu [128.2.217.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id DDDD714A4CF for ; Sun, 8 Nov 2015 03:09:58 +0000 (UTC) Received-SPF: none (cmu.edu: No applicable sender policy available) receiver=smtp02.srv.cs.cmu.edu; identity=mailfrom; envelope-from="jhutz@cmu.edu"; helo="[192.168.202.98]"; client-ip=74.109.252.206 Received: from [192.168.202.98] (pool-74-109-252-206.pitbpa.fios.verizon.net [74.109.252.206]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id tA839POk018632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 7 Nov 2015 22:09:27 -0500 (EST) Message-ID: <1446952165.4540.1.camel@destiny.pc.cs.cmu.edu> Subject: Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation From: Jeffrey Hutzelman To: denis bider Cc: jhutz@cmu.edu, Peter Gutmann , "ietf-ssh@netbsd.org" , =?ISO-8859-1?Q?NielsM=F6ller?= , "Mark D. Baushke" , "stephen.farrell@cs.tcd.ie" , "jon@siliconcircus.com" , "djm@mindrot.org" , Max Horn Date: Sat, 07 Nov 2015 22:09:25 -0500 In-Reply-To: <2072949147-896@skroderider.denisbider.com> References: <2072949147-896@skroderider.denisbider.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.201 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Sun, 2015-11-08 at 02:30 +0000, denis bider wrote: > The "ecdsa-sha2-..." algorithm names (RFC 5656) do not use the "ssh-" prefix. > > Neither do the new formats in RFC 6187, i.e. "x509v3-rsa2048-sha256" and "x509v3-ecdsa-sha2-...". > > In my opinion, the "ssh-" prefix is superfluous. The context of SSH is > implied by where the names are used. It's superfluous except for "ssh-rsa" and "ssh-dsa", where it serves in various out-of-protocol contexts to distinguish between these and the corresponding SSHv1 key types. > The prefix would make sense if it were needed to disambiguate from > something. However, I am not aware of any proposal for SSH to do a > wholesale import of algorithm names from some other, SSH-unaware spec. > Moreover, if such names were imported, then THOSE names would be > prefixed with something, not the SSH native algorithm names. Right, agreed. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Nov 8 07:36:15 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC6C1B30A5 for ; Sun, 8 Nov 2015 07:36:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 krx-0tYibqew for ; Sun, 8 Nov 2015 07:36:13 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D8231B3094 for ; Sun, 8 Nov 2015 07:36:13 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 246B714A0E1; Sun, 8 Nov 2015 15:36:12 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id B016414A0E0; Sun, 8 Nov 2015 15:36:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 72FCF14A227 for ; Sun, 8 Nov 2015 09:11:09 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 2sR7Xr0xiY49 for ; Sun, 8 Nov 2015 09:11:08 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 633CF14A20D for ; Sun, 8 Nov 2015 09:11:08 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for pgut001@cs.auckland.ac.nz; Sun, 8 Nov 2015 09:10:53 +0000 Date: Sun, 8 Nov 2015 09:10:53 +0000 Subject: Experimental server for RSA SHA-2 X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <2096718084-720@skroderider.denisbider.com> X-Priority: 3 Importance: Normal In-Reply-To: <2073638188-720@skroderider.denisbider.com> MIME-Version: 1.0 From: denis bider To: Peter Gutmann , "ietf-ssh@netbsd.org" Cc: Jeffrey Hutzelman , =?UTF-8?q?NielsM=C3=B6ller?= , "Mark D. Baushke" , "stephen.farrell@cs.tcd.ie" , "jon@siliconcircus.com" , "djm@mindrot.org" , Max Horn Content-Type: multipart/alternative; boundary="=-efczcuIPJQNHLFGb+CeL" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-efczcuIPJQNHLFGb+CeL Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I have set up a server where we can test support for RSA SHA-2. You can connect to it at: experiment.bitvise.com:10712 It is set up to test the new RSA SHA-2 signature methods - rsa-sha2-256 and= rsa-sha2-512 - as currently defined here: https://tools.ietf.org/html/draft-rsa-dsa-sha2-256-02 You can test support for these new algorithms for both host and user authen= tication. To test host authentication, set the list of host key algorithms in your KE= XINIT to "rsa-sha2-256" or "rsa-sha2-512". You will need at least one of th= ese for successful key exchange - the server doesn't offer anything else. To test user authentication, log into the account "test" using "rsa-sha2-25= 6" or "rsa-sha2-512" as the signature method. You will need to use the foll= owing 2048-bit RSA private key for the server to accept the public key: -----BEGIN RSA PRIVATE KEY----- MIIEoQIBAAKCAQEAmKWhKT/t0vdBSIjDt+yz39yknfNalzGPDR2Hsw1s4PFbuHQU FPBdSL751K9EH9dpI7+npb6bbHIilPlwQXJBqhzRxs/XDHDMXTgIANO9s8D6ag8e Ed47HN7GAmb9uh4Raiffxh9yumM/kxxqjagFVuHfxLLHitfZGZ5OJOOS1TB79FTl wgn+om9LINkChQ14uacfoVCNKqIcRWoGqJ931q9CwOwut6pm6vXNcpMtL6NpaZLH tMkwOpfPyvuZ7ZKFRXzeH6YXwOdDzRqwr4iCyVERTdouKd9IDn6GNGeaPuCCfSg0 SgCNys1zexDuWXJm6hvJPOwM7XsAE8SzkWBQhQIBEQKCAQBH1XkEWlHMsJcxMU0L QjaHduQOGCqhgLvJ78djUZymFzo4rxiCUv640ldzJU08KSJrLQOZSqN+U9QJ3stq F6ZuK64DNKFvRCPvoeWmCUo2eO5QBx01lcF2/2w9XaST0eoT1odsSwjQLrSBdsi7 IeRlHv/kF+Vug7F1d6xNmEUZBwd8IcUNbdRUVTmlksbrHChZiahW4IFVY4TvKdNC V8i7IWtlDYQPQ2leBSa/JCYgHYAsp3PYd2uTfFnPqqggf9R0P/Sr+df7JPXkid8b uOTmK5HT/eSQzYW0FBreonn++YVAtxgE0adk6BPuEm4Z2MvHuK9vHWfo0oVwA6jn vgtRAoGBALpb9t+1ZnG612oR9tTtJK44BGAye4YWUcxOTPMK1RbXnFGdTnexmR+/ ILDMRvePJtSjW/qVeXUqwTGxWM+rJPugshM8iM3atqDNqxNu6kES5MYOB8ED0C87 NjtKNErDRDsuvRTYcN05ZRXOUzl6aRQvn7dSU+UB5WPs21/VG7a7AoGBANGwlkNQ Gim0YsaPCkbkTPTDXjm2N/Q+3NV65DKwz9Zxa+zs4P5logdECipQH2ScPeRnUvbz UfZ2bl9AWCT9XeYtwuL1ql7wghh5yqMltVtNT7VdVudyWly0nZHRGgw9ygwk5gxn Uiza+zNS1oroHKGyE50eeasc1kCY4YzP0MG/AoGBAI6Cj5wDMDjaLEINvMDxlIU5 5TqA9QwvL34dwl+AwRF3s8Xww4i0/J/OZEr2kJ8xO8/IN0cnAobGV4BacRdGo896 4ocuSn9M5gJ/KHhFwjHDJ2pG9t7kzGBadMPtc0g69/EFn6aHZV3gmJg0XcKKyNMz eiLGfGPURgEeiaOi9xNDAoGAGKtc+Nw/UDNW6i7yJnU2OunO2Zz3hiWDZGjPjX42 kbL9o2cph1dAPRcQQTaaSBJhomaCOyuvSiwM/CWwBFoLDAViONGbkrLiIP9FBCKN zoGQ6CkZSGfOZUJs4/p7iPg140+imAwnyQq0JCfdAUh71smn9F3wMj+gvE44pyeB +K0CgYAITZe+CF7vELMcFmoOLP8NeJ4kIPhDeY+jZGs7xLBf+whXqv/B/dzShtJa a+phP7znrIapd/ovO07GYlAgM6vjuriBTO2BLgPrE+kg9uFNgEFdg0qiTXdVBBUa X2LMxNHgbhlZ8/KntaGGVntq7I3BNIzHnPHzFZV1Fx0fGBqZCA=3D=3D -----END RSA PRIVATE KEY----- denis bider , 11/8/2015 2:36 AM: I can make available an experimental build of our SSH Server that will impl= ement these algorithms. Might need to give me a few hours. denis bider , 11/8/2015 2:24 AM: The "ecdsa-sha2-..." algorithm names (RFC 5656) do not use the "ssh-" prefi= x. Neither do the new formats in RFC 6187, i.e. "x509v3-rsa2048-sha256" and "x= 509v3-ecdsa-sha2-...". In my opinion, the "ssh-" prefix is superfluous. The context of SSH is impl= ied by where the names are used. The prefix would make sense if it were needed to disambiguate from somethin= g. However, I am not aware of any proposal for SSH to do a wholesale import= of algorithm names from some other, SSH-unaware spec. Moreover, if such na= mes were imported, then THOSE names would be prefixed with something, not t= he SSH native algorithm names. I think the use of "ssh-" prefixes for all kinds of names was a (small) mis= take in the original design. I think we can safely migrate away from it. Therefore, I have specified no "ssh-" prefix for these algorithms. Peter Gutmann , 11/8/2015 2:23 AM: denis bider writes: >(1) I have uploaded a new version of the RSA SHA-2 draft: > >https://tools.ietf.org/html/draft-rsa-dsa-sha2-256-02 Has anyone else implemented this? =C2=A0I've dropped in some quick partial = support for it, and I can't see why it wouldn't work transparently to replace the existing form, but being able to test against someone else would be good. Hmm, just saw an issue, I used "ssh-rsa-sha2..." instead of rsa-..., should the new names also have the "ssh-" prefix to match existing usage? =C2=A0As= I see it the name has to identify the format used, "ssh-", and the signature algorithm, "rsa-sha...", having just the latter makes it difficult to speci= fy other signature formats. Peter. = --=-efczcuIPJQNHLFGb+CeL Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable I have set up a server where we can test support f= or RSA SHA-2.

You can connect to it at:

experiment.bitvise.co= m:10712

It is set up to test the new RSA SHA-2 signature methods - r= sa-sha2-256 and rsa-sha2-512 - as currently defined here:

https://to= ols.ietf.org/html/draft-rsa-dsa-sha2-256-02

You can test support for= these new algorithms for both host and user authentication.

To test= host authentication, set the list of host key algorithms in your KEXINIT t= o "rsa-sha2-256" or "rsa-sha2-512". You will need at least one of these for= successful key exchange - the server doesn't offer anything else.

T= o test user authentication, log into the account "test" using "rsa-sha2-256= " or "rsa-sha2-512" as the signature method. You will need to use the follo= wing 2048-bit RSA private key for the server to accept the public key:
<= br>-----BEGIN RSA PRIVATE KEY-----
MIIEoQIBAAKCAQEAmKWhKT/t0vdBSIjDt+yz3= 9yknfNalzGPDR2Hsw1s4PFbuHQU
FPBdSL751K9EH9dpI7+npb6bbHIilPlwQXJBqhzRxs/X= DHDMXTgIANO9s8D6ag8e
Ed47HN7GAmb9uh4Raiffxh9yumM/kxxqjagFVuHfxLLHitfZGZ5= OJOOS1TB79FTl
wgn+om9LINkChQ14uacfoVCNKqIcRWoGqJ931q9CwOwut6pm6vXNcpMtL6= NpaZLH
tMkwOpfPyvuZ7ZKFRXzeH6YXwOdDzRqwr4iCyVERTdouKd9IDn6GNGeaPuCCfSg0<= br>SgCNys1zexDuWXJm6hvJPOwM7XsAE8SzkWBQhQIBEQKCAQBH1XkEWlHMsJcxMU0L
QjaH= duQOGCqhgLvJ78djUZymFzo4rxiCUv640ldzJU08KSJrLQOZSqN+U9QJ3stq
F6ZuK64DNKF= vRCPvoeWmCUo2eO5QBx01lcF2/2w9XaST0eoT1odsSwjQLrSBdsi7
IeRlHv/kF+Vug7F1d6= xNmEUZBwd8IcUNbdRUVTmlksbrHChZiahW4IFVY4TvKdNC
V8i7IWtlDYQPQ2leBSa/JCYgH= YAsp3PYd2uTfFnPqqggf9R0P/Sr+df7JPXkid8b
uOTmK5HT/eSQzYW0FBreonn++YVAtxgE= 0adk6BPuEm4Z2MvHuK9vHWfo0oVwA6jn
vgtRAoGBALpb9t+1ZnG612oR9tTtJK44BGAye4Y= WUcxOTPMK1RbXnFGdTnexmR+/
ILDMRvePJtSjW/qVeXUqwTGxWM+rJPugshM8iM3atqDNqx= Nu6kES5MYOB8ED0C87
NjtKNErDRDsuvRTYcN05ZRXOUzl6aRQvn7dSU+UB5WPs21/VG7a7A= oGBANGwlkNQ
Gim0YsaPCkbkTPTDXjm2N/Q+3NV65DKwz9Zxa+zs4P5logdECipQH2ScPeRn= Uvbz
UfZ2bl9AWCT9XeYtwuL1ql7wghh5yqMltVtNT7VdVudyWly0nZHRGgw9ygwk5gxnUiza+zNS1oroHKGyE50eeasc1kCY4YzP0MG/AoGBAI6Cj5wDMDjaLEINvMDxlIU5
5TqA9Q= wvL34dwl+AwRF3s8Xww4i0/J/OZEr2kJ8xO8/IN0cnAobGV4BacRdGo896
4ocuSn9M5gJ/K= HhFwjHDJ2pG9t7kzGBadMPtc0g69/EFn6aHZV3gmJg0XcKKyNMz
eiLGfGPURgEeiaOi9xND= AoGAGKtc+Nw/UDNW6i7yJnU2OunO2Zz3hiWDZGjPjX42
kbL9o2cph1dAPRcQQTaaSBJhoma= COyuvSiwM/CWwBFoLDAViONGbkrLiIP9FBCKN
zoGQ6CkZSGfOZUJs4/p7iPg140+imAwnyQ= q0JCfdAUh71smn9F3wMj+gvE44pyeB
+K0CgYAITZe+CF7vELMcFmoOLP8NeJ4kIPhDeY+jZ= Gs7xLBf+whXqv/B/dzShtJa
a+phP7znrIapd/ovO07GYlAgM6vjuriBTO2BLgPrE+kg9uFN= gEFdg0qiTXdVBBUa
X2LMxNHgbhlZ8/KntaGGVntq7I3BNIzHnPHzFZV1Fx0fGBqZCA=3D= =3D
-----END RSA PRIVATE KEY-----


denis bider <ietf-ssh3@denisbider.com> , 11/8/2015 = 2:36 AM:
I can make available an experimen= tal build of our SSH Server that will implement these algorithms.

Mi= ght need to give me a few hours.


denis bider <ietf-ssh3@denisbider.com> , 11/8/2015 2:24 AM:
<= div>The "ecdsa-sha2-..." algorithm names (RFC 5656) do not use the "ssh-" p= refix.

Neither do the new formats in RFC 6187, i.e. "x509v3-rsa2048-= sha256" and "x509v3-ecdsa-sha2-...".

In my opinion, the "ssh-" prefi= x is superfluous. The context of SSH is implied by where the names are used= .

The prefix would make sense if it were needed to disambiguate from= something. However, I am not aware of any proposal for SSH to do a wholesa= le import of algorithm names from some other, SSH-unaware spec. Moreover, i= f such names were imported, then THOSE names would be prefixed with somethi= ng, not the SSH native algorithm names.

I think the use of "ssh-" pr= efixes for all kinds of names was a (small) mistake in the original design.= I think we can safely migrate away from it.

Therefore, I have speci= fied no "ssh-" prefix for these algorithms.


Peter Gutmann<= /span> <pgut001@cs.auckland.ac.nz> , 11/8/2015 2:23 AM= :
denis bider <ietf-ssh3@denisbider.com> writes:
>(1) I have uploaded a new version of the RSA SHA-2 draft:
>=
>https://tools.ietf.org/html/draft-rsa-dsa-sha2-256-02

Has = anyone else implemented this?  I've dropped in some quick partial supp= ort
for it, and I can't see why it wouldn't work transparently to replac= e the
existing form, but being able to test against someone else would b= e good.

Hmm, just saw an issue, I used "ssh-rsa-sha2..." instead of = rsa-..., should
the new names also have the "ssh-" prefix to match exist= ing usage?  As I see
it the name has to identify the format used, "= ssh-", and the signature
algorithm, "rsa-sha...", having just the latter= makes it difficult to specify
other signature formats.

Peter.
= --=-efczcuIPJQNHLFGb+CeL-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Nov 8 07:36:27 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 760371B30B6 for ; Sun, 8 Nov 2015 07:36:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 431DbUwUo0Rh for ; Sun, 8 Nov 2015 07:36:26 -0800 (PST) Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BD931B30B0 for ; Sun, 8 Nov 2015 07:36:26 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 54C5114A120; Sun, 8 Nov 2015 15:36:25 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id EC2D614A11F; Sun, 8 Nov 2015 15:36:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id C8D3914A4DF for ; Sun, 8 Nov 2015 03:24:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id OgeCl9KIBcME for ; Sun, 8 Nov 2015 03:24:50 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 30F5014A450 for ; Sun, 8 Nov 2015 03:24:50 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for jhutz@cmu.edu; Sun, 8 Nov 2015 03:24:21 +0000 Date: Sun, 8 Nov 2015 03:24:21 +0000 Subject: Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <2076152815-3028@skroderider.denisbider.com> X-Priority: 3 Importance: Normal In-Reply-To: <1446952165.4540.1.camel@destiny.pc.cs.cmu.edu> MIME-Version: 1.0 From: denis bider To: Jeffrey Hutzelman Cc: Peter Gutmann , "ietf-ssh@netbsd.org" , =?UTF-8?q?NielsM=C3=B6ller?= , "Mark D. Baushke" , "stephen.farrell@cs.tcd.ie" , "jon@siliconcircus.com" , "djm@mindrot.org" , Max Horn Content-Type: multipart/alternative; boundary="=-W3tyMkOP613XE3wm+leP" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-W3tyMkOP613XE3wm+leP Content-Type: text/plain; charset="utf-8" Oh; thanks for the clarification. We never implemented SSHv1, so I haven't been exposed to that. The public key format used by the "rsa-sha2-XXXX" signature algorithms remains "ssh-rsa", so I think that distinction will remain, to the extent it is needed. Jeffrey Hutzelman , 11/8/2015 3:09 AM: On Sun, 2015-11-08 at 02:30 +0000, denis bider wrote: > The "ecdsa-sha2-..." algorithm names (RFC 5656) do not use the "ssh-" prefix. > > Neither do the new formats in RFC 6187, i.e. "x509v3-rsa2048-sha256" and "x509v3-ecdsa-sha2-...". > > In my opinion, the "ssh-" prefix is superfluous. The context of SSH is > implied by where the names are used. It's superfluous except for "ssh-rsa" and "ssh-dsa", where it serves in various out-of-protocol contexts to distinguish between these and the corresponding SSHv1 key types. > The prefix would make sense if it were needed to disambiguate from > something. However, I am not aware of any proposal for SSH to do a > wholesale import of algorithm names from some other, SSH-unaware spec. > Moreover, if such names were imported, then THOSE names would be > prefixed with something, not the SSH native algorithm names. Right, agreed. --=-W3tyMkOP613XE3wm+leP Content-Type: text/html; charset="utf-8" Oh; thanks for the clarification. We never implemented SSHv1, so I haven't been exposed to that.

The public key format used by the "rsa-sha2-XXXX" signature algorithms remains "ssh-rsa", so I think that distinction will remain, to the extent it is needed.


Jeffrey Hutzelman <jhutz@cmu.edu> , 11/8/2015 3:09 AM:
On Sun, 2015-11-08 at 02:30 +0000, denis bider wrote:
> The "ecdsa-sha2-..." algorithm names (RFC 5656) do not use the "ssh-" prefix.
>
> Neither do the new formats in RFC 6187, i.e. "x509v3-rsa2048-sha256" and "x509v3-ecdsa-sha2-...".
>
> In my opinion, the "ssh-" prefix is superfluous. The context of SSH is
> implied by where the names are used.

It's superfluous except for "ssh-rsa" and "ssh-dsa", where it serves in
various out-of-protocol contexts to distinguish between these and the
corresponding SSHv1 key types.



> The prefix would make sense if it were needed to disambiguate from
> something. However, I am not aware of any proposal for SSH to do a
> wholesale import of algorithm names from some other, SSH-unaware spec.
> Moreover, if such names were imported, then THOSE names would be
> prefixed with something, not the SSH native algorithm names.

Right, agreed.



--=-W3tyMkOP613XE3wm+leP-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Nov 8 07:36:39 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDBF1B30AB for ; Sun, 8 Nov 2015 07:36:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 oMFSh85XRPpB for ; Sun, 8 Nov 2015 07:36:37 -0800 (PST) Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B14D1B30B6 for ; Sun, 8 Nov 2015 07:36:37 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id DB82814A15C; Sun, 8 Nov 2015 15:36:36 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 7E95E14A156; Sun, 8 Nov 2015 15:36:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 9DAB414A4B1 for ; Sun, 8 Nov 2015 02:14:52 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id DK9R6cBkon87 for ; Sun, 8 Nov 2015 02:14:51 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id CAC8414A4AF for ; Sun, 8 Nov 2015 02:14:51 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for ietf-ssh@netbsd.org; Sun, 8 Nov 2015 02:14:47 +0000 Date: Sun, 8 Nov 2015 02:14:47 +0000 Subject: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <2070897157-568@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: ietf-ssh@netbsd.org Cc: Jeffrey Hutzelman , =?UTF-8?q?NielsM=C3=B6ller?= , "Mark D. Baushke" , stephen.farrell@cs.tcd.ie, jon@siliconcircus.com, djm@mindrot.org, Peter Gutmann , Max Horn Content-Type: multipart/alternative; boundary="=-3lmUV6PzGmKn6PWxIWqj" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-3lmUV6PzGmKn6PWxIWqj Content-Type: text/plain; charset="utf-8" (1) I have uploaded a new version of the RSA SHA-2 draft: https://tools.ietf.org/html/draft-rsa-dsa-sha2-256-02 Changes: - Based on feedback from Peter, now again includes rsa-sha2-256 as RECOMMENDED. - rsa-sha2-512 is now OPTIONAL. - The signature algorithm discovery method described in -01 is removed. Instead: (2) I have written a new draft for a general SSH Extension Negotiation mechanism: https://tools.ietf.org/html/draft-ssh-ext-info-00 Summary: * Special indicator names are included in KEXINIT to indicate support for this mechanism. I have looked at alternatives, but: - libssh handles the KEXINIT reserved field incorrectly (ignores actual value, so key exchange fails if it's not zero) - I'm hesitant to increase the protocol version number for a change that does not affect security, and does not touch KEXINIT, or affect key exchange - Fields cannot be added to existing packets without negotiation, due to reasons discussed previously (implementations take a restrictive view of packet formats) * If both parties indicate support for extension negotiation, the SERVICE_REQUEST and SERVICE_ACCEPT messages are replaced with a new message, SSH_MSG_EXT_INFO. This is more useful than SERVICE_REQUEST, and saves at least half a round-trip because the server sends EXT_INFO immediately, and does not wait for client. * The EXT_INFO message contains a list of name-value pairs, each identifying an extension and optional parameters. * Three extensions are defined upfront: server-sig-algs: Allows efficient discovery of signature algorithms supported by the server. For public key authentication, the client only needs to wait for the EXT_INFO message sent by the server. This should arrive half a round-trip sooner than SERVICE_ACCEPT. The client can then immediately send a public key authentication request with an appropriate signature method. client-req-ok: Allows clients to affirm that the server can send a global request (especially an unrecognized global request) without risking the client disconnecting. This should be supported by all clients. It is necessary so that servers can enable active keep-alive, which is not otherwise possible generally because some clients do disconnect when they receive a global request. no-handbrake: Peter ought to like this. :) A few years late, but this makes window size infinite for both directions in a channel, at the cost of restricting the session to one simultaneous channel. This should help file transfer applications for which the channel flow control in SSH is an impediment, rather than a feature. If you guys like this, then - if anyone else has an extension they would like to add, now might be the time to define them! denis --=-3lmUV6PzGmKn6PWxIWqj Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable (1) I have uploaded a new version of the RSA SHA-2= draft:

https://tools.ietf.org/html/draft-rsa-dsa-sha2-256-02
Changes:

- Based on feedback from Peter, now again includes rsa-sha= 2-256 as RECOMMENDED.
- rsa-sha2-512 is now OPTIONAL.
- The signature= algorithm discovery method described in -01 is removed. Instead:

(2) I have written a new draft for a general SSH Extension Negotiation me= chanism:

https://tools.ietf.org/html/draft-ssh-ext-info-00

Su= mmary:

* Special indicator names are included in KEXINIT to indicate= support for this mechanism.

I have looked at alternatives, but:
= - libssh handles the KEXINIT reserved field incorrectly (ignores actual val= ue, so key exchange fails if it's not zero)
- I'm hesitant to increase t= he protocol version number for a change that does not affect security, and = does not touch KEXINIT, or affect key exchange
- Fields cannot be added = to existing packets without negotiation, due to reasons discussed previousl= y (implementations take a restrictive view of packet formats)

* If b= oth parties indicate support for extension negotiation, the SERVICE_REQUEST= and SERVICE_ACCEPT messages are replaced with a new message, SSH_MSG_EXT_I= NFO.

This is more useful than SERVICE_REQUEST, and saves at least ha= lf a round-trip because the server sends EXT_INFO immediately, and does not= wait for client.

* The EXT_INFO message contains a list of name-val= ue pairs, each identifying an extension and optional parameters.

* T= hree extensions are defined upfront:

server-sig-algs: Allows = efficient discovery of signature algorithms supported by the server. For pu= blic key authentication, the client only needs to wait for the EXT_INFO mes= sage sent by the server. This should arrive half a round-trip sooner than S= ERVICE_ACCEPT. The client can then immediately send a public key authentica= tion request with an appropriate signature method.

client-req-ok:= Allows clients to affirm that the server can send a global request (es= pecially an unrecognized global request) without risking the client disconn= ecting. This should be supported by all clients. It is necessary so that se= rvers can enable active keep-alive, which is not otherwise possible general= ly because some clients do disconnect when they receive a global request.
no-handbrake: Peter ought to like this. :) A few years late, b= ut this makes window size infinite for both directions in a channel, at the= cost of restricting the session to one simultaneous channel. This should h= elp file transfer applications for which the channel flow control in SSH is= an impediment, rather than a feature.

If you guys like this, then -= if anyone else has an extension they would like to add, now might be the t= ime to define them!

denis

= --=-3lmUV6PzGmKn6PWxIWqj-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Nov 8 07:37:16 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 915DF1B30CE for ; Sun, 8 Nov 2015 07:37:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 jlODz_THEW2h for ; Sun, 8 Nov 2015 07:37:14 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3C571B30DD for ; Sun, 8 Nov 2015 07:37:14 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 849A814A27E; Sun, 8 Nov 2015 15:37:14 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 2133A14A156; Sun, 8 Nov 2015 15:37:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id E8DB114A347 for ; Sun, 8 Nov 2015 02:36:30 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 9B_2dC07RO8L for ; Sun, 8 Nov 2015 02:36:30 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 2D80F14A340 for ; Sun, 8 Nov 2015 02:36:30 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for pgut001@cs.auckland.ac.nz; Sun, 8 Nov 2015 02:36:25 +0000 Date: Sun, 8 Nov 2015 02:36:25 +0000 Subject: Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <2073638188-720@skroderider.denisbider.com> From: denis bider To: Peter Gutmann , "ietf-ssh@netbsd.org" Cc: Jeffrey Hutzelman , =?UTF-8?q?NielsM=C3=B6ller?= , "Mark D. Baushke" , "stephen.farrell@cs.tcd.ie" , "jon@siliconcircus.com" , "djm@mindrot.org" , Max Horn X-Priority: 3 Importance: Normal In-Reply-To: <2072949147-896@skroderider.denisbider.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=-3AHfQpthCFMIUA5ns36B" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-3AHfQpthCFMIUA5ns36B Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I can make available an experimental build of our SSH Server that will impl= ement these algorithms. Might need to give me a few hours. denis bider , 11/8/2015 2:24 AM: The "ecdsa-sha2-..." algorithm names (RFC 5656) do not use the "ssh-" prefi= x. Neither do the new formats in RFC 6187, i.e. "x509v3-rsa2048-sha256" and "x= 509v3-ecdsa-sha2-...". In my opinion, the "ssh-" prefix is superfluous. The context of SSH is impl= ied by where the names are used. The prefix would make sense if it were needed to disambiguate from somethin= g. However, I am not aware of any proposal for SSH to do a wholesale import= of algorithm names from some other, SSH-unaware spec. Moreover, if such na= mes were imported, then THOSE names would be prefixed with something, not t= he SSH native algorithm names. I think the use of "ssh-" prefixes for all kinds of names was a (small) mis= take in the original design. I think we can safely migrate away from it. Therefore, I have specified no "ssh-" prefix for these algorithms. Peter Gutmann , 11/8/2015 2:23 AM: denis bider writes: >(1) I have uploaded a new version of the RSA SHA-2 draft: > >https://tools.ietf.org/html/draft-rsa-dsa-sha2-256-02 Has anyone else implemented this? =C2=A0I've dropped in some quick partial = support for it, and I can't see why it wouldn't work transparently to replace the existing form, but being able to test against someone else would be good. Hmm, just saw an issue, I used "ssh-rsa-sha2..." instead of rsa-..., should the new names also have the "ssh-" prefix to match existing usage? =C2=A0As= I see it the name has to identify the format used, "ssh-", and the signature algorithm, "rsa-sha...", having just the latter makes it difficult to speci= fy other signature formats. Peter. = --=-3AHfQpthCFMIUA5ns36B Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable I can make available an experimental build of our = SSH Server that will implement these algorithms.

Might need to give = me a few hours.


denis bider <= ;ietf-ssh3@denisbider.com> , 11/8/2015 2:24 AM:
The "ecdsa-sha2-..." algorithm names (RFC 5656) do n= ot use the "ssh-" prefix.

Neither do the new formats in RFC 6187, i.= e. "x509v3-rsa2048-sha256" and "x509v3-ecdsa-sha2-...".

In my opinio= n, the "ssh-" prefix is superfluous. The context of SSH is implied by where= the names are used.

The prefix would make sense if it were needed t= o disambiguate from something. However, I am not aware of any proposal for = SSH to do a wholesale import of algorithm names from some other, SSH-unawar= e spec. Moreover, if such names were imported, then THOSE names would be pr= efixed with something, not the SSH native algorithm names.

I think t= he use of "ssh-" prefixes for all kinds of names was a (small) mistake in t= he original design. I think we can safely migrate away from it.

Ther= efore, I have specified no "ssh-" prefix for these algorithms.


<= div>Peter Gutmann <pgut001@cs.auckland.ac.nz> , 11/8/2015 2:23 AM= :
denis bider <ietf-ssh3@denisbider.com> writes:

>(1) I hav= e uploaded a new version of the RSA SHA-2 draft:
>
>https://tools= .ietf.org/html/draft-rsa-dsa-sha2-256-02

Has anyone else impleme= nted this?  I've dropped in some quick partial support
for it, and = I can't see why it wouldn't work transparently to replace the
existing f= orm, but being able to test against someone else would be good.

Hmm,= just saw an issue, I used "ssh-rsa-sha2..." instead of rsa-..., should
= the new names also have the "ssh-" prefix to match existing usage?  As= I see
it the name has to identify the format used, "ssh-", and the sign= ature
algorithm, "rsa-sha...", having just the latter makes it difficult= to specify
other signature formats.

Peter.
= --=-3AHfQpthCFMIUA5ns36B-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Nov 8 07:37:43 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D67251B3145 for ; Sun, 8 Nov 2015 07:37:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 oNkdq2VwLal0 for ; Sun, 8 Nov 2015 07:37:42 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8311B1B3134 for ; Sun, 8 Nov 2015 07:37:42 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 25BB014A2B8; Sun, 8 Nov 2015 15:37:42 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id BD2B714A2B7; Sun, 8 Nov 2015 15:37:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 58C1614A437 for ; Sun, 8 Nov 2015 08:58:14 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id gNV4wMb92nQv for ; Sun, 8 Nov 2015 08:58:13 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 9C06514A434 for ; Sun, 8 Nov 2015 08:58:13 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for pgut001@cs.auckland.ac.nz; Sun, 8 Nov 2015 08:58:12 +0000 Date: Sun, 8 Nov 2015 08:58:12 +0000 Subject: Re: DH group exchange (Re: SSH key algorithm updates) X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <2096379125-720@skroderider.denisbider.com> X-Priority: 3 Importance: Normal In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B5993D@uxcn10-5.UoA.auckland.ac.nz> MIME-Version: 1.0 From: denis bider To: Peter Gutmann , "Mark D. Baushke" Cc: Jeffrey Hutzelman , =?UTF-8?q?Niels_M=C3=B6ller?= , "ietf-ssh@NetBSD.org" , "stephen.farrell@cs.tcd.ie" , "jon@siliconcircus.com" Content-Type: multipart/alternative; boundary="=-LmVGvbdoO1qIXK6lze5Y" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-LmVGvbdoO1qIXK6lze5Y Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable If this new draft could specify group generation such that: - Windows built-in crypto (CNG) running under FIPS mode - and possibly, but not as critically, the Crypto++ 5.3.0 FIPS-certified mo= dule could reliably use parameters sent by servers that implement the new spec -= that would be quite awesome. I have not yet implemented DH using Windows CNG, so I can't verify if it ha= s the same issues as Crypto++ has. However, I should get there in the next = few weeks. Peter Gutmann , 11/8/2015 8:16 AM: mdb@juniper.net writes: >To me, the term '(p-1)/2' implies that we are calculating a value for 'q' = ... >in other words, I thought that q was a Sophie Germain prime and an p was t= he >safe prime. Ah, yeah, it works if you're using safe primes and can assume that form. = =C2=A0I use Lim-Lee primes (p =3D 2q * ( prime[1] * ... prime[n] ) + 1 rather than = p =3D 2q + 1), for which an attempt to back-derive q from p will lead to funny results. >If you want to allow for things like group25 (RFC 5114), then having all o= f >the group parameters g,p,q would make it possible. I would have no problem= s >with that addition. That would be a considerable help, particularly given the recent attacks on PKCS #3 DH values in TLS (SSH uses the same form, but so far hasn't been fo= und vulnerable). If no-one else has any objections, I'll work on a quick draft, all it'll do= is update '4419 to define a SSH_MSG_KEX_DH_GEX2_GROUP and a new identifier, "diffie-hellman-group-exchange2-sha256" (I assume there's no demand for a sha-1 version any more...). =C2=A0The impact on an implemention should be n= o more than a few lines of code changed, a new entry in an algorithm table for the= ID string and a call to read the extra q value. Peter. = --=-LmVGvbdoO1qIXK6lze5Y Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable If this new draft could specify group generation s= uch that:

- Windows built-in crypto (CNG) running under FIPS mode
- and possibly, but not as critically, the Crypto++ 5.3.0 FIPS-certifi= ed module

could reliably use parameters sent by servers that impleme= nt the new spec - that would be quite awesome.

I have not yet implem= ented DH using Windows CNG, so I can't verify if it has the same issues as = Crypto++ has. However, I should get there in the next few weeks.

Peter Gutmann <pgut001@cs.auckland.a= c.nz> , 11/8/2015 8:16 AM:
mdb@juniper.net <mdb@juniper.net> writes:
>To me, the term '(p-1)/2' implies that we are calculating a value = for 'q' ...
>in other words, I thought that q was a Sophie Germain pr= ime and an p was the
>safe prime.

Ah, yeah, it works if you're= using safe primes and can assume that form.  I
use Lim-Lee primes = (p =3D 2q * ( prime[1] * ... prime[n] ) + 1 rather than p =3D
2q + 1), f= or which an attempt to back-derive q from p will lead to funny
results.<= br>
>If you want to allow for things like group25 (RFC 5114), then ha= ving all of
>the group parameters g,p,q would make it possible. I wou= ld have no problems
>with that addition.

That would be a consi= derable help, particularly given the recent attacks on
PKCS #3 DH values= in TLS (SSH uses the same form, but so far hasn't been found
vulnerable= ).

If no-one else has any objections, I'll work on a quick draft, al= l it'll do is
update '4419 to define a SSH_MSG_KEX_DH_GEX2_GROUP and a n= ew identifier,
"diffie-hellman-group-exchange2-sha256" (I assume there's= no demand for a
sha-1 version any more...).  The impact on an impl= emention should be no more
than a few lines of code changed, a new entry= in an algorithm table for the ID
string and a call to read the extra q = value.

Peter.
= --=-LmVGvbdoO1qIXK6lze5Y-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Nov 8 07:37:56 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9429C1B3147 for ; Sun, 8 Nov 2015 07:37:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 218GzMBjR3dg for ; Sun, 8 Nov 2015 07:37:54 -0800 (PST) Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0F9B1B3134 for ; Sun, 8 Nov 2015 07:37:54 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 8CB8E14A2BE; Sun, 8 Nov 2015 15:37:54 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 2EC3D14A2BA; Sun, 8 Nov 2015 15:37:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id E7BDB14A40A for ; Sun, 8 Nov 2015 03:35:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id hCS59ow8fRpa for ; Sun, 8 Nov 2015 03:35:04 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 20C8414A405 for ; Sun, 8 Nov 2015 03:35:03 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for pgut001@cs.auckland.ac.nz; Sun, 8 Nov 2015 03:35:02 +0000 Date: Sun, 8 Nov 2015 03:35:02 +0000 Subject: Re: SSH key algorithm updates X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <2076731579-720@skroderider.denisbider.com> X-Priority: 3 Importance: Normal In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B59718@uxcn10-5.UoA.auckland.ac.nz> MIME-Version: 1.0 From: denis bider To: Peter Gutmann , Max Horn Cc: "ietf-ssh@NetBSD.org" Content-Type: multipart/alternative; boundary="=-+Ic7M+VKF5X2IizAXuJo" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-+Ic7M+VKF5X2IizAXuJo Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable A universal extractor might have trouble with our stuff. We don't use Windo= ws Installer (the thing is a nightmare), instead we pack a large BLOB with = all the files, compress it with a compression library, and stuff the compre= ssed BLOB as a resource into the installer executable. If the extractor is universal enough to recognize the compressed resource, = and its compression format, that would leave you with a BLOB containing all= the files, on which you could run "strings". You're going to get loads of = strings, however. I agree that including the "none" user auth method should probably not be d= one, since it's usually supported as discovery rather than an authenticatio= n method, and it's hard to tell when it's supported for login (if ever). Peter Gutmann , 11/8/2015 3:06 AM: Max Horn writes: >That's what I've been doing for multiple entries in my list already; but i= t >has limitation, e.g. if the binaries are wrapped in an installer, which >contains only a compressed version of the actual executable.=20 There are a bunch of universal extractors that will bypass the need to install, google "windows installer unpacker", so you don't need to install random binaries on your system. >It also can lead to inaccurate results, and does not reveal which methods = are >enabled/disabled by default, etc. Yeah, that's a good point. =C2=A0OTOH you then need to do test runs on the = app to try and probe what's present and what isn't. =C2=A0It depends on how much t= ime you want to sink into it :-). >Yes, I was (and am) having precisely the same concern. But now I am wonder= ing >whether I should just omit the "none" entry completely. After all, it eith= er >leaves an incorrect bad impression (if people read it as meaning that a >server supports "non-as-auth" by default), and otherwise is useless, as it >doesn't tell you whether it actually means it works as "none-as-query". That sounds like a good idea. =C2=A0You more or less have to support none-a= s-query in order to be able to communicate with some clients, so in theory every implementation would have to have support for "none". =C2=A0OTOH I would im= agine few implementations allow you in without authentication, so few would supor= t the other "none". Oh, and you'll need to add columns for the SHA-2 forms of signatures soon := -). Peter. = --=-+Ic7M+VKF5X2IizAXuJo Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable A universal extractor might have trouble with our = stuff. We don't use Windows Installer (the thing is a nightmare), instead w= e pack a large BLOB with all the files, compress it with a compression libr= ary, and stuff the compressed BLOB as a resource into the installer executa= ble.

If the extractor is universal enough to recognize the compresse= d resource, and its compression format, that would leave you with a BLOB co= ntaining all the files, on which you could run "strings". You're going to g= et loads of strings, however.

I agree that including the "none" user= auth method should probably not be done, since it's usually supported as d= iscovery rather than an authentication method, and it's hard to tell when i= t's supported for login (if ever).


Peter Gutmann <pgut001@cs.auckland.ac.nz> , 11/= 8/2015 3:06 AM:
Max Horn <post= box@quendi.de> writes:

>That's what I've been doing for mu= ltiple entries in my list already; but it
>has limitation, e.g. if th= e binaries are wrapped in an installer, which
>contains only a compre= ssed version of the actual executable.

There are a bunch of univers= al extractors that will bypass the need to
install, google "windows inst= aller unpacker", so you don't need to install
random binaries on your sy= stem.

>It also can lead to inaccurate results, and does not revea= l which methods are
>enabled/disabled by default, etc.

Yeah, t= hat's a good point.  OTOH you then need to do test runs on the app to<= br>try and probe what's present and what isn't.  It depends on how muc= h time you
want to sink into it :-).

>Yes, I was (and am) havi= ng precisely the same concern. But now I am wondering
>whether I shou= ld just omit the "none" entry completely. After all, it either
>leave= s an incorrect bad impression (if people read it as meaning that a
>s= erver supports "non-as-auth" by default), and otherwise is useless, as it>doesn't tell you whether it actually means it works as "none-as-query= ".

That sounds like a good idea.  You more or less have to supp= ort none-as-query
in order to be able to communicate with some clients, = so in theory every
implementation would have to have support for "none".=  OTOH I would imagine
few implementations allow you in without aut= hentication, so few would suport
the other "none".

Oh, and you'll= need to add columns for the SHA-2 forms of signatures soon :-).

Pet= er.
= --=-+Ic7M+VKF5X2IizAXuJo-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Nov 8 07:38:44 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 271231B3178 for ; Sun, 8 Nov 2015 07:38:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 dOfbtPqPeHBt for ; Sun, 8 Nov 2015 07:38:42 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 521291B3147 for ; Sun, 8 Nov 2015 07:38:42 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 600C314A2C2; Sun, 8 Nov 2015 15:38:40 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 05B0714A2BF; Sun, 8 Nov 2015 15:38:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 7D83514A2C2 for ; Sun, 8 Nov 2015 10:30:01 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 00ijoZ1-dzWC for ; Sun, 8 Nov 2015 10:30:00 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id A5B1014A2A5 for ; Sun, 8 Nov 2015 10:30:00 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for pgut001@cs.auckland.ac.nz; Sun, 8 Nov 2015 10:29:57 +0000 Date: Sun, 8 Nov 2015 10:29:57 +0000 Subject: Re: DH group exchange (Re: SSH key algorithm updates) X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <2101577796-896@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: Peter Gutmann Cc: ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-aqENt4QAqUz62vqQAmd8" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-aqENt4QAqUz62vqQAmd8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > The annoying thing about this change is that it's going to take me > about 20x as long to do the spec describing it as it will to make > the code changes, sigh. That's the thing with writing every spec. :) I find, though, that the extra effort in writing a spec contributes in impo= rtant ways to thinking of and addressing corner cases, which an intuitive i= mplementation process might otherwise gloss over. It's 80% more work for wh= at seems like 20% more correctness, but those 20% more correctness tend to = make or break the thing, in many cases. If we had infinite time, we should be writing all the specs. It might even save us time in the long run... :) ----- Original Message ----- From: Peter Gutmann=20 Sent: Sunday, November 8, 2015 03:42 To: denis bider ; Mark D. Baushke=20 Cc: Jeffrey Hutzelman ; Niels M=C3=B6ller ; ietf-ssh@NetBSD.org ; stephen.f= arrell@cs.tcd.ie ; jon@siliconcircus.com=20 Subject: RE: DH group exchange (Re: SSH key algorithm updates) denis bider writes: >If this new draft could specify group generation such that: > >- Windows built-in crypto (CNG) running under FIPS mode > >- and possibly, but not as critically, the Crypto++ 5.3.0 FIPS-certified m= odule > >could reliably use parameters sent by servers that implement the new spec = - >that would be quite awesome. I don't know if you need to specify the exact generation method, only the verification checks to perform, which are given in FIPS 186.=C2=A0 The inte= nt is to create verifiable DH parameters, so the important thing is the verification mechanism, not the generation one (both safe primes and Lim-Lee primes, for example, will produce verifiable values).=C2=A0 It would certainly make sen= se, if you're using { p, q, g } primes, to require that they be verified as per th= e FIPS 186 checks, since that's the point to using them. The annoying thing about this change is that it's going to take me about 20= x as long to do the spec describing it as it will to make the code changes, sigh. One other thing that'd be good to have, based on the Logjam paper, is to specify some means of distinguishing g from q, since Logjam mentions that there are implementations that confuse the two.=C2=A0 Does anyone have prob= lems with requiring that g =3D ?=C2=A0 This both makes the DH op = much more efficient, and makes it easy to quickly distinguish g from q without requir= ing complex bignum ops. Peter. = --=-aqENt4QAqUz62vqQAmd8 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable > The annoying thing about this change is that = it's going to take me
> about 20x as long to do the spec describing i= t as it will to make
> the code changes, sigh.

That's the thin= g with writing every spec. :)

I find, though, that the extra effort = in writing a spec contributes in important ways to thinking of and addressi= ng corner cases, which an intuitive implementation process might otherwise = gloss over. It's 80% more work for what seems like 20% more correctness, bu= t those 20% more correctness tend to make or break the thing, in many cases= .

If we had infinite time, we should be writing all the specs= .

It might even save us time in the long run... :)


----- = Original Message -----
From: Peter Gutmann
Sent: Sunday, November 8,= 2015 03:42
To: denis bider ; Mark D. Baushke
Cc: Jeffrey Hutzelman = ; Niels M=C3=B6ller ; ietf-ssh@NetBSD.org ; stephen.farrell@cs.tcd.ie ; jon= @siliconcircus.com
Subject: RE: DH group exchange (Re: SSH key algorith= m updates)

denis bider <ietf-ssh3@denisbider.com> writes:
<= br>>If this new draft could specify group generation such that:
><= br>>- Windows built-in crypto (CNG) running under FIPS mode
>
&= gt;- and possibly, but not as critically, the Crypto++ 5.3.0 FIPS-certified= module
>
>could reliably use parameters sent by servers that i= mplement the new spec -
>that would be quite awesome.

I don't = know if you need to specify the exact generation method, only the
verifi= cation checks to perform, which are given in FIPS 186.  The intent is = to
create verifiable DH parameters, so the important thing is the verifi= cation
mechanism, not the generation one (both safe primes and Lim-Lee p= rimes, for
example, will produce verifiable values).  It would cert= ainly make sense, if
you're using { p, q, g } primes, to require that th= ey be verified as per the
FIPS 186 checks, since that's the point to usi= ng them.

The annoying thing about this change is that it's going to = take me about 20x
as long to do the spec describing it as it will to mak= e the code changes,
sigh.

One other thing that'd be good to have,= based on the Logjam paper, is to
specify some means of distinguishing g= from q, since Logjam mentions that
there are implementations that confu= se the two.  Does anyone have problems
with requiring that g =3D &l= t;small integer>?  This both makes the DH op much more
efficient= , and makes it easy to quickly distinguish g from q without requiring
co= mplex bignum ops.

Peter.

= --=-aqENt4QAqUz62vqQAmd8-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Nov 8 07:51:06 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8EDC1B31BD for ; Sun, 8 Nov 2015 07:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 n_B9C3OrB0-0 for ; Sun, 8 Nov 2015 07:51:05 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EE021B31BB for ; Sun, 8 Nov 2015 07:51:05 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 39A8214A202; Sun, 8 Nov 2015 15:36:46 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id C0AD614A1F0; Sun, 8 Nov 2015 15:36:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 8CA9A14A4C2 for ; Sun, 8 Nov 2015 02:30:23 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id vcH--2YfnyUy for ; Sun, 8 Nov 2015 02:30:22 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id D5E1814A4BD for ; Sun, 8 Nov 2015 02:30:22 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for pgut001@cs.auckland.ac.nz; Sun, 8 Nov 2015 02:30:18 +0000 Date: Sun, 8 Nov 2015 02:30:18 +0000 Subject: Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <2072949147-896@skroderider.denisbider.com> X-Priority: 3 Importance: Normal In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B59673@uxcn10-5.UoA.auckland.ac.nz> MIME-Version: 1.0 From: denis bider To: Peter Gutmann , "ietf-ssh@netbsd.org" Cc: Jeffrey Hutzelman , =?UTF-8?q?NielsM=C3=B6ller?= , "Mark D. Baushke" , "stephen.farrell@cs.tcd.ie" , "jon@siliconcircus.com" , "djm@mindrot.org" , Max Horn Content-Type: multipart/alternative; boundary="=-9CD3OjhRD9s91kjrwp3N" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-9CD3OjhRD9s91kjrwp3N Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The "ecdsa-sha2-..." algorithm names (RFC 5656) do not use the "ssh-" prefi= x. Neither do the new formats in RFC 6187, i.e. "x509v3-rsa2048-sha256" and "x= 509v3-ecdsa-sha2-...". In my opinion, the "ssh-" prefix is superfluous. The context of SSH is impl= ied by where the names are used. The prefix would make sense if it were needed to disambiguate from somethin= g. However, I am not aware of any proposal for SSH to do a wholesale import= of algorithm names from some other, SSH-unaware spec. Moreover, if such na= mes were imported, then THOSE names would be prefixed with something, not t= he SSH native algorithm names. I think the use of "ssh-" prefixes for all kinds of names was a (small) mis= take in the original design. I think we can safely migrate away from it. Therefore, I have specified no "ssh-" prefix for these algorithms. Peter Gutmann , 11/8/2015 2:23 AM: denis bider writes: >(1) I have uploaded a new version of the RSA SHA-2 draft: > >https://tools.ietf.org/html/draft-rsa-dsa-sha2-256-02 Has anyone else implemented this? =C2=A0I've dropped in some quick partial = support for it, and I can't see why it wouldn't work transparently to replace the existing form, but being able to test against someone else would be good. Hmm, just saw an issue, I used "ssh-rsa-sha2..." instead of rsa-..., should the new names also have the "ssh-" prefix to match existing usage? =C2=A0As= I see it the name has to identify the format used, "ssh-", and the signature algorithm, "rsa-sha...", having just the latter makes it difficult to speci= fy other signature formats. Peter. = --=-9CD3OjhRD9s91kjrwp3N Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable The "ecdsa-sha2-..." algorithm names (RFC 5656) do= not use the "ssh-" prefix.

Neither do the new formats in RFC 6187, = i.e. "x509v3-rsa2048-sha256" and "x509v3-ecdsa-sha2-...".

In my opin= ion, the "ssh-" prefix is superfluous. The context of SSH is implied by whe= re the names are used.

The prefix would make sense if it were needed= to disambiguate from something. However, I am not aware of any proposal fo= r SSH to do a wholesale import of algorithm names from some other, SSH-unaw= are spec. Moreover, if such names were imported, then THOSE names would be = prefixed with something, not the SSH native algorithm names.

I think= the use of "ssh-" prefixes for all kinds of names was a (small) mistake in= the original design. I think we can safely migrate away from it.

Th= erefore, I have specified no "ssh-" prefix for these algorithms.

Peter Gutmann <pgut001@cs.auckland.a= c.nz> , 11/8/2015 2:23 AM:
den= is bider <ietf-ssh3@denisbider.com> w= rites:

>(1) I have uploaded a new version of the RSA SHA-2 draft:=
>
>https://tools.ietf.org/html/draft-rsa-dsa-sha2-256-02
=
Has anyone else implemented this?  I've dropped in some quick part= ial support
for it, and I can't see why it wouldn't work transparently t= o replace the
existing form, but being able to test against someone else= would be good.

Hmm, just saw an issue, I used "ssh-rsa-sha2..." ins= tead of rsa-..., should
the new names also have the "ssh-" prefix to mat= ch existing usage?  As I see
it the name has to identify the format= used, "ssh-", and the signature
algorithm, "rsa-sha...", having just th= e latter makes it difficult to specify
other signature formats.

P= eter.
= --=-9CD3OjhRD9s91kjrwp3N-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Nov 8 08:22:50 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2F01A0180 for ; Sun, 8 Nov 2015 08:22:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 pEplPYQ9VPRV for ; Sun, 8 Nov 2015 08:22:48 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1C741A0173 for ; Sun, 8 Nov 2015 08:22:48 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 3A7B414A258; Sun, 8 Nov 2015 16:22:48 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id CC1ED14A257 for ; Sun, 8 Nov 2015 16:22:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 4yWl5q1huvza for ; Sun, 8 Nov 2015 16:22:43 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id D52F814A255 for ; Sun, 8 Nov 2015 16:22:41 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 0386240023; Sun, 8 Nov 2015 17:22:37 +0100 (CET) Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id 5391340021; Sun, 8 Nov 2015 17:22:35 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Sun, 08 Nov 2015 17:22:35 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: Jeffrey Hutzelman Cc: "Mark D. Baushke" , denis bider , ietf-ssh@NetBSD.org, stephen.farrell@cs.tcd.ie, jon@siliconcircus.com Subject: Re: SSH key algorithm updates References: <1297540000-2044@skroderider.denisbider.com> <51845.1446188002@eng-mail01.juniper.net> <1446228753.32676.1.camel@destiny.pc.cs.cmu.edu> <1446789400.4752.33.camel@destiny.pc.cs.cmu.edu> Date: Sun, 08 Nov 2015 17:22:35 +0100 In-Reply-To: <1446789400.4752.33.camel@destiny.pc.cs.cmu.edu> (Jeffrey Hutzelman's message of "Fri, 06 Nov 2015 00:56:40 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Jeffrey Hutzelman writes: > Group exchange doesn't have to mean live, dynamic group generation. It > can work fine with a set of fixed groups, either manually configured or > compiled in. I've been thinking a bit more about this, and I think that way of using group exchange has to be *highly discoraged*. First, it totally defeats the original purpose of group exchange, which was to avoid wide use of any particular group, in order to reduce the attacker's gain from massive precomputation. Second, if fixed groups are used, then those groups ought to be subject to both standardization review and negotiation at runtime. E.g., suppose one server implementation with signiifcant deployment uses group exchange with a single fixed group, say p =3D 2^3072 - 47. (And it al= so supports group14, for interop reasons). Then, it is discovered that there are relevant attacks on this group and it should be avoided. But how can a client make sure the 2^3072 - 47 group is avoided, and still interoperate with the above server? It has to give group14 higher preference than group exchange (with the effect of practically never negotiating use of group exchange), or resort to hacks using the server version string and an extra roundtrip delay. Best regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Nov 8 08:47:41 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3CF71A1C02 for ; Sun, 8 Nov 2015 08:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 4xJH5HZvdGg9 for ; Sun, 8 Nov 2015 08:47:39 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE6781A1BB3 for ; Sun, 8 Nov 2015 08:47:39 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id CA5BE14A276; Sun, 8 Nov 2015 16:47:37 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id BE64A14A1F0 for ; Sun, 8 Nov 2015 16:47:30 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id sN2MvE35aiBS for ; Sun, 8 Nov 2015 16:47:30 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0747.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::747]) by mail.netbsd.org (Postfix) with ESMTP id 7687D14A146 for ; Sun, 8 Nov 2015 16:47:28 +0000 (UTC) Received: from BLUPR05CA0077.namprd05.prod.outlook.com (10.141.20.47) by BLUPR05MB056.namprd05.prod.outlook.com (10.255.210.151) with Microsoft SMTP Server (TLS) id 15.1.312.18; Sun, 8 Nov 2015 16:47:26 +0000 Received: from BY2FFO11OLC012.protection.gbl (2a01:111:f400:7c0c::128) by BLUPR05CA0077.outlook.office365.com (2a01:111:e400:855::47) with Microsoft SMTP Server (TLS) id 15.1.318.15 via Frontend Transport; Sun, 8 Nov 2015 16:47:26 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=juniper.net; cs.tcd.ie; dkim=none (message not signed) header.d=none;cs.tcd.ie; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.17) by BY2FFO11OLC012.mail.protection.outlook.com (10.1.15.23) with Microsoft SMTP Server (TLS) id 15.1.325.5 via Frontend Transport; Sun, 8 Nov 2015 16:47:25 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 8 Nov 2015 08:47:24 -0800 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id tA8GlMD10713; Sun, 8 Nov 2015 08:47:22 -0800 (PST) (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id C20DC11496; Sun, 8 Nov 2015 08:47:21 -0800 (PST) To: Peter Gutmann CC: denis bider , Jeffrey Hutzelman , =?iso-8859-1?Q?Niels_M=F6ller?= , "ietf-ssh@NetBSD.org" , "stephen.farrell@cs.tcd.ie" , "jon@siliconcircus.com" Subject: Re: DH group exchange (Re: SSH key algorithm updates) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B599ED@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4B5993D@uxcn10-5.UoA.auckland.ac.nz>,<2096379125-720@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B599ED@uxcn10-5.UoA.auckland.ac.nz> Comments: In-reply-to: Peter Gutmann message dated "Sun, 08 Nov 2015 09:42:29 +0000." From: "Mark D. Baushke" X-Phone: +1 408 745-2952 (Office) X-Mailer: MH-E 8.5; nmh 1.2; GNU Emacs 24.3.1 X-Face: #8D_6URD2G%vC.hzU MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1;BY2FFO11OLC012;1:C6+0GRhLr2TBDWK6JPk2ZnHfqwaRWo+dT/NiGn/DGrut0LT7pW7GFAVPJE5SGDewGAc3//bJcx1NF7zHktl8JonD3rXHk7nPVuKAXMW5Rs6RbzHcE1oLd2cB5GRrOjYzkaA0Sqe9BQ4Ti0eQLHIXydc84Z0eeT7G1MwiJYOcpQyi/f2d0RqAsU1VC15dTTbQZ7WsB29IovcYX6dQFYOdZZCh1wbEegyyDWeRpmC1qyaT6YvnaTtNL+nIFRXKEad1rwCLyLtpLxTdPdOkDs0ffXeemBU9yXfC6I5BVgX3EZXj91vwwB80AWa+iFSiqbrqBONcBrOBBtrdQTfdyxxi9jT04ic5NRZJLvNPZKNZupe+1E8CmzGxkFCBJLHrszO9pt6cmqGbxMDS+2bD9aEhJA== X-Forefront-Antispam-Report: CIP:66.129.239.17;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(2980300002)(189002)(199003)(7110500001)(5003600100002)(189998001)(5003940100001)(5001960100002)(110136002)(19580395003)(69596002)(87936001)(19580405001)(47776003)(76176999)(50986999)(48376002)(50466002)(86362001)(11100500001)(10710500006)(117636001)(6806005)(5007970100001)(2420400006)(50226001)(53416004)(97736004)(81156007)(76506005)(2950100001)(77096005)(106466001)(105596002)(15975445007)(92566002)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:BLUPR05MB056;H:p-emfe01a-sac.jnpr.net;FPR:;SPF:SoftFail;PTR:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BLUPR05MB056;2:msH9k8yKPJ1lNr19C7byDOFUSYch1WvU8qpFe2oDZdoRmGMzkdyYtvXuRN89jD6NdZNyy6YVAo/d4J4HFbDy65G2Tx1wj/AEpnJv3q1/DbeIZIiPtl/4Gdve7gruR3h11Rlt+wve5BCL6oh8Yt2QNgHud8B985mAzKutpk63B8c=;3:Ehq7WzWPvaNHXq3qR/Vc3i1o06jnteoRZYn4n4Qhxi4Orx9VMZjXkB0IfiXMpIkctMYUCuh7W7DmI646zSKkaCe4imRHzQ5cKcEdE1rSGb6A+kR1g+wwDEgCRLI/l7yjJjWPglMUtVPKtpn0gHyC13rYPQVzD5Ldi4XlBjexJTMkH2nsNFCUn9VG2LRxzHcuLa7rvDjyCGEaD2NvLeYRZxiy3CPSwn9EspcRqJtnM8E=;25:f5QQVvSbtw4fwumbW/r/VsAK34JG6t7n6eaBHXcQ7Fs9auhLT8UrbVs8GDkB2oSLgmAUqERHQgb0gYwMzvKR8fM4GX3kMPiDMbbUzmPpzvV50gPQtypQcZ+ssDWxhgvpUVqIVxo9sAU4iio/qim8tyujmZ8IFps8Z4B2BLjkoPmsPfpDFbCZ9KU5GBFUU8fYE+VpgNi4dBrXpOpIZihvzmo4H3hVkX/BllyzWgPxm2FDKVKiQfXDVPWdYAWAPf6eFC7VjJCNwIotIKDEixVMIA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB056; X-Microsoft-Exchange-Diagnostics: 1;BLUPR05MB056;20:DaYR1RQyEXsmB0AqtqaP5Zdg1n5fmBgI699EEilDSnSqbB5B4IjJSgWb/3/jhkiMQpt5z4vu9dcpSKshNL4vTMnD0mcn6kwGgiXVn5p7aYCbchGVCJ/QEY0C92oqvdfravN9/ld0jEaaMlnLHkoMCrZNekx2Sdq9fRxQug9xfjApJ1wnys2yIPPi1ftNpsxDBbvAvLlpq9uI1HT3VhvRlHTMOmRa3jffrAl7/xP6JqfdBVGgvxiNU6SjIOKJF4Sbso0dSyO23AMyctBXhYe0O0BwWDOCHKiB2Cb4ih06+pB50SakNxoSN1y365K6WyAFKn+d73wjPqcy3J1jMi9HZiyvxBmHHSbs22ADWF7B1wJWRH2zMqKhARgdhABz/vGVSdMVJ60Ozm8vHNUOmWCz5jnFpQMq9RUVfgvo3De6T2qzPqRhQaszItbpGkkhSvklYYO6UGfwuZdfotRPQXpHLN107HMSgWD5MGb3UgsW7//c6sd4/tNzxZPy+fi2LYOp;4:cPzhsisMms/GcWb22fGwGR2ukrbgd9IdmR4qo5azfDDXl3E+hvoOf0bWfO9FiOCsJZqZZTS+9pH2L8v3gnFd+JUO9BB07GDOf67KxuGwXOdfRjiwyst35DWA4ZLRS9i0CiWsj02Z9aMdMmfea9k2+kBvb29CBCfy8UQcMFBAkxImrx8BZUObt4XURWAXYLfF/sUZbkJHu7E/qQgRHvXzrJiALOFRlBftrFiGxkY52+qwOPzA07tx1g4bvl1pm13p4n8bIUI8JNVqlhtD3w4P1YNQ/Kz/yUzz8aRyMv+VLQr4zCqDp7gE23Jgs1Zbi4oLqjenqGzxxpCXCwzZ2tA2pEW7iRgkKhTO/kxiKw14JKYzLnGS+oLoa4B5gXALiL2n X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001);SRVR:BLUPR05MB056;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB056; X-Forefront-PRVS: 0754F7E325 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;BLUPR05MB056;23:mZVXnGEvvxzMmuX079RFyP6kQ8/xSooGNe405PhNcY?= =?us-ascii?Q?bV0ZjgOeFclJEEhApQREwgf/vT7KZp9uuK2EEOa8XBbNmL/kVhDOpvK3tu0F?= =?us-ascii?Q?PVZsPvo3fHRWpR2PEETf8FI63VAGpIWuiKVub+CG5vV/PBVXfFohp+DdSnou?= =?us-ascii?Q?180Ts55y5f3YiqzUbqUXX96/JQYkgRLgEWoOCz+AEhFQ5EAR+/q7HX20QHWw?= =?us-ascii?Q?ioA32TRK36etHaGsy1KQUuyzMSyLCu7BGfjn+JtL1+3oxnGZyS+UbgWVo8o2?= =?us-ascii?Q?GtkgBKM3KKbsBVXPat9wa2Fl9NSmTIsOE6nDB7/GdbJuqsWd4EI9z6Bz0B/q?= =?us-ascii?Q?pxej9Em7qx03ae/ImERslQA+1O4j8uYLzOpX2NphmEy9ffMTlaWZJM87yMAv?= =?us-ascii?Q?u0LSg3uqBUyXIAuZLwo3Bbb2qudaiFvSFT/VL8QZ1GoECZ2VDP6oGC7/0U+s?= =?us-ascii?Q?KSG5gBqu2zf5rd1SGxqJPyjAsaPSeaVs/L3bj5sOpmgzZWoWsrTensRuhwxq?= =?us-ascii?Q?nOdn9szXdeBPgw3krWWBafBZidET/5Ru/f1t9ZfEOm9njzgSkXR/wnWgrYOl?= =?us-ascii?Q?oaerFQt8Yhis4l62ZmQdIlht24FV0bY5hNaMffM5ZFDBnpG8T/EoBCnFZFnp?= =?us-ascii?Q?tJ550mLTG0LexdHBOxkC1hvXNlsVR369ukUGn4qS8T1DWONRa9nSICfofUVA?= =?us-ascii?Q?dL3ISiD/Q6DDeMwt1hKc2gsnx3Q2iu4Dnl8ZUzJwotUU+nd6jQNfoKF9HfLu?= =?us-ascii?Q?OIBQGOEdmq1h0b33AjA0E7fN1IMb9YfI0etF5trlW0w8AN3df9x/8hCCYg9V?= =?us-ascii?Q?+4WB3SHDUrhSVPnbkYVmYY4zC+1jOulQi0Sc5RW+Iez8QJNXLcqXc88mzHzp?= =?us-ascii?Q?PGBYRsbJnLFyGbbvmgsvOjVlDZbZ1qkB3mLCxs3Q8LfnrOuEU18yfV9DeCsl?= =?us-ascii?Q?/t/kI/IaghIblxfxWCLzJqpVBG8CFJQpEONviLnEL+45YsJJ1sFWBgQPz0fU?= =?us-ascii?Q?jkk3f7Hc1K5Qc5zEntbAkzjGfzrymCqEXBwi7hRL8EIfBD9NOAr1824PJXC9?= =?us-ascii?Q?jemMw=3D?= X-Microsoft-Exchange-Diagnostics: 1;BLUPR05MB056;5:1pTzoCQtH0SWW0D9eXnLDYXs0MD5MWqFOh48/NHV6QlTAm7jJq3DSe07hTM6WEFzk7UKTLEMwqZaNYdVS5BOdbOsm1v/jqN5pzXxFS2D+Ew9e3qcbFA7dsCeeZVuvOwCPdh3TSejtJoQxpKtQI1VlA==;24:jBUFjDXTUJCkM/Xifs74osiHS9zOJxAW/RbwZShOaXsCgcbaGIuNJ8DepuKlBItWdHDCAzcmvFodgEYU/v4KeB0IIFj6zKulE9k12g7gbac=;20:o2BS8CwQl4AqSOwLF4iDFMErbhPRyRQImTcS0L4e9iPUzzxBO5i83eyBrRoWwsQmRayla+FBoiNnhg6e+hzrUQ== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Nov 2015 16:47:25.3847 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.17];Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB056 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Peter Gutmann writes: > denis bider writes: > I don't know if you need to specify the exact generation method, only > the verification checks to perform, which are given in FIPS 186. Actually, it depends on the evaluation lab somewhat, but they typically want evaluations to use generation and verification based on FIPS 186-4 appendix A.1 and show the code that is doing the generation if it is inside of the crypto module. Validation of existing DH FCC domain parameters is expected to use the methods in section A.1. Section A.1.1.2 outlines the method of generation of probable primes. However, it limits the values of the number of bits of p and q based on L and N values taken from section 4.2. Where the max is L=3072 and N=256 apparnetly resuing the same table as for DSA parameters. I would hope generating a lot of 2048-bit and 3072-bit DH primes would be sufficient for now. A possible method to generate larger DH parameters is to generate primes in any way you can and then validate them using one of the primality proving algorithms in http://cr.yp.to/primetests.html ... of course as it is not FIPS-approved, that would need to be done outside of the crypto boundary. :-( There seems to be little use of DH primes being much bigger than 4096 bits right now in any case. It becomes easier to move to ECDH for performance. > The intent is to create verifiable DH parameters, so the important > thing is the verification mechanism, not the generation one (both safe > primes and Lim-Lee primes, for example, will produce verifiable > values). It would certainly make sense, if you're using { p, q, g } > primes, to require that they be verified as per the FIPS 186 checks, > since that's the point to using them. Yes. That said, I do not find any FIPS or NIST documents talking about Lim-Lee primes for use in FIPS certified systems. > The annoying thing about this change is that it's going to take me > about 20x as long to do the spec describing it as it will to make the > code changes, sigh. That always seems to be the way of things. > One other thing that'd be good to have, based on the Logjam paper, is > to specify some means of distinguishing g from q, since Logjam > mentions that there are implementations that confuse the two. Does > anyone have problems with requiring that g = ? This > both makes the DH op much more efficient, and makes it easy to quickly > distinguish g from q without requiring complex bignum ops. Well, if you look at group25, you see that g is larger than q. I know that at one time, a few of our govenmental customers were twisting arms over implemnting group25 everywhere and were not happy that it was not possible for SSH at that time. I would therefore really like to see it possible to express all of the MODP groups via this new extension if possible. Just my $0.02, -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Nov 8 10:19:10 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989BA1A9239 for ; Sun, 8 Nov 2015 10:19:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 de_3nULisKcL for ; Sun, 8 Nov 2015 10:19:09 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5D581A9238 for ; Sun, 8 Nov 2015 10:19:09 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id CF3D914A1B5; Sun, 8 Nov 2015 18:19:06 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 7905A14A1B4 for ; Sun, 8 Nov 2015 18:19:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id YPiM-aRhpcku for ; Sun, 8 Nov 2015 18:19:04 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id B004F14A14C for ; Sun, 8 Nov 2015 18:19:02 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 1612E40023; Sun, 8 Nov 2015 19:19:00 +0100 (CET) Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id A7C4540022; Sun, 8 Nov 2015 19:18:58 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Sun, 08 Nov 2015 19:18:58 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: Peter Gutmann Cc: denis bider , "ietf-ssh\@netbsd.org" Subject: Re: New version of rsa-sha2-512 draft posted: no more DSA References: <1837603091-896@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B56EBA@uxcn10-5.UoA.auckland.ac.nz> Date: Sun, 08 Nov 2015 19:18:58 +0100 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B56EBA@uxcn10-5.UoA.auckland.ac.nz> (Peter Gutmann's message of "Fri, 6 Nov 2015 08:57:50 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Peter Gutmann writes: > (I can't see any good reason to have -512, it has little support, it's a = pain > to do on 32-bit CPUs, it's slow, and it offers little to no practical sec= urity > advantage over -256). My experience is that sha512 actually seems to be a bit faster than sha256 on 64-bit hardware. That said, I do agree rsa-sha256 might be a better choice for a new required or strongly recommended signature algorithm. Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Nov 8 10:30:59 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 034F21A92FF for ; Sun, 8 Nov 2015 10:30:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 amUkXhFgr-BT for ; Sun, 8 Nov 2015 10:30:58 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F7521A92FE for ; Sun, 8 Nov 2015 10:30:58 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id AE37214A1E9; Sun, 8 Nov 2015 18:30:55 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id B804914A1E7 for ; Sun, 8 Nov 2015 18:30:52 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id DQCZZgZpl3DM for ; Sun, 8 Nov 2015 18:30:52 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id E6B5114A1E5 for ; Sun, 8 Nov 2015 18:30:51 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id A6A1E40023; Sun, 8 Nov 2015 19:30:46 +0100 (CET) Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id 565E840022; Sun, 8 Nov 2015 19:30:45 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Sun, 08 Nov 2015 19:30:45 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: Peter Gutmann Cc: denis bider , "ietf-ssh\@netbsd.org" Subject: Re: New version of rsa-sha2-512 draft posted: no more DSA References: <1985908046-756@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B58ACD@uxcn10-5.UoA.auckland.ac.nz> Date: Sun, 08 Nov 2015 19:30:45 +0100 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B58ACD@uxcn10-5.UoA.auckland.ac.nz> (Peter Gutmann's message of "Sat, 7 Nov 2015 03:46:03 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Peter Gutmann writes: > Hmm, I wonder if it'd be worth doing a profile of SSH for embedded use? = It'd > certainly help clear some interop headaches, and give the SCADA folks a t= arget > to aim for. I think we should try our best to have the set of REQUIRED algorithms make sense on constrained embedded systems. (Which might be a good reason to move forward with ed25519 and curve25519. A few years ago I ported dropbear to a proprietary and pretty slow embedded device, with only 8-bit arithmetic hardware. IIRC, we constrained it to 1024-but RSA and group1 only. And after some pretty serious but not exhaustive optimization (basically ripping out most of libtomcrypt and replacing it with platform specific routines in assembly and microcode), initial key exchange still took almost one minute. A careful implementation of curve25519 and ed25519 would likely have brought down the keyexchange time to something a bit more user-friendly). Regards /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Nov 8 14:05:44 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA8911B441D for ; Sun, 8 Nov 2015 14:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 WPr2-odoVap7 for ; Sun, 8 Nov 2015 14:05:43 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 656901B441C for ; Sun, 8 Nov 2015 14:05:43 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 33C8914A20B; Sun, 8 Nov 2015 22:05:40 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id AE3F214A205 for ; Sun, 8 Nov 2015 22:05:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id XBGDwZNXyCx5 for ; Sun, 8 Nov 2015 22:05:36 +0000 (UTC) Received: from newmailhub.uq.edu.au (mailhub2.soe.uq.edu.au [130.102.132.209]) by mail.netbsd.org (Postfix) with ESMTP id A972714A1DF for ; Sun, 8 Nov 2015 22:05:33 +0000 (UTC) Received: from smtp2.soe.uq.edu.au (smtp2.soe.uq.edu.au [10.138.113.41]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id tA8M5ROP022701; Mon, 9 Nov 2015 08:05:27 +1000 Received: from mailhub.eait.uq.edu.au (hazel.eait.uq.edu.au [130.102.60.17]) by smtp2.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id tA8M5RbK002386 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 9 Nov 2015 08:05:27 +1000 Received: from natsu.mindrot.org (natsu.mindrot.org [130.102.96.2]) by mailhub.eait.uq.edu.au (8.15.1/8.15.1) with ESMTP id tA8M5Qcs032253; Mon, 9 Nov 2015 08:05:26 +1000 (AEST) Received: by natsu.mindrot.org (Postfix, from userid 1000) id 5DA32A4F31; Mon, 9 Nov 2015 09:05:26 +1100 (AEDT) Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id 5D169A4F30; Mon, 9 Nov 2015 09:05:26 +1100 (AEDT) Date: Mon, 9 Nov 2015 09:05:26 +1100 (AEDT) From: Damien Miller To: Peter Gutmann cc: denis bider , "ietf-ssh@netbsd.org" Subject: RE: New version of rsa-sha2-512 draft posted: no more DSA In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B56EBA@uxcn10-5.UoA.auckland.ac.nz> Message-ID: References: <1837603091-896@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B56EBA@uxcn10-5.UoA.auckland.ac.nz> User-Agent: Alpine 2.20 (BSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub X-Scanned-By: MIMEDefang 2.75 on 130.102.60.17 X-UQ-FilterTime: 1447020328 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Fri, 6 Nov 2015, Peter Gutmann wrote: > denis bider writes: > > >I have taken into account Damien's suggestion for rsa-sha2-512, and observed > >that there appears to be no reason to have rsa-sha2-256, if we have rsa- > >sha2-512. As far as I can tell, SHA-2 512 should be reasonably available > >everywhere that SHA-2 256 is available. > > Uhh, that's more or less the opposite of the actual situation: SHA2-256 is > fast becoming the universal replacement for SHA-1, while SHA2-512 is the "oh, > there's another one alongside -256?" alternative. For example Mozilla just > posted the following discussion item: > > In item #8 of the Maintenance Policy recommend that CAs avoid SHA-512 and > P-521, especially in their CA certificates. This is to ensure > interoperability, as SHA-512 and (especially) P-521 are less well-supported > than the other algorithms. I don't think the glacial* crypto adoption pace of CAs is relevant to the choices we make for SSH. Moreover, any SSH implementation that supports ed25519 in the future will need SHA512 for it's inner hash, so it's not like it will be extra code to carry around. -d * actually unfair to glaciers From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Nov 8 15:32:05 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97A671B4D95 for ; Sun, 8 Nov 2015 15:32:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Wiijj1UvbWcn for ; Sun, 8 Nov 2015 15:32:03 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 368D31B4D99 for ; Sun, 8 Nov 2015 15:32:03 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 2912214A210; Sun, 8 Nov 2015 23:32:01 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id D816414A20A for ; Sun, 8 Nov 2015 23:31:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id VYo4whgDIC2j for ; Sun, 8 Nov 2015 23:31:57 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 9404D14A1E7 for ; Sun, 8 Nov 2015 23:31:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1447025517; x=1478561517; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=DW+XK8Ddg2tntCZwkK06Rh5FEfCm6luoJqV/B5ShYA4=; b=5SVZTwXwdlJ+hkQ99pm35bqopuJ/W0Jw9rpV0WIU7bbR/tIWxgVdmjni RpD9qtQG2MXCmC2QYKopXJnzvTMaSjHQ9LmmPNL5sJr/BAJQNoQWD9xl6 UZ0mt/ji3hk5S6h1w5yDakmrF1193k6YI+f2FPo4LqKJXpKkTZWFkI70m 6RRe/SZ3eNCmJtwxtZFoyLbh8tBjOlZQiSEEWPAngWCJL8vHpKfcfe3pT jGdhxDSHqKpBwEUGUSedgur8Xp8ZpossZ7WaQqN5gSEvOTaq6PnFOcrni Ccb3vEABVewI4UFikHlRG4jhU70Y1QKvuzXmrz8i7sBaY00Lbl/p/A8z/ w==; X-IronPort-AV: E=Sophos;i="5.20,264,1444647600"; d="scan'208";a="53217029" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe1.UoA.auckland.ac.nz) ([130.216.4.112]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 09 Nov 2015 12:31:51 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Mon, 9 Nov 2015 12:31:50 +1300 From: Peter Gutmann To: Damien Miller CC: denis bider , "ietf-ssh@netbsd.org" Subject: RE: New version of rsa-sha2-512 draft posted: no more DSA Thread-Topic: New version of rsa-sha2-512 draft posted: no more DSA Thread-Index: AQHRF/ILEdK76i2qrUycWMyswUrF1J6OsjsbgAMnFwCAAPGmiw== Date: Sun, 8 Nov 2015 23:31:48 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B5A8AE@uxcn10-5.UoA.auckland.ac.nz> References: <1837603091-896@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B56EBA@uxcn10-5.UoA.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Damien Miller writes:=0A= =0A= >I don't think the glacial* crypto adoption pace of CAs is relevant to the= =0A= >choices we make for SSH.=0A= =0A= The OP wasn't commenting on use by CAs, it was commenting on use by clients= .=0A= In other words it was saying that CAs should hold back on -512 otherwise=0A= clients won't be able to verify the certs they issue.=0A= =0A= >Moreover, any SSH implementation that supports ed25519 in the future will= =0A= >need SHA512 for it's inner hash, so it's not like it will be extra code to= =0A= >carry around.=0A= =0A= This assumes that your implementation carries an entire crypto library arou= nd=0A= with it. Many don't, but use the host's crypto. If the host doesn't suppo= rt=0A= algorithm X, then you're out of luck.=0A= =0A= Peter.= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Nov 8 15:49:35 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5367B1B4F62 for ; Sun, 8 Nov 2015 15:49:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 l616SJhJupCU for ; Sun, 8 Nov 2015 15:49:33 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCF781B4F60 for ; Sun, 8 Nov 2015 15:49:33 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id E5A6414A136; Sun, 8 Nov 2015 23:49:31 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 2C2A214A12E for ; Sun, 8 Nov 2015 23:49:29 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id eLJQBsFXVgVJ for ; Sun, 8 Nov 2015 23:49:28 +0000 (UTC) Received: from newmailhub.uq.edu.au (mailhub2.soe.uq.edu.au [130.102.132.209]) by mail.netbsd.org (Postfix) with ESMTP id 30FBF14A11F for ; Sun, 8 Nov 2015 23:49:25 +0000 (UTC) Received: from smtp2.soe.uq.edu.au (smtp2.soe.uq.edu.au [10.138.113.41]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id tA8NnMHH038579; Mon, 9 Nov 2015 09:49:22 +1000 Received: from mailhub.eait.uq.edu.au (hazel.eait.uq.edu.au [130.102.60.17]) by smtp2.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id tA8NnMfA045850 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 9 Nov 2015 09:49:22 +1000 Received: from natsu.mindrot.org (natsu.mindrot.org [130.102.96.2]) by mailhub.eait.uq.edu.au (8.15.1/8.15.1) with ESMTP id tA8NnLj4017184; Mon, 9 Nov 2015 09:49:21 +1000 (AEST) Received: by natsu.mindrot.org (Postfix, from userid 1000) id 5A3FEA4F32; Mon, 9 Nov 2015 10:49:21 +1100 (AEDT) Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id 59A12A4F31; Mon, 9 Nov 2015 10:49:21 +1100 (AEDT) Date: Mon, 9 Nov 2015 10:49:21 +1100 (AEDT) From: Damien Miller To: Peter Gutmann cc: denis bider , "ietf-ssh@netbsd.org" Subject: RE: New version of rsa-sha2-512 draft posted: no more DSA In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B5A8AE@uxcn10-5.UoA.auckland.ac.nz> Message-ID: References: <1837603091-896@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B56EBA@uxcn10-5.UoA.auckland.ac.nz>, <9A043F3CF02CD34C8E74AC1594475C73F4B5A8AE@uxcn10-5.UoA.auckland.ac.nz> User-Agent: Alpine 2.20 (BSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub X-Scanned-By: MIMEDefang 2.75 on 130.102.60.17 X-UQ-FilterTime: 1447026562 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Sun, 8 Nov 2015, Peter Gutmann wrote: > Damien Miller writes: > > >Moreover, any SSH implementation that supports ed25519 in the future will > >need SHA512 for it's inner hash, so it's not like it will be extra code to > >carry around. > > This assumes that your implementation carries an entire crypto library around > with it. Many don't, but use the host's crypto. If the host doesn't support > algorithm X, then you're out of luck. What I'm saying is that any implementation that does ed25519 keys will also need to support SHA512. So SHA512 seems like a good choice if you care about minimising the amount of code that you want to carry around. ed25519 looks like it will be an excellent choice for embedded devices, and Peter Schwabe has a couple of MCU ports (inc. 8 bit AVR) already. -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Nov 8 16:39:32 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE4811B37DA for ; Sun, 8 Nov 2015 16:39:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 IFr5e5aIZyIz for ; Sun, 8 Nov 2015 16:39:31 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 869A81B37D7 for ; Sun, 8 Nov 2015 16:39:31 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 1403114A21D; Mon, 9 Nov 2015 00:39:29 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 550F214A0BE for ; Mon, 9 Nov 2015 00:36:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id w61xFqimpWXw for ; Mon, 9 Nov 2015 00:36:03 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 0971114A1FD for ; Mon, 9 Nov 2015 00:36:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1447029363; x=1478565363; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=1z34m8sZ+EBDGBXtcOHhuUg8imhcP6Wxt1C5fRiksfo=; b=sk20RhXEzQrEUnmtQ7FQhA6Uo6PmljRmNYItQtYIXvH+70owl5ubnl/Z OhraqwqbkUFcoLv+wYia0b+Yt77VYbvKQ8LCx6YKQdS3+GsHttLN9tm2b tFn4uduDQSKdVlpmx4GGXm4PbnVSRVo3f26ed7pAUcyMGT4eF9uXa94Zg ONRhXA1/3fz/LIbIZoLuIjcrEzpjQwIv9FvAUBCFe33boTaqcf/2MSyvm g5xhX/snWOSdQJbjx/y6HtoLQRw7tN5QgyNPhyeGU/rD148jAP2HyNYZ1 yEWouqF4lKzDNuRx4SsrBIr0VxbAelfqqNao7tXKULUTlBNPBRiKqr8JP Q==; X-IronPort-AV: E=Sophos;i="5.20,264,1444647600"; d="scan'208";a="53235028" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 09 Nov 2015 13:36:01 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Mon, 9 Nov 2015 13:36:00 +1300 From: Peter Gutmann To: =?iso-8859-1?Q?Niels_M=F6ller?= CC: denis bider , "ietf-ssh@netbsd.org" Subject: RE: New version of rsa-sha2-512 draft posted: no more DSA Thread-Topic: New version of rsa-sha2-512 draft posted: no more DSA Thread-Index: AQHRGlOUEdK76i2qrUycWMyswUrF1J6S2E0r Date: Mon, 9 Nov 2015 00:35:59 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B5A982@uxcn10-5.UoA.auckland.ac.nz> References: <1985908046-756@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B58ACD@uxcn10-5.UoA.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Niels M=F6ller writes:=0A= =0A= >I think we should try our best to have the set of REQUIRED algorithms make= =0A= >sense on constrained embedded systems.=0A= =0A= I've never really noticed any problem with the current set, typically time= =0A= isn't a big issue (as in, if ops take a few seconds then you just have to= =0A= accept that), the main one is memory use. That is, users don't see it as a= =0A= big issue, there are always some requests about whether it can be made a bi= t=0A= faster, but compatibility requirements with deployed code/devices almost=0A= always outweigh that.=0A= =0A= That's what a profile would have aimed at, a single well-defined set of=0A= algorithms and mechanisms so you don't need to support every option availab= le.=0A= I actually had a go at this a while back:=0A= =0A= https://www.cs.auckland.ac.nz/~pgut001/pubs/simplessh.txt=0A= =0A= based on what I'd experienced in embedded environments. The constraints=0A= weren't the crypto used, it was cutting out the huge amount of unnecessary= =0A= (for the way it's used in embedded) complexity in the protocol.=0A= =0A= >A few years ago I ported dropbear to a proprietary and pretty slow embedde= d=0A= >device, with only 8-bit arithmetic hardware. =0A= =0A= You got SSH working on an 8-bit CPU? How?=0A= =0A= Peter.=0A= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Nov 8 16:47:05 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29A421B55DF for ; Sun, 8 Nov 2015 16:47:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 3vSYOyQTHFfQ for ; Sun, 8 Nov 2015 16:47:04 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 219241B55DA for ; Sun, 8 Nov 2015 16:47:04 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 66A5514A211; Mon, 9 Nov 2015 00:47:02 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id CB7D214A205 for ; Mon, 9 Nov 2015 00:46:58 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id FpiajvcnsDe7 for ; Mon, 9 Nov 2015 00:46:58 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id A334B14A203 for ; Mon, 9 Nov 2015 00:46:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1447030018; x=1478566018; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=V+wDSPb5mnlpGqxl7iRUdsVpQD4pXQgsxaZgnWJgOAY=; b=UHGkcndT9jSd/fDe06hy3QTm2i43NO1sIRSABgSG3ibh1Xn0V19KrxYn 6rNehWE6ks6I4fvXWMK+itskjWLgO1PtTbSDrYKI7tPHZCHLG1Azs6Bs1 gxZoLrkVDOwt5NkBnMg73dLoP+npYLEzRYhme6rjVNfSZA2ZYMJAcOt1H 3v99I7fYKdyED1uKmNon8DejheILCsij9diE+khm9SHYjfmdxtYRKDogn eetzMA+rKeiT0Lj49vvm1HdjyW3mBmwTAVr0t+MMjC0bjIWvJkXmShOY0 i6MOymWlAvftz1Vti/rrksFQY4cZHGdMQWOsklnuZafEgAO2BM7cll5i9 Q==; X-IronPort-AV: E=Sophos;i="5.20,264,1444647600"; d="scan'208";a="53237256" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe1.UoA.auckland.ac.nz) ([130.216.4.112]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 09 Nov 2015 13:46:56 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Mon, 9 Nov 2015 13:46:55 +1300 From: Peter Gutmann To: "Mark D. Baushke" CC: denis bider , Jeffrey Hutzelman , =?iso-8859-1?Q?Niels_M=F6ller?= , "ietf-ssh@NetBSD.org" , "stephen.farrell@cs.tcd.ie" , "jon@siliconcircus.com" Subject: RE: DH group exchange (Re: SSH key algorithm updates) Thread-Topic: DH group exchange (Re: SSH key algorithm updates) Thread-Index: AQHRGkUqWMzLJpSvpUGOgEa2UJnMnp6S2nWL Date: Mon, 9 Nov 2015 00:46:54 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B5A9BC@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4B5993D@uxcn10-5.UoA.auckland.ac.nz>,<2096379125-720@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B599ED@uxcn10-5.UoA.auckland.ac.nz>,<55190.1447001241@eng-mail01.juniper.net> In-Reply-To: <55190.1447001241@eng-mail01.juniper.net> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list mdb@juniper.net writes:=0A= =0A= >That said, I do not find any FIPS or NIST documents talking about Lim-Lee= =0A= >primes for use in FIPS certified systems.=0A= =0A= Sure, because it post-dates the original NIST docs that specified the keyge= n.=0A= The idea is that if you need FIPS validation you use the NIST generation=0A= method, if you don't, you use any method that works, one obvious example be= ing=0A= Lim-Lee (same result but much quicker because you're generating lots of sma= ll=0A= primes, particularly useful if you want to generate a new DH parameter set = on=0A= each handshake).=0A= =0A= Since the verification process for both 186 and Lim-Lee generated values is= =0A= identical, you can verify the keys either way. So the spec would cover bot= h=0A= NIST and non-NIST options at the same time, depending on implementer=0A= preference.=0A= =0A= Peter.= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Nov 8 16:53:13 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652521B5663 for ; Sun, 8 Nov 2015 16:53:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 XnrvtLxwSXqa for ; Sun, 8 Nov 2015 16:53:12 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A361D1B5662 for ; Sun, 8 Nov 2015 16:53:12 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 9D01814A21A; Mon, 9 Nov 2015 00:53:10 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id F093914A205 for ; Mon, 9 Nov 2015 00:53:05 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id reyS99RtetKV for ; Mon, 9 Nov 2015 00:53:05 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id B51B714A1FA for ; Mon, 9 Nov 2015 00:53:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1447030384; x=1478566384; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=90nV86L87tMekyHk7SS2ref/VXy32BTOFvDzPJ3bENk=; b=k8TZEWTpLuWTXnR6hUQIy2Na5Rfpq8KN5xWSNfI/gEA/OG0r15rXiER9 EXOiCB/OPpNwkXxsBEzdEoGyIUnBX1MB64UgiZtZEMBMbLinBLHG+E2rT c1sDO+9m9MJ7mEI0W6RqJ7UQdpKIWhb/OOmkb386sxZQMtjc+G1AIT9eq B35bKfJX8jAvYjqN0bCvdFvZ5yxg3bDGJlvIm9+LB8Tf8Bq8RDvmvfbJP tMmLC1TbfQZndiAsNNyft5rCl1QqdlFVz+Qf1KJiwrHVXP80OOyBDBmXz ADxw66n6LAgbX4CV4/gvE/aSmzACqpk4rjLI4zBWnFVyIoglSnl44aDhA Q==; X-IronPort-AV: E=Sophos;i="5.20,264,1444647600"; d="scan'208";a="53238709" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 09 Nov 2015 13:53:03 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Mon, 9 Nov 2015 13:53:02 +1300 From: Peter Gutmann To: =?iso-8859-1?Q?Niels_M=F6ller?= , Jeffrey Hutzelman CC: "Mark D. Baushke" , denis bider , "ietf-ssh@NetBSD.org" , "stephen.farrell@cs.tcd.ie" , "jon@siliconcircus.com" Subject: RE: SSH key algorithm updates Thread-Topic: SSH key algorithm updates Thread-Index: AQHRGkGtBkokXX9VnEy0Wo+WRjNjMZ6S3T/r Date: Mon, 9 Nov 2015 00:53:02 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B5A9D4@uxcn10-5.UoA.auckland.ac.nz> References: <1297540000-2044@skroderider.denisbider.com> <51845.1446188002@eng-mail01.juniper.net> <1446228753.32676.1.camel@destiny.pc.cs.cmu.edu> <1446789400.4752.33.camel@destiny.pc.cs.cmu.edu>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Niels M=F6ller writes:=0A= =0A= >First, it totally defeats the original purpose of group exchange, which wa= s=0A= >to avoid wide use of any particular group, in order to reduce the attacker= 's=0A= >gain from massive precomputation.=0A= =0A= Something even scarier, first pointed out in the Logjam paper, is that (at= =0A= least for TLS) some server implementations precompute g^x mod p and reuse i= t=0A= over a period of time, so every client that connects gets the same DH phase= 1=0A= value sent to them. It's a nice efficiency "optimisation", but it turns DH= =0A= into something that works more like RSA (or, since it's DLP, maybe Elgamal)= =0A= than DH.=0A= =0A= I wouldn't even have considered that someone would do that until I saw it i= n=0A= the Logjam paper.=0A= =0A= >Second, if fixed groups are used, then those groups ought to be subject to= =0A= >both standardization review and negotiation at runtime.=0A= =0A= The benefit of fixed groups is that, as you mention, they can be reviewed, = and=0A= also that they're a lot more efficient than on-the-fly keygen, particularly= if=0A= you have to use full-size safe primes rather than the Lim-Lee swarm-of-smal= l-=0A= primes trick.=0A= =0A= I'm worried about this short, quick draft turning into a tutorial on how no= t=0A= to do DH...=0A= =0A= Peter.= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Nov 8 21:28:29 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1691B650A for ; Sun, 8 Nov 2015 21:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 PlzMObObETtq for ; Sun, 8 Nov 2015 21:28:28 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A7AB1B651E for ; Sun, 8 Nov 2015 21:28:21 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 5462414A247; Mon, 9 Nov 2015 05:28:19 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 24DE914A23B for ; Mon, 9 Nov 2015 05:28:13 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id OnTyh--BpvpO for ; Mon, 9 Nov 2015 05:28:12 +0000 (UTC) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0797.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc0c::797]) by mail.netbsd.org (Postfix) with ESMTP id D2FCF14A223 for ; Mon, 9 Nov 2015 05:28:11 +0000 (UTC) Received: from BLUPR05CA0051.namprd05.prod.outlook.com (10.141.20.21) by BLUPR05MB053.namprd05.prod.outlook.com (10.255.210.139) with Microsoft SMTP Server (TLS) id 15.1.312.18; Mon, 9 Nov 2015 05:28:08 +0000 Received: from BL2FFO11FD008.protection.gbl (2a01:111:f400:7c09::119) by BLUPR05CA0051.outlook.office365.com (2a01:111:e400:855::21) with Microsoft SMTP Server (TLS) id 15.1.318.15 via Frontend Transport; Mon, 9 Nov 2015 05:28:08 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=juniper.net; cs.tcd.ie; dkim=none (message not signed) header.d=none;cs.tcd.ie; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.17) by BL2FFO11FD008.mail.protection.outlook.com (10.173.161.4) with Microsoft SMTP Server (TLS) id 15.1.325.5 via Frontend Transport; Mon, 9 Nov 2015 05:28:07 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 8 Nov 2015 21:28:03 -0800 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id tA95S1D17686; Sun, 8 Nov 2015 21:28:01 -0800 (PST) (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 4586C11494; Sun, 8 Nov 2015 21:28:01 -0800 (PST) To: Peter Gutmann CC: denis bider , Jeffrey Hutzelman , =?iso-8859-1?Q?Niels_M=F6ller?= , "ietf-ssh@NetBSD.org" , "stephen.farrell@cs.tcd.ie" , "jon@siliconcircus.com" Subject: Re: DH group exchange (Re: SSH key algorithm updates) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B5A9BC@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4B5993D@uxcn10-5.UoA.auckland.ac.nz>,<2096379125-720@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B599ED@uxcn10-5.UoA.auckland.ac.nz>,<55190.1447001241@eng-mail01.juniper.net> <9A043F3CF02CD34C8E74AC1594475C73F4B5A9BC@uxcn10-5.UoA.auckland.ac.nz> Comments: In-reply-to: Peter Gutmann message dated "Mon, 09 Nov 2015 00:46:54 +0000." From: "Mark D. Baushke" X-Phone: +1 408 745-2952 (Office) X-Mailer: MH-E 8.5; nmh 1.2; GNU Emacs 24.3.1 X-Face: #8D_6URD2G%vC.hzU MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1;BL2FFO11FD008;1:2tc0+yBadwVshcasxCrBZtOGiuD7OuYrmac5UhuPLRWj6roigNMxf6cAPGbeL/MZM5vE12O76NQyYTImHVANMfn28u0p6KINdSueB98QeL5748ZFPuRpl+8FxpCB/oodXsdjW8UP+a0J2ca9hWhcsBv4B9dB15gd7buZ7ydLk9fM4mp1RcszNUy90fY6YkKBqCZ+LrEBL+i2ge4hOOJm5iAtjloN+rZncGBdUjjyzE2+CWe3vWU1COP/H4zPqApyGNtvxrqV9/lWjIJrTK+8hdimlHSiCciel8LHkPyQqtWP9rVgG6o0aPIU1OX9OkxC933obB2Maf0/ttRKBgNHePe7iConnyblggtfHoYT3FdWhbKbqi3dWlqmreDIno1QDx6+glwLm0aoK6R0vYuHjg== X-Forefront-Antispam-Report: CIP:66.129.239.17;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10019020)(979002)(6009001)(2980300002)(199003)(189002)(87936001)(106466001)(76176999)(50986999)(77096005)(47776003)(5001960100002)(2950100001)(110136002)(53416004)(92566002)(189998001)(117636001)(76506005)(48376002)(5001920100001)(97736004)(5007970100001)(19580395003)(69596002)(93886004)(50466002)(81156007)(5003600100002)(6806005)(105596002)(5003940100001)(11100500001)(86362001)(19580405001)(50226001)(42262002)(969003)(989001)(999001)(1009001)(1019001);DIR:OUT;SFP:1102;SCL:1;SRVR:BLUPR05MB053;H:p-emfe01a-sac.jnpr.net;FPR:;SPF:SoftFail;PTR:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BLUPR05MB053;2:MEDE/t+/CcyKYmgq7bWCpw0hhgW2Xw2jLGSASNVdvss6hGgQWVCE9yQZepuTdz0/S92zIeHCRczCPr0JToE4IlPAegG3ter/GvHAgMJthTCWedauUZjxuTVxKiUQqBi6Grueq1LWqvQ2HJchBWNxXDcVIoz18b4OUvxmZDksUKI=;3:SYNC+luq7jS+2nfjGi8SPWJ/geqrLBgOY1ewSgVWq61z48qC1kBFkj5NxWtB33dMr/c3O6YSojDyB/RLJRZ+HaSpuPCjKy8MRAfRLWQUZWdxjmtPiIFcmJyrl5zF22DRufCs9kbAxF9Jwg8avtJm/PPCjIz0fnKVXdSa0jQHvnNewhDhCsb2XY1l5FQXsgdwsgnIhczG85OBH461GuVaSLBQ0AWMss0tEX0nEZNlImA=;25:LhHf60kxUUHS4TGJtyLWHWOAhg60qDuWYLnxdBbd1UlMm67MDJDurYD4kSurx4pGqY69vlG4col6MS0LOQYgOrkLLPH1+hxzZgCtiRPN6AGj6Xy5Z63jwq6RPd70w/l8ytibsCAXp/HEa+mCA/bonYdN+OrgDvsGqz3sPXtualcKT3rfZIwRatPuVmlupVLIpbouD5Z0shF8dOnbhU8CFiBq4Z3I6PYiFLs/91wsOwVWqeIj/Vz1km0Fr8Gwyb+i8c7n2uFSkDaTJnHylYIwQA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB053; X-Microsoft-Exchange-Diagnostics: 1;BLUPR05MB053;20:/UsuzRlSUANRwgPb0pHYvCrFYiFLX3YlhDRIPgiWlrarqV4pivqkdw/CFJmBgD+3TX+MdvoR0hTgnZ9tCWZcAkQfIbwmxB8c5Vq2REDxubNuFnzBbg7vuz3WpMynO7r7MwQ+EGcZ+vZQtWIm9OKhN3wTREbFk2yD2ic1krdnYdVqdbMuIjN6X0tpHKgZiXRE8y7r0KnJJ9popTYgmvY+b4DG0McSfgHh1rGy9nBPMCuTMFyovejbryUS/mAWqhObgkfOfOrIRNSnTMYmjTLfcWkW3cLyuByF0Fa1jYU1QMb7CmODnxpyJpZpY4WOYc/ev6fK2Vhl2D3A/Uwy4GwVlqji/G9KLDXOlLV/fzdoswBWR5lvcR+IjB/dDDLVEeTXfzXA+UmO7U7IgCKCrbrl38t5HN5DXeTUiRKVsLK5CFlOv/66Jevs/JCucyjPqtYDiQX3xQ+CQBVFKAVdnQ8Xm+8TLl+bUkT8IzTRk20VJPc4DLE0C9rN1kiba+thqpWC;4:KEq55rN05swr8oZ362GJUeKxTiu172UsuAXpFD/TjPSyQdM0D3AWgsAKAkmxKqx+2JjcU+9eGfw8OPNOSYm8CsMwgODOtji7oB58Jg3ECzIQfBAlYcGZ/il5rXTsG5A5oyZW+0QyX6w64j0U16NsCE3UN7F761KPRGmNmhXI6Rep30xFAqGGajXtwNhfX5izyQT1rzFQxA7WfOOGO6Zx20itptzsrXhAFWtThpApEY1hWaR1pntFEbHOzbw1hVkcgjGQO383rt9ndRaFGvyJPZYO7XIoopkThwIXqEXWdwHkMqTweiz/Wyy+MRUVwV5bd6I9xMiCJl2CAO1wtqCgxLsGkgUneWS20c7Yir0wfJVs9RFLqvAo/Ajmh7vpHlrg X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001);SRVR:BLUPR05MB053;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB053; X-Forefront-PRVS: 0755F54DD9 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;BLUPR05MB053;23:vQR8E7A4Fo4Tn7loPWD4XYVkwLO4clrQwDbiCKp+Lm?= =?us-ascii?Q?x7u+rUux0Q7+/zD1DLWtlKWCURqSi6s7AppCukeAFT8tuG2Lzl0vxn0V/qI0?= =?us-ascii?Q?CnXXWHJoFHz6avZFUk9jB9P/9/tD54NhzM3kMF8VIMrgSm44KOpxLDzUEYBa?= =?us-ascii?Q?I68HONAdMjhVeiwQD7s2DF1OTtmUg4Iu5COmW8obhRofB/VlZZSnxSrQYEED?= =?us-ascii?Q?tTKx25M8rkXIVLMAOEh1r1TGfV5rGwZQk0sHCShpg6R8wWKxDj2lhcTymu6l?= =?us-ascii?Q?ZUAOSYSkDNXEQAkOhZsmqWVTdld+drJxXr+7eBpk//A50Xdsmt89LjINVbBQ?= =?us-ascii?Q?qhtv67s1fyTChqdmzuWC9V7+1V6jQE9UVnfngRdKZZ6DvWkw/9jaxkT3EJAd?= =?us-ascii?Q?1xaPE7Fp0oM9JgQmQkRD2+L5jA0WgUaxgi+IslfTD7uhd/hiDvnJ+z4vmKJW?= =?us-ascii?Q?XKPLzdF89/9loiV6cFgh45YPIzrOBD7bqLPxXKZu5emVbMMa5CmJHlw2wnbj?= =?us-ascii?Q?Bl9YaNA8EpEEuvbZI130Wnq7tJDnnNNLaQKD3gcFHa/E1YPmnymesDc9Fr3a?= =?us-ascii?Q?IUwXMZIb6GV/VV/QPsXLZ3XOH0rSvf0yLWYHW15vGf2fIQNE7XQrFcXalIIK?= =?us-ascii?Q?0fk+8mi/mACF+9Jb2v4UgVCUonCL9lkoW9HyS22w7PQ3gf0mwIkgaGhOSB7R?= =?us-ascii?Q?6t6MOSUzOXX2UdjmhOVj52UD7mVN+IyVqUCMu8OmpeKQJiSiTtP03Wd4mANA?= =?us-ascii?Q?yE1+of1fUTc5DLI40jFsYAoR+s/IyQ+Izg/VYkfMWOGwUwSctrayuWOXjG2A?= =?us-ascii?Q?bXvP0wc0VL2wqkyHyxPwyh07ZYvQR27VCOSnKv1obJHq9a+KiAt7VEWXBdZt?= =?us-ascii?Q?EyW8+9DQClrmQRXuaBnqF++5aaGfx+SO/eAEoDkOWdavyvKoA0hqfnh4ywAS?= =?us-ascii?Q?lAyVjFK79lBAd3x9G9pJstI0QTWUm7h/uP/XtN8xuAnTr7C1wui/bzAnY01l?= =?us-ascii?Q?RFTXYYYHPeIilrseAC7ES27s8GJgNwtA+eCGhdRanTb7VhpzK3Yn9JQ4tlSr?= =?us-ascii?Q?6qqKsDBuDzZhEBZaMp2e4DjYQBjnFjOt4Fr1aVN1OXkAzjTQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1;BLUPR05MB053;5:MHn0hvvYsrlNWDi0RDMayVus3h9115JLmqtPelnNyonRG6Zn/wyzqpvHXb9ciUTvCZt84AAKaU3AqNgQYJFSlpsiloSuFkTqAFe+//CPEpCXGZB09XLQvcMo1SI1JZ8Ast+q6p8prmrBHAB4OTcVNw==;24:dJO/E6l5267PYX5I5nciLnJSzJ/sZpZMy62odqj3G9NBBib0T4EowtP0UgsmM7H+EUrTK1jiR9EbXbbdsfLVFf93Mzpm5ojsJFfmyoG/w8A=;20:QqisJ9/0hK0Q7KKutpvQYrpSXW1E+eeX59xR7nzYjC9zOD/Kv5yi0nXgm0Jt93/mQwK0gMOjhNIrILYPm7wvPw== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Nov 2015 05:28:07.5680 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.17];Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB053 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hi Peter, Peter Gutmann writes: > mdb@juniper.net writes: > > >That said, I do not find any FIPS or NIST documents talking about > >Lim-Lee primes for use in FIPS certified systems. > > Sure, because it post-dates the original NIST docs that specified the > keygen. I am under the impression that Lim-Lee published their paper in 1997 "A key recovery attack on discrete log-based schemes using a prime order subgroup" FIPS 186 was published in 1994. FIPS 186-1 was published in December 1998. FIPS 186-2 was published in January 2000. FIPS 186-3 was published in June 2009. FIPS 186-4 was published in July 2013. so, for the last four editions of FIPS 186, no mention of the Lim and Lee algorithm has been mentioned... I would have thought they might mention generation of q in subsequent publications, but I only really ever had to deal with FIPS 186-2, FIPS 186-3 and FIPS 186-4 myself. > The idea is that if you need FIPS validation you use the NIST > generation method, if you don't, you use any method that works, one > obvious example being Lim-Lee (same result but much quicker because > you're generating lots of small primes, particularly useful if you > want to generate a new DH parameter set on each handshake). Yup, a FIPS compliant system needs to generate new FCC Domain Parameters for Diffie-Hellman using the method described in FIPS 186-4. A non-FIPS compliant system would be free to sue Lim-Lee if they desired. It is possible to generate the values outside of the crypto boundary in which case only validation needs to be performed, but that does not really live up to the expectations of RFC 4419 which wants to be generating new DH parameters for each connection, or at least be able to randomly selection a set of parameters that have been calculated in the short term rather than the long term. > Since the verification process for both 186 and Lim-Lee generated > values is identical, you can verify the keys either way. So the spec > would cover both NIST and non-NIST options at the same time, depending > on implementer preference. So, the RFC 4419bis would include both parameter generation techniques as well as coming up with a better generator g that would always pass for a non-FIPS compliant application talking to a FIPS compliant application? That seems reasonable to me. -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 9 14:25:23 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2D41B863C for ; Mon, 9 Nov 2015 14:25:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 6o-jwDay_ene for ; Mon, 9 Nov 2015 14:25:20 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CB351B8635 for ; Mon, 9 Nov 2015 14:25:19 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 313D714A2C3; Mon, 9 Nov 2015 22:25:16 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id E733114A2B9 for ; Mon, 9 Nov 2015 22:25:05 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 1IfqDA8RIcui for ; Mon, 9 Nov 2015 22:25:04 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0711.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:711]) by mail.netbsd.org (Postfix) with ESMTP id 64EC214A2B2 for ; Mon, 9 Nov 2015 22:24:59 +0000 (UTC) Received: from CO2PR05CA016.namprd05.prod.outlook.com (10.141.241.144) by BLUPR05MB053.namprd05.prod.outlook.com (10.255.210.139) with Microsoft SMTP Server (TLS) id 15.1.318.15; Mon, 9 Nov 2015 22:24:56 +0000 Received: from BY2FFO11FD025.protection.gbl (2a01:111:f400:7c0c::196) by CO2PR05CA016.outlook.office365.com (2a01:111:e400:1429::16) with Microsoft SMTP Server (TLS) id 15.1.318.15 via Frontend Transport; Mon, 9 Nov 2015 22:24:56 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=juniper.net; cs.tcd.ie; dkim=none (message not signed) header.d=none;cs.tcd.ie; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.17) by BY2FFO11FD025.mail.protection.outlook.com (10.1.15.214) with Microsoft SMTP Server (TLS) id 15.1.325.5 via Frontend Transport; Mon, 9 Nov 2015 22:24:55 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 9 Nov 2015 14:24:41 -0800 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id tA9MObD99554; Mon, 9 Nov 2015 14:24:37 -0800 (PST) (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 857D61148D; Mon, 9 Nov 2015 14:24:36 -0800 (PST) To: Niels =?us-ascii?Q?=3D=3Futf-8=3FQ=3FM=3DC3=3DB6ller=3F=3D?= CC: Peter Gutmann , denis bider , Jeffrey Hutzelman , "ietf-ssh@NetBSD.org" , "stephen.farrell@cs.tcd.ie" , "jon@siliconcircus.com" Subject: Re: DH group exchange (Re: SSH key algorithm updates) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73F4B5993D@uxcn10-5.UoA.auckland.ac.nz> <2096379125-720@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B599ED@uxcn10-5.UoA.auckland.ac.nz> <55190.1447001241@eng-mail01.juniper.net> <9A043F3CF02CD34C8E74AC1594475C73F4B5A9BC@uxcn10-5.UoA.auckland.ac.nz> Comments: In-reply-to: Niels =?us-ascii?Q?=3D=3Futf-8=3FQ=3FM=3DC3=3DB6lle?= =?us-ascii?Q?r=3F=3D?= message dated "Mon, 09 Nov 2015 19:22:44 +0100." From: "Mark D. Baushke" MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Nov 2015 14:24:36 -0800 Message-ID: <65113.1447107876@eng-mail01.juniper.net> X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1;BY2FFO11FD025;1:TbCPPvxZ95+txYr27O8kGVUNoWfwofV0Txl3PHTiUTdBSmwadJRH6mPg6y29hNQ9AXcip8f6khvSpXXPlZSaAbFMexv8dw14kLHmRiA3JGuPLTFQqV1d/aZsPkN+FzhcuOg1qoS8+3/Q6XgUlgcY6LnKkeNohk6mq0T6N3s3BmrbIYhYslGe+ljkKQfSW3MyeBNYzkYWZbCks0Vvt+FuSf8j9RDQRwIH5H8MTffm/irZUT35D4ittG9RSb41O8FbSJOEwDNMxwJg13Q661skG5cnOihcU9SqHYDNg2bDojORqZHO7CuTHGYUsuG/JVLWS5tcPrEHv8+NahKVYG8NRrSS5By7pjE5eus+sG9ySkC4r7J0+ge1nmHYFippjedn/jNIaFFzFxIqKh3KiK0a4w== X-Forefront-Antispam-Report: CIP:66.129.239.17;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(2980300002)(199003)(164054003)(189002)(69596002)(47776003)(50466002)(86362001)(87936001)(23676002)(19580395003)(50986999)(19580405001)(117636001)(76176999)(105596002)(11100500001)(6806005)(106466001)(97736004)(92566002)(2950100001)(81156007)(189998001)(5001920100001)(54356999)(77096005)(110136002)(5003600100002)(5001960100002)(5007970100001)(76506005)(53416004)(93886004)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:BLUPR05MB053;H:p-emfe01a-sac.jnpr.net;FPR:;SPF:SoftFail;PTR:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BLUPR05MB053;2:SmWRXdIfXjaXQ9QCXdIln4gkJfqXQk2JNNm/D6TpVAP0YxiCIFijDboWJryio6DNYxzJKVuER/UQD+hPTwk9V+Fc8R/hEVBU63N4eZ1Z9SvYVlaGCG7BfRTvEzQfskgzuBC/AjbV9Z3youflP21sLZkmEkIf1JcVL/RJvrfVMrc=;3:HhrTKUnpNOgz2EPKgyeMyn0YD79uSotm2M0XGYy/X1ONWpH2pG5AUNcLXN4oagUabK3R7N3UObZquOC1vh4tkCJ7+6mKAT2UazGMxcVng+HaQO5AfD4HtTkXR9F1ilGJU1pYsLaxbtqSbAdTNfIon1qwDB72HHbkGkETSIi+FVIfVB34DLJsnkuZCZlIBQI8SzVWZPDGUzDnuN6HFxYutALU5gIfivlM3wjG4tIf2HU=;25:hAka7/upjjdx9tzOnL5LklrPoVH7eJK7iMUbraMptR1SSj5iltvBhaBhBZn5Gkd5vBorRkLs4wmRStbELrzsi6UvNCpp2ruSBKvA3XzpuMTjnxibWEXFELAcr0SVr8WbJpAdv86VtVsdODeRfpHG1cylHn6AdQj7z8kRKdPak5m5WTwt3q62xoMQ65iu81M2bfFP3W9XzZl2wvRwPmMELpUICSalXsGePZY/z52jhZcjxFCIJPE7z2CfzkLhyUkQMldBd0UDbyfHqw4aUDr/+A== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB053; X-Microsoft-Exchange-Diagnostics: 1;BLUPR05MB053;20:R8AIt8Qr+G9yYu9zmqYKDPbo72eQ2c8YhYkyfCGs7DhbhcGVUZSkQFE4MEd9Pi8hxIYt5SyTwckMp8ncQBBw1VtV58xDhbEsUlzA5xKM0ZdvPx9/Gasc7p4cfFrtAWEGvvO3Ky2EIog/Ap4tUQKSs97974BNVJYL/iwDKLozSKprGtqSRLeLeH4JqHkq6Ryo6Ns3IHe3zHz9rZYAwN99hy8PB9tN0akw4qmlDiDEDzeuA43uM+3r3btm77tpGFAlYDbMVoWYk4i2gUafRl6CsRGK46rYdUE1YBt0umc5Rp8AQyii5+Is/Xg8aVDgE9E05QfKQQTPP9/cXq3mp7WEYbzvyy9GzJ5pZWnESBd0cuUTnZq2w6KXQxWDNYjeOITlUP9UEnSI+g+9Z4ENP6Zgwak81El2YnQCh+inJzvaN2A4TsUUtupfOZlOMJBjrSiEQIGvNXFXFqQllQ2km5Inphv65yqWJymXpoMiv8zyfaB1AdwdLIkt04xbEigqNx6a;4:64bjSfMCM6vPDSyKV7ImwbpqhNpM20CTsdcaV6yLvaS/6GSvbLw5a1uXZcIe/AH725WfsG0U3/1FjKAqSyIdG4eVD3EXZFWc12qKmcBaZrbFZkalfWrjZrZpMIncV/x2Bdy4fY0EH5tQ6Zpglpuev8cb+QigFV/i6RroIbp0FB3N+IndDUVfkgAfSVBO4E0XLlpk01xVVqQgCVqv22KlMUKdl76DIlDchhEwQML76qjlgr+n4ZKb8aycMwwhqxh1C/FjQ0+VVKbthVE/0m9bzAjEWKi983n+OzOyIY+utZil4sNki3ECZ18mhpKpS2td0RESjEZ4Ix62CIUg1jwr8GECbrxFwpGXoSOyWrfXUGVEtvaQHjcgT78iRFvmu4j4 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001);SRVR:BLUPR05MB053;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB053; X-Forefront-PRVS: 0755F54DD9 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTFVQUjA1TUIwNTM7MjM6NGFsUitIVjFDVzJBL2FHY0M1K0Rkc3RkQUNO?= =?utf-8?B?MWJkZmlhOFVFdUE3YkFhZWh1ZC8rN1VtMkp1Snlzd3oyenA4akN3aE96MThP?= =?utf-8?B?OGJVSWNRZlpoa05QWGh1UHF3L1FHeUsvM3QvSUlUeHpmUHRPako2QjF2WlEy?= =?utf-8?B?ek9NVktCellMcjhXZEtlSVZXZUFBYzFUREx4UXgrbHNrZWdEbzdoYS8zMHlE?= =?utf-8?B?UU11TjlNWlNyYXk4R0Nwd1BnUGVxVjdzMEZmMkdSVGJ0NGQyQmxNK1N3QU4w?= =?utf-8?B?YUtLNFFFSnBnMTlCVW8vV0ZoV3M4RHlYYXMrTmJRMlFRK2tuQmRVTzdZcVlZ?= =?utf-8?B?VEhpY1hwZ2FDLzlDTVFsdEZZVVlNR1VnZEREbWZvMHY4czJmSE40Uytnc3I1?= =?utf-8?B?NkZMWGRhOHUwQy9YQ2tKK1dwOVladlNsRkhmZm5uWVZkaWtxejA4SEhjRUZq?= =?utf-8?B?dndvR3VVMU9NS0NQRy9ibWlMc0pJQ0ZqVzBIUWJqaW4wM3NPWENQZzlkTHI3?= =?utf-8?B?NDJnUmZSa1RYQ1NpSGw3RXUzN2hET2JwOXlJMW44T1U5RXNCWUxuYUtTRXNZ?= =?utf-8?B?N1JpdUZua0lxcTVKdUpCR2JMV1FkeGVYMEcyTnEvZ2dHUzhSVk9FYzQ2dDRH?= =?utf-8?B?MW1NZk02dzFISjd1MXg3bkpGNDduU2p5V0FXNmROazVhYVJ1UDIrMkRhWm8z?= =?utf-8?B?dkFLSUVmek5DK1lFUk9uVG55bGRpczdkQ3JHbFhuZ3FsTWFlSXRiZXBEYTJu?= =?utf-8?B?MXZsNGRLTlVnME9DUTNjTmxLNzlHR0ZNSXI4T3pPb2JnWDFHOUxKNHNqazR1?= =?utf-8?B?RDBTaWFNL1M0SC9pcDVaYXhaZEI1ZnZXUVhZM0NzU09KbnVrSUw4M0R3R1Ew?= =?utf-8?B?eStnRW5PMWFyd0t5WU82QnAyVDNweWJKQ21jdyt2bHpMNFcrZVM4aFI0NUdS?= =?utf-8?B?YWxxZENUTXBlNlpyc1J5Zk52eER5NG8wb052UitNanFJKzJqYzAyRGcyaUxX?= =?utf-8?B?V3lnV0YrYTVOOUMrYW9ieWdPMWxTdzhIaVZET0tGN053U3JSZVRZYW5EM0ZP?= =?utf-8?B?RGs1ZVNleXdiOHhPUDJjanVNTk5zNXVQeXIreXNZN2U2R21ETkRPTjBuR2RU?= =?utf-8?B?OHVsMnRGMmQ0L1gvR2NWbXpqemlwelBCcTZWTzRGRUViRDFoZm4yUHJXUU4z?= =?utf-8?B?dWoxRG5OT2wrOGptTFI1VWl4T3hYVGdTN2VFUTZjQTl5ZkZEY2lEU0htYmpq?= =?utf-8?B?bFZBbmsrRUFHRzNhR3RDZVdCdG1zVEdubWVpUmUvVm1SS21US0FJbVFJY3RV?= =?utf-8?Q?pyo5CD2qIkW8qhCQZ0CN+ie0RrULj3c=3D?= X-Microsoft-Exchange-Diagnostics: 1;BLUPR05MB053;5:PwPt/pkviK2NoyQD+u/aZ3gxSnMDh7/1bYVOt68uL4pwx5LP+bcsc6e2cfJxmCWWQTg1geRWoLl4INylxDttLKvrhn2TfO6n0SZiRw8Nqg1wqwiChsNgnBmteFBz/EIzdeGVOFoDbETLcMjys7Rkyw==;24:zmnMwXTsWvtER3A5Umi9DePy58DqcuTI0UHykS17m8H78G0WC8CyGqkgStICQqCg7ECCb9hSQJtp4hXkrtw+D9XuHK5I2dTTxnle9uWYbGw=;20:/ULHgsdguYcZL9bena6emdhuxke84tv+9m0+wKO7xxdBpv7cFDgNshMLy84Yrfftj/9IdmjDRzzxZ3X9nyBS1Q== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Nov 2015 22:24:55.3228 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.17];Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB053 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hi Niels, Niels M=C3=B6ller writes: > Peter Gutmann writes: >=20 > > Since the verification process for both 186 and Lim-Lee generated > > values is identical, you can verify the keys either way. So the spec > > would cover both NIST and non-NIST options at the same time, > > depending on implementer preference. >=20 > I'm not following the fine details here, but does the verification > step include proving the primality of p (and q)? There are two validations in FIPS 186-4: a) Section A.1.1 Generation and Validation of Probable Primes b) Section A.2.2 Assurance of the Validity of the Generator g A FIPS implementation of ephemeral Finite Field Cryptography is expected to generate p,q,g parameters using FIPS 186-4 methods. There are two validations in NIST SP 800-56A: a) Section 5.6.1.1 FFC Key Pair Generation b) Section 5.6.2.4 FFC Full Public Key Validation Routine A FIPS implementation of Diffie-Hellman is expected to generate a Key Pair and do parameter validation using NIST SP 800-56A methods. Right now, an implementation of RFC 4419 may assume a Sophie Germain prime q with safe prime p such that p =3D 2q + 1. RFC 4419 section 6.1 Selection of Generator will often lead to values which are outside of the q-ordered subgroup. Obviously, systems not using the Sophie Germain and safe primes assumption does not have a q value on which to perform validation, so from a FIPS point of view the key exchange would fail. Niels M=C3=B6ller writes: > "Mark D. Baushke" writes: >=20 > > I would therefore really like to see it possible to express all of the > > MODP groups via this new extension if possible. >=20 > I still think it is inappropriate to use group-exchange for groups > that are going to be widely used.=20 I suppose we disagree on this subject. I believe it to be desirable to make published groups available to the RFC 4419 extension mechanism when there may not have been time or sufficient entropy to generate key pairs of the selected size for ephemeral groups. > Widely used groups should be subject to negotiation.=20 I have no objection to this approach. As has been noted by Peter, there are many different mechanisms for generation of the primes to be used for ephemeral groups. It should be possible to perform FIPS validation on those p,q,g parameters, but to do that would require an extension to the possible messages to send q to the client from the server. As to your suggestion, I have no objection if we also want to add negotiaion for some more fixed DH MODP groups. It may also be desirable to setup a way that RFC 3526 groups: diffie-hellman-group14-sha256 (2048-bit MODP group - 112 bits of security) diffie-hellman-group15-sha256 (3072-bit MODP group - 128 bits of security) diffie-hellman-group16-sha384 (4096-bit MODP group - ~150 bits of securit= y) or diffie-hellman-group16-sha512 (4096-bit MODP group - ~150 bits of securit= y) could be used. I do not really see a strong need for these: group17 (6144-bit MODP Group - ~170 bits of security) group18 (8192-bit MODP Group - ~190 bits of security) at the present time. > Group-exchange should be used only for ephemeral groups which each > server discard before they get "widely used". This is not a bad idea, but right now there exists only the ecdh-sha2-* KEX which are FIPS compliant. Not all implementations of SSH seem to want or are able to use ECDH. It is somewhat desirable to have a DH mechanism that is able to use sha256 which leaves only diffie-hellman-group-exchange-sha256 at present. As has been noted, diffie-hellman-group-exchange-sha256 may be difficult to use in a FIPS compliant manner as many implementations are not selection a g that allows a FIPS compliant implementation to always interoperate between client and server. Thanks, -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 9 14:29:10 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C67611B8660 for ; Mon, 9 Nov 2015 14:29:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 mdRmLuMjmSU6 for ; Mon, 9 Nov 2015 14:29:09 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A5DA1B865C for ; Mon, 9 Nov 2015 14:29:09 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 0B60D14A2DB; Mon, 9 Nov 2015 22:29:03 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 94FDB14A2D9; Mon, 9 Nov 2015 22:29:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id C783C14A1ED for ; Mon, 9 Nov 2015 15:07:28 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id EN9i14zHF8Rb for ; Mon, 9 Nov 2015 15:07:28 +0000 (UTC) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id E3CF014A185 for ; Mon, 9 Nov 2015 15:07:25 +0000 (UTC) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id tA9F7C0G020123 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 9 Nov 2015 16:07:13 +0100 X-Hashcash: 1:22:151109:ietf-ssh@netbsd.org::jc9OFcB1/Fcz+Bf2:BjVH From: Simon Josefsson To: ietf-ssh@netbsd.org Subject: Curve25519/448 key agreement for SSH OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt Date: Mon, 09 Nov 2015 16:07:11 +0100 Message-ID: <87pozjyzxc.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-=-= Content-Type: text/plain Aris and me have prepared a document describing key agreement using the CFRG curves for Secure Shell. As you know, curve25519-sha256@libssh.org is already implemented by libssh, OpenSSH, Dropbear, and some others. This is about putting the description of that into IETF format, and to add the Curve448 hedge variant chosen by CFRG. It might not be detailed enough for independent implementation, but we hope to get there. Any review and feedback is welcome. https://tools.ietf.org/html/draft-josefsson-ssh-curves /Simon PS. There is https://tools.ietf.org/html/draft-bjh21-ssh-ed25519 but that talks about Ed25519 signatures. The document above is about key agreement. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWQLafAAoJEIYLf7sy+BGd73oH/RwTmpa4ugvkuXCwQzoZ8qH0 RGL3GfsY1BoFA6ch2xcZyoJrFsKPzMuUq5BcDcpmSQUudABLNN0Dp4k0vNRdv3mk J6yUFRDQHpmuOBXZoEBkiSmTJelN59tM8bKiINPfrQV7IAMQy9g0XBss4OMmb7+T OCr5LLfIFPEoku/3yOdK8V31qhbjDvjw5o6tMI1NUUgn/QD4TFN8bM5js/6wbQeT Q0D5MDDA95eKR8wdg6YJHheFgfIrkWDzHdkf5oi4m/5m84h18SjNyhpJSS2Dm3AQ hkzlJTTWhSW+ytU8pnB6nUdrQv8CNJHoye0wdnsrUIZ5qvWSas5g3+OWDmv8rCY= =37CD -----END PGP SIGNATURE----- --=-=-=-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 9 14:30:46 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 074991B866E for ; Mon, 9 Nov 2015 14:30:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 4chnfO2fxXLO for ; Mon, 9 Nov 2015 14:30:45 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C1EE1B8665 for ; Mon, 9 Nov 2015 14:30:45 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 89C0514A2C6; Mon, 9 Nov 2015 22:30:44 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 2218114A2C5; Mon, 9 Nov 2015 22:30:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 2397C14A2C3 for ; Mon, 9 Nov 2015 18:22:53 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 0JTtEgN-MkfU for ; Mon, 9 Nov 2015 18:22:52 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 54A5F14A219 for ; Mon, 9 Nov 2015 18:22:50 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 0578A40032; Mon, 9 Nov 2015 19:22:47 +0100 (CET) Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id 6BA6F40021; Mon, 9 Nov 2015 19:22:44 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Mon, 09 Nov 2015 19:22:44 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: Peter Gutmann Cc: "Mark D. Baushke" , denis bider , Jeffrey Hutzelman , "ietf-ssh\@NetBSD.org" , "stephen.farrell\@cs.tcd.ie" , "jon\@siliconcircus.com" Subject: Re: DH group exchange (Re: SSH key algorithm updates) References: <9A043F3CF02CD34C8E74AC1594475C73F4B5993D@uxcn10-5.UoA.auckland.ac.nz> <2096379125-720@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B599ED@uxcn10-5.UoA.auckland.ac.nz> <55190.1447001241@eng-mail01.juniper.net> <9A043F3CF02CD34C8E74AC1594475C73F4B5A9BC@uxcn10-5.UoA.auckland.ac.nz> Date: Mon, 09 Nov 2015 19:22:44 +0100 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B5A9BC@uxcn10-5.UoA.auckland.ac.nz> (Peter Gutmann's message of "Mon, 9 Nov 2015 00:46:54 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Peter Gutmann writes: > Since the verification process for both 186 and Lim-Lee generated values = is > identical, you can verify the keys either way. So the spec would cover b= oth > NIST and non-NIST options at the same time, depending on implementer > preference. I'm not following the fine details here, but does the verification step include proving the primality of p (and q)?=20 Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 9 14:31:11 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485691B866C for ; Mon, 9 Nov 2015 14:31:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 Fbhzrz-P8-6v for ; Mon, 9 Nov 2015 14:31:10 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB10C1B866A for ; Mon, 9 Nov 2015 14:31:10 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id E5DD814A2CD; Mon, 9 Nov 2015 22:31:09 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 8015714A2C8; Mon, 9 Nov 2015 22:31:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 155C314A21F for ; Mon, 9 Nov 2015 18:26:22 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id N7dTnp-FL_TD for ; Mon, 9 Nov 2015 18:26:21 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 585BB14A219 for ; Mon, 9 Nov 2015 18:26:21 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 7F83740032; Mon, 9 Nov 2015 19:26:19 +0100 (CET) Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id 15B5840021; Mon, 9 Nov 2015 19:26:18 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Mon, 09 Nov 2015 19:26:18 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: "Mark D. Baushke" Cc: Peter Gutmann , denis bider , Jeffrey Hutzelman , "ietf-ssh\@NetBSD.org" , "stephen.farrell\@cs.tcd.ie" , "jon\@siliconcircus.com" Subject: Re: DH group exchange (Re: SSH key algorithm updates) References: <9A043F3CF02CD34C8E74AC1594475C73F4B5993D@uxcn10-5.UoA.auckland.ac.nz> <2096379125-720@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B599ED@uxcn10-5.UoA.auckland.ac.nz> <55190.1447001241@eng-mail01.juniper.net> Date: Mon, 09 Nov 2015 19:26:17 +0100 In-Reply-To: <55190.1447001241@eng-mail01.juniper.net> (Mark D. Baushke's message of "Sun, 8 Nov 2015 08:47:21 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list "Mark D. Baushke" writes: > I would therefore really like to see it possible to express all of the > MODP groups via this new extension if possible. I still think it is inappropriate to use group-exchange for groups that are going to be widely used. Widely used groups should be subject to negotiation. Group-exchange should be used only for ephemeral groups which each server discard before they get "widely used". Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 9 14:31:53 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36ED01B8678 for ; Mon, 9 Nov 2015 14:31:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 X8qHQI69Vroh for ; Mon, 9 Nov 2015 14:31:52 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 801121B8677 for ; Mon, 9 Nov 2015 14:31:52 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id E7CE914A2EA; Mon, 9 Nov 2015 22:31:51 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 78F0514A2D0; Mon, 9 Nov 2015 22:31:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 6980B14A28D for ; Mon, 9 Nov 2015 18:42:53 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id iiaQ4sCnAh9n for ; Mon, 9 Nov 2015 18:42:52 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 9C00614A28A for ; Mon, 9 Nov 2015 18:42:52 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id A793940021; Mon, 9 Nov 2015 19:42:49 +0100 (CET) Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id CBD7740032; Mon, 9 Nov 2015 19:42:47 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Mon, 09 Nov 2015 19:42:47 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: denis bider Cc: Peter Gutmann , "ietf-ssh\@netbsd.org" , Jeffrey Hutzelman , "Mark D. Baushke" , "stephen.farrell\@cs.tcd.ie" , "jon\@siliconcircus.com" , "djm\@mindrot.org" , Max Horn Subject: Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation References: <2072949147-896@skroderider.denisbider.com> Date: Mon, 09 Nov 2015 19:42:47 +0100 In-Reply-To: <2072949147-896@skroderider.denisbider.com> (denis bider's message of "Sun, 8 Nov 2015 02:30:18 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list denis bider writes: > The "ecdsa-sha2-..." algorithm names (RFC 5656) do not use the "ssh-" pre= fix. > > Neither do the new formats in RFC 6187, i.e. "x509v3-rsa2048-sha256" > and "x509v3-ecdsa-sha2-...". > > In my opinion, the "ssh-" prefix is superfluous. The context of SSH is > implied by where the names are used. The "ssh-" prefix specifies the encoding to use for keys and signatures. My understanding is that for ecdsa- and x509v3-, the encoding is specified by appropiate other standards. While for ssh-rsa and ssh-dss, the encoding is ssh-specific: It is specified in the ssh transport protocol (RFC 4253), and include strings like "ssh-rsa" as part of the encoding. I belive the new rsa-sha2-256 algorithm name ought to also have an "ssh-" prefix, because the format is equally ssh specific. > I think the use of "ssh-" prefixes for all kinds of names was a > (small) mistake in the original design. I disagree. And even if it were a small mistake, we should strive to keep naming consistent. Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 9 14:32:45 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22011B8688 for ; Mon, 9 Nov 2015 14:32:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 p2Gb_zKOunlm for ; Mon, 9 Nov 2015 14:32:45 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDA331B8687 for ; Mon, 9 Nov 2015 14:32:44 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 79CC414A28A; Mon, 9 Nov 2015 22:32:44 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 16F6914A235; Mon, 9 Nov 2015 22:32:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id C3DD714A2DF for ; Mon, 9 Nov 2015 19:05:47 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id KJI94pz-yCRu for ; Mon, 9 Nov 2015 19:05:47 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id CFF6014A1CF for ; Mon, 9 Nov 2015 19:05:46 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 99F4040032; Mon, 9 Nov 2015 20:05:44 +0100 (CET) Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id 36C4940021; Mon, 9 Nov 2015 20:05:42 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Mon, 09 Nov 2015 20:05:42 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: denis bider Cc: ietf-ssh@netbsd.org, Jeffrey Hutzelman , "Mark D. Baushke" , stephen.farrell@cs.tcd.ie, jon@siliconcircus.com, djm@mindrot.org, Peter Gutmann , Max Horn Subject: Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation References: <2070897157-568@skroderider.denisbider.com> Date: Mon, 09 Nov 2015 20:05:42 +0100 In-Reply-To: <2070897157-568@skroderider.denisbider.com> (denis bider's message of "Sun, 8 Nov 2015 02:14:47 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list denis bider writes: > I have looked at alternatives, but: > - libssh handles the KEXINIT reserved field incorrectly (ignores > actual value, so key exchange fails if it's not zero) Is this a bug or not? The reserved field is intended for extensions, but from a quick look I can't see that the spec (RFC 4253) defines any valid behaviour when a client or server receives a non-zero value there. I think a complient implementation ought to disconnect. It would make some sense to combine client's and server's value in some way, e.g., bitwise and, or taking the maximum value, and use the result to enable extensions. But we really have to define that mechanism first, before we can define extensions using it... So in the short term, this field seems pretty useless. =20 > client-req-ok: Allows clients to affirm that the server can send a > global request (especially an unrecognized global request) without > risking the client disconnecting. This should be supported by all > clients. It is necessary so that servers can enable active keep-alive, > which is not otherwise possible generally because some clients do > disconnect when they receive a global request. This is essentially an extension saying "I don't have known bug X". I think we should avoid those things. If we want to interoperate with buggy implementations, I'd actually prefer hacks based on the version strings. Sooner or later we'll see an implementation which advertises "no bug X" but actually has bug X, and then we're back to square one. > no-handbrake: Peter ought to like this. :) A few years late, but this > makes window size infinite for both directions in a channel, at the > cost of restricting the session to one simultaneous channel. This > should help file transfer applications for which the channel flow > control in SSH is an impediment, rather than a feature. Makes some sense. Is the intention that the endpoints should buffer arbitrarily large amounts of data, or is the receiver of the data stream allowed to block and stop processing ssh messages while delivering the data? I think I'd prefer to do it per-channel, and if enabled, let the parties do their best if other channels are starved for data or get blocked. And if it is intended to be a global state, a GLOBAL_REQUEST seems more appropriate than an extension to the *transport* layer of the ssh protocol. If we want to improve on the flow control in ssh-connection, it might also make sense to look at what other recent multiplexing protocols do, e.g, http/2. Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 9 22:31:32 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5384E1B3362 for ; Mon, 9 Nov 2015 22:31:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 NTjzpuf6PLbN for ; Mon, 9 Nov 2015 22:31:30 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1DBF1B3360 for ; Mon, 9 Nov 2015 22:31:30 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id CB35014A242; Tue, 10 Nov 2015 06:31:28 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 0B79514A23A for ; Tue, 10 Nov 2015 06:31:24 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id USMD3-NyW8hf for ; Tue, 10 Nov 2015 06:31:23 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id A541214A232 for ; Tue, 10 Nov 2015 06:31:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1447137083; x=1478673083; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kTh1oomf9GtBsI3BMHpIOWLwHAGKSNsiVBi12Ro2S8M=; b=pz8DcEatE20LqtCJ2ZIR6BPExDQ1NSeHMHv3vK7g1z+xpTf6eSiqmwRs YSq7gZOZiOSbUOrVXBDXPP9VrXgulspJ/xp+DSj1z3swzAnhkrcLulf7F DWwnmBjvEVTH4L3WGUm40z+ZZRiTPLtWCscCmGBdZ6DLygYJtuX3aP1sA kKYromcg2OS+xpiYf7l2eGn4j1XJfwTmOnJ5VjR1Hbym6T1b9ECvm5SU8 MViDM/6ififP/d9W+2avRwFFDeN72g1gAyVb4EbDGqDT8+vb00Hb6Pqo9 Wv6eIHcIal4NLtUqP7FOhfbaZOqZ7T6WWHW3N7fJEe3TAP2+O1tgsg00B A==; X-IronPort-AV: E=Sophos;i="5.20,269,1444647600"; d="scan'208";a="53518381" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe2.UoA.auckland.ac.nz) ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 10 Nov 2015 19:31:17 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Tue, 10 Nov 2015 19:31:16 +1300 From: Peter Gutmann To: denis bider , "ietf-ssh@netbsd.org" CC: Jeffrey Hutzelman , =?iso-8859-1?Q?NielsM=F6ller?= , "Mark D. Baushke" , "stephen.farrell@cs.tcd.ie" , "jon@siliconcircus.com" , "djm@mindrot.org" , Max Horn Subject: RE: Experimental server for RSA SHA-2 Thread-Topic: Experimental server for RSA SHA-2 Thread-Index: AQHRGgVgKCANwh+VhEemT+UuTqD4Yp6UzkDX Date: Tue, 10 Nov 2015 06:31:15 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B5BD70@uxcn10-5.UoA.auckland.ac.nz> References: <2073638188-720@skroderider.denisbider.com>,<2096718084-720@skroderider.denisbider.com> In-Reply-To: <2096718084-720@skroderider.denisbider.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list denis bider writes:=0A= =0A= >I have set up a server where we can test support for RSA SHA-2.=0A= >=0A= >You can connect to it at:=0A= >=0A= >experiment.bitvise.com:10712=0A= =0A= So I figured this would be the quickest RFC (draft) implementation ever, on= e=0A= line of code:=0A= =0A= { "rsa-sha2-256", 12, CRYPT_ALGO_RSA, CRYPT_ALGO_RSA, CRYPT_ALGO_SHA2 },= =0A= =0A= However, this doesn't work, for several reasons... the biggest problem is t= hat=0A= the hash algorithm HASH is already specified in the keyex method, for "diff= ie-=0A= hellman-group-exchange-sha1" it's SHA-1 and for "diffie-hellman-group-=0A= exchange-sha256" it's SHA2-256. So specifying "rsa-sha2-256" for "diffie-= =0A= hellman-group-exchange- sha1" doesn't make sense, and specifying it for=0A= "diffie-hellman-group-exchange-sha256" is redundant.=0A= =0A= Another problem is shown up by the argument about naming, that since this i= s a=0A= standard SSH signature, the "ssh-" isn't needed. Looking at the draft, thi= s=0A= isn't anything like any other SSH signature, it uses RSA-PSS not PKCS #1,= =0A= which no other SSH signature uses. So it needs some indicator in the name= =0A= that it's a nonstandard signature type, not a standard SSH signature, e.g.= =0A= "ssh-rsa-pss" to contrast with the standard "ssh-rsa". It also means that = you=0A= need to do an implementation of RSA-PSS just to support this signature type= .=0A= =0A= The result is that the draft is really "Use of RSA-PSS with SSH", not "Use = of=0A= RSA Keys with SHA-2 256 and 512 in Secure Shell (SSH)", since they're alrea= dy=0A= in use with SHA-2 when "diffie-hellman-group-exchange-sha256" is used.=0A= =0A= Peter.= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 9 22:33:58 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF271B336E for ; Mon, 9 Nov 2015 22:33:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 nKITccrSfSuw for ; Mon, 9 Nov 2015 22:33:57 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DFB31B336C for ; Mon, 9 Nov 2015 22:33:57 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id B0E4B14A2A1; Tue, 10 Nov 2015 06:33:55 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 5F64114A294 for ; Tue, 10 Nov 2015 06:33:53 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id LoFvj3Uak0Nx for ; Tue, 10 Nov 2015 06:33:52 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 42A4714A255 for ; Tue, 10 Nov 2015 06:33:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1447137232; x=1478673232; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5j1OzyiLvhtFHU1t8XPTvbsNZyK43i+5QnWeuILasSM=; b=BCHkFO7ckAS8t/jd+wqzXdnsCyifjTG4RGVwbHOmFIPCZFIGP6w4sJM3 xWwKFchoLZOujWynREp0Tt7R+vAbYgnPciL2dTNFHqWvRhK1mxDQpO7Xb wcLN/ZdADd4ZS6FNPiFiGG5JpvNgF8lKKA4AVGSCr3JxhSln0Ys9zSRYC C2/VgS3aEPzdPc+uWWyUnTLmfQm3qNpEPI1ek/RSZjjod6Iy+283Hfhgi d15QGIX8np8UzAMsnq8evhkDkohDVGPFlGIzscPHh6OOusrEYwT+XBNFG afhZyK5zUVrajW5vchyXPcIxBlcOpDnWh5TlviFX4t5raq+5y5cRUHFJd w==; X-IronPort-AV: E=Sophos;i="5.20,269,1444647600"; d="scan'208";a="53518508" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe4.UoA.auckland.ac.nz) ([130.216.4.171]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 10 Nov 2015 19:33:50 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Tue, 10 Nov 2015 19:33:50 +1300 From: Peter Gutmann To: =?iso-8859-1?Q?Niels_M=F6ller?= CC: "Mark D. Baushke" , denis bider , Jeffrey Hutzelman , "ietf-ssh@NetBSD.org" , "stephen.farrell@cs.tcd.ie" , "jon@siliconcircus.com" Subject: RE: DH group exchange (Re: SSH key algorithm updates) Thread-Topic: DH group exchange (Re: SSH key algorithm updates) Thread-Index: AQHRGxugq51zpHEwR0KblpfSUHdPHJ6UzK1H Date: Tue, 10 Nov 2015 06:33:49 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B5BD80@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4B5993D@uxcn10-5.UoA.auckland.ac.nz> <2096379125-720@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B599ED@uxcn10-5.UoA.auckland.ac.nz> <55190.1447001241@eng-mail01.juniper.net> <9A043F3CF02CD34C8E74AC1594475C73F4B5A9BC@uxcn10-5.UoA.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Niels M=F6ller writes:=0A= =0A= >I'm not following the fine details here, but does the verification step=0A= >include proving the primality of p (and q)?=0A= =0A= No (that would make ops incredibly expensive), just things like verifying t= hat=0A= g is a generator of order q.=0A= =0A= Peter.=0A= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 9 22:50:45 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC3131B33BE for ; Mon, 9 Nov 2015 22:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 jNRPZM3g3dJv for ; Mon, 9 Nov 2015 22:50:44 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 339F11B33BF for ; Mon, 9 Nov 2015 22:50:41 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id A1DEA14A2B0; Tue, 10 Nov 2015 06:50:40 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 981FD14A2AD for ; Tue, 10 Nov 2015 06:50:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 5vkh53QviCUR for ; Tue, 10 Nov 2015 06:50:34 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 3248E14A283 for ; Tue, 10 Nov 2015 06:50:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1447138234; x=1478674234; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7e8iUp6w2QgJXUxqhqtZCwgf3XrscrA1WIAoVSq79DQ=; b=C7MsSUUQqG+2xA0Vuc8/S/iw4Vag76UvjErbpTyN8IaQAGZAOmn5sbLo +jk053Cmucm+IbgCMYCMR9wbZQzqOyanXWgvPI/kCKsGrTv9mk4EmB/WB l34hGJgP6Fk/LsjlItcpK/44bUPBWFmjDBvqZBXs7tq1G//J/UgtsEzvQ +4kvrCEV1WB1dJuuvbAwRpxEPjAtCznAnFEz6WgQhQFPk40C4FUAx/+CE x7S6V50JBZyS3Zg3IbKtikKYesUfKpxlJ4Vj5jbP8hY9ONijYv3y3cm7M tgX03sHaIC1SxvzLoqHvx+TO53PUnYYWFVe0sWtI2rPn2B6sBK8bKfQoe w==; X-IronPort-AV: E=Sophos;i="5.20,269,1444647600"; d="scan'208";a="53519554" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe3.UoA.auckland.ac.nz) ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 10 Nov 2015 19:50:32 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Tue, 10 Nov 2015 19:50:32 +1300 From: Peter Gutmann To: =?iso-8859-1?Q?Niels_M=F6ller?= , denis bider CC: "ietf-ssh@netbsd.org" , Jeffrey Hutzelman , "Mark D. Baushke" , "stephen.farrell@cs.tcd.ie" , "jon@siliconcircus.com" , "djm@mindrot.org" , Max Horn Subject: RE: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation Thread-Topic: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation Thread-Index: AQHRGyGhhOUdZ9Oj4Ee4+Vj0CybFfp6U0bTr Date: Tue, 10 Nov 2015 06:50:31 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B5BDE2@uxcn10-5.UoA.auckland.ac.nz> References: <2070897157-568@skroderider.denisbider.com>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Niels M=F6ller writes:=0A= =0A= >Is this a bug or not? The reserved field is intended for extensions, but f= rom=0A= >a quick look I can't see that the spec (RFC 4253) defines any valid behavi= our=0A= >when a client or server receives a non-zero value there. I think a complie= nt=0A= >implementation ought to disconnect.=0A= =0A= I would consider it a bug in the spec, indicating that there's a reserved= =0A= field but not saying how it's meant to be handled. My code checks for its= =0A= presence, but explicitly doesn't try and interpret it in any way. OTOH the= =0A= following:=0A= =0A= execl("/usr/games/hack", "#pragma", 0); // try to run the game NetHack=0A= =0A= would also be perfectly valid behaviour. Or at least, you could argue that= =0A= rejecting it if it's nonzero is valid, not rejecting it if it's nonzero is= =0A= valid, and ignoring it is valid.=0A= =0A= It's a bit of a strange field in any case, unless your entire protocol=0A= extension is a single bitflag it's more or less useless for specifying=0A= extensions because there's no room for anything.=0A= =0A= >Is the intention that the endpoints should buffer arbitrarily large amount= s=0A= >of data, or is the receiver of the data stream allowed to block and stop= =0A= >processing ssh messages while delivering the data?=0A= =0A= The latter. Implementations would, I assume, be doing this anyway, if your= =0A= incoming data stream is faster than what you can write to disk (or whatever= ),=0A= you use TCP's flow control to manage things.=0A= =0A= (Oh, and as Denis pointed out, I'd definitely support this one :-).=0A= =0A= Peter.= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 9 23:16:01 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6731A0021 for ; Mon, 9 Nov 2015 23:16:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.609 X-Spam-Level: X-Spam-Status: No, score=-1.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 FYGtQigmw-gw for ; Mon, 9 Nov 2015 23:15:59 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 370841A001A for ; Mon, 9 Nov 2015 23:15:59 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 507F614A23B; Tue, 10 Nov 2015 07:15:56 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id E987514A1E7; Tue, 10 Nov 2015 07:15:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 6A1C214A25A for ; Tue, 10 Nov 2015 04:56:14 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id b4luIUAsCqya for ; Tue, 10 Nov 2015 04:56:13 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 054E214A23B for ; Tue, 10 Nov 2015 04:56:12 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for nisse@lysator.liu.se; Tue, 10 Nov 2015 04:55:44 +0000 Date: Tue, 10 Nov 2015 04:55:44 +0000 Subject: Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <2252876847-480@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: =?UTF-8?q?Niels_M=C3=B6ller?= Cc: ietf-ssh@netbsd.org, Jeffrey Hutzelman , "Mark D. Baushke" , stephen.farrell@cs.tcd.ie, jon@siliconcircus.com, djm@mindrot.org, Peter Gutmann , Max Horn Content-Type: multipart/alternative; boundary="=-jgqtALIevglqzwhe4mGM" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-jgqtALIevglqzwhe4mGM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Niels: >> - libssh handles the KEXINIT reserved field incorrectly >> (ignores actual value, so key exchange fails if it's not zero) > Is this a bug or not?=20 This is a bug. The implementation forgets to decode this field. It does not= disconnect on purpose. The disconnect is just a side effect of key exchang= e failing. > The reserved field is intended for extensions, but from > a quick look I can't see that the spec (RFC 4253) defines > any valid behaviour when a client or server receives a > non-zero value there. I think a complient implementation > ought to disconnect. You cannot extend the protocol using this field, if existing implementation= s disconnect when they see a new value. That would not allow for extension.= It would require replacement of the protocol with a new and incompatible v= ersion. This goes to show that this kind of thing is not obvious to everyone, and m= ust be explicitly spelled out. It is a flaw of RFC 4253 that it assumes peo= ple will understand how extension fields function, and does not spend a par= agraph on this. > So in the short term, this field seems pretty useless. The common convention with extension flags is as follows. If you are unawar= e of any extensions: (1) Always set the defined non-extended value. This is usually zero. (2) DO NOT EVER VERIFY that you have received some particular value. That's all there is to it. That's how extension fields function. An applica= tion that is aware of the extension will notice a non-zero value if it's re= ceived, and will know what to do with it. The problem is that this extension strategy is fragile. For this to work, a= ll implementations have to do the correct thing: which is to reliably send = the non-extended value if they're unaware; and never verify the received va= lue. > > client-req-ok > This is essentially an extension saying "I don't have > known bug X". The behavior isn't known to be a bug. It's an ambiguity in the spec, which = produces this behavior when combined with implementers who think there's be= nefit in being difficult on purpose. (For illustration, see your reasoning = with respect to KEXINIT extension field.) This is an extension saying "I implement non-guaranteed behavior X". > Sooner or later we'll see an implementation which advertises > "no bug X" but actually has bug X, There's no reason to expect that. Disconnecting on global request is not so= me kind of "whoops". It's a "feature" implemented by someone who likes to m= akes things difficult on purpose. It does not necessarily violate the spec = because the spec is silent on whether clients should gracefully handle a gl= obal request. > > no-handbrake > Is the intention that the endpoints should buffer arbitrarily large > amounts of data, or is the receiver of the data stream allowed to > block and stop processing ssh messages while delivering the data? The intention is that TCP-based flow control is used. > I think I'd prefer to do it per-channel, and if enabled, let the > parties do their best if other channels are starved for data > or get blocked. Enabling this by necessity changes flow control for the entire session. > If we want to improve on the flow control in ssh-connection, > it might also make sense to look at what other recent > multiplexing protocols do, e.g, http/2. I think our multiplexing is fine. This extension is to accommodate applicat= ions that don't want to multiplex. denis ----- Original Message ----- From: Niels "M=C3=B6ller"=20 Sent: Monday, November 9, 2015 13:05 To: denis bider=20 Cc: ietf-ssh@netbsd.org ; Jeffrey Hutzelman ; Mark D. Baushke ; stephen.far= rell@cs.tcd.ie ; jon@siliconcircus.com ; djm@mindrot.org ; Peter Gutmann ; = Max Horn=20 Subject: Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation denis bider writes: > I have looked at alternatives, but: > - libssh handles the KEXINIT reserved field incorrectly (ignores > actual value, so key exchange fails if it's not zero) Is this a bug or not? The reserved field is intended for extensions, but from a quick look I can't see that the spec (RFC 4253) defines any valid behaviour when a client or server receives a non-zero value there. I think a complient implementation ought to disconnect. It would make some sense to combine client's and server's value in some way, e.g., bitwise and, or taking the maximum value, and use the result to enable extensions. But we really have to define that mechanism first, before we can define extensions using it... So in the short term, this field seems pretty useless. > client-req-ok: Allows clients to affirm that the server can send a > global request (especially an unrecognized global request) without > risking the client disconnecting. This should be supported by all > clients. It is necessary so that servers can enable active keep-alive, > which is not otherwise possible generally because some clients do > disconnect when they receive a global request. This is essentially an extension saying "I don't have known bug X". I think we should avoid those things. If we want to interoperate with buggy implementations, I'd actually prefer hacks based on the version strings. Sooner or later we'll see an implementation which advertises "no bug X" but actually has bug X, and then we're back to square one. > no-handbrake: Peter ought to like this. :) A few years late, but this > makes window size infinite for both directions in a channel, at the > cost of restricting the session to one simultaneous channel. This > should help file transfer applications for which the channel flow > control in SSH is an impediment, rather than a feature. Makes some sense. Is the intention that the endpoints should buffer arbitrarily large amounts of data, or is the receiver of the data stream allowed to block and stop processing ssh messages while delivering the data? I think I'd prefer to do it per-channel, and if enabled, let the parties do their best if other channels are starved for data or get blocked. And if it is intended to be a global state, a GLOBAL_REQUEST seems more appropriate than an extension to the *transport* layer of the ssh protocol. If we want to improve on the flow control in ssh-connection, it might also make sense to look at what other recent multiplexing protocols do, e.g, http/2. Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. = --=-jgqtALIevglqzwhe4mGM Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Niels:

>> - libssh handles the KEXINI= T reserved field incorrectly
>> (ignores actual value, so key exch= ange fails if it's not zero)

> Is this a bug or not?

This= is a bug. The implementation forgets to decode this field. It does not dis= connect on purpose. The disconnect is just a side effect of key exchange fa= iling.


> The reserved field is intended for extensions, but f= rom
> a quick look I can't see that the spec (RFC 4253) defines
&g= t; any valid behaviour when a client or server receives a
> non-zero = value there. I think a complient implementation
> ought to disconnect= .

You cannot extend the protocol using this field, if existing imple= mentations disconnect when they see a new value. That would not allow for e= xtension. It would require replacement of the protocol with a new and incom= patible version.

This goes to show that this kind of thing is not ob= vious to everyone, and must be explicitly spelled out. It is a flaw of RFC = 4253 that it assumes people will understand how extension fields function, = and does not spend a paragraph on this.


> So in the short ter= m, this field seems pretty useless.

The common convention with exten= sion flags is as follows. If you are unaware of any extensions:

(1) = Always set the defined non-extended value. This is usually zero.
(2) DO = NOT EVER VERIFY that you have received some particular value.

That's= all there is to it. That's how extension fields function. An application t= hat is aware of the extension will notice a non-zero value if it's received= , and will know what to do with it.

The problem is that this extensi= on strategy is fragile. For this to work, all implementations have t= o do the correct thing: which is to reliably send the non-extended value if= they're unaware; and never verify the received value.


> >= client-req-ok
> This is essentially an extension saying "I don't hav= e
> known bug X".

The behavior isn't known to be a bug.= It's an ambiguity in the spec, which produces this behavior when combined = with implementers who think there's benefit in being difficult on purpose. = (For illustration, see your reasoning with respect to KEXINIT extension fie= ld.)

This is an extension saying "I implement non-guaranteed behavio= r X".


> Sooner or later we'll see an implementation which adv= ertises
> "no bug X" but actually has bug X,

There's no reason= to expect that. Disconnecting on global request is not some kind of "whoop= s". It's a "feature" implemented by someone who likes to makes things diffi= cult on purpose. It does not necessarily violate the spec because the spec = is silent on whether clients should gracefully handle a global request.
=

> > no-handbrake
> Is the intention that the endpoints = should buffer arbitrarily large
> amounts of data, or is the receiver= of the data stream allowed to
> block and stop processing ssh messag= es while delivering the data?

The intention is that TCP-based flow c= ontrol is used.


> I think I'd prefer to do it per-channel, an= d if enabled, let the
> parties do their best if other channels are s= tarved for data
> or get blocked.

Enabling this by necessity c= hanges flow control for the entire session.


> If we want to i= mprove on the flow control in ssh-connection,
> it might also make se= nse to look at what other recent
> multiplexing protocols do, e.g, ht= tp/2.

I think our multiplexing is fine. This extension is to accommo= date applications that don't want to multiplex.


denis

----- Original Message -----
From: Niels "M=C3=B6ller"
Sent: Monday= , November 9, 2015 13:05
To: denis bider
Cc: ietf-ssh@netbsd.org ; J= effrey Hutzelman ; Mark D. Baushke ; stephen.farrell@cs.tcd.ie ; jon@silico= ncircus.com ; djm@mindrot.org ; Peter Gutmann ; Max Horn
Subject: Re: U= pdated RSA SHA-2 draft / New draft: SSH Extension Negotiation

denis = bider <ietf-ssh3@denisbider.com> writes:

> I have looked at= alternatives, but:
> - libssh handles the KEXINIT reserved field inc= orrectly (ignores
> actual value, so key exchange fails if it's not z= ero)

Is this a bug or not? The reserved field is intended for extens= ions, but
from a quick look I can't see that the spec (RFC 4253) defines= any valid
behaviour when a client or server receives a non-zero value t= here. I
think a complient implementation ought to disconnect.

It = would make some sense to combine client's and server's value in some
way= , e.g., bitwise and, or taking the maximum value, and use the result
to = enable extensions. But we really have to define that mechanism first,
be= fore we can define extensions using it... So in the short term, this
fie= ld seems pretty useless.

> client-req-ok: Allows clients to affir= m that the server can send a
> global request (especially an unrecogn= ized global request) without
> risking the client disconnecting. This= should be supported by all
> clients. It is necessary so that server= s can enable active keep-alive,
> which is not otherwise possible gen= erally because some clients do
> disconnect when they receive a globa= l request.

This is essentially an extension saying "I don't have kno= wn bug X". I
think we should avoid those things. If we want to interoper= ate with
buggy implementations, I'd actually prefer hacks based on the v= ersion
strings. Sooner or later we'll see an implementation which advert= ises
"no bug X" but actually has bug X, and then we're back to square on= e.

> no-handbrake: Peter ought to like this. :) A few years late,= but this
> makes window size infinite for both directions in a chann= el, at the
> cost of restricting the session to one simultaneous chan= nel. This
> should help file transfer applications for which the chan= nel flow
> control in SSH is an impediment, rather than a feature.
Makes some sense. Is the intention that the endpoints should bufferarbitrarily large amounts of data, or is the receiver of the data streamallowed to block and stop processing ssh messages while delivering thedata?

I think I'd prefer to do it per-channel, and if enabled, let = the parties
do their best if other channels are starved for data or get = blocked. And
if it is intended to be a global state, a GLOBAL_REQUEST se= ems more
appropriate than an extension to the *transport* layer of the s= sh
protocol.

If we want to improve on the flow control in ssh-con= nection, it might
also make sense to look at what other recent multiplex= ing protocols do,
e.g, http/2.

Regards,
/Niels

--
N= iels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26.
Inte= rnet email is subject to wholesale government surveillance.

<= /html>= --=-jgqtALIevglqzwhe4mGM-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 9 23:16:35 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDB051A00AC for ; Mon, 9 Nov 2015 23:16:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 78Wm6obuMB2u for ; Mon, 9 Nov 2015 23:16:34 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 144B91A0049 for ; Mon, 9 Nov 2015 23:16:34 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 9C7E814A2A5; Tue, 10 Nov 2015 07:16:33 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 46D4614A2A4; Tue, 10 Nov 2015 07:16:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 3BACA14A294 for ; Tue, 10 Nov 2015 06:12:30 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id MlfjT5mAirxD for ; Tue, 10 Nov 2015 06:12:29 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 8B09C14A292 for ; Tue, 10 Nov 2015 06:12:29 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for simon@josefsson.org; Tue, 10 Nov 2015 06:12:05 +0000 Date: Tue, 10 Nov 2015 06:12:05 +0000 Subject: RE: Curve25519/448 key agreement for SSH X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <2258609541-1780@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: simon@josefsson.org Cc: ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-nwP56JKnmRWlPXz3TWCc" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-nwP56JKnmRWlPXz3TWCc Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2ltb24sIEFyaXMgLQ0KDQp0aGFuayB5b3UgZm9yIHRoaXMgd29yay4gSSBwbGFuIHRvIGJlIGlt cGxlbWVudGluZyB0aGlzIHNvb24sIGFuZCBJIGFwcHJlY2lhdGUgdGhhdCB5b3UncmUgbW92aW5n IGFoZWFkIHdpdGggc3RhbmRhcmRpemF0aW9uLg0KDQpXaXRoIHJlc3BlY3QgdG8gY29udmVyc2lv biBvZiB0aGUgYmluYXJ5IHN0cmluZyBYIGludG8gbXBpbnQgSywgaXMgdGhlcmUgYSBjaGFuY2Ug dGhhdCBYIG1pZ2h0IGhhdmUgaXRzIGhpZ2ggYml0IHNldD8NCg0KSWYgaXQncyBwb3NzaWJsZSBm b3IgdGhlIGhpZ2ggYml0IHRvIGJlIHNldCwgaXQgc2VlbXMgeW91IG91Z2h0IHRvIGNsYXJpZnkg aG93IHRoYXQncyBjb252ZXJ0ZWQgaW50byBtcGludCwgZ2l2ZW4gdGhhdCBtcGludCBpcyBzaWdu ZWQ6DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmYy9yZmM0MjUxLnR4dA0KICAgICAgUmVwcmVz ZW50cyBtdWx0aXBsZSBwcmVjaXNpb24gaW50ZWdlcnMgaW4gdHdvJ3MgY29tcGxlbWVudCBmb3Jt YXQsCiAgICAgIHN0b3JlZCBhcyBhIHN0cmluZywgOCBiaXRzIHBlciBieXRlLCBNU0IgZmlyc3Qu ICBOZWdhdGl2ZSBudW1iZXJzCiAgICAgIGhhdmUgdGhlIHZhbHVlIDEgYXMgdGhlIG1vc3Qgc2ln bmlmaWNhbnQgYml0IG9mIHRoZSBmaXJzdCBieXRlIG9mCiAgICAgIHRoZSBkYXRhIHBhcnRpdGlv bi4gIElmIHRoZSBtb3N0IHNpZ25pZmljYW50IGJpdCB3b3VsZCBiZSBzZXQgZm9yCiAgICAgIGEg cG9zaXRpdmUgbnVtYmVyLCB0aGUgbnVtYmVyIE1VU1QgYmUgcHJlY2VkZWQgYnkgYSB6ZXJvIGJ5 dGUuQmVzaWRlcyB0aGF0LCBJJ20gbm90aWNpbmcgdGhlIGxhbmd1YWdlIGNvdWxkIHVzZSBpbXBy b3ZlbWVudCBpbiBwbGFjZXMgKCJ0aGlzIGRvY3VtZW50IHJlLXVzZSIgLT4gInRoaXMgZG9jdW1l bnQgcmV1c2VzIiwgImlzIGlzIiAtPiAiaXMiKS4NCg0KT3ZlcmFsbCwgdGhhbmsgeW91IGZvciBt b3ZpbmcgZm9yd2FyZCB3aXRoIHRoaXMsIHRob3VnaC4NCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNz YWdlIC0tLS0tDQpGcm9tOiBTaW1vbiBKb3NlZnNzb24gDQpTZW50OiBNb25kYXksIE5vdmVtYmVy IDksIDIwMTUgMDk6MDcNClRvOiBpZXRmLXNzaEBuZXRic2Qub3JnIA0KU3ViamVjdDogQ3VydmUy NTUxOS80NDgga2V5IGFncmVlbWVudCBmb3IgU1NIDQoNCkFyaXMgYW5kIG1lIGhhdmUgcHJlcGFy ZWQgYSBkb2N1bWVudCBkZXNjcmliaW5nIGtleSBhZ3JlZW1lbnQgdXNpbmcgdGhlDQpDRlJHIGN1 cnZlcyBmb3IgU2VjdXJlIFNoZWxsLsKgIEFzIHlvdSBrbm93LCBjdXJ2ZTI1NTE5LXNoYTI1NkBs aWJzc2gub3JnDQppcyBhbHJlYWR5IGltcGxlbWVudGVkIGJ5IGxpYnNzaCwgT3BlblNTSCwgRHJv cGJlYXIsIGFuZCBzb21lIG90aGVycy4NClRoaXMgaXMgYWJvdXQgcHV0dGluZyB0aGUgZGVzY3Jp cHRpb24gb2YgdGhhdCBpbnRvIElFVEYgZm9ybWF0LCBhbmQgdG8NCmFkZCB0aGUgQ3VydmU0NDgg aGVkZ2UgdmFyaWFudCBjaG9zZW4gYnkgQ0ZSRy7CoCBJdCBtaWdodCBub3QgYmUgZGV0YWlsZWQN CmVub3VnaCBmb3IgaW5kZXBlbmRlbnQgaW1wbGVtZW50YXRpb24sIGJ1dCB3ZSBob3BlIHRvIGdl dCB0aGVyZS7CoCBBbnkNCnJldmlldyBhbmQgZmVlZGJhY2sgaXMgd2VsY29tZS4NCg0KaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpvc2Vmc3Nvbi1zc2gtY3VydmVzDQoNCi9TaW1v bg0KDQpQUy4gVGhlcmUgaXMgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJqaDIx LXNzaC1lZDI1NTE5IGJ1dA0KdGhhdCB0YWxrcyBhYm91dCBFZDI1NTE5IHNpZ25hdHVyZXMuwqAg VGhlIGRvY3VtZW50IGFib3ZlIGlzIGFib3V0IGtleQ0KYWdyZWVtZW50Lg0KDQo= --=-nwP56JKnmRWlPXz3TWCc Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Simon, Aris -

thank you for this work. I pl= an to be implementing this soon, and I appreciate that you're moving ahead = with standardization.

With respect to conversion of the binary strin= g X into mpint K, is there a chance that X might have its high bit set?
=
If it's possible for the high bit to be set, it seems you ought to clar= ify how that's converted into mpint, given that mpint is signed:

htt= ps://www.ietf.org/rfc/rfc4251.txt
      Represents multiple precisi=
on integers in two's complement format,
      stored as a string, 8 bits per byte, MSB first.  Negative numbers
      have the value 1 as the most significant bit of the first byte of
      the data partition.  If the most significant bit would be set for
      a positive number, the number MUST be preceded by a zero byte.
B= esides that, I'm noticing the language could use improvement in places ("th= is document re-use" -> "this document reuses", "is is" -> "is").
<= br>Overall, thank you for moving forward with this, though.


----= - Original Message -----
From: Simon Josefsson
Sent: Monday, Novembe= r 9, 2015 09:07
To: ietf-ssh@netbsd.org
Subject: Curve25519/448 key = agreement for SSH

Aris and me have prepared a document describing ke= y agreement using the
CFRG curves for Secure Shell.  As you know, c= urve25519-sha256@libssh.org
is already implemented by libssh, OpenSSH, D= ropbear, and some others.
This is about putting the description of that = into IETF format, and to
add the Curve448 hedge variant chosen by CFRG.&= nbsp; It might not be detailed
enough for independent implementation, bu= t we hope to get there.  Any
review and feedback is welcome.
https://tools.ietf.org/html/draft-josefsson-ssh-curves

/Simon
PS. There is https://tools.ietf.org/html/draft-bjh21-ssh-ed25519 but
t= hat talks about Ed25519 signatures.  The document above is about keyagreement.

= --=-nwP56JKnmRWlPXz3TWCc-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 9 23:17:09 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3021A0097 for ; Mon, 9 Nov 2015 23:17:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.609 X-Spam-Level: X-Spam-Status: No, score=-1.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 4mtEaSWIxecP for ; Mon, 9 Nov 2015 23:17:07 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E95C1A007E for ; Mon, 9 Nov 2015 23:17:07 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 2424A14A2AB; Tue, 10 Nov 2015 07:17:07 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id BCFA214A2A6; Tue, 10 Nov 2015 07:17:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 39D7314A2AA for ; Tue, 10 Nov 2015 04:20:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id eXwQN59m-n5E for ; Tue, 10 Nov 2015 04:20:38 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 1E8C014A28F for ; Tue, 10 Nov 2015 04:20:38 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for nisse@lysator.liu.se; Tue, 10 Nov 2015 04:20:10 +0000 Date: Tue, 10 Nov 2015 04:20:10 +0000 Subject: Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <2251009843-932@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: =?UTF-8?q?Niels_M=C3=B6ller?= Cc: Peter Gutmann , ietf-ssh@netbsd.org, Jeffrey Hutzelman , "Mark D. Baushke" , stephen.farrell@cs.tcd.ie, jon@siliconcircus.com, djm@mindrot.org, Max Horn Content-Type: multipart/alternative; boundary="=-uckyKI4oNPXQsrpTt8h7" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-uckyKI4oNPXQsrpTt8h7 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBUaGUgInNzaC0iIHByZWZpeCBzcGVjaWZpZXMgdGhlIGVuY29kaW5nIHRvIHVzZSBmb3Iga2V5 cyBhbmQgc2lnbmF0dXJlcy4NCg0KVGhlIGN1cnJlbnQgUlNBIFNIQS0yIGRyYWZ0IGRlZmluZXMg c2lnbmF0dXJlIGFsZ29yaXRobSBuYW1lcyBzZXBhcmF0ZSBmcm9tIHB1YmxpYyBrZXkgZm9ybWF0 LiBJIGJlbGlldmUgdGhpcyBpcyBpbXBvcnRhbnQ6IGl0IGFsbG93cyBmb3Igc2VhbWxlc3MgdXBn cmFkZSBvZiBleGlzdGluZyBSU0EgaG9zdCBhbmQgdXNlciBrZXlzIHRvIHVzZSB0aGUgbmV3IHNp Z25hdHVyZSBtZXRob2RzLiBJZiB3ZSBkbyBub3QgYWxsb3cgZm9yIHRoaXMgc2VhbWxlc3MgdXBn cmFkZSwgYWRvcHRpb24gb2YgU0hBLTIgZm9yIGhvc3QgYW5kIHVzZXIgYXV0aGVudGljYXRpb24g d2lsbCBiZSBkZWxheWVkLg0KDQpZb3UgYXNzZXJ0IHRoYXQgdGhlICJzc2gtIiBwcmVmaXggaXMg bmVjZXNzYXJ5IHRvIGNvbnZleSBhIGhpbnQgYWJvdXQgdGhlIGVuY29kaW5nLiBUbyBtZSwgdGhp cyBhcHBlYXJzIHRvIGJlIGFuIGFyYml0cmFyeSBpbnRlcnByZXRhdGlvbi4gSSBwZXJzb25hbGx5 IGRvIG5vdCBzZWUgdGhpcyBhcyByZWxldmFudC4NCg0KQnV0IGlmIHRoaXMgd2FzIHJlbGV2YW50 LCB0aGUgbmFtZXMgaW4gdGhlIGN1cnJlbnQgZHJhZnQgc3RpbGwgbWVldCB5b3VyIGNyaXRlcmlh Og0KDQotIFRoZSBuYW1lIG9mIHRoZSBwdWJsaWMga2V5IGZvcm1hdCwgd2hpY2ggaXMgdGhlIFNT SC1zcGVjaWZpYyBrZXkgZm9ybWF0LCBjb250aW51ZXMgdG8gYmUgInNzaC1yc2EiLiBUaGlzIGlu ZHVsZ2VzIHRoZSBpZGVhIHRoYXQgYW4gInNzaC0iIHByZWZpeCBzaG91bGQgYmUgdXNlZCBpZiB0 aGUgZm9ybWF0IGlzIFNTSC1zcGVjaWZpYy4NCg0KLSBUaGUgc2lnbmF0dXJlIGFsZ29yaXRobSBu YW1lcyBhcmUgInJzYS1zaGEyLTI1NiIgYW5kICJyc2Etc2hhMi01MTIiLiBUaGUgc2lnbmF0dXJl IGVuY29kaW5ncyBqdXN0IGNvbnRhaW4gdGhlIFJTQSBzaWduYXR1cmUgYmxvYiwgd2hpY2ggaXMg ZGVmaW5lZCBpbiBSRkMgMzQ0Ny4gVGhpcyBpcyBub3QgU1NILXNwZWNpZmljLg0KDQpOb3RlIHRo YXQsIGJlc2lkZXMgYSBkaWZmZXJlbnQgbmFtZSwgdGhlIHNpZ25hdHVyZSBlbmNvZGluZyBpcyBp ZGVudGljYWwgdG8gdGhpcywgZGVmaW5lZCBpbiBSRkMgNjE4NyBmb3IgdGhlIGtleSBmb3JtYXQg Ing1MDl2My1yc2EyMDQ4LXNoYTI1NiI6DQogICAgIHN0cmluZyAgInJzYTIwNDgtc2hhMjU2Igog ICAgIHN0cmluZyAgcnNhX3NpZ25hdHVyZV9ibG9iCk5vdGljZSBob3cgdGhpcyBkb2VzIG5vdCBo YXZlIGFuICJzc2gtIiBwcmVmaXguDQoNCg0KPiBBbmQgZXZlbiBpZiBpdCB3ZXJlIGEgc21hbGwg bWlzdGFrZSwgd2Ugc2hvdWxkDQo+IHN0cml2ZSB0byBrZWVwIG5hbWluZyBjb25zaXN0ZW50Lg0K DQpUaGVyZSBoYXMgdG8gYmUgYSByZWFzb24gZm9yIGRlY2lzaW9ucyBiZXlvbmQganVzdCBjb25z aXN0ZW5jeS4gQ29uc2lzdGVuY3kgbXVzdCBoYXZlIGEgYmVuZWZpdCwgd2hpY2ggaXQgb2Z0ZW4g ZG9lczsgYnV0IEkgZG8gbm90IHNlZSB0aGF0IGJlbmVmaXQgaGVyZS4NCg0KV2hhdCBJIHNlZSBh cmUgZGlzYWR2YW50YWdlczoNCg0KLSBXZSBoYXZlIHRvIGRlYWwgd2l0aCBhIGxlc3MgcHJhY3Rp Y2FsLCBsZXNzIHJlYWRhYmxlIG5hbWUgZXZlcnl3aGVyZS4NCi0gVGhlIHByZWZpeGVkIG5hbWUg d291bGQgbm90IGRpc2FtYmlndWF0ZSB0aGlzIGFsZ29yaXRobSBmcm9tIGFueXRoaW5nLg0KLSBU aGUgcHJlZml4ZWQgbmFtZSB3b3VsZCBub3QgZXZlbiBiZSBjb25zaXN0ZW50IHdpdGggUkZDIDYx ODcuDQotIFBlb3BsZSBmcm93biBvbiB1cyBmb3IgaGF2aW5nIGRlbGliZXJhdGVseSBjaG9zZW4s IGZvciBvdXJzZWx2ZXMgYW5kIGZvciBldmVyeW9uZSwgYSBsZXNzIHByYWN0aWNhbCBuYW1lLg0K DQpUaGUgbmFtZSB3ZSBjaG9vc2UgcmlnaHQgbm93IHdpbGwgYmUgd2l0aCB1cyBhbmQgb3VyIHVz ZXJzIGZvciB5ZWFycyB0byBjb21lLiBUaGUgbm9uLXByZWZpeGVkIGNob2ljZSBpcyBvbmUgSSB3 b3VsZCB2ZXJ5IG11Y2ggcHJlZmVyIHRvIHNlZSAtIGFuZCBpcyB0aGUgb25lIHRoYXQgSSB0aGlu ayBpcyBtb3JlIHNlbnNpYmxlLg0KDQpBbHNvOg0KDQpodHRwczovL2VuLndpa2lwZWRpYS5vcmcv d2lraS9QYXJraW5zb24nc19sYXdfb2ZfdHJpdmlhbGl0eQ0KDQoNCi0tLS0tIE9yaWdpbmFsIE1l c3NhZ2UgLS0tLS0NCkZyb206IE5pZWxzICJNw7ZsbGVyIiANClNlbnQ6IE1vbmRheSwgTm92ZW1i ZXIgOSwgMjAxNSAxMjo0Mg0KVG86IGRlbmlzIGJpZGVyIA0KQ2M6IFBldGVyIEd1dG1hbm4gOyBp ZXRmLXNzaEBuZXRic2Qub3JnIDsgSmVmZnJleSBIdXR6ZWxtYW4gOyBNYXJrIEQuIEJhdXNoa2Ug OyBzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllIDsgam9uQHNpbGljb25jaXJjdXMuY29tIDsgZGpt QG1pbmRyb3Qub3JnIDsgTWF4IEhvcm4gDQpTdWJqZWN0OiBSZTogVXBkYXRlZCBSU0EgU0hBLTIg ZHJhZnQgLyBOZXcgZHJhZnQ6IFNTSCBFeHRlbnNpb24gTmVnb3RpYXRpb24NCg0KZGVuaXMgYmlk ZXIgPGlldGYtc3NoM0BkZW5pc2JpZGVyLmNvbT4gd3JpdGVzOg0KDQo+IFRoZSAiZWNkc2Etc2hh Mi0uLi4iIGFsZ29yaXRobSBuYW1lcyAoUkZDIDU2NTYpIGRvIG5vdCB1c2UgdGhlICJzc2gtIiBw cmVmaXguDQo+DQo+IE5laXRoZXIgZG8gdGhlIG5ldyBmb3JtYXRzIGluIFJGQyA2MTg3LCBpLmUu ICJ4NTA5djMtcnNhMjA0OC1zaGEyNTYiDQo+IGFuZCAieDUwOXYzLWVjZHNhLXNoYTItLi4uIi4N Cj4NCj4gSW4gbXkgb3BpbmlvbiwgdGhlICJzc2gtIiBwcmVmaXggaXMgc3VwZXJmbHVvdXMuIFRo ZSBjb250ZXh0IG9mIFNTSCBpcw0KPiBpbXBsaWVkIGJ5IHdoZXJlIHRoZSBuYW1lcyBhcmUgdXNl ZC4NCg0KVGhlICJzc2gtIiBwcmVmaXggc3BlY2lmaWVzIHRoZSBlbmNvZGluZyB0byB1c2UgZm9y IGtleXMgYW5kIHNpZ25hdHVyZXMuDQpNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgZm9yIGVjZHNh LSBhbmQgeDUwOXYzLSwgdGhlIGVuY29kaW5nIGlzDQpzcGVjaWZpZWQgYnkgYXBwcm9waWF0ZSBv dGhlciBzdGFuZGFyZHMuIFdoaWxlIGZvciBzc2gtcnNhIGFuZCBzc2gtZHNzLA0KdGhlIGVuY29k aW5nIGlzIHNzaC1zcGVjaWZpYzogSXQgaXMgc3BlY2lmaWVkIGluIHRoZSBzc2ggdHJhbnNwb3J0 DQpwcm90b2NvbCAoUkZDIDQyNTMpLCBhbmQgaW5jbHVkZSBzdHJpbmdzIGxpa2UgInNzaC1yc2Ei IGFzIHBhcnQgb2YgdGhlDQplbmNvZGluZy4NCg0KSSBiZWxpdmUgdGhlIG5ldyByc2Etc2hhMi0y NTYgYWxnb3JpdGhtIG5hbWUgb3VnaHQgdG8gYWxzbyBoYXZlIGFuDQoic3NoLSIgcHJlZml4LCBi ZWNhdXNlIHRoZSBmb3JtYXQgaXMgZXF1YWxseSBzc2ggc3BlY2lmaWMuDQoNCj4gSSB0aGluayB0 aGUgdXNlIG9mICJzc2gtIiBwcmVmaXhlcyBmb3IgYWxsIGtpbmRzIG9mIG5hbWVzIHdhcyBhDQo+ IChzbWFsbCkgbWlzdGFrZSBpbiB0aGUgb3JpZ2luYWwgZGVzaWduLg0KDQpJIGRpc2FncmVlLiBB bmQgZXZlbiBpZiBpdCB3ZXJlIGEgc21hbGwgbWlzdGFrZSwgd2Ugc2hvdWxkIHN0cml2ZSB0bw0K a2VlcCBuYW1pbmcgY29uc2lzdGVudC4NCg0KUmVnYXJkcywNCi9OaWVscw0KDQotLSANCk5pZWxz IE3DtmxsZXIuIFBHUC1lbmNyeXB0ZWQgZW1haWwgaXMgcHJlZmVycmVkLiBLZXlpZCBDMEI5OEUy Ni4NCkludGVybmV0IGVtYWlsIGlzIHN1YmplY3QgdG8gd2hvbGVzYWxlIGdvdmVybm1lbnQgc3Vy dmVpbGxhbmNlLg0KDQo= --=-uckyKI4oNPXQsrpTt8h7 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable > The "ssh-" prefix specifies the encoding to u= se for keys and signatures.

The current RSA SHA-2 draft defines sign= ature algorithm names separate from public key format. I believe this is im= portant: it allows for seamless upgrade of existing RSA host and user keys = to use the new signature methods. If we do not allow for this seamless upgr= ade, adoption of SHA-2 for host and user authentication will be delayed.
You assert that the "ssh-" prefix is necessary to convey a hint about = the encoding. To me, this appears to be an arbitrary interpretation. I pers= onally do not see this as relevant.

But if this was relevant,= the names in the current draft still meet your criteria:

- The name= of the public key format, which is the SSH-specific key format, continues = to be "ssh-rsa". This indulges the idea that an "ssh-" prefix should be use= d if the format is SSH-specific.

- The signature algorithm names are= "rsa-sha2-256" and "rsa-sha2-512". The signature encodings just contain th= e RSA signature blob, which is defined in RFC 3447. This is not SSH-= specific.

Note that, besides a different name, the signature encodin= g is identical to this, defined in RFC 6187 for the key format "x509v3-rsa2= 048-sha256":
     string  "rsa2048-sha256"
     string  rsa_signature_blob
Notice how this does not have an "ssh-" prefix.


> And e= ven if it were a small mistake, we should
> strive to keep naming con= sistent.

There has to be a reason for decisions beyond just consiste= ncy. Consistency must have a benefit, which it often does; but I do not see= that benefit here.

What I see are disadvantages:

- We have t= o deal with a less practical, less readable name everywhere.
- The prefi= xed name would not disambiguate this algorithm from anything.
- The pref= ixed name would not even be consistent with RFC 6187.
- People frown on = us for having deliberately chosen, for ourselves and for everyone, a less p= ractical name.

The name we choose right now will be with us and our = users for years to come. The non-prefixed choice is one I would very much p= refer to see - and is the one that I think is more sensible.

Also:
https://en.wikipedia.org/wiki/Parkinson's_law_of_triviality

----- Original Message -----
From: Niels "M=C3=B6ller"
Sent: Monda= y, November 9, 2015 12:42
To: denis bider
Cc: Peter Gutmann ; ietf-s= sh@netbsd.org ; Jeffrey Hutzelman ; Mark D. Baushke ; stephen.farrell@cs.tc= d.ie ; jon@siliconcircus.com ; djm@mindrot.org ; Max Horn
Subject: Re: = Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation

denis= bider <ietf-ssh3@denisbider.com> writes:

> The "ecdsa-sha2= -..." algorithm names (RFC 5656) do not use the "ssh-" prefix.
>
&= gt; Neither do the new formats in RFC 6187, i.e. "x509v3-rsa2048-sha256"> and "x509v3-ecdsa-sha2-...".
>
> In my opinion, the "ssh-= " prefix is superfluous. The context of SSH is
> implied by where the= names are used.

The "ssh-" prefix specifies the encoding to use for= keys and signatures.
My understanding is that for ecdsa- and x509v3-, t= he encoding is
specified by appropiate other standards. While for ssh-rs= a and ssh-dss,
the encoding is ssh-specific: It is specified in the ssh = transport
protocol (RFC 4253), and include strings like "ssh-rsa" as par= t of the
encoding.

I belive the new rsa-sha2-256 algorithm name o= ught to also have an
"ssh-" prefix, because the format is equally ssh sp= ecific.

> I think the use of "ssh-" prefixes for all kinds of nam= es was a
> (small) mistake in the original design.

I disagree.= And even if it were a small mistake, we should strive to
keep naming co= nsistent.

Regards,
/Niels

--
Niels M=C3=B6ller. PGP-en= crypted email is preferred. Keyid C0B98E26.
Internet email is subject to= wholesale government surveillance.

= --=-uckyKI4oNPXQsrpTt8h7-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 9 23:17:32 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4259C1A00B0 for ; Mon, 9 Nov 2015 23:17:32 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, MIME error: error: part did not end with expected boundary; ; error: unexpected end of parts before epilogue X-Spam-Flag: NO X-Spam-Score: -0.452 X-Spam-Level: X-Spam-Status: No, score=-0.452 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 wRnFTvNAwkz0 for ; Mon, 9 Nov 2015 23:17:31 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 040021A00AC for ; Mon, 9 Nov 2015 23:17:31 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 86D9E14A2B2; Tue, 10 Nov 2015 07:17:30 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 2DA0C14A2AD; Tue, 10 Nov 2015 07:17:30 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id A5DD814A2AB for ; Tue, 10 Nov 2015 05:20:14 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 2tywqSIU8X34 for ; Tue, 10 Nov 2015 05:20:13 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 9B4C414A2A1 for ; Tue, 10 Nov 2015 05:20:13 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for nisse@lysator.liu.se; Tue, 10 Nov 2015 05:20:06 +0000 Date: Tue, 10 Nov 2015 05:20:06 +0000 Subject: Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <2255441753-568@skroderider.denisbider.com> X-Priority: 3 Importance: Normal In-Reply-To: MIME-Version: 1.0 From: denis bider To: =?UTF-8?q?Niels_M=C3=B6ller?= Cc: Peter Gutmann , ietf-ssh@netbsd.org, Jeffrey Hutzelman , "Mark D. Baushke" , stephen.farrell@cs.tcd.ie, jon@siliconcircus.com, djm@mindrot.org, Max Horn Content-Type: multipart/alternative; boundary="=-aJmU1inx5VDYKTs8vIJG" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-aJmU1inx5VDYKTs8vIJG Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > I view it sligtly differently. The "ssh-rsa" string inside > the key encoding is not a name intended to be > parsed (at least not when received over the wire), > it's just required to be there. We do sometimes use that string to identify the format, when the key is not= presented to an application with out-of-band information. When the key is read from an SSH public key file, for instance, this encode= d string is crucial to knowing what kind of key it is. I think it's a good idea for this string to be included in the public key f= ormat. It provides a common format that makes it easy to have consensus on = calculating fingerprints, and it allows identification of key type when enc= ountered outside of context. (It further, theoretically, allows multiple public key formats to be used w= ith the same negotiated host key algorithm. We haven't had a need for that = yet, but it seems the SSHv2 designers went out of their way to avoid baking= in place forced 1-to-1 mappings. The protocol has flexible hinges everywhe= re.) Niels M=C3=B6ller , 11/10/2015 5:02 AM: denis bider writes:=20 =20 > The current RSA SHA-2 draft defines signature algorithm names separate=20 > from public key format. I believe this is important: it allows for=20 > seamless upgrade of existing RSA host and user keys to use the new=20 > signature methods. If we do not allow for this seamless upgrade,=20 > adoption of SHA-2 for host and user authentication will be delayed.=20 =20 I fully agree this makes sense.=20 =20 > You assert that the "ssh-" prefix is necessary to convey a hint about=20 > the encoding. To me, this appears to be an arbitrary interpretation. I=20 > personally do not see this as relevant.=20 =20 My understanding of this design is that the prefix simply means=20 "encoding is ssh-specific", and that is applicable also to the new=20 signature algorithm. I'm sorry if I sounded too harsh; I think=20 consistent naming is important, but it is still a minor detail.=20 =20 > - The name of the public key format, which is the SSH-specific key=20 > format, continues to be "ssh-rsa". This indulges the idea that an=20 > "ssh-" prefix should be used if the format is SSH-specific.=20 =20 I view it sligtly differently. The "ssh-rsa" string inside the key=20 encoding is not a name intended to be parsed (at least not when received=20 over the wire), it's just required to be there. Which *is* a bit of a=20 peculiar design. The name *identifying* the algorithm and format is the=20 name used in negotiating the algorithm, in keyexchange and user=20 authentication, and it must be known prior to parsing an encoded key or=20 signature.=20 =20 And then it happens that the different algorithms named "ssh-rsa" and=20 "rsa-sha2-256" are specified to use the same encoding of public keys=20 (for good reasons as you explain above).=20 =20 > - The signature algorithm names are "rsa-sha2-256" and "rsa-sha2-512".=20 > The signature encodings just contain the RSA signature blob, which is=20 > defined in RFC 3447. This is not SSH-specific.=20 =20 That is a relevant detail I had missed at first reading. So you use a=20 standard format for the signature (and just prepend a fixed string, for=20 consistency with other signature algorithms in ssh), but keep using the=20 ssh-specific encoding for the keys.=20 =20 To sum up the naming issue: We seem to disagree, but I can live with=20 either name. I'll do my best to refrain from writing more on that issue,=20 but I'd be happy to hear other's opinions.=20 =20 Regards,=20 /Niels=20 =20 -- =20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26.=20 Internet email is subject to wholesale government surveillance.=20 = --=-aJmU1inx5VDYKTs8vIJG Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable > I view it sligtly differently. The "ssh-rsa" = string inside
> the key encoding is not a name intended to be
>= parsed (at least not when received over the wire),
> it's just requi= red to be there.

We do sometimes use that string to identify the for= mat, when the key is not presented to an application with out-of-band infor= mation.

When the key is read from an SSH public key file, for instan= ce, this encoded string is crucial to knowing what kind of key it is.
I think it's a good idea for this string to be included in the public key= format. It provides a common format that makes it easy to have consensus o= n calculating fingerprints, and it allows identification of key type when e= ncountered outside of context.

(It further, theoretically, allows mu= ltiple public key formats to be used with the same negotiated host key algo= rithm. We haven't had a need for that yet, but it seems the SSHv2 designers= went out of their way to avoid baking in place forced 1-to-1 mappings. The= protocol has flexible hinges everywhere.)


= --=-x0OEwpiYZdCNrsfq0hF/-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Nov 12 14:57:33 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C29251B3A0B for ; Thu, 12 Nov 2015 14:57:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.609 X-Spam-Level: X-Spam-Status: No, score=-1.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 glWRr712Pgd1 for ; Thu, 12 Nov 2015 14:57:32 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73F561B3A0C for ; Thu, 12 Nov 2015 14:57:32 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id EC78014A2C6; Thu, 12 Nov 2015 22:57:31 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 8327214A2C4; Thu, 12 Nov 2015 22:57:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 9662114A255 for ; Thu, 12 Nov 2015 08:39:51 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id VxFw0xIVd6_D for ; Thu, 12 Nov 2015 08:39:50 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id B346B14A254 for ; Thu, 12 Nov 2015 08:39:50 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for pgut001@cs.auckland.ac.nz; Thu, 12 Nov 2015 08:39:41 +0000 Date: Thu, 12 Nov 2015 08:39:41 +0000 Subject: Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <11020971-2016@skroderider.denisbider.com> X-Priority: 3 Importance: Normal In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B5F0E3@uxcn10-5.UoA.auckland.ac.nz> MIME-Version: 1.0 From: denis bider To: Peter Gutmann , =?UTF-8?q?Niels_M=C3=B6ller?= Cc: "ietf-ssh@netbsd.org" , Jeffrey Hutzelman , "Mark D. Baushke" , "stephen.farrell@cs.tcd.ie" , "jon@siliconcircus.com" , "djm@mindrot.org" , Max Horn Content-Type: multipart/alternative; boundary="=-XGCThric1AeFdz9xCsPI" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-XGCThric1AeFdz9xCsPI Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable It seems to me the only known applications that might want to use "no-handb= rake" are those that don't want to use multiplexing. I don't know of a diff= erent usage case. To support a different usage case that we do not know of, we would have to = specify a mechanism for enabling this on a per-channel basis. This could be= a channel request sent by the client. If supported and confirmed by the se= rver, the channel request would switch the channel to infinite-window mode. The way I see it, though, supporting infinite windows with multiple channel= s just doesn't seem to make sense. The problem is not sending data. Yeah, in that case, you send in a round-ro= bin fashion, no problem. The problem is receiving. What happens when you can't write to the infinite= -window channel, but the data keeps coming? In this situation, you must stop reading from the SSH socket, which affects= all channels. You must stop reading because you have no way of knowing whe= ther the next packet you receive is going to be data for the infinite-windo= w channel. The way I see it, the only clean usage scenario for this feature is where t= here's a single channel. Anything else introduces dirty dilemmas that aren'= t even necessary, because the only actual usage case is single-channel. Peter Gutmann , 11/12/2015 7:50 AM: Niels M=C3=B6ller writes: >Send 0, ignore received value, would have made it actually useful. Can we get any figures on what effect making it nonzero would have? =C2=A0W= e know that there are at least some implementations who would have problems with this, but if they're OSS and frequently updated then it may not be such a b= ig issue, push out a fix fairly soon and by the time the RFC is ready most of = the problem will have fixed itself. Another workaround, although it's a bit of a hack, is if the two major clie= nt and server implementations, putty and OpenSSH, could retry an initial conne= ct with a nonzero field that's failed with a zeroed field and if it works, rep= ort to the user that the implementation needs an update. >Also, I'm not sure it has to be restricted to a single channel, I think it >would make sense to disable flow control independently for a single channe= l >or a single unidirectional flow. Ah, good point. =C2=A0The number of users of multichannel that I have is pr= etty minimal, so I never see this (it's used almost exclusively as a secure teln= et or for firmware upgrades, neither of which need multi-channel, to the point where it's disabled by default in the source code). >Do we have a common understanding of how it's going to work? Not yet, I think :-). =C2=A0I'd just seen it as all-or-nothing, is there an= y reason why you'd have windowing on three channels but not a fourth? =C2=A0That is,= is there a need for per-channel windowing enable/disable? =C2=A0Can it be enab= led mid- flow or only on channel open? Peter.= --=-XGCThric1AeFdz9xCsPI Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable It seems to me the only known applications that mi= ght want to use "no-handbrake" are those that don't want to use multiplexin= g. I don't know of a different usage case.

To support a different us= age case that we do not know of, we would have to specify a mechanism for e= nabling this on a per-channel basis. This could be a channel request sent b= y the client. If supported and confirmed by the server, the channel request= would switch the channel to infinite-window mode.

The way I see it,= though, supporting infinite windows with multiple channels just doesn't se= em to make sense.

The problem is not sending data. Yeah, in that cas= e, you send in a round-robin fashion, no problem.

The problem is rec= eiving. What happens when you can't write to the infinite-window channel, b= ut the data keeps coming?

In this situation, you must stop re= ading from the SSH socket, which affects all channels. You must stop readin= g because you have no way of knowing whether the next packet you receive is= going to be data for the infinite-window channel.

The way I see it,= the only clean usage scenario for this feature is where there's a single c= hannel. Anything else introduces dirty dilemmas that aren't even necessary,= because the only actual usage case is single-channel.


Peter Gutmann <pgut001@cs.auckland.ac.n= z> , 11/12/2015 7:50 AM:
Niels= M=C3=B6ller <nisse@lysator.liu.se> writes:
>Send 0, ignore received value, would have made it actually useful= .

Can we get any figures on what effect making it nonzero would have= ?  We know
that there are at least some implementations who would h= ave problems with
this, but if they're OSS and frequently updated then i= t may not be such a big
issue, push out a fix fairly soon and by the tim= e the RFC is ready most of the
problem will have fixed itself.

An= other workaround, although it's a bit of a hack, is if the two major client=
and server implementations, putty and OpenSSH, could retry an initial c= onnect
with a nonzero field that's failed with a zeroed field and if it = works, report
to the user that the implementation needs an update.
>Also, I'm not sure it has to be restricted to a single channel, I thi= nk it
>would make sense to disable flow control independently for a s= ingle channel
>or a single unidirectional flow.

Ah, good point= .  The number of users of multichannel that I have is pretty
minima= l, so I never see this (it's used almost exclusively as a secure telnet
= or for firmware upgrades, neither of which need multi-channel, to the point=
where it's disabled by default in the source code).

>Do we ha= ve a common understanding of how it's going to work?

Not yet, I thin= k :-).  I'd just seen it as all-or-nothing, is there any reason
why= you'd have windowing on three channels but not a fourth?  That is, is=
there a need for per-channel windowing enable/disable?  Can it be = enabled mid-
flow or only on channel open?

Peter.
= --=-XGCThric1AeFdz9xCsPI-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Nov 12 14:58:12 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E75261B3A0E for ; Thu, 12 Nov 2015 14:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 0WJ93fM6QMOL for ; Thu, 12 Nov 2015 14:58:11 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DE801B3A0D for ; Thu, 12 Nov 2015 14:58:11 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 1032014A2CD; Thu, 12 Nov 2015 22:58:11 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 9C7BC14A2CA; Thu, 12 Nov 2015 22:58:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 27ED414A265 for ; Thu, 12 Nov 2015 05:28:17 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id A4d9hX0EOrN4 for ; Thu, 12 Nov 2015 05:28:16 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id DB37C14A262 for ; Thu, 12 Nov 2015 05:28:14 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 539C84003F; Thu, 12 Nov 2015 06:28:11 +0100 (CET) Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id 3A7E640002; Thu, 12 Nov 2015 06:28:07 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Thu, 12 Nov 2015 06:28:07 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: Peter Gutmann Cc: denis bider , "ietf-ssh\@netbsd.org" , Jeffrey Hutzelman , "Mark D. Baushke" , "stephen.farrell\@cs.tcd.ie" , "jon\@siliconcircus.com" , "djm\@mindrot.org" , Max Horn Subject: Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation References: <2070897157-568@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B5BDE2@uxcn10-5.UoA.auckland.ac.nz> Date: Thu, 12 Nov 2015 06:28:07 +0100 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B5BDE2@uxcn10-5.UoA.auckland.ac.nz> (Peter Gutmann's message of "Tue, 10 Nov 2015 06:50:31 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Peter Gutmann writes: > I would consider it a bug in the spec, indicating that there's a reserved > field but not saying how it's meant to be handled. I think your (and Denis) is right. Send 0, ignore received value, would have made it actually useful. > The latter. Implementations would, I assume, be doing this anyway, if yo= ur > incoming data stream is faster than what you can write to disk (or whatev= er), > you use TCP's flow control to manage things. > > (Oh, and as Denis pointed out, I'd definitely support this one :-). I think the basic idea is sound, but I'm not sure enabling it belongs in the *transport* layer. Also, I'm not sure it has to be restricted to a single channel, I think it would make sense to disable flow control independently for a single channel or a single unidirectional flow. One can think of this feature as (1) disabling flow control, equivalent to using an infinite ssh window size, and (2) disabling buffering of received data (or limiting to a small buffer). This is my understanding of how it would work: If you are sending data on any channel without flow control, then you have to pause reading from all data sources when writing to the ssh connection blocks. And when it's possible to write on the ssh socket, you can read in a round-robin fashion from all data sources for which you either have available window space, or for which flow-control is disabled. If you are receiving data on any channel without flow control, you have to pause reading from the ssh socket while delivering received data to its data sink. Do we have a common understanding of how it's going to work? Some other thoughts: Can it be made work with "connection sharing"/"gateway mode"? There are similar flow-control isues there already, at least in my implementation. Is it possible to do something similar by advertising a large window size, but keep a smaller receive buffer? And then blocking the ssh connection (preferably with some short timeout) as needed to deliver the data? One alternative might be a channel request saying "please give me a very large 100 MB windows size, but you don't need to buffer it all, instead, please just close this channel if data delivery blocks for 10s." Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Nov 12 15:05:20 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 555261B3A37 for ; Thu, 12 Nov 2015 15:05:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 k8arqANYvbL3 for ; Thu, 12 Nov 2015 15:05:18 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09BE11B3A3C for ; Thu, 12 Nov 2015 15:05:18 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 52AF814A2AD; Thu, 12 Nov 2015 22:54:57 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id D96C414A2AB; Thu, 12 Nov 2015 22:54:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 91B0714A1E7 for ; Wed, 11 Nov 2015 21:07:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id ee0NFuE_gsaM for ; Wed, 11 Nov 2015 21:07:49 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id A224A14A1D3 for ; Wed, 11 Nov 2015 21:07:49 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for simon@josefsson.org; Wed, 11 Nov 2015 21:07:22 +0000 Date: Wed, 11 Nov 2015 21:07:22 +0000 Subject: Re: Curve25519/448 key agreement for SSH X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <2399114696-3616@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: Simon Josefsson Cc: Damien Miller , ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-9Yg/lXD/fCVVHhibwTMI" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-9Yg/lXD/fCVVHhibwTMI Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable It seems to me the whole X -> K issue can be solved relatively trivially by= specifying the operation as an equivalent of a C++ reinterpret_cast. Any valid X is already a valid K. If the high bit is set, it just so happen= s that the K is negative. But this doesn't matter because K is never used a= s an actual integer, anyway. So, if you have the freedom to do so (not sure how it's done currently for = Curve2559 in OpenSSH), you can replace this text: =C2=A0=C2=A0=C2=A0 The whole 32 bytes of the number X are then converted in= to a big integer k. which with these words is underspecified, with this: =C2=A0=C2=A0=C2=A0 To convert X into K, the [32 bytes / 56 bytes] of X are = reinterpreted as an encoded mpint value of length [32 / 56]. Note that if t= he high bit of the first byte of X is set, the resulting K value is negativ= e. This allows for an unambiguous and trivial conversion, and doesn't leak any= thing in the length of K. ----- Original Message ----- From: Damien Miller=20 Sent: Tuesday, November 10, 2015 18:01 To: Simon Josefsson=20 Cc: ietf-ssh@netbsd.org=20 Subject: Re: Curve25519/448 key agreement for SSH On Tue, 10 Nov 2015, Simon Josefsson wrote: > > AFAIK it might not be possible to resolve without being incompatible > > with the deployed curve25519-sha256@libssh.org protocol: OpenSSH at > > least checks for correct zero-padding for mpints with the MSB set. >=20 > Curve25519 would never have the MSB set, if I understand correctly.=C2=A0= So > what is the potential for incompatibility?=C2=A0 Maybe I'm missing someth= ing. That's true of the public values, but not necessarily of the shared secret, right? I'd expect the shared secret to have the most significant bit set half the time. > I believe this document should document exactly what > curve25519-sha256@libssh.org does, otherwise things will be confusing. > Unless there is a significant mistake with it, of course, but then > people shouldn't be using it at all. >=20 > Nobody has implemented Curve448 for SSH so there is no compatibility to > think about there.=C2=A0 There has not been a lot of interest from > implementers in Curve448 either, since it is slower (no twisted curve). > The only argument I can think of for supporting it is that it hedges you > against potential new analytical ECC attacks that would affect > Curve25519.=C2=A0 But for this work, I believe including Curve448 makes s= ense > since it is what CFRG recommends. Changing the encoding means changing the exchange hash's last field from mpint to string. I argued for this when Aris sent the original curve25519-sha256@libssh.org diff to OpenSSH, but didn't think of the possible MSB leakage and lost the argument :/ Anyway, to summarise the arguments: For changing the encoding of K from mpint to string: - Avoids varying length of K encoding in exchange hash, unlikely leak =C2=A0 of MSB via timing channel - Easier to implement Against: - Inconsistency between curve25519 and curve448 K encoding - Inconsistency between curve448 and all the other KEX methods I honestly don't know whether it is worth fixing it. If I were writing SSH protocol v.3 then I'd remove mpints from the wire protocol entirely and have each protocol define a canonical string encoding for its values. -d = --=-9Yg/lXD/fCVVHhibwTMI Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable It seems to me the whole X -> K issue can be so= lved relatively trivially by specifying the operation as an equivalent of a= C++ reinterpret_cast.

Any valid X is already a valid K. If the high= bit is set, it just so happens that the K is negative. But this doesn't ma= tter because K is never used as an actual integer, anyway.

So, if yo= u have the freedom to do so (not sure how it's done currently for Curve2559= in OpenSSH), you can replace this text:

    The whol= e 32 bytes of the number X are then converted into a big integer k.

= which with these words is underspecified, with this:

  &nb= sp; To convert X into K, the [32 bytes / 56 bytes] of X are reinterpreted a= s an encoded mpint value of length [32 / 56]. Note that if the high bit of = the first byte of X is set, the resulting K value is negative.

This = allows for an unambiguous and trivial conversion, and doesn't leak anything= in the length of K.


----- Original Message -----
From: Damie= n Miller
Sent: Tuesday, November 10, 2015 18:01
To: Simon Josefsson =
Cc: ietf-ssh@netbsd.org
Subject: Re: Curve25519/448 key agreement f= or SSH

On Tue, 10 Nov 2015, Simon Josefsson wrote:

> > = AFAIK it might not be possible to resolve without being incompatible
>= ; > with the deployed curve25519-sha256@libssh.org protocol: OpenSSH at<= br>> > least checks for correct zero-padding for mpints with the MSB = set.
>
> Curve25519 would never have the MSB set, if I underst= and correctly.  So
> what is the potential for incompatibility?&= nbsp; Maybe I'm missing something.

That's true of the public values,= but not necessarily of the shared
secret, right? I'd expect the shared = secret to have the most
significant bit set half the time.

> I= believe this document should document exactly what
> curve25519-sha2= 56@libssh.org does, otherwise things will be confusing.
> Unless ther= e is a significant mistake with it, of course, but then
> people shou= ldn't be using it at all.
>
> Nobody has implemented Curve448 = for SSH so there is no compatibility to
> think about there.  Th= ere has not been a lot of interest from
> implementers in Curve448 ei= ther, since it is slower (no twisted curve).
> The only argument I ca= n think of for supporting it is that it hedges you
> against potentia= l new analytical ECC attacks that would affect
> Curve25519.  Bu= t for this work, I believe including Curve448 makes sense
> since it = is what CFRG recommends.

Changing the encoding means changing the ex= change hash's last field
from mpint to string. I argued for this when Ar= is sent the original
curve25519-sha256@libssh.org diff to OpenSSH, but d= idn't think of the
possible MSB leakage and lost the argument :/

= Anyway, to summarise the arguments:

For changing the encoding of K f= rom mpint to string:

- Avoids varying length of K encoding in exchan= ge hash, unlikely leak
  of MSB via timing channel
- Easier to i= mplement

Against:

- Inconsistency between curve25519 and curv= e448 K encoding
- Inconsistency between curve448 and all the other KEX m= ethods

I honestly don't know whether it is worth fixing it. If I wer= e writing
SSH protocol v.3 then I'd remove mpints from the wire protocol= entirely
and have each protocol define a canonical string encoding for = its
values.

-d

= --=-9Yg/lXD/fCVVHhibwTMI-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Nov 12 15:10:26 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9A01B3A6F for ; Thu, 12 Nov 2015 15:10:26 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, MIME error: error: part did not end with expected boundary; ; error: unexpected end of parts before epilogue X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 nHA5a7ggQRzP for ; Thu, 12 Nov 2015 15:10:17 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF7551B3A6C for ; Thu, 12 Nov 2015 15:10:17 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id C5ADA14A2AE; Thu, 12 Nov 2015 22:55:15 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 5E56814A2AB; Thu, 12 Nov 2015 22:55:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id E6FC814A219 for ; Thu, 12 Nov 2015 18:14:15 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id JVjaLY_f2yyF for ; Thu, 12 Nov 2015 18:14:15 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 3A74414A1FF for ; Thu, 12 Nov 2015 18:14:15 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for pgut001@cs.auckland.ac.nz; Thu, 12 Nov 2015 18:14:12 +0000 Date: Thu, 12 Nov 2015 18:14:12 +0000 Subject: Re: New version of rsa-sha2-256 draft: Back to PKCS#1 v1.5 X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <44533449-2924@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: Peter Gutmann Cc: ietf-ssh@netbsd.org, djm@mindrot.org, terrafrost@gmail.com, thierry.moreau@connotech.com Content-Type: multipart/alternative; boundary="=-U/m8Cwxt2O9GqFlJXw9F" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-U/m8Cwxt2O9GqFlJXw9F Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Alright - I have enabled CBC mode algorithms to make testing easier. We default to CTR mode only now, given that OpenSSH disabled CBC last year,= and our customers want to follow external recommendations, which are to di= sable CBC. Our implementation actually implements a defense for the CBC problem - but = that only works for incoming data, not outgoing. And folks who still only h= ave CBC probably do not implement a defense... ----- Original Message ----- From: Peter Gutmann=20 Sent: Thursday, November 12, 2015 09:51 To: denis bider ; ietf-ssh@netbsd.org=20 Cc: djm@mindrot.org ; terrafrost@gmail.com ; thierry.moreau@connotech.com=20 Subject: RE: New version of rsa-sha2-256 draft: Back to PKCS#1 v1.5 denis bider writes: >I have posted a new version of the draft, which switches back to PKCS#1 v1= .5: Phew, thanks, that makes things much easier to deal with. >I have also updated the experimental server so it implements the latest dr= aft >version (with PKCS#1 v1.5): > >experiment.bitvise.com:10712 > >To test host authentication, set the list of host key algorithms in your >KEXINIT to "rsa-sha2-256" or "rsa-sha2-512". You will need at least one of >these for successful key exchange - the server doesn't offer anything else= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Nov 12 18:50:02 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E12C1B3F08 for ; Thu, 12 Nov 2015 18:50:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 2Bx5ZZpEGy1P for ; Thu, 12 Nov 2015 18:50:00 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADC711B3F03 for ; Thu, 12 Nov 2015 18:50:00 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 3A73814A2AA; Fri, 13 Nov 2015 02:49:57 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 18DC614A2A9 for ; Fri, 13 Nov 2015 02:49:53 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 1XmTNrtL3Kkc for ; Fri, 13 Nov 2015 02:49:52 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id BF60114A2A8 for ; Fri, 13 Nov 2015 02:49:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1447382992; x=1478918992; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5EiL+Fae6lWZVcvyQUjDrsOmJLOUUylO8yid1UIwiik=; b=EnL34XkDq9HGyAbfFqOYu2Kg1+9A4upDXiAnWAw/gMTNC7jsk5MtF/PL gDiFnkGt5/O2kJDqYWPCuVRFOPzln2Z59KQ2m8shj+VSoZ9rxHeKF4tb/ VrRSj+2ztNPPOyGNCulgTXNETlyHxEz2woAzkuFaIMiGAtu/SeiDCtyAW wlp+CpTZTkF513R/0PSfLHHPjjH+NdgpfdzsnVYecPRuIwhxxOa9YTmHl aHoQv7hSCnglLh2BKP57XFjbIvfprxcM0tHSgw62fYwRGAg/lLnrdZ34M xjTbctEHO+8IvXTjSn9xZ2aHGwgqPqBlsIpCfI7ca/zUPBN6JRn4DmVL5 w==; X-IronPort-AV: E=Sophos;i="5.20,285,1444647600"; d="scan'208";a="54041708" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe3.UoA.auckland.ac.nz) ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 13 Nov 2015 15:49:34 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Fri, 13 Nov 2015 15:49:33 +1300 From: Peter Gutmann To: denis bider CC: "ietf-ssh@netbsd.org" , "djm@mindrot.org" , "terrafrost@gmail.com" , "thierry.moreau@connotech.com" Subject: RE: New version of rsa-sha2-256 draft: Back to PKCS#1 v1.5 Thread-Topic: New version of rsa-sha2-256 draft: Back to PKCS#1 v1.5 Thread-Index: AQHRHXXusq8SN1Tfz0+kbj2q9UYctp6ZQJHi Date: Fri, 13 Nov 2015 02:49:33 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B60013@uxcn10-5.UoA.auckland.ac.nz> References: <44533449-2924@skroderider.denisbider.com> In-Reply-To: <44533449-2924@skroderider.denisbider.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list denis bider writes:=0A= =0A= >We default to CTR mode only now, given that OpenSSH disabled CBC last year= ,=0A= >and our customers want to follow external recommendations, which are to=0A= >disable CBC.=0A= =0A= I've never used CTR for the reason I mentioned earlier, it may be worse tha= n=0A= the problem it's meant to be fixing. If you look at Wei Dai's attack, it's= =0A= pretty difficult to actually carry out, it's a chosen-plaintext attack that= =0A= assumes an attacker controls the plaintext, and requires that they wait aro= und=0A= observing a huge number of packets to get a collision on the bits they don'= t=0A= control. Yeah, it's a theoretical weakness, but not one I'm losing much sl= eep=0A= over.=0A= =0A= OTOH CTR mode, which is a keystream generator (KSG), gives the attacker=0A= complete control over the decrypted plaintext. Because of SSH's unfortunat= e=0A= choice of MAC-then-encrypt, the victim has to act on attacker-controlled=0A= metadata in order to verify the MAC and discover that the data was in fact= =0A= manipulated. Try the same thing in CBC mode and you'll just end up garblin= g=0A= the block.=0A= =0A= So my staying with CBC isn't laziness, it's because I consider the practica= l=0A= (not theoretical, I mean CTR even has a security proof) risks of CBC to be= =0A= lower than CTR.=0A= =0A= Peter.= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Nov 12 19:18:30 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92D601B3F40 for ; Thu, 12 Nov 2015 19:18:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 9Wr2WRrROSJa for ; Thu, 12 Nov 2015 19:18:29 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E5511B3F3F for ; Thu, 12 Nov 2015 19:18:29 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 7CE7C14A2B8; Fri, 13 Nov 2015 03:18:28 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 3652214A2B3 for ; Fri, 13 Nov 2015 03:18:25 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 7aqZpynytb32 for ; Fri, 13 Nov 2015 03:18:24 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id E792414A0A4 for ; Fri, 13 Nov 2015 03:18:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1447384704; x=1478920704; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=1/Zh+DxQNrDUkjS6wNTnlrsPkNziNg68XvRYDHm9esg=; b=WP7m0b0ceMGvs6fzra6P8TbbdSfBYEsHJ4DIooKcgFRo6kcJtfN42DbL mCV5WwXbPlKyi1hGRopKFDaRqleDyUPtX1IaOh9taCzbTXHn1Y0Scq3IN qVF/JT3FBvQg1zghhn3zJxCrQux08crqExmm73SsiJayxqdwcIh8H/PKq zCKAJXbBnb8EHEsoJpCvtF25WFBcEcXbzVEu8qb2K+h77Lr2vwjqd7KT+ zNX3UfeFO/oVrh5lVI9LHjPBG6Tv6NZWZIAf/FUFu469sA0KNBzgssyjo Aq6+ZcavqKbC5P48s6JViPmaEwC6iiKy7oXrSXlTfuoLfwfJVKjDqTMsW Q==; X-IronPort-AV: E=Sophos;i="5.20,285,1444647600"; d="scan'208";a="54048341" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe1.UoA.auckland.ac.nz) ([130.216.4.112]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 13 Nov 2015 16:18:22 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Fri, 13 Nov 2015 16:18:22 +1300 From: Peter Gutmann To: denis bider CC: "ietf-ssh@netbsd.org" , "djm@mindrot.org" , "terrafrost@gmail.com" , "thierry.moreau@connotech.com" Subject: RE: New version of rsa-sha2-256 draft: Back to PKCS#1 v1.5 Thread-Topic: New version of rsa-sha2-256 draft: Back to PKCS#1 v1.5 Thread-Index: AQHRHXXusq8SN1Tfz0+kbj2q9UYctp6ZSJ+F Date: Fri, 13 Nov 2015 03:18:21 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B60052@uxcn10-5.UoA.auckland.ac.nz> References: <44533449-2924@skroderider.denisbider.com> In-Reply-To: <44533449-2924@skroderider.denisbider.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list denis bider writes:=0A= =0A= >Alright - I have enabled CBC mode algorithms to make testing easier.=0A= =0A= OK, that worked:=0A= =0A= Testing SSH session...=0A= Remote host: experiment.bitvise.com:10712.=0A= Attempt to activate SSH client session failed with error code -22, line 1= 129.=0A= Error message =3D 'Server reported: Invalid password'.=0A= (Incorrect username/password, continuing...)=0A= =0A= This is some generic test code, so it tries to feed in a default password,= =0A= thus the "invalid password". What format is the private key the banner in?= =0A= It looks OpenSSL-ey...=0A= =0A= Peter.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Nov 12 21:25:13 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 535C81B4027 for ; Thu, 12 Nov 2015 21:25:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 COuVxAQ01Fgx for ; Thu, 12 Nov 2015 21:25:12 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5435C1B4026 for ; Thu, 12 Nov 2015 21:25:12 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 11FEA14A2BD; Fri, 13 Nov 2015 05:25:10 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 8D3CF14A2BA for ; Fri, 13 Nov 2015 05:25:07 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id B_RXvRCsWxBg for ; Fri, 13 Nov 2015 05:25:07 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id C882414A2B3 for ; Fri, 13 Nov 2015 05:25:04 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 142574007C; Fri, 13 Nov 2015 06:25:02 +0100 (CET) Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id 6BA164007A; Fri, 13 Nov 2015 06:25:00 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Fri, 13 Nov 2015 06:25:00 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: Simon Josefsson Cc: denis bider , ietf-ssh@netbsd.org Subject: Re: Curve25519/448 key agreement for SSH References: <2258609541-1780@skroderider.denisbider.com> <87y4e6w69u.fsf@latte.josefsson.org> Date: Fri, 13 Nov 2015 06:25:00 +0100 In-Reply-To: <87y4e6w69u.fsf@latte.josefsson.org> (Simon Josefsson's message of "Tue, 10 Nov 2015 10:30:37 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Simon Josefsson writes: > A simple approach would be to say that if the MSB is 1, prepend a zero > byte. However, the length difference would leak that information. Note that it's also possible to use some slightly different mapping than for mpints. Like it's been done in the dsa signature blob since ages; there the integers are always coded as 20-byte values, no sign bit, and no normalization if some value happens to get a zero high byte.=20 I'm not sure I like that departure from mpint, but I'd like to point out that it's a possibilty and it's been done before. Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Nov 12 23:59:12 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2D51A0018 for ; Thu, 12 Nov 2015 23:59:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 Nd3nuel_BkUT for ; Thu, 12 Nov 2015 23:59:11 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16CE81A0029 for ; Thu, 12 Nov 2015 23:59:11 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id C9B8214A253; Fri, 13 Nov 2015 07:59:07 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 6A95414A24F; Fri, 13 Nov 2015 07:59:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 9561D14A2CE for ; Fri, 13 Nov 2015 06:21:45 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id KvO7cY5RSFI9 for ; Fri, 13 Nov 2015 06:21:44 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 8E0E214A2CD for ; Fri, 13 Nov 2015 06:21:44 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 6EEEB4003E; Fri, 13 Nov 2015 07:21:41 +0100 (CET) Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id 7A30640023; Fri, 13 Nov 2015 07:21:37 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Fri, 13 Nov 2015 07:21:37 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: denis bider Cc: Peter Gutmann , "ietf-ssh\@netbsd.org" , Jeffrey Hutzelman , "Mark D. Baushke" , "stephen.farrell\@cs.tcd.ie" , "jon\@siliconcircus.com" , "djm\@mindrot.org" , Max Horn Subject: Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation References: <11020971-2016@skroderider.denisbider.com> Date: Fri, 13 Nov 2015 07:21:37 +0100 In-Reply-To: <11020971-2016@skroderider.denisbider.com> (denis bider's message of "Thu, 12 Nov 2015 08:39:41 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list denis bider writes: > It seems to me the only known applications that might want to use > "no-handbrake" are those that don't want to use multiplexing. I don't > know of a different usage case. One usecase: Make make s single general-purpose connection from my workstation to my server, using it for one or more shell sessions, port worfwarding, etc. I use "connection sharing", i.e., a local private unix socket that can be used to create additional channels over the same connection. Then I decide to do a large file transfer, so I create a new channel just for that purpose, and I really want it to finish as soon as possible. Now, this is a problem in my implementation which I haven't yet bothered to solve, because it uses a fix and pretty small window size, and typically I won't get close to full network utilization. So I don't know if it's good enough to just set a much larger window size (but if it doesn' I think that ought to solve all "no-handbrake" usecases). > In this situation, you must stop reading from the SSH socket, which > affects all channels. Agreed. And we should note that the "no-handbrake" will not work well if the bottleneck of the data flow actually is after ssh, so users need to enable it with care. One option might be to timeout after a few seconds and close the connection; then we kill the affected channel, without hanging the connection indefinitely. > The way I see it, the only clean usage scenario for this feature is > where there's a single channel. Also in this case, if you get overwelmed with data, you have to stop reading the ssh socket, and hence making timely key reexchange impossible. > That's why I think it makes sense to negotiate it on the transport > layer. The transport layer must be aware of this. Maybe. but I'd prefer a solution to both the single-channel use-case and the usecase above. I think we need to take a step back and sort out what the use cases are. I've been thinking that the poor utilization I've seen is simply a sign of poorly chosen window sizes in my implementation. If it's a more general problem, we need to understand what the usecases and failure modes are. A different solution which I've been considering is a channel mechanism to automatically increase the window size when the ssh flow control is the bottleneck. It could be as easy as checking on reception of SSH_MSG_DATA if the receive window goes down to 0, and if so increase the size of the receive buffer and send a WINDOW_ADJUST which reflects not delivery of data, but the increased buffer. Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Nov 13 00:42:34 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA4F1A1BC2 for ; Fri, 13 Nov 2015 00:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 1kNeSrFrIPX6 for ; Fri, 13 Nov 2015 00:42:33 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57DCD1A1BCB for ; Fri, 13 Nov 2015 00:41:41 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 2F8F214A228; Fri, 13 Nov 2015 08:41:38 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id AF39714A1FF for ; Fri, 13 Nov 2015 08:41:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id HC8oyYZvG9jm for ; Fri, 13 Nov 2015 08:41:35 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id E5BBD14A1D2 for ; Fri, 13 Nov 2015 08:41:34 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 132234003E; Fri, 13 Nov 2015 09:41:33 +0100 (CET) Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id B5F9D40020; Fri, 13 Nov 2015 09:41:31 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Fri, 13 Nov 2015 09:41:31 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: denis bider Cc: ietf-ssh@netbsd.org, Peter Gutmann , djm@mindrot.org, terrafrost@gmail.com, thierry.moreau@connotech.com Subject: Re: New version of rsa-sha2-256 draft: Back to PKCS#1 v1.5 References: <9430962-2924@skroderider.denisbider.com> Date: Fri, 13 Nov 2015 09:41:31 +0100 In-Reply-To: <9430962-2924@skroderider.denisbider.com> (denis bider's message of "Thu, 12 Nov 2015 08:23:06 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list denis bider writes: > Alright - points taken. :-) > > The feedback I've received appears to be as follows: > > - 1 count of support with caveats (Terra) > - 1 count of neutral feedback (received from Thierry; my summary: determi= nistic intuitively better than probabilistic; but then again, this is proba= bly not a problem with PSS) > - 1 count of strong opposition (Peter) Like Peter, I oppose making pss mandatory at this time (i.e., no choice if you want to use sha2). I have no objection to specifying optional methods with pss, if there are people who think migration towards pss is desirable. Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Nov 14 04:28:17 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 662E41B6763 for ; Sat, 14 Nov 2015 04:28:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 TiWLY-UTS_Dp for ; Sat, 14 Nov 2015 04:28:15 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C27F1B675F for ; Sat, 14 Nov 2015 04:28:15 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id D5A4D14A1D3; Sat, 14 Nov 2015 12:28:11 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 7996C14A1D2; Sat, 14 Nov 2015 12:28:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id C59C614A2B8 for ; Fri, 13 Nov 2015 17:15:08 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id AuFhW9Vlve9p for ; Fri, 13 Nov 2015 17:15:08 +0000 (UTC) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id C8D9514A2AC for ; Fri, 13 Nov 2015 17:15:05 +0000 (UTC) Received: from dynamic.wline.6rd.res.cust.swisscom.ch (dynamic.wline.6rd.res.cust.swisscom.ch [IPv6:2a02:120b:2c01:86e0:394d:e19b:44be:1dfd] (may be forged)) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id tADHEk4I007348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Nov 2015 18:14:48 +0100 User-Agent: K-9 Mail for Android In-Reply-To: <33696590-2740@skroderider.denisbider.com> References: <33696590-2740@skroderider.denisbider.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Subject: Re: Curve25519/448 key agreement for SSH From: Simon Josefsson Date: Fri, 13 Nov 2015 18:14:38 +0100 To: denis bider CC: ietf-ssh@netbsd.org Message-ID: <0BA46F13-5A10-425B-B569-0B215E3062DA@josefsson.org> X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Please send me any language improvements - English isn't my native tounge. /Simon denis bider skrev: (13 november 2015 13:29:56 CET) >Looks good to me at this time (before having yet attempted to implement >it). > >I can help you fix up some grammar if you would like, but it's not >crucial to technical understanding. > >(If it stays as-is - I expect it will be caught during the rest of the >process.) > > >----- Original Message ----- >From: Simon Josefsson >Sent: Thursday, November 12, 2015 03:24 >To: ietf-ssh@netbsd.org >Subject: Re: Curve25519/448 key agreement for SSH > >I have updated the document to be clearer about the encoding issue, and >to fix some minor issues. > >https://tools.ietf.org/html/draft-josefsson-ssh-curves-01 > >If Aris and Damien are happy with this version, I believe the document >is in good shape. > >Feedback from others is welcome, especially if anyone is considering >implementing this. > >/Simon -- Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Nov 14 04:28:38 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA9B01B676E for ; Sat, 14 Nov 2015 04:28:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.609 X-Spam-Level: X-Spam-Status: No, score=-1.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 X9R5_wEKC7tl for ; Sat, 14 Nov 2015 04:28:37 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 094461B676B for ; Sat, 14 Nov 2015 04:28:37 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id B1BC514A1DA; Sat, 14 Nov 2015 12:28:36 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 54AA614A1D8; Sat, 14 Nov 2015 12:28:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id E411E14A28A for ; Fri, 13 Nov 2015 14:19:05 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id gznOniMsjgrr for ; Fri, 13 Nov 2015 14:19:05 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id E8BD514A245 for ; Fri, 13 Nov 2015 14:19:04 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for nisse@lysator.liu.se; Fri, 13 Nov 2015 14:18:59 +0000 Date: Fri, 13 Nov 2015 14:18:59 +0000 Subject: Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <2916251-1136@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: =?UTF-8?q?Niels_M=C3=B6ller?= Cc: ietf-ssh@netbsd.org, Damien Miller , Jeffrey Hutzelman , "Mark D. Baushke" , stephen.farrell@cs.tcd.ie, jon@siliconcircus.com, Peter Gutmann , Max Horn Content-Type: multipart/alternative; boundary="=-fJJeQpgkHYKu/W2+C2gW" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-fJJeQpgkHYKu/W2+C2gW Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Niels (regarding EXT_INFO): > But please don't mix that up with the simpler issue > of algorithm updates. Yes - this is why I have separated the RFCs, so they can progress, or not p= rogress, independently. > Note that's what relevant for public key user auth > isn't really the algorithms supported by the server, > but the algorithms of the keys which are actually > authorized for login. This seems to me the kind of setting that's likely to be enabled or disable= d by server-wide policy or algorithm availability, not by per-user configur= ation. For example, if the server doesn't support rsa-sha2-512, but does su= pport rsa-sha2-256, that's probably going to be server-wide, not user-speci= fic. If the server administrator disabled ssh-rsa due to SHA-1 concerns, th= at's also going to be server-wide. > It makes some sense to filter available keys depending > on what the server supports, but I don't think it will > make much of a practical difference. Consider that you have a server that supports rsa-sha2-256, but not ssh-rsa= . You have a client who's inclined to try rsa-sha2-512 first, and rsa-sha2-= 256 next. Or the other way around. Without EXT_INFO, you spend: - one round-trip in SERVICE_REQUEST and SERVICE_ACCEPT - one round-trip in initial request with rsa-sha2-512 signature, rejected - one round-trip in next request with rsa-sha2-256 signature, accepted Total: 3 round-trips. This might be 0.6 seconds over the Pacific (200 ms pe= r round-trip), or 6 seconds over a satellite link (2s per round-trip). With EXT_INFO, you spend: - half a round-trip waiting for server's EXT_INFO, which comes with NEWKEYS - one round-trip in request with rsa-sha2-256 signature, accepted Total cost: 1.5 round-trips. This might be 0.3 seconds over the Pacific, or= 3 seconds over a satellite link. =C2=A0=C2=A0=C2=A0=20 Now consider a future scenario where we add rsa-sha3-256 and rsa-sha3-512. = :) Now you might be spending 5 round-trips guessing the right algorithm wit= hout EXT_INFO. Whereas with EXT_INFO, you are done in 1.5 round-trips. Thes= e 5 round-trips might be 1 second over the Pacific, or 10 seconds over a sa= tellite link. With EXT_INFO, we have a flat cost that does not increase. Without EXT_INFO= , cost may not look so bad right now (say 3 round-trips if second guess is = right); but future round-trip cost increases. ----- Original Message ----- From: Niels "M=C3=B6ller"=20 Sent: Friday, November 13, 2015 02:16 To: denis bider=20 Cc: ietf-ssh@netbsd.org ; Damien Miller ; Jeffrey Hutzelman ; Mark D. Baush= ke ; stephen.farrell@cs.tcd.ie ; jon@siliconcircus.com ; Peter Gutmann ; Ma= x Horn=20 Subject: Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation denis bider writes: > It seems to me that SSH needs a proper extension mechanism to avoid > version-string-based hacks and other kinds of hacks. Maybe. But please don't mix that up with the simpler issue of algorithm updates. > - Does not make signature algorithm information available in time for > the client's first user auth request. This costs a round-trip if the > client's first guess is incorrect. Note that's what relevant for public key user auth isn't really the algorithms supported by the server, but the algorithms of the keys which are actually authorized for login. It makes some sense to filter available keys depending on what the server supports, but I don't think it will make much of a practical difference. Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.= --=-fJJeQpgkHYKu/W2+C2gW Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Niels (regarding EXT_INFO):

> But please= don't mix that up with the simpler issue
> of algorithm updates.
=
Yes - this is why I have separated the RFCs, so they can progress, or n= ot progress, independently.


> Note that's what relevant for p= ublic key user auth
> isn't really the algorithms supported by the se= rver,
> but the algorithms of the keys which are actually
> aut= horized for login.

This seems to me the kind of setting that's likel= y to be enabled or disabled by server-wide policy or algorithm availability= , not by per-user configuration. For example, if the server doesn't support= rsa-sha2-512, but does support rsa-sha2-256, that's probably going to be s= erver-wide, not user-specific. If the server administrator disabled ssh-rsa= due to SHA-1 concerns, that's also going to be server-wide.


>= ; It makes some sense to filter available keys depending
> on what th= e server supports, but I don't think it will
> make much of a practic= al difference.

Consider that you have a server that supports rsa-sha= 2-256, but not ssh-rsa. You have a client who's inclined to try rsa-sha2-51= 2 first, and rsa-sha2-256 next. Or the other way around.

Without EXT= _INFO, you spend:
- one round-trip in SERVICE_REQUEST and SERVICE_ACCEPT=
- one round-trip in initial request with rsa-sha2-512 signature, reject= ed
- one round-trip in next request with rsa-sha2-256 signature, accepte= d

Total: 3 round-trips. This might be 0.6 seconds over the Pacific (= 200 ms per round-trip), or 6 seconds over a satellite link (2s per round-tr= ip).

With EXT_INFO, you spend:
- half a round-trip waiting for se= rver's EXT_INFO, which comes with NEWKEYS
- one round-trip in request wi= th rsa-sha2-256 signature, accepted

Total cost: 1.5 round-trips. Thi= s might be 0.3 seconds over the Pacific, or 3 seconds over a satellite link= .
   
Now con= sider a future scenario where we add rsa-sha3-256 and rsa-sha3-512. :) Now = you might be spending 5 round-trips guessing the right algorithm without EX= T_INFO. Whereas with EXT_INFO, you are done in 1.5 round-trips. These 5 rou= nd-trips might be 1 second over the Pacific, or 10 seconds over a satellite= link.

With EXT_INFO, we have a flat cost that does not increase. Wi= thout EXT_INFO, cost may not look so bad right now (say 3 round-trips if se= cond guess is right); but future round-trip cost increases.


----= - Original Message -----
From: Niels "M=C3=B6ller"
Sent: Friday, Nov= ember 13, 2015 02:16
To: denis bider
Cc: ietf-ssh@netbsd.org ; Damie= n Miller ; Jeffrey Hutzelman ; Mark D. Baushke ; stephen.farrell@cs.tcd.ie = ; jon@siliconcircus.com ; Peter Gutmann ; Max Horn
Subject: Re: Updated= RSA SHA-2 draft / New draft: SSH Extension Negotiation

denis bider = <ietf-ssh3@denisbider.com> writes:

> It seems to me that SS= H needs a proper extension mechanism to avoid
> version-string-based = hacks and other kinds of hacks.

Maybe. But please don't mix that up = with the simpler issue of algorithm
updates.

> - Does not make= signature algorithm information available in time for
> the client's= first user auth request. This costs a round-trip if the
> client's f= irst guess is incorrect.

Note that's what relevant for public key us= er auth isn't really the
algorithms supported by the server, but the alg= orithms of the keys which
are actually authorized for login. It makes so= me sense to filter
available keys depending on what the server supports,= but I don't think
it will make much of a practical difference.

R= egards,
/Niels

--
Niels M=C3=B6ller. PGP-encrypted email is p= referred. Keyid C0B98E26.
Internet email is subject to wholesale governm= ent surveillance.= --=-fJJeQpgkHYKu/W2+C2gW-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Nov 14 04:28:52 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC7DA1B676D for ; Sat, 14 Nov 2015 04:28:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.909 X-Spam-Level: X-Spam-Status: No, score=-3.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 LIp6gsfnQQbS for ; Sat, 14 Nov 2015 04:28:50 -0800 (PST) Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53DAF1B676E for ; Sat, 14 Nov 2015 04:28:46 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id F2A3714A1E9; Sat, 14 Nov 2015 12:28:45 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 9380114A1E1; Sat, 14 Nov 2015 12:28:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id E578214A2B8 for ; Fri, 13 Nov 2015 13:42:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 3q_fP2f078Qb for ; Fri, 13 Nov 2015 13:42:34 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 9EB3A14A2B1 for ; Fri, 13 Nov 2015 13:42:34 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for nisse@lysator.liu.se; Fri, 13 Nov 2015 13:42:26 +0000 Date: Fri, 13 Nov 2015 13:42:26 +0000 Subject: Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <1295245-1136@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: =?UTF-8?q?Niels_M=C3=B6ller?= Cc: Peter Gutmann , Jeffrey Hutzelman , ietf-ssh@netbsd.org, "Mark D. Baushke" , stephen.farrell@cs.tcd.ie, jon@siliconcircus.com, djm@mindrot.org, Max Horn Content-Type: multipart/alternative; boundary="=-2jkgpzFQWm/9q++2BM82" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-2jkgpzFQWm/9q++2BM82 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable If you're not seeing full network utilization to the extent permitted by yo= ur TCP stack (note that the TCP stack may itself be throttling you below ne= twork potential), then the problem is very likely either mismanaged channel= window size (probably in the sending direction), or insufficient SFTP requ= est pipelining. In general, the channel window must be large enough that the sender doesn't= get throttled by the window size before the receiver can respond with a wi= ndow adjust. The size required increases linearly with a multiple of connec= tion latency and bandwidth. Note that the required window size for full throughput can be fairly large = with long fat pipes; WAY larger than would be appropriate for a slow, low-l= atency connection. If you're sending at 40 Mbps (which is not even that fas= t now) across the Atlantic or Pacific (200 ms round-trip) you need a window= size on the order of 1 MB. If you want to send at gigabit speeds with same= latency, you need appropriately more; e.g. 20 MB. The SFTP performance problem can be solved, and we believe it to be solved = in our software, using both appropriate window sizing and SFTP request pipe= lining. So the "no-handbrake" extension is not strictly NECESSARY, it's pos= sible to reach network potential without it. What the "no-handbrake" extension does is remove a level of complexity for = people writing simple, special-purpose SSH implementations, who want to ach= ieve decent performance without having to make a PhD out of it. If the chan= nel window sizing implementation is poor, then if "no-handbrake" is not ava= ilable, performance will suck. But if it's available, performance will be a= s good as the TCP stack permits (which is written by professionals). If you have a multipurpose implementation that supports multiple channels, = I think you should just do channel window sizing properly. I would not like= general-purpose, multichannel implementations resorting to this. You're al= ready accepting a higher level of complexity by supporting multiple channel= s; so why not do it right. ----- Original Message ----- From: Niels "M=C3=B6ller"=20 Sent: Friday, November 13, 2015 00:21 To: denis bider=20 Cc: Peter Gutmann ; ietf-ssh@netbsd.org ; Jeffrey Hutzelman ; Mark D. Baush= ke ; stephen.farrell@cs.tcd.ie ; jon@siliconcircus.com ; djm@mindrot.org ; = Max Horn=20 Subject: Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation denis bider writes: > It seems to me the only known applications that might want to use > "no-handbrake" are those that don't want to use multiplexing. I don't > know of a different usage case. One usecase: Make make s single general-purpose connection from my workstation to my server, using it for one or more shell sessions, port worfwarding, etc. I use "connection sharing", i.e., a local private unix socket that can be used to create additional channels over the same connection. Then I decide to do a large file transfer, so I create a new channel just for that purpose, and I really want it to finish as soon as possible. Now, this is a problem in my implementation which I haven't yet bothered to solve, because it uses a fix and pretty small window size, and typically I won't get close to full network utilization. So I don't know if it's good enough to just set a much larger window size (but if it doesn' I think that ought to solve all "no-handbrake" usecases). > In this situation, you must stop reading from the SSH socket, which > affects all channels. Agreed. And we should note that the "no-handbrake" will not work well if the bottleneck of the data flow actually is after ssh, so users need to enable it with care. One option might be to timeout after a few seconds and close the connection; then we kill the affected channel, without hanging the connection indefinitely. > The way I see it, the only clean usage scenario for this feature is > where there's a single channel. Also in this case, if you get overwelmed with data, you have to stop reading the ssh socket, and hence making timely key reexchange impossible. > That's why I think it makes sense to negotiate it on the transport > layer. The transport layer must be aware of this. Maybe. but I'd prefer a solution to both the single-channel use-case and the usecase above. I think we need to take a step back and sort out what the use cases are. I've been thinking that the poor utilization I've seen is simply a sign of poorly chosen window sizes in my implementation. If it's a more general problem, we need to understand what the usecases and failure modes are. A different solution which I've been considering is a channel mechanism to automatically increase the window size when the ssh flow control is the bottleneck. It could be as easy as checking on reception of SSH_MSG_DATA if the receive window goes down to 0, and if so increase the size of the receive buffer and send a WINDOW_ADJUST which reflects not delivery of data, but the increased buffer. Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. = --=-2jkgpzFQWm/9q++2BM82 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable If you're not seeing full network utilization to t= he extent permitted by your TCP stack (note that the TCP stack may itself b= e throttling you below network potential), then the problem is very likely = either mismanaged channel window size (probably in the sending direction), = or insufficient SFTP request pipelining.

In general, the channel win= dow must be large enough that the sender doesn't get throttled by the windo= w size before the receiver can respond with a window adjust. The size requi= red increases linearly with a multiple of connection latency and bandwidth.=

Note that the required window size for full throughput can be fairl= y large with long fat pipes; WAY larger than would be appropriate for a slo= w, low-latency connection. If you're sending at 40 Mbps (which is not even = that fast now) across the Atlantic or Pacific (200 ms round-trip) you need = a window size on the order of 1 MB. If you want to send at gigabit speeds w= ith same latency, you need appropriately more; e.g. 20 MB.

The SFTP = performance problem can be solved, and we believe it to be solved in our so= ftware, using both appropriate window sizing and SFTP request pipelining. S= o the "no-handbrake" extension is not strictly NECESSARY, it's possible to = reach network potential without it.

What the "no-handbrake" extensio= n does is remove a level of complexity for people writing simple, special-p= urpose SSH implementations, who want to achieve decent performance without = having to make a PhD out of it. If the channel window sizing implementation= is poor, then if "no-handbrake" is not available, performance will suck. B= ut if it's available, performance will be as good as the TCP stack permits = (which is written by professionals).

If you have a multipurpose impl= ementation that supports multiple channels, I think you should just do chan= nel window sizing properly. I would not like general-purpose, multichannel = implementations resorting to this. You're already accepting a higher level = of complexity by supporting multiple channels; so why not do it right.
<= br>
----- Original Message -----
From: Niels "M=C3=B6ller"
Sent: = Friday, November 13, 2015 00:21
To: denis bider
Cc: Peter Gutmann ; = ietf-ssh@netbsd.org ; Jeffrey Hutzelman ; Mark D. Baushke ; stephen.farrell= @cs.tcd.ie ; jon@siliconcircus.com ; djm@mindrot.org ; Max Horn
Subject= : Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation
denis bider <nospam@denisbider.com> writes:

> It seems to = me the only known applications that might want to use
> "no-handbrake= " are those that don't want to use multiplexing. I don't
> know of a = different usage case.

One usecase: Make make s single general-purpos= e connection from my
workstation to my server, using it for one or more = shell sessions, port
worfwarding, etc. I use "connection sharing", i.e.,= a local private unix
socket that can be used to create additional chann= els over the same
connection.

Then I decide to do a large file tr= ansfer, so I create a new channel
just for that purpose, and I really wa= nt it to finish as soon as
possible.

Now, this is a problem in my= implementation which I haven't yet bothered
to solve, because it uses a= fix and pretty small window size, and
typically I won't get close to fu= ll network utilization. So I don't know
if it's good enough to just set = a much larger window size (but if it
doesn' I think that ought to solve = all "no-handbrake" usecases).

> In this situation, you must stop = reading from the SSH socket, which
> affects all channels.

Agr= eed. And we should note that the "no-handbrake" will not work well if
th= e bottleneck of the data flow actually is after ssh, so users need to
en= able it with care. One option might be to timeout after a few seconds
an= d close the connection; then we kill the affected channel, without
hangi= ng the connection indefinitely.

> The way I see it, the only clea= n usage scenario for this feature is
> where there's a single channel= .

Also in this case, if you get overwelmed with data, you have to st= op
reading the ssh socket, and hence making timely key reexchange
imp= ossible.

> That's why I think it makes sense to negotiate it on t= he transport
> layer. The transport layer must be aware of this.
<= br>Maybe. but I'd prefer a solution to both the single-channel use-case and=
the usecase above. I think we need to take a step back and sort out wha= t
the use cases are. I've been thinking that the poor utilization I'veseen is simply a sign of poorly chosen window sizes in my
implementati= on. If it's a more general problem, we need to understand
what the useca= ses and failure modes are.

A different solution which I've been cons= idering is a channel mechanism
to automatically increase the window size= when the ssh flow control is
the bottleneck. It could be as easy as che= cking on reception of
SSH_MSG_DATA if the receive window goes down to 0,= and if so increase
the size of the receive buffer and send a WINDOW_ADJ= UST which reflects
not delivery of data, but the increased buffer.
Regards,
/Niels

--
Niels M=C3=B6ller. PGP-encrypted email i= s preferred. Keyid C0B98E26.
Internet email is subject to wholesale gove= rnment surveillance.

= --=-2jkgpzFQWm/9q++2BM82-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Nov 14 04:29:05 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A11E1B6775 for ; Sat, 14 Nov 2015 04:29:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 7-AZh1NWt7Fp for ; Sat, 14 Nov 2015 04:28:57 -0800 (PST) Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B88991B6773 for ; Sat, 14 Nov 2015 04:28:57 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 7225A14A1F0; Sat, 14 Nov 2015 12:28:57 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 19E7314A1EF; Sat, 14 Nov 2015 12:28:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 6A81F14A0DC for ; Fri, 13 Nov 2015 12:30:19 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 3LNlDFo6CBPt for ; Fri, 13 Nov 2015 12:30:18 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id DC7D014A0A0 for ; Fri, 13 Nov 2015 12:30:18 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for simon@josefsson.org; Fri, 13 Nov 2015 12:29:56 +0000 Date: Fri, 13 Nov 2015 12:29:56 +0000 Subject: Re: Curve25519/448 key agreement for SSH X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <33696590-2740@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: Simon Josefsson Cc: ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-QcxefYa5ne7AuT+DkIxN" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-QcxefYa5ne7AuT+DkIxN Content-Type: text/plain; charset="utf-8" Looks good to me at this time (before having yet attempted to implement it). I can help you fix up some grammar if you would like, but it's not crucial to technical understanding. (If it stays as-is - I expect it will be caught during the rest of the process.) ----- Original Message ----- From: Simon Josefsson Sent: Thursday, November 12, 2015 03:24 To: ietf-ssh@netbsd.org Subject: Re: Curve25519/448 key agreement for SSH I have updated the document to be clearer about the encoding issue, and to fix some minor issues. https://tools.ietf.org/html/draft-josefsson-ssh-curves-01 If Aris and Damien are happy with this version, I believe the document is in good shape. Feedback from others is welcome, especially if anyone is considering implementing this. /Simon --=-QcxefYa5ne7AuT+DkIxN Content-Type: text/html; charset="utf-8" Looks good to me at this time (before having yet attempted to implement it).

I can help you fix up some grammar if you would like, but it's not crucial to technical understanding.

(If it stays as-is - I expect it will be caught during the rest of the process.)


----- Original Message -----
From: Simon Josefsson
Sent: Thursday, November 12, 2015 03:24
To: ietf-ssh@netbsd.org
Subject: Re: Curve25519/448 key agreement for SSH

I have updated the document to be clearer about the encoding issue, and
to fix some minor issues.

https://tools.ietf.org/html/draft-josefsson-ssh-curves-01

If Aris and Damien are happy with this version, I believe the document
is in good shape.

Feedback from others is welcome, especially if anyone is considering
implementing this.

/Simon

--=-QcxefYa5ne7AuT+DkIxN-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Nov 14 04:29:24 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6081B6779 for ; Sat, 14 Nov 2015 04:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 OZSWSfiK8B5i for ; Sat, 14 Nov 2015 04:29:22 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61D4B1B6778 for ; Sat, 14 Nov 2015 04:29:22 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id F2AB914A1FF; Sat, 14 Nov 2015 12:29:21 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 9726D14A1D3; Sat, 14 Nov 2015 12:29:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 6BAB814A27F for ; Fri, 13 Nov 2015 13:23:21 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 7Gob1l42V-Ug for ; Fri, 13 Nov 2015 13:23:20 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id C30AE14A25C for ; Fri, 13 Nov 2015 13:23:20 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for pgut001@cs.auckland.ac.nz; Fri, 13 Nov 2015 13:23:16 +0000 Date: Fri, 13 Nov 2015 13:23:16 +0000 Subject: Re: New version of rsa-sha2-256 draft: Back to PKCS#1 v1.5 X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <388395-1136@skroderider.denisbider.com> From: denis bider To: Peter Gutmann Cc: ietf-ssh@netbsd.org, djm@mindrot.org, terrafrost@gmail.com, thierry.moreau@connotech.com X-Priority: 3 Importance: Normal MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=-8EH1zMHcfqDhBjr8djSP" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-8EH1zMHcfqDhBjr8djSP Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The format of the private key is OpenSSH, yes. I can also export in PuTTY o= r Bitvise format, but I'm not sure either of those would be more helpful...= :) You can also send me an RSA public key (e.g. in standard SSH format, or Ope= nSSH format) and I can import it, if you like. ----- Original Message ----- From: Peter Gutmann=20 Sent: Thursday, November 12, 2015 21:18 To: denis bider=20 Cc: ietf-ssh@netbsd.org ; djm@mindrot.org ; terrafrost@gmail.com ; thierry.= moreau@connotech.com=20 Subject: RE: New version of rsa-sha2-256 draft: Back to PKCS#1 v1.5 denis bider writes: >Alright - I have enabled CBC mode algorithms to make testing easier. OK, that worked: =C2=A0 Testing SSH session... =C2=A0 Remote host: experiment.bitvise.com:10712. =C2=A0 Attempt to activate SSH client session failed with error code -22, l= ine 1129. =C2=A0 Error message =3D 'Server reported: Invalid password'. =C2=A0 (Incorrect username/password, continuing...) This is some generic test code, so it tries to feed in a default password, thus the "invalid password".=C2=A0 What format is the private key the banne= r in? It looks OpenSSL-ey... Peter. = --=-8EH1zMHcfqDhBjr8djSP Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable The format of the private key is OpenSSH, yes. I c= an also export in PuTTY or Bitvise format, but I'm not sure either of those= would be more helpful... :)

You can also send me an RSA public key = (e.g. in standard SSH format, or OpenSSH format) and I can import it, if yo= u like.


----- Original Message -----
From: Peter Gutmann
= Sent: Thursday, November 12, 2015 21:18
To: denis bider
Cc: ietf-ssh= @netbsd.org ; djm@mindrot.org ; terrafrost@gmail.com ; thierry.moreau@conno= tech.com
Subject: RE: New version of rsa-sha2-256 draft: Back to PKCS#1= v1.5

denis bider <ietf-ssh3@denisbider.com> writes:

&g= t;Alright - I have enabled CBC mode algorithms to make testing easier.
<= br>OK, that worked:

  Testing SSH session...
  Remote h= ost: experiment.bitvise.com:10712.
  Attempt to activate SSH client= session failed with error code -22, line 1129.
  Error message =3D= 'Server reported: Invalid password'.
  (Incorrect username/passwor= d, continuing...)

This is some generic test code, so it tries to fee= d in a default password,
thus the "invalid password".  What format = is the private key the banner in?
It looks OpenSSL-ey...

Peter.
= --=-8EH1zMHcfqDhBjr8djSP-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Nov 14 04:29:34 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59AA01B677B for ; Sat, 14 Nov 2015 04:29:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.609 X-Spam-Level: X-Spam-Status: No, score=-1.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 OWdBpR7EjlhL for ; Sat, 14 Nov 2015 04:29:33 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F5D41B6778 for ; Sat, 14 Nov 2015 04:29:33 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 06CC414A201; Sat, 14 Nov 2015 12:29:33 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 9782B14A200; Sat, 14 Nov 2015 12:29:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 7E02514A2CA for ; Fri, 13 Nov 2015 15:24:26 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 0YJFRmK96tFg for ; Fri, 13 Nov 2015 15:24:25 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id C875414A2BD for ; Fri, 13 Nov 2015 15:24:25 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for jhutz@cmu.edu; Fri, 13 Nov 2015 15:24:18 +0000 Date: Fri, 13 Nov 2015 15:24:18 +0000 Subject: Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <7144003-2676@skroderider.denisbider.com> X-Priority: 3 Importance: Normal In-Reply-To: MIME-Version: 1.0 From: denis bider To: Jeffrey Hutzelman , =?UTF-8?q?Niels_M=C3=B6ller?= Cc: Peter Gutmann , ietf-ssh@netbsd.org, "Mark D. Baushke" , stephen.farrell@cs.tcd.ie, jon@siliconcircus.com, djm@mindrot.org, Max Horn Content-Type: multipart/alternative; boundary="=-5KPNSpZC5bXO2V0O/ys2" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-5KPNSpZC5bXO2V0O/ys2 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I think it's appropriate as an explicit clarification of the behavior the R= FC intended, and which most implementations implement (but some don't). I don't think It's too late because errant implementations can correct this= , and in time new versions of these implementations will be used. Don't think in 2-3 years time, think in 10 years time. Internet protocols t= end to hang around for a while. SMTP has been around for 33 years... Jeffrey Hutzelman , 11/13/2015 3:12 PM: On November 13, 2015 9:39:23 AM EST, denis bider = wrote:=20 >Much agreed.=20 >=20 >If the IETF will accept an erratum with a clarification, here's a=20 >proposed wording:=20 >=20 >=20 >"Servers and clients may or may not be aware of a future extension to=20 >this RFC that specifies a use for the KEXINIT reserved field.=20 >=20 >Servers and clients that are NOT aware of such an extension:=20 >- MUST send the reserved field with the value zero (indicating=20 >unawareness);=20 >- MUST NOT act on any value of this field when received, whether zero=20 >or non-zero;=20 >- in key exchange, MUST properly hash the actual received value of this=20 >field.=20 >=20 >This behavior is REQUIRED to allow use of this field in future protocol=20 >extension."=20 =20 It certainly was a mistake not to specify this to begin with. =C2=A0However= , this represents a change to the protocol, not correction of a technical i= naccuracy in the document. =C2=A0Nor is it a change to reflect common, cons= istent actual practice which differs from the specified protocol. =C2=A0So,= I don't think it's appropriate for an erratum. =C2=A0Further, it's too lat= e: this behavior is only useful if older implementations follow it; you can= 't add extensibility after the fact.=20 =20 -- Jeff=20 =20 = --=-5KPNSpZC5bXO2V0O/ys2 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
I think it's appropriate as an explicit clari= fication of the behavior the RFC intended, and which most implementations i= mplement (but some don't).

I don't think It's too late because erran= t implementations can correct this, and in time new versions of these imple= mentations will be used.

Don't think in 2-3 years time, think in 10 = years time. Internet protocols tend to hang around for a while. SMTP has be= en around for 33 years...


Jeffrey Hutzelman <jhutz@cmu.edu> , 11/13/2015 3:12 PM:
=
On November 13, 2015 9:39:23 AM EST, denis bid= er <ietf-ssh3@denisbider.com&= gt; wrote:
>Much agreed.
>
>If the IETF will accept an erratum with a clarification, here's a
>proposed wording:
>
>
>"Servers and clients may or may not be aware of a future extension = to
>this RFC that specifies a use for the KEXINIT reserved field.
>
>Servers and clients that are NOT aware of such an extension:
>- MUST send the reserved field with the value zero (indicating
>unawareness);
>- MUST NOT act on any value of this field when received, whether ze= ro
>or non-zero;
>- in key exchange, MUST properly hash the actual received value of = this
>field.
>
>This behavior is REQUIRED to allow use of this field in future prot= ocol
>extension."

It certainly was a mistake not to specify this to begin with.  How= ever, this represents a change to the protocol, not correction of a technic= al inaccuracy in the document.  Nor is it a change to reflect common, = consistent actual practice which differs from the specified protocol.  = ;So, I don't think it's appropriate for an erratum.  Further, it's too= late: this behavior is only useful if older implementations follow it; you= can't add extensibility after the fact.

-- Jeff

= --=-5KPNSpZC5bXO2V0O/ys2-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Nov 14 04:29:55 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 106CF1A01D7 for ; Sat, 14 Nov 2015 04:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.909 X-Spam-Level: X-Spam-Status: No, score=-3.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 XHsef8O_Lj6Y for ; Sat, 14 Nov 2015 04:29:53 -0800 (PST) Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4019C1A0155 for ; Sat, 14 Nov 2015 04:29:53 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id D2B5D14A213; Sat, 14 Nov 2015 12:29:52 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 788EB14A209; Sat, 14 Nov 2015 12:29:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id C923514A2BC for ; Fri, 13 Nov 2015 15:04:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id x0Yafo7jLvOH for ; Fri, 13 Nov 2015 15:04:36 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 165E514A2AD for ; Fri, 13 Nov 2015 15:04:36 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for nisse@lysator.liu.se; Fri, 13 Nov 2015 15:04:28 +0000 Date: Fri, 13 Nov 2015 15:04:28 +0000 Subject: Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <6459923-1084@skroderider.denisbider.com> From: denis bider To: =?UTF-8?q?Niels_M=C3=B6ller?= Cc: Peter Gutmann , ietf-ssh@netbsd.org, Jeffrey Hutzelman , "Mark D. Baushke" , stephen.farrell@cs.tcd.ie, jon@siliconcircus.com, djm@mindrot.org, Max Horn X-Priority: 3 Importance: Normal In-Reply-To: <4323240-1468@skroderider.denisbider.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=-5zCMCZqBMOHiN/BhIGy8" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-5zCMCZqBMOHiN/BhIGy8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I have submitted this erratum. We will see how it's received. denis bider , 11/13/2015 2:28 PM: Much agreed. If the IETF will accept an erratum with a clarification, here's a proposed = wording: "Servers and clients may or may not be aware of a future extension to this = RFC that specifies a use for the KEXINIT reserved field. Servers and clients that are NOT aware of such an extension: - MUST send the reserved field with the value zero (indicating unawareness)= ; - MUST NOT act on any value of this field when received, whether zero or no= n-zero; - in key exchange, MUST properly hash the actual received value of this fie= ld. This behavior is REQUIRED to allow use of this field in future protocol ext= ension." ----- Original Message ----- From: Niels "M=C3=B6ller"=20 Sent: Friday, November 13, 2015 02:37 To: Peter Gutmann=20 Cc: denis bider ; ietf-ssh@netbsd.org ; Jeffrey Hutzelman ; Mark D. Baushke= ; stephen.farrell@cs.tcd.ie ; jon@siliconcircus.com ; djm@mindrot.org ; Ma= x Horn=20 Subject: Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation Peter Gutmann writes: > Niels M=C3=B6ller writes: > >>Send 0, ignore received value, would have made it actually useful. > > Can we get any figures on what effect making it nonzero would have? I think my implementation will disconnect. Anyway, if we do a general smallish update, it would make sense to fix this (not sure in which form, note in the algorithms update rfc, or an errate on hte old rfc). And simply say that until any of the future extensions are specified, implementations should accept and ignore non-zero values for this field. That will make our lives a little easier a few years from now. Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. = --=-5zCMCZqBMOHiN/BhIGy8 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable I have submitted this erratum. We will see how it'= s received.


denis bider <ietf-= ssh3@denisbider.com> , 11/13/2015 2:28 PM:
Much agreed.

If the IETF will accept an erratum wi= th a clarification, here's a proposed wording:


"Servers and clie= nts may or may not be aware of a future extension to this RFC that specifie= s a use for the KEXINIT reserved field.

Servers and clients that are= NOT aware of such an extension:
- MUST send the reserved field with the= value zero (indicating unawareness);
- MUST NOT act on any value of thi= s field when received, whether zero or non-zero;
- in key exchange, MUST= properly hash the actual received value of this field.

This behavio= r is REQUIRED to allow use of this field in future protocol extension."
=

----- Original Message -----
From: Niels "M=C3=B6ller"
Sent:= Friday, November 13, 2015 02:37
To: Peter Gutmann
Cc: denis bider ;= ietf-ssh@netbsd.org ; Jeffrey Hutzelman ; Mark D. Ba= ushke ; stephen.farrell@cs.tcd.ie ; jon@siliconcircus.com ; djm@mindrot.org = ; Max Horn
Subject: Re: Updated RSA SHA-2 draft / New draft: SSH Extens= ion Negotiation

Peter Gutmann <pgut= 001@cs.auckland.ac.nz> writes:

> Niels M=C3=B6ller <nisse@lysator.liu.se> writes:
>
>>Se= nd 0, ignore received value, would have made it actually useful.
>> Can we get any figures on what effect making it nonzero would have?
I think my implementation will disconnect.

Anyway, if we do a = general smallish update, it would make sense to fix
this (not sure in wh= ich form, note in the algorithms update rfc, or an
errate on hte old rfc= ). And simply say that until any of the future
extensions are specified,= implementations should accept and ignore
non-zero values for this field= .

That will make our lives a little easier a few years from now.
=
Regards,
/Niels

--
Niels M=C3=B6ller. PGP-encrypted email= is preferred. Keyid C0B98E26.
Internet email is subject to wholesale go= vernment surveillance.

= --=-5zCMCZqBMOHiN/BhIGy8-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Nov 14 04:30:09 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ADB61A0235 for ; Sat, 14 Nov 2015 04:30:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 0c1Z9bS0qs2b for ; Sat, 14 Nov 2015 04:30:07 -0800 (PST) Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 821771A0211 for ; Sat, 14 Nov 2015 04:30:07 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 2CDC514A20F; Sat, 14 Nov 2015 12:30:07 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id C9F0D14A209; Sat, 14 Nov 2015 12:30:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 97F5214A2AA for ; Fri, 13 Nov 2015 12:53:17 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 2sYiCTO0ONVc for ; Fri, 13 Nov 2015 12:53:16 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id B1FDC14A2A6 for ; Fri, 13 Nov 2015 12:53:16 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for pgut001@cs.auckland.ac.nz; Fri, 13 Nov 2015 12:53:10 +0000 Date: Fri, 13 Nov 2015 12:53:10 +0000 Subject: Re: New version of rsa-sha2-256 draft: Back to PKCS#1 v1.5 X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <540590-3304@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: Peter Gutmann Cc: ietf-ssh@netbsd.org, djm@mindrot.org, terrafrost@gmail.com, thierry.moreau@connotech.com Content-Type: multipart/alternative; boundary="=-HcBHN2MNnKskTIW5VqF6" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-HcBHN2MNnKskTIW5VqF6 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I'm not sure we're referring to the same attack. The most critical SSH + CB= C attack I can think of right now is this: http://isg.rhul.ac.uk/~kp/SandPfinal.pdf This requires only a MITM position and allows recovery of up to 32 plaintex= t bits once per about ~200k intercepted connections. That's perfectly feasi= ble if the connections are being automatically retried over some time witho= ut supervision (which is not unusual in deployment). Our defense against this is to not obviously leak info about whether the re= sult of packet length decryption was something sensible or not. But it may = be that most implementations don't do this. ----- Original Message ----- From: Peter Gutmann=20 Sent: Thursday, November 12, 2015 20:49 To: denis bider=20 Cc: ietf-ssh@netbsd.org ; djm@mindrot.org ; terrafrost@gmail.com ; thierry.= moreau@connotech.com=20 Subject: RE: New version of rsa-sha2-256 draft: Back to PKCS#1 v1.5 denis bider writes: >We default to CTR mode only now, given that OpenSSH disabled CBC last year= , >and our customers want to follow external recommendations, which are to >disable CBC. I've never used CTR for the reason I mentioned earlier, it may be worse tha= n the problem it's meant to be fixing.=C2=A0 If you look at Wei Dai's attack,= it's pretty difficult to actually carry out, it's a chosen-plaintext attack that assumes an attacker controls the plaintext, and requires that they wait aro= und observing a huge number of packets to get a collision on the bits they don'= t control.=C2=A0 Yeah, it's a theoretical weakness, but not one I'm losing mu= ch sleep over. OTOH CTR mode, which is a keystream generator (KSG), gives the attacker complete control over the decrypted plaintext.=C2=A0 Because of SSH's unfor= tunate choice of MAC-then-encrypt, the victim has to act on attacker-controlled metadata in order to verify the MAC and discover that the data was in fact manipulated.=C2=A0 Try the same thing in CBC mode and you'll just end up ga= rbling the block. So my staying with CBC isn't laziness, it's because I consider the practica= l (not theoretical, I mean CTR even has a security proof) risks of CBC to be lower than CTR. Peter. = --=-HcBHN2MNnKskTIW5VqF6 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable I'm not sure we're referring to the same attack. T= he most critical SSH + CBC attack I can think of right now is this:

= http://isg.rhul.ac.uk/~kp/SandPfinal.pdf

This requires only a MITM p= osition and allows recovery of up to 32 plaintext bits once per about ~200k= intercepted connections. That's perfectly feasible if the connections are = being automatically retried over some time without supervision (which is no= t unusual in deployment).

Our defense against this is to not obvious= ly leak info about whether the result of packet length decryption was somet= hing sensible or not. But it may be that most implementations don't do this= .


----- Original Message -----
From: Peter Gutmann
Sent: = Thursday, November 12, 2015 20:49
To: denis bider
Cc: ietf-ssh@netbs= d.org ; djm@mindrot.org ; terrafrost@gmail.com ; thierry.moreau@connotech.c= om
Subject: RE: New version of rsa-sha2-256 draft: Back to PKCS#1 v1.5<= br>
denis bider <ietf-ssh3@denisbider.com> writes:

>We d= efault to CTR mode only now, given that OpenSSH disabled CBC last year,
= >and our customers want to follow external recommendations, which are to=
>disable CBC.

I've never used CTR for the reason I mentioned = earlier, it may be worse than
the problem it's meant to be fixing. = If you look at Wei Dai's attack, it's
pretty difficult to actually carr= y out, it's a chosen-plaintext attack that
assumes an attacker controls = the plaintext, and requires that they wait around
observing a huge numbe= r of packets to get a collision on the bits they don't
control.  Ye= ah, it's a theoretical weakness, but not one I'm losing much sleep
over.=

OTOH CTR mode, which is a keystream generator (KSG), gives the atta= cker
complete control over the decrypted plaintext.  Because of SSH= 's unfortunate
choice of MAC-then-encrypt, the victim has to act on atta= cker-controlled
metadata in order to verify the MAC and discover that th= e data was in fact
manipulated.  Try the same thing in CBC mode and= you'll just end up garbling
the block.

So my staying with CBC is= n't laziness, it's because I consider the practical
(not theoretical, I = mean CTR even has a security proof) risks of CBC to be
lower than CTR.
Peter.

= --=-HcBHN2MNnKskTIW5VqF6-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Nov 14 04:30:41 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C621A036C for ; Sat, 14 Nov 2015 04:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 S-qsHQ-pUILH for ; Sat, 14 Nov 2015 04:30:40 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 158951A0358 for ; Sat, 14 Nov 2015 04:30:40 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id B038614A1BD; Sat, 14 Nov 2015 12:30:39 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 53AC314A1B8; Sat, 14 Nov 2015 12:30:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 5CB5414A27F for ; Fri, 13 Nov 2015 08:16:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id I3uiWIcPfW3Q for ; Fri, 13 Nov 2015 08:16:34 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id F3E1214A262 for ; Fri, 13 Nov 2015 08:16:32 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id E514440020; Fri, 13 Nov 2015 09:16:30 +0100 (CET) Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id 1C8DA40012; Fri, 13 Nov 2015 09:16:28 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Fri, 13 Nov 2015 09:16:28 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: denis bider Cc: ietf-ssh@netbsd.org, Damien Miller , Jeffrey Hutzelman , "Mark D. Baushke" , stephen.farrell@cs.tcd.ie, jon@siliconcircus.com, Peter Gutmann , Max Horn Subject: Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation References: <2288549674-480@skroderider.denisbider.com> Date: Fri, 13 Nov 2015 09:16:28 +0100 In-Reply-To: <2288549674-480@skroderider.denisbider.com> (denis bider's message of "Tue, 10 Nov 2015 14:24:03 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list denis bider writes: > It seems to me that SSH needs a proper extension mechanism to avoid > version-string-based hacks and other kinds of hacks. Maybe. But please don't mix that up with the simpler issue of algorithm updates. > - Does not make signature algorithm information available in time for > the client's first user auth request. This costs a round-trip if the > client's first guess is incorrect. Note that's what relevant for public key user auth isn't really the algorithms supported by the server, but the algorithms of the keys which are actually authorized for login. It makes some sense to filter available keys depending on what the server supports, but I don't think it will make much of a practical difference. Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Nov 14 04:30:52 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D641A03A5 for ; Sat, 14 Nov 2015 04:30:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 HURxSkEChaA6 for ; Sat, 14 Nov 2015 04:30:51 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E86ED1A039A for ; Sat, 14 Nov 2015 04:30:51 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 6BF4514A218; Sat, 14 Nov 2015 12:30:51 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 0689614A209; Sat, 14 Nov 2015 12:30:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id B6D5B14A1EF for ; Fri, 13 Nov 2015 08:32:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id q5noUyj5WcdZ for ; Fri, 13 Nov 2015 08:32:26 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 45DEC14A228 for ; Fri, 13 Nov 2015 08:32:25 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 23BD44003E; Fri, 13 Nov 2015 09:32:24 +0100 (CET) Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id 769D940012; Fri, 13 Nov 2015 09:32:22 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Fri, 13 Nov 2015 09:32:22 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: "Mark D. Baushke" Cc: Damien Miller , Peter Gutmann , denis bider , "Jeffrey Hutzelman" , "ietf-ssh\@NetBSD.org" , "stephen.farrell\@cs.tcd.ie" , "jon\@siliconcircus.com" Subject: Re: DH group exchange (Re: SSH key algorithm updates) References: <9A043F3CF02CD34C8E74AC1594475C73F4B5993D@uxcn10-5.UoA.auckland.ac.nz> <2096379125-720@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B599ED@uxcn10-5.UoA.auckland.ac.nz> <55190.1447001241@eng-mail01.juniper.net> <9A043F3CF02CD34C8E74AC1594475C73F4B5A9BC@uxcn10-5.UoA.auckland.ac.nz> <65113.1447107876@eng-mail01.juniper.net> <90378.1447145301@eng-mail01.juniper.net> <41119.1447226323@eng-mail01.juniper.net> Date: Fri, 13 Nov 2015 09:32:22 +0100 In-Reply-To: <41119.1447226323@eng-mail01.juniper.net> (Mark D. Baushke's message of "Tue, 10 Nov 2015 23:18:43 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list "Mark D. Baushke" writes: > See also: > > http://csrc.nist.gov/publications/nistpubs/800-107-rev1/sp800-107-rev1.= pdf > Section 4.2 table 1. It's not clear to me why the "collision resistance strength" rather than "preimage resistance strength" or "second preimage strength" apply when using sha2 for generating session keys and the exchange hash. Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Nov 14 04:31:02 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFF1C1A03A5 for ; Sat, 14 Nov 2015 04:31:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 0Bsl5nADGLCt for ; Sat, 14 Nov 2015 04:31:01 -0800 (PST) Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE08E1A039A for ; Sat, 14 Nov 2015 04:31:01 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 797ED14A22A; Sat, 14 Nov 2015 12:31:01 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 0E61E14A225; Sat, 14 Nov 2015 12:31:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 8789614A25C for ; Fri, 13 Nov 2015 08:37:07 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id o5vvP8hejzVY for ; Fri, 13 Nov 2015 08:37:07 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id B14AB14A228 for ; Fri, 13 Nov 2015 08:37:06 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id E61334003E; Fri, 13 Nov 2015 09:37:04 +0100 (CET) Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id 8709740012; Fri, 13 Nov 2015 09:37:03 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Fri, 13 Nov 2015 09:37:03 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: Peter Gutmann Cc: denis bider , "ietf-ssh\@netbsd.org" , Jeffrey Hutzelman , "Mark D. Baushke" , "stephen.farrell\@cs.tcd.ie" , "jon\@siliconcircus.com" , "djm\@mindrot.org" , Max Horn Subject: Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation References: <2070897157-568@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B5BDE2@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B5F0E3@uxcn10-5.UoA.auckland.ac.nz> Date: Fri, 13 Nov 2015 09:37:03 +0100 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B5F0E3@uxcn10-5.UoA.auckland.ac.nz> (Peter Gutmann's message of "Thu, 12 Nov 2015 07:49:58 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Peter Gutmann writes: > Niels M=C3=B6ller writes: > >>Send 0, ignore received value, would have made it actually useful. > > Can we get any figures on what effect making it nonzero would have? I think my implementation will disconnect. Anyway, if we do a general smallish update, it would make sense to fix this (not sure in which form, note in the algorithms update rfc, or an errate on hte old rfc). And simply say that until any of the future extensions are specified, implementations should accept and ignore non-zero values for this field. That will make our lives a little easier a few years from now. Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Nov 14 04:31:25 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E921ACDB3 for ; Sat, 14 Nov 2015 04:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 rwaAHnM27-Ie for ; Sat, 14 Nov 2015 04:31:24 -0800 (PST) Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8476B1B6781 for ; Sat, 14 Nov 2015 04:31:24 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 13C6A14A22E; Sat, 14 Nov 2015 12:31:24 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id AA8F514A22D; Sat, 14 Nov 2015 12:31:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 29F5A14A2D6 for ; Fri, 13 Nov 2015 18:13:12 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id b7eUnHCDB73x for ; Fri, 13 Nov 2015 18:13:11 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 0F3DB14A2C2 for ; Fri, 13 Nov 2015 18:13:09 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id BB1CF40093; Fri, 13 Nov 2015 19:13:07 +0100 (CET) Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id 7421040092; Fri, 13 Nov 2015 19:13:04 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Fri, 13 Nov 2015 19:13:04 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: Jeffrey Hutzelman Cc: denis bider , Peter Gutmann , ietf-ssh@netbsd.org, "Mark D. Baushke" , stephen.farrell@cs.tcd.ie, jon@siliconcircus.com, djm@mindrot.org, Max Horn Subject: Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation References: <4323240-1468@skroderider.denisbider.com> Date: Fri, 13 Nov 2015 19:13:04 +0100 In-Reply-To: (Jeffrey Hutzelman's message of "Fri, 13 Nov 2015 10:11:47 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Jeffrey Hutzelman writes: > So, I don't think it's appropriate for an erratum. What's the correct process, then? > Further, it's too late: this behavior is only useful if older > implementations follow it; you can't add extensibility after the fact. I'd expect a correction published now will get widely implemented within a decade. So I think it's a useful thing to do. Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Nov 14 04:35:19 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0ED1B67CB for ; Sat, 14 Nov 2015 04:35:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.009 X-Spam-Level: X-Spam-Status: No, score=-1.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 FdtG9br6UN08 for ; Sat, 14 Nov 2015 04:35:18 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9693E1B67CA for ; Sat, 14 Nov 2015 04:35:18 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 6BC1B14A1FD; Sat, 14 Nov 2015 12:29:10 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 129DA14A1EF; Sat, 14 Nov 2015 12:29:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 7851D14A2C2 for ; Fri, 13 Nov 2015 12:36:49 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 57Yw6DoMRpOo for ; Fri, 13 Nov 2015 12:36:48 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id B1AD614A2BA for ; Fri, 13 Nov 2015 12:36:48 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for nisse@lysator.liu.se; Fri, 13 Nov 2015 12:36:22 +0000 Date: Fri, 13 Nov 2015 12:36:22 +0000 Subject: Re: Curve25519/448 key agreement for SSH X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <34195481-392@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: =?UTF-8?q?Niels_M=C3=B6ller?= , Simon Josefsson Cc: ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-dBFpRe5GZL3HfskNarN8" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-dBFpRe5GZL3HfskNarN8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIERTQSBzaWduYXR1cmUgYmxvYiBpcyBvcmlnaW5hbGx5IGRlZmluZWQgYXMgYSBzdHJpbmcg aW4gUkZDIDQyNTMsIHRob3VnaC4NCg0KVGhlIGlzc3VlIHdpdGggSyBpcyB0aGF0IGl0J3MgZGVm aW5lZCBhcyBtcGludCBmb3IgYWxsIGtleSBleGNoYW5nZSBtZXRob2RzIGluIFJGQyA0MjUzLCBz ZWN0aW9uIDcuMiwgT3V0cHV0IGZyb20gS2V5IEV4Y2hhbmdlOg0KDQogICBFbmNyeXB0aW9uIGtl eXMgTVVTVCBiZSBjb21wdXRlZCBhcyBIQVNILCBvZiBhIGtub3duIHZhbHVlIGFuZCBLLCBhcwog ICBmb2xsb3dzOgoKICAgbyAgSW5pdGlhbCBJViBjbGllbnQgdG8gc2VydmVyOiBIQVNIKEsgfHwg SCB8fCAiQSIgfHwgc2Vzc2lvbl9pZCkKICAgICAgKEhlcmUgSyBpcyBlbmNvZGVkIGFzIG1waW50 IGFuZCAiQSIgYXMgYnl0ZSBhbmQgc2Vzc2lvbl9pZCBhcyByYXcKICAgICAgZGF0YS4gICJBIiBt ZWFucyB0aGUgc2luZ2xlIGNoYXJhY3RlciBBLCBBU0NJSSA2NSkuCg0KSXQgaXMgdGhpcyB0aGF0 IGhhcyB0byBiZSBjaGFuZ2VkIC0gYWxsb3dpbmcgSyB0byBoYXZlIGEgZGlmZmVyZW50IGVuY29k aW5nIGZvciBkaWZmZXJlbnQga2V5IGV4Y2hhbmdlIG1ldGhvZHMgLSBpbiBvcmRlciB0byBhbGxv dyBLIHRvIGJlIGVuY29kZWQgYXMgc3RyaW5nLg0KDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2Ug LS0tLS0NCkZyb206IE5pZWxzICJNw7ZsbGVyIiANClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAx MiwgMjAxNSAyMzoyNQ0KVG86IFNpbW9uIEpvc2Vmc3NvbiANCkNjOiBkZW5pcyBiaWRlciA7IGll dGYtc3NoQG5ldGJzZC5vcmcgDQpTdWJqZWN0OiBSZTogQ3VydmUyNTUxOS80NDgga2V5IGFncmVl bWVudCBmb3IgU1NIDQoNClNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9zZWZzc29uLm9yZz4gd3Jp dGVzOg0KDQo+IEEgc2ltcGxlIGFwcHJvYWNoIHdvdWxkIGJlIHRvIHNheSB0aGF0IGlmIHRoZSBN U0IgaXMgMSwgcHJlcGVuZCBhIHplcm8NCj4gYnl0ZS7CoCBIb3dldmVyLCB0aGUgbGVuZ3RoIGRp ZmZlcmVuY2Ugd291bGQgbGVhayB0aGF0IGluZm9ybWF0aW9uLg0KDQpOb3RlIHRoYXQgaXQncyBh bHNvIHBvc3NpYmxlIHRvIHVzZSBzb21lIHNsaWdodGx5IGRpZmZlcmVudCBtYXBwaW5nIHRoYW4N CmZvciBtcGludHMuIExpa2UgaXQncyBiZWVuIGRvbmUgaW4gdGhlIGRzYSBzaWduYXR1cmUgYmxv YiBzaW5jZSBhZ2VzOw0KdGhlcmUgdGhlIGludGVnZXJzIGFyZSBhbHdheXMgY29kZWQgYXMgMjAt Ynl0ZSB2YWx1ZXMsIG5vIHNpZ24gYml0LCBhbmQNCm5vIG5vcm1hbGl6YXRpb24gaWYgc29tZSB2 YWx1ZSBoYXBwZW5zIHRvIGdldCBhIHplcm8gaGlnaCBieXRlLiANCg0KSSdtIG5vdCBzdXJlIEkg bGlrZSB0aGF0IGRlcGFydHVyZSBmcm9tIG1waW50LCBidXQgSSdkIGxpa2UgdG8gcG9pbnQgb3V0 DQp0aGF0IGl0J3MgYSBwb3NzaWJpbHR5IGFuZCBpdCdzIGJlZW4gZG9uZSBiZWZvcmUuDQoNClJl Z2FyZHMsDQovTmllbHMNCg0KLS0gDQpOaWVscyBNw7ZsbGVyLiBQR1AtZW5jcnlwdGVkIGVtYWls IGlzIHByZWZlcnJlZC4gS2V5aWQgQzBCOThFMjYuDQpJbnRlcm5ldCBlbWFpbCBpcyBzdWJqZWN0 IHRvIHdob2xlc2FsZSBnb3Zlcm5tZW50IHN1cnZlaWxsYW5jZS4NCg0K --=-dBFpRe5GZL3HfskNarN8 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable The DSA signature blob is originally defined as a = string in RFC 4253, though.

The issue with K is that it's defined as= mpint for all key exchange methods in RFC 4253, section 7.2, Output from K= ey Exchange:

   Encryption keys MUST be compu=
ted as HASH, of a known value and K, as
   follows:

   o  Initial IV client to server: HASH(K || H || "A" || session_id)
      (Here K is encoded as mpint and "A" as byte and session_id as raw
      data.  "A" means the single character A, ASCII 65).

It is this that has to be changed - allowing K to have a differen= t encoding for different key exchange methods - in order to allow K to be e= ncoded as string.


----- Original Message -----
From: Niels "M= =C3=B6ller"
Sent: Thursday, November 12, 2015 23:25
To: Simon Josefs= son
Cc: denis bider ; ietf-ssh@netbsd.org
Subject: Re: Curve25519/4= 48 key agreement for SSH

Simon Josefsson <simon@josefsson.org>= writes:

> A simple approach would be to say that if the MSB is 1= , prepend a zero
> byte.  However, the length difference would l= eak that information.

Note that it's also possible to use some sligh= tly different mapping than
for mpints. Like it's been done in the dsa si= gnature blob since ages;
there the integers are always coded as 20-byte = values, no sign bit, and
no normalization if some value happens to get a= zero high byte.

I'm not sure I like that departure from mpint, but= I'd like to point out
that it's a possibilty and it's been done before.=

Regards,
/Niels

--
Niels M=C3=B6ller. PGP-encrypted e= mail is preferred. Keyid C0B98E26.
Internet email is subject to wholesal= e government surveillance.

= --=-dBFpRe5GZL3HfskNarN8-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Nov 14 04:40:19 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9673F1B6829 for ; Sat, 14 Nov 2015 04:40:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.609 X-Spam-Level: X-Spam-Status: No, score=-1.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 yakMkbOUhFfG for ; Sat, 14 Nov 2015 04:40:18 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FCF41B6827 for ; Sat, 14 Nov 2015 04:40:18 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 3002C14A206; Sat, 14 Nov 2015 12:29:44 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id C0D1014A202; Sat, 14 Nov 2015 12:29:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id CF8A814A2A1 for ; Fri, 13 Nov 2015 14:39:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id RbpnBZ8NKELO for ; Fri, 13 Nov 2015 14:39:31 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 1F0CC14A196 for ; Fri, 13 Nov 2015 14:39:31 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for nisse@lysator.liu.se; Fri, 13 Nov 2015 14:39:23 +0000 Date: Fri, 13 Nov 2015 14:39:23 +0000 Subject: Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <4323240-1468@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: =?UTF-8?q?Niels_M=C3=B6ller?= Cc: Peter Gutmann , ietf-ssh@netbsd.org, Jeffrey Hutzelman , "Mark D. Baushke" , stephen.farrell@cs.tcd.ie, jon@siliconcircus.com, djm@mindrot.org, Max Horn Content-Type: multipart/alternative; boundary="=-14MLYE+WDCpshKRQIAKL" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-14MLYE+WDCpshKRQIAKL Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Much agreed. If the IETF will accept an erratum with a clarification, here's a proposed = wording: "Servers and clients may or may not be aware of a future extension to this = RFC that specifies a use for the KEXINIT reserved field. Servers and clients that are NOT aware of such an extension: - MUST send the reserved field with the value zero (indicating unawareness)= ; - MUST NOT act on any value of this field when received, whether zero or no= n-zero; - in key exchange, MUST properly hash the actual received value of this fie= ld. This behavior is REQUIRED to allow use of this field in future protocol ext= ension." ----- Original Message ----- From: Niels "M=C3=B6ller"=20 Sent: Friday, November 13, 2015 02:37 To: Peter Gutmann=20 Cc: denis bider ; ietf-ssh@netbsd.org ; Jeffrey Hutzelman ; Mark D. Baushke= ; stephen.farrell@cs.tcd.ie ; jon@siliconcircus.com ; djm@mindrot.org ; Ma= x Horn=20 Subject: Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation Peter Gutmann writes: > Niels M=C3=B6ller writes: > >>Send 0, ignore received value, would have made it actually useful. > > Can we get any figures on what effect making it nonzero would have? I think my implementation will disconnect. Anyway, if we do a general smallish update, it would make sense to fix this (not sure in which form, note in the algorithms update rfc, or an errate on hte old rfc). And simply say that until any of the future extensions are specified, implementations should accept and ignore non-zero values for this field. That will make our lives a little easier a few years from now. Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. = --=-14MLYE+WDCpshKRQIAKL Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Much agreed.

If the IETF will accept an err= atum with a clarification, here's a proposed wording:


"Servers a= nd clients may or may not be aware of a future extension to this RFC that s= pecifies a use for the KEXINIT reserved field.

Servers and clients t= hat are NOT aware of such an extension:
- MUST send the reserved field w= ith the value zero (indicating unawareness);
- MUST NOT act on any value= of this field when received, whether zero or non-zero;
- in key exchang= e, MUST properly hash the actual received value of this field.

This = behavior is REQUIRED to allow use of this field in future protocol extensio= n."


----- Original Message -----
From: Niels "M=C3=B6ller" Sent: Friday, November 13, 2015 02:37
To: Peter Gutmann
Cc: denis = bider ; ietf-ssh@netbsd.org ; Jeffrey Hutzelman ; Mark D. Baushke ; stephen= .farrell@cs.tcd.ie ; jon@siliconcircus.com ; djm@mindrot.org ; Max Horn Subject: Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiatio= n

Peter Gutmann <pgut001@cs.auckland.ac.nz> writes:

>= ; Niels M=C3=B6ller <nisse@lysator.liu.se> writes:
>
>>= ;Send 0, ignore received value, would have made it actually useful.
>=
> Can we get any figures on what effect making it nonzero would have= ?

I think my implementation will disconnect.

Anyway, if we do= a general smallish update, it would make sense to fix
this (not sure in= which form, note in the algorithms update rfc, or an
errate on hte old = rfc). And simply say that until any of the future
extensions are specifi= ed, implementations should accept and ignore
non-zero values for this fi= eld.

That will make our lives a little easier a few years from now.<= br>
Regards,
/Niels

--
Niels M=C3=B6ller. PGP-encrypted em= ail is preferred. Keyid C0B98E26.
Internet email is subject to wholesale= government surveillance.

= --=-14MLYE+WDCpshKRQIAKL-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Nov 14 12:01:31 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A88D31B2B0B for ; Sat, 14 Nov 2015 12:01:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 TDSIzvaQuwsr for ; Sat, 14 Nov 2015 12:01:30 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B3A41B2B09 for ; Sat, 14 Nov 2015 12:01:13 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 2AA3C14A1D3; Sat, 14 Nov 2015 20:01:12 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 6F2D214A1D2 for ; Sat, 14 Nov 2015 20:01:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id DcLZQvQ3scUh for ; Sat, 14 Nov 2015 20:01:05 +0000 (UTC) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0775.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc09::775]) by mail.netbsd.org (Postfix) with ESMTP id 1E42914A1C9 for ; Sat, 14 Nov 2015 20:01:04 +0000 (UTC) Received: from BY1PR0501CA0039.namprd05.prod.outlook.com (10.162.139.49) by BY1PR0501MB1382.namprd05.prod.outlook.com (10.160.107.140) with Microsoft SMTP Server (TLS) id 15.1.325.17; Sat, 14 Nov 2015 20:01:01 +0000 Received: from BN1BFFO11FD042.protection.gbl (2a01:111:f400:7c10::1:199) by BY1PR0501CA0039.outlook.office365.com (2a01:111:e400:4821::49) with Microsoft SMTP Server (TLS) id 15.1.325.17 via Frontend Transport; Sat, 14 Nov 2015 20:01:01 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=juniper.net; josefsson.org; dkim=none (message not signed) header.d=none;josefsson.org; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.17) by BN1BFFO11FD042.mail.protection.outlook.com (10.58.144.105) with Microsoft SMTP Server (TLS) id 15.1.325.5 via Frontend Transport; Sat, 14 Nov 2015 20:00:59 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 14 Nov 2015 12:00:58 -0800 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id tAEK0uD58177; Sat, 14 Nov 2015 12:00:56 -0800 (PST) (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id CD6881145A; Sat, 14 Nov 2015 12:00:54 -0800 (PST) To: denis bider CC: Simon Josefsson , , Subject: Re: Curve25519/448 key agreement for SSH In-Reply-To: <23975746-2988@skroderider.denisbider.com> References: <23975746-2988@skroderider.denisbider.com> Comments: In-reply-to: denis bider message dated "Thu, 12 Nov 2015 12:07:08 +0000." From: "Mark D. Baushke" X-Phone: +1 408 745-2952 (Office) X-Mailer: MH-E 8.5; nmh 1.2; GNU Emacs 24.3.1 X-Face: #8D_6URD2G%vC.hzU MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1;BN1BFFO11FD042;1:Cwmp04p66b4BvjwcPwSdMipD+BDmnKIDBSh1qiYHPywTxHuQrxDHY4P9Riw71n1EQWe8EIHXomTp6E/Px4uMvOvB36repny7Ru5q2L+KA6pYDjiY4nJpZqY1uxEwezREt+PISuS4zEvnYOWL3pFziT37fi/qz7Jsx7+7o47yueYcNbC/IfMaUMatjQ6ND3aYqFNZmq7f3fNJPpVr79k8qbpi7HGX3L+imFadY/JvMKrgXRh5NadfaZK784wqgWOOXQomqxarGUxsblZfhp7o3mKWNem7ebdzkvA1eOmQaQbQAo90hbTLH2IiP1/3wz7kNxxW4SHIKveyjtHSbB3f0wqH6QAfh0aqDrqNQyPzZgZXS+uMXpIJEAdAE6w7LlzX X-Forefront-Antispam-Report: CIP:66.129.239.17;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(2980300002)(24454002)(189002)(199003)(189998001)(110136002)(19580405001)(5003940100001)(69596002)(77096005)(19580395003)(5001960100002)(2950100001)(81156007)(15975445007)(48376002)(50986999)(50466002)(5003600100002)(97736004)(92566002)(76176999)(117636001)(5007970100001)(6806005)(87936001)(86362001)(47776003)(50226001)(586003)(11100500001)(76506005)(53416004)(105596002)(106466001)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:BY1PR0501MB1382;H:p-emfe01a-sac.jnpr.net;FPR:;SPF:SoftFail;PTR:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BY1PR0501MB1382;2:JZd4u589dQVb7rj2nVw8ezBW14pJ+UppBPTHJl8WsKMkoi03YQJcuHSqhBjtLdZi3m7G/XjWxe7pZ9x/uASZooLaYh7+2F3rC4Iv1tha09ulotIVKrJV2XRxX2F3S0Bkv3DkPntXZO0kPDQEzpq9vl8dizR64a5m0kLjHf9X7J8=;3:eBxaIGE4OPTEs9ieQ4vhLlK1QXkSszYg+vp0yKogyC0QzbEb3fHNwgD96xZ3HeR927w25x8TUcKupyCh69t0nrPIw6lciWB1tCVVxJiRj9jx7TfJBPiksW5j3KpXJpW3t9cT0yIQi+eF0urPTlquIpUEX28SgYqiUU0B46rpLMqbjKML8XWUyTxjYfe5qIj/NSxSIK4FzOttFWydQB8F+d8bcZglf6hZbmg6mZOvH9A=;25:753yzfLlkXVGwAqK3Z2KSyI7xxUKT/7MJfe3yCshV7e/dcgWXYha1L4HWdfWYGk+GJKFqFCaZf0C88kvkATxG0zK7BicFm880gukZcv4qfZ0s/oFGPr/qW64HL80/+MdA4oseNW3cu7YQ0qA3ZvjPBhZwKG6Ug1v/bxYgDRXT5QwZgETKPvHrVQIJzI74zqGdNB5A7Xs7VMJ1XvEmXHE5zxdlCRZbsXFGq+KKz3J6dDPsecoGn7OilMXkNVKpeWwr2HgpayLDX0zoTp6N7YSjw== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1382; X-Microsoft-Exchange-Diagnostics: 1;BY1PR0501MB1382;20:CQ3bNWFCRXAU3H24BPrrKMeKwr42XxFURtGDcj3HMmkJSTXH2VWanPGnj/LSI1CaYywwIYE/CAKAVHm0sWqL+3E+vX/b8M/StDt9vH+AOg2EwW7fQonvsX040BvZZ77XY3MZE3zsiZHSYt9pcrby4+lU5hNmYs6kH6qnMIZILvGATHUDyEAoI2rfNzVKC/x/Pi0LiDSg/Y9iGQYEJd4jqMdhHzkBK28Oh61LeF2bE2ApJLHfqtVY+FE1IevokZM2tSjeELP07g4uWosxQNaZ2rf6cY7HsvN9MztSjl1Wtuv/molWuaP/gTIv48aDIijdWNgZHZFh0hvT1ixEopTpFxuZozsGsrLpSOy0QxY6Pf4sL0AJLnFFxDxwSCaIl5xNJPXziettwHBaSfBeJoU4fpo/dpQYGND+a/yFxPFkJMoom/c7HnrKOq5ggBa4VmWW8I+gD1L8opBRvVQFYIHJCmYeP35mS73PD+oU2LrZ/RNSk0cqTPSIuWCiplYxxdwf;4:OTsxV49/LGW8vXPSWSNV/EkMhiVPGrwILuNn+dux+6flK3LeRDxfcilDmT6ZfiCTq9gWusZtTth4Sp0uuM187EnhZef3PCkWUaP2co4rWouzKmCGAxavkkFHmI+5yAvCi0tyr3kUUmcvrXHpcO966+R3RhMoFvYAGcKiUnQ9buw2xXhl9QkiPNWtwNPIh8uj7zvVUHvumS0PFaaEjlGz9tzAjgwvc+9YHoZIySTsTbI9Kqkh1wCGOy8oPctR+sT1+RQg4TqwPdccXNhiSMnysmQ1hDCWmLklTN1GEwdPm2vZIgbkZw3gWJBaMzSUGCvsUFtnUD+DvAyfeiguc/tjU+aQXcWrXl7it8wWFgUvwNXxUXJ2UU6ssxNMY06tgMsp X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001)(10201501046);SRVR:BY1PR0501MB1382;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1382; X-Forefront-PRVS: 07607ED19A X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;BY1PR0501MB1382;23:KQt1BbDeKO2LgEl9h6cIiUXESbDnJHEjbcYm4hU?= =?us-ascii?Q?9AvB635c3jaSynrnrb0h76WPyBDH+T3FVewniaT6SGAquXcC84GCrt8LlbRe?= =?us-ascii?Q?JRStuFEqtpUlSUKsSe2WYGSD+U+BkTXBOqjb8LWkEgi6nCB9bKuiUV4N9s0F?= =?us-ascii?Q?hXMIC/rxgIg+QnBP63gTc+mEMPWJ2lGEA6fakd90O27vuBK7CwKWzbT9PpOt?= =?us-ascii?Q?SCR0YbJK3YhgB0IYIZ4+YXqvP8yDR1hG0YB2HCoJzA80UXmtrkAevo3QyA2q?= =?us-ascii?Q?4PN+Iw+p3ZIKij4/OA8I+c8SUCiqD2A0bKCUnoCCulp+NTqKL5QrgAo0L10w?= =?us-ascii?Q?/owDXZOHbnz8OnBYju9ScUqIt+F3bzW1tLkzkh0S5aoxNojBNdJrrqsnp5uX?= =?us-ascii?Q?BHz60i1M1f1wnHTmPSLrnFUTihfK0Q8aJd+l+SAOMEoOG4bRXasteH2uUWkC?= =?us-ascii?Q?N3Kj2tdSWSbn/nHru9pfQwA6diILUr4otBHPENpyX9HZ2EC4evREK49eZ60x?= =?us-ascii?Q?/srTWvymIJzFwdzmdVy9PrkdLH0AhDwNPY/qHvrG53pSnEXJYhwA3dx2YFsB?= =?us-ascii?Q?Q5TMdBLMBPyuRJOZ4R4jQmsmnicCL3dMVtVNm4UySgLShr90jb9GHJ8O7OMz?= =?us-ascii?Q?UEj4run/jqjWvFUbjIH4CMHn+aCAt3NbLGenQHCpjUOxVc86oPNKzeTa3D+R?= =?us-ascii?Q?JvML/jCOSY+gKIcMBhrmdNTofnAXxr30lJVJGct1cZq24aEc3nPAuH3SsiPt?= =?us-ascii?Q?esImERnttoGX4ddPIT6C1I7//CJv+Uhu9mQdn54yo+zE0yL9ARL0/v9bvjxL?= =?us-ascii?Q?+CLjBqDdc+W2p8h/fGzoAaXIlhQStNlJ7rT2sXookyOr6l9B7fxzGljp7NtV?= =?us-ascii?Q?9e7WkX+8dkWpHnlc7E/gM2xQlQRZYNoh+ScDw0xv7cyASU8DfYiCOqA7Hc15?= =?us-ascii?Q?y3Q5JqzPlwazwh03BMas/0WRzikn9GjjN6QwlNHSKLkaS63lEdnobRF3kyK0?= =?us-ascii?Q?4UaO3p5m8Pxu0Xit0ngQMnIGN?= X-Microsoft-Exchange-Diagnostics: 1;BY1PR0501MB1382;5:rmU63RhEJVv6QienUVm+zZdvFmWh2jULvbIhIq3EHLoZ3al1Q/vmL5iZeKVO9E640YrGXKgE0hwIL9FhZ5kFhjVRTkjCnyeZ0aBt7/SnsqheSj8nq4iqJkvtj2F9UA7B/QhXeqD2W3+UqHLhVysDDw==;24:Ocrvxx+pXFbcWEIsAT/IvLSWoHFLL/VUT7hjNBpv5MKs39qmWjUrljwEI75TTMpSjYo4aCzpeRJAyNgtoCaSR99s/EjjE4cExiXrd5PBplw=;20:qW+8/zUO87hERCa3QzJSxn7hiJmooHRO770ON8AuHT2Zn6qnzLHZwltyCUM3Kjatrg4e0M0kqs22lqDcLnecYw== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Nov 2015 20:00:59.7306 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.17];Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1382 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list denis wrote: > Folks who use older versions are typically people who don't care about > CBC until it comes up in a security scan... At which point they > grudgingly consider upgrading their 10 year old version. :) I believe that more than just ancient editions of SSH implementations are going to need to have AES CBC mode for at least a few more years... In the Common Criteria world, there is the collaborative Protection Profile for Network Devices Version 1.0 https://www.niap-ccevs.org/pp/pp.cfm?id=CPP_ND_V1.0 FCS_SSHC_EXT.1.1 The TSF shall implement the SSH protocol that complies with RFCs 4251, 4252, 4253, 4254, and [selection: 5647, 5656, 6187, 6668, no other RFCs]. ...elided... FCS_SSHC_EXT.1.4 The TSF shall ensure that the SSH transport implementation uses the following encryption algorithms and rejects all other encryption algorithms: aes128-cbc, aes256-cbc, [selection: AEAD_AES_128_GCM, AEAD_AES_256_GCM, no other algorithms]. The AEAD_AES_128_GCM and AEAD_AES_256_GCM as specified in RFC 5647 is not implemented exactly by a number of SSH implementations, so that tends to leave aes128-cbc and aes256-cbc for those trying to obtain a Common Criteria CPP_ND_V1.0 certification. While it may be possible to change this going forward, it probably means that one or more folks from the technical community need to participate in the Technical Communities by asking tc-ssh-staff@niap-ccevs.org ... | Call for Participants in Technical Communities (26 August 2015) | | The National Information Assurance Partnership/Common Criteria | Evaluation and Validation Scheme (NIAP/CCEVS) is inviting industry, | government, end users, academic institutions, and labs with relevant | technology expertise and research focus to participate in the | following Technical Communities (TCs). If you are interested in | joining a technical community and participating in the development | of Protection Profiles for these technologies, please contact | NIAP/CCEVS at: | | Secure Shell (SSH) tc-ssh-staff@niap-ccevs.org | | VPN Client tc-vpnclient-staff@niap-ccevs.org -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Nov 14 13:02:53 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C44F1B2AAE for ; Sat, 14 Nov 2015 13:02:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 LdRFWFPuxX0i for ; Sat, 14 Nov 2015 13:02:51 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC9CE1B2A9B for ; Sat, 14 Nov 2015 13:02:51 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 50D4D14A1C4; Sat, 14 Nov 2015 21:02:48 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id EED7014A1B8 for ; Sat, 14 Nov 2015 21:02:42 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id ZMSRMN6cJIAw for ; Sat, 14 Nov 2015 21:02:42 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0795.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::795]) by mail.netbsd.org (Postfix) with ESMTP id D74FC14A1A8 for ; Sat, 14 Nov 2015 21:02:41 +0000 (UTC) Received: from DM2PR0501CA0039.namprd05.prod.outlook.com (10.162.29.177) by BN1PR05MB060.namprd05.prod.outlook.com (10.255.202.153) with Microsoft SMTP Server (TLS) id 15.1.325.17; Sat, 14 Nov 2015 21:02:38 +0000 Received: from BN1AFFO11FD023.protection.gbl (2a01:111:f400:7c10::102) by DM2PR0501CA0039.outlook.office365.com (2a01:111:e400:5148::49) with Microsoft SMTP Server (TLS) id 15.1.325.17 via Frontend Transport; Sat, 14 Nov 2015 21:02:38 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=juniper.net; cs.tcd.ie; dkim=none (message not signed) header.d=none;cs.tcd.ie; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.17) by BN1AFFO11FD023.mail.protection.outlook.com (10.58.52.83) with Microsoft SMTP Server (TLS) id 15.1.325.5 via Frontend Transport; Sat, 14 Nov 2015 21:02:37 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 14 Nov 2015 13:02:36 -0800 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id tAEL2YD09832; Sat, 14 Nov 2015 13:02:34 -0800 (PST) (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 0FAF81141B; Sat, 14 Nov 2015 13:02:33 -0800 (PST) To: Niels =?us-ascii?Q?=3D=3Futf-8=3FQ=3FM=3DC3=3DB6ller=3F=3D?= CC: Damien Miller , Peter Gutmann , denis bider , "Jeffrey Hutzelman" , "ietf-ssh@NetBSD.org" , "stephen.farrell@cs.tcd.ie" , "jon@siliconcircus.com" Subject: Re: DH group exchange (Re: SSH key algorithm updates) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73F4B5993D@uxcn10-5.UoA.auckland.ac.nz> <2096379125-720@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B599ED@uxcn10-5.UoA.auckland.ac.nz> <55190.1447001241@eng-mail01.juniper.net> <9A043F3CF02CD34C8E74AC1594475C73F4B5A9BC@uxcn10-5.UoA.auckland.ac.nz> <65113.1447107876@eng-mail01.juniper.net> <90378.1447145301@eng-mail01.juniper.net> <41119.1447226323@eng-mail01.juniper.net> Comments: In-reply-to: Niels =?us-ascii?Q?=3D=3Futf-8=3FQ=3FM=3DC3=3DB6lle?= =?us-ascii?Q?r=3F=3D?= message dated "Fri, 13 Nov 2015 09:32:22 +0100." From: "Mark D. Baushke" MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Sat, 14 Nov 2015 13:02:33 -0800 Message-ID: <67048.1447534953@eng-mail01.juniper.net> X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1;BN1AFFO11FD023;1:R3F7JuU8ho5k9S8VmsqDyHtIZEpFiKPbNG4OCXVNA48tZNguDY21PMxS/5tU1gkEjpFjFEqES8LaGPSn3+KxMK+vucfBd2RPboZv7miHGbosMcXehq8okD0Ue6MsqlZt1WCwVIr4fLux0xeO6zfwvKdyNiIM0Srjs3R/D1BfR/xEAHQI/oBd3WsIAk3JLAnXc4viDUf6MNNZ3RnUPYCGp8rcIn2GfwccpgxHKMzor7Cu827wZxmpbpqzuXS83mqRYiPnghVzKnu8arp8TWBruDIy8Z92EaYnA4jKkSkdTmP1cDqll//5XPprP4U+lAdBK2M5ep3m9xpaMMLNsfGHRilJ9Ubz0GAhSWw7mdluSSz26Sa5lvviSIsSMNz2eoI7EswWD1k71LujiWhMalPuyQ== X-Forefront-Antispam-Report: CIP:66.129.239.17;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(2980300002)(189002)(199003)(243025005)(117636001)(15975445007)(7110500001)(110136002)(189998001)(5001960100002)(87936001)(50986999)(54356999)(6806005)(76176999)(2420400006)(81156007)(53416004)(23676002)(76506005)(97736004)(11100500001)(5003600100002)(2950100001)(50466002)(5001920100001)(106466001)(93886004)(92566002)(5007970100001)(105596002)(86362001)(69596002)(77096005)(19580395003)(19580405001)(47776003)(586003)(10710500006)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:BN1PR05MB060;H:p-emfe01a-sac.jnpr.net;FPR:;SPF:SoftFail;PTR:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BN1PR05MB060;2:GiMLXpBRayN82nTFnc92evX+cynOn3lP7ZlaMGUObntlhlplEBWUM0WfWiezoaPR7Comxi8nb/aw2xDyjjdxQBPXCYsgm0hsZ1+8crhRT0gNZvLCMTBaRGlTCcF2SaSDosQAOb6Zp6dIgC2LE8Xcuq/iiSPyyw5ICytjuTB654I=;3:jHQeSq/2bo9QPXQ2QBRIS26Lwp0kWFqenlb+X6B/LStaIAHm6m2Q4SlY2bXRDAs9KsNRUV5/80P43IEncK9wf0WvdOmahaIVrFBExQON2iLMxHVti7dHSAZGdAwYFvYTeyedkmk8RpUoxFNcCeASJFSHC6JdtPRxcMmvm+dRUXtuLVbO4InVc+plKSaHZex+EV/UGp6QV4msKNvbCAXo4BJz+elw5+1QSbwZJ6WEmPQ=;25:T2Npiy+33GkOUtkFj7KU5v5i6js2HlvL/j2/zhwOxq1xnmptf4W7KGwxjGCx5XWoUd4uFHXu+glFvlJTCUntlEZZ6mb0rQnhvZ+bkQPuzF7w6sH3vNhfsLCsndADflyGRtoQ/KuOTAjiCwma+H/woQb45f7h3IZLOzCnByMJXFLE+AdvoGn5XpkYwZVx2cbhIwvF6/F5s19c5RbKUbqsVKV0cHZ6SS0gtZ4Rbjf1udc9LSZD1pvKrMIUFhUz3ktdoKotLp//K3bhKdMVQiacXQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB060; X-Microsoft-Exchange-Diagnostics: 1;BN1PR05MB060;20:bZJVqnFuMsbM2FSat85B8PpfUronnGQOv5lwTn6tWBekHy5qbrNqbnqFynxW3H+IwA9Ewj8MUF8icBQ0kK9DSPm2YRvuCQM2C5GKHJL/s8CAN3f3EZOzXzoQL/ccgS5pD1owZNHRvZG3OUvni03MbeC4ndpsLyYfBxqHr4U8edSYDNDdBuQygwnkde7bu7Ex/oDIVfzs521DQB5rOg5sL/680cwlb49kXNQKH/hnWZMKcEcXfaLhAgymfK/VDG4BRNmOEArzDizpzdTrmsYUpDC6z1in059/4fT4mBH5nnoqMKp9Zw7HEyNYUWifu7fdYnwBLklsUN07Fn/kYKSbK4uzJyG7ESUv2d8Uo2IDt9hvVzuzdNZVmaFk4gzm8y8SDQIaU9SMZ0ga6/dWS2lAXca4EF6uwlRKBJ3WHlD7ENvKojMh+7KoQgnd1+/TOw6Ee4YVJQrUqZdikEeS/89MVjimPP0N5RItbkXzuyoDx41U/cbm7981amLcyaT8XKpv;4:qTNvwCG1GBDVydtHo7T20UHRcXSihde1HKuJR55Mmt8HHkXDrvbXRAVYBmm+lkXDznz9ceLan0XyOdoN1DC+v2Irdtpq62TZFqo5mz9+QnXKTr450sSxGaGVtdENQgciCWZvWuwDInqfyNfSW9aoPR/BgQP24BnjEcZcixk7Ifp2J2CWwF73yAoMNCi5APSKqsdq9EJ6ZJluQClkk2ZZw4RhoD25R+qIXg+c5tlnreKg4fMz1vOh0OozacLfyKZiWqhPQhj2FqCP4Ejd4/WikJcpYxFW6JSdWORls8Vg80Mgs/MIuo2NGpSVUuef+JO47chr6Fl6d7MezJ0QJMnKitQEXTZKErjt0S2SjuOtxsQUz1jGIBSECp+3ZeM9QzkZ X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008)(65766998875637); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001);SRVR:BN1PR05MB060;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB060; X-Forefront-PRVS: 07607ED19A X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjFQUjA1TUIwNjA7MjM6Q0YzRGt4cVlJMDAzSVRGVGpHY0RlRWFLR1Yx?= =?utf-8?B?czV6T081K253Z1VvTEdDNm9UdVVuN1AyMHd5Nlh5OG95NDdjVk1xOGZxa2Vx?= =?utf-8?B?Rm9SNkZ0aUZ1SktNRk5uU2ZST2phR2l4bkxPODVQaUN1RjVKM3ZaditwQWtO?= =?utf-8?B?dU1hRWE2T29IRklMZHJzUkIrUFVhM1NQL05TZ1kzalVtZEd1bGJabTdFRVZI?= =?utf-8?B?bXJlUi9pTExkS2JmVkVHTXZ6RmFkbUxxNFBGdnJQSFNnMjZjRGk5UTVFQUVo?= =?utf-8?B?ZWFQd0dSS0tNOTBnUzhIN0lmREgrOUJvakIvV1RpcU14U0pIQ3pUQmY0QklE?= =?utf-8?B?OXluMFNHYWNkWDY2RFhTTGovUU8zcXBRa0NvSStBSTNnaHBnWklMMzFWK0VZ?= =?utf-8?B?TWJmMUFIb0JWcEd5ZzlKeEptZlFmMWZwakFkck40WVJpbnRTMk84SEhWcWFp?= =?utf-8?B?VEozL0N0Z2RxMENOdHEzYUFrQ0ZrbDRMMGx6WWdJSkw4VVZmVDduY0h1VEhW?= =?utf-8?B?VWJEZDkzVndqVmNZZWpMN0NhQlhpbGhsUG9naUUxenUyZkZHU0svaTYveWFw?= =?utf-8?B?VDhkSWx3V2N0ZGljMlBEcnZoRHZoNzJwaDRWZVpjRTNtUXVWb3U2V1R5T3M3?= =?utf-8?B?WCtlVFJYZjJNMVBaY25oOWNhQmZhM2M4OGd5VVBhWHdOTmhGREVRTkdoNmVW?= =?utf-8?B?V2FJcUFIN2tPOVJWU0o5U3ZhbzdEbS9yRFd1UHBKZGhhQmM1ekdHaXJwY01u?= =?utf-8?B?cEcwcGdJK2pEUHY4MWU1U1RzcjF1VkhIMngzS1hxMHQwTEJhcFVIVFl4cy9N?= =?utf-8?B?YTZVaFRSVjUrekE3c3pjTFNEM2V0VzZoZkFNcWY2WXRsTk5ndlltNktNY2Uz?= =?utf-8?B?djFsWW9BNlJHSXNYQ0JwU0c5Y3l5UGJNRmVCNSs1WDVpVkRFaEpiTjNuZVd5?= =?utf-8?B?OXp6VXNpY1M2b0d2OXFjVDZvZGdKQklycDl2TDBYdHVuQklPNlBDeW1IWDVF?= =?utf-8?B?MExGZlhPRDZ6d3JNM2RxZmhuUmY1VXlMcVR3azVCQTVqdzRwMTFSSE4xTk93?= =?utf-8?B?Tk5qNEdsMXFPQjRkK3duSlorQURlL0daWnYrRDZMQ1IrZlUwL1dGeG4zWU9G?= =?utf-8?B?V1E4eld6c1d4RDVCbm5FOC9QV21JOVZjNFExeHJMWk5MYVJhMGErSWNLcmpt?= =?utf-8?B?dlAwYnVBb2RJd3Zpbzk4Y1l1RVdJMGFaVmRYQXJNUncwQ0kxREIvRWlaRCsw?= =?utf-8?B?dnBjMVBtTDd3b3puNW1lTEFGcFFqYTl5eUNWMXc1ZVc3SVI1REx4enBKVHZv?= =?utf-8?B?WWRhYlYwbzViSjhsblptQ1g5V0tGa0FBWjNSb3p5NFFCRlV1aFhEelA5M1gx?= =?utf-8?B?Nkl4bnVRVWkwME9wN1J4d3htSlJDSERxZmJNS01nM2xYVHQ5Q2RKdmRBdFdp?= =?utf-8?B?NFM3emdhdVZEdHU4RTRya01XY3Zhdkc2WnpSZW1NbHBXYjdibUI5SUw5K01U?= =?utf-8?Q?Im8j70Y+/vjGJbtPbuJ9tdV0=3D?= X-Microsoft-Exchange-Diagnostics: 1;BN1PR05MB060;5:K5PjMRtcL/ZKdEiErmnYJRYnwzoWmia/4TxO4ooAo1yYCuGB22ax2uKyd8p/zwvIl8Efr/WaPNzp+Fql5ksSr7m/eLbRro4abTy6J+8IT3cfJ37xIQZcGLjaNgNaobjtXRbnV2WBc/NikKApStgdvA==;24:0oa14EJv7mr1ifnBZ6rQtAzwrFmHJWa7Oa/T8Zc/7elf4aJ+39snX6PkuP6qQMAZFf0zSERYnchL2kbqIdjXiwaw609gvxb0Buh57OPxp4I=;20:xj0wwAIPmY8NPdRyYhWIy6fNvx3v2/XncAPP7SUzyf8uI+DI0ZCphse2J+syGRztU25S2QtLkZ3gjILtAvLlQQ== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Nov 2015 21:02:37.0600 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.17];Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB060 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Niels M=C3=B6ller writes: > "Mark D. Baushke" writes: >=20 > > See also: > > > > http://csrc.nist.gov/publications/nistpubs/800-107-rev1/sp800-107-rev= 1.pdf > > Section 4.2 table 1. >=20 > It's not clear to me why the "collision resistance strength" rather > than "preimage resistance strength" or "second preimage strength" apply > when using sha2 for generating session keys and the exchange hash. Looking more carefully at what is being hashed in the exchange, I agree with you that collision resistance strength is not involved here. So, that only leaves open if choosing to use sha256 as a hash for larger diffie-hellman MODP groups... For now, does it seem reasonable to add RFC 3526 group15 & group16 to the protocol? diffie-hellman-group15-sha256 (3072-bit MODP group ~130 bits of security) diffie-hellman-group16-sha256 (4096-bit MODP group ~150 bits of security) I do not see a need at present for using: * group17 (6144-bit MODP group ~170 bits of security) * group18 (8192-bit MODP group ~190 bits of security) IMO, it just takes too long to do calculations with them. -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Nov 14 23:48:56 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8021A8AE7 for ; Sat, 14 Nov 2015 23:48:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 WA5zdCslJ4CI for ; Sat, 14 Nov 2015 23:48:55 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD5C61A8AE5 for ; Sat, 14 Nov 2015 23:48:55 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 535A214A209; Sun, 15 Nov 2015 07:48:51 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 066A214A207 for ; Sun, 15 Nov 2015 07:48:44 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id ElWqYtTqsRpK for ; Sun, 15 Nov 2015 07:48:43 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0795.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:795]) by mail.netbsd.org (Postfix) with ESMTP id BD06514A201 for ; Sun, 15 Nov 2015 07:48:42 +0000 (UTC) Received: from CO2PR05CA018.namprd05.prod.outlook.com (10.141.241.146) by DM2PR0501MB1391.namprd05.prod.outlook.com (10.161.224.13) with Microsoft SMTP Server (TLS) id 15.1.325.17; Sun, 15 Nov 2015 07:48:38 +0000 Received: from BL2FFO11OLC012.protection.gbl (2a01:111:f400:7c09::124) by CO2PR05CA018.outlook.office365.com (2a01:111:e400:1429::18) with Microsoft SMTP Server (TLS) id 15.1.325.17 via Frontend Transport; Sun, 15 Nov 2015 07:48:38 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=juniper.net; cs.tcd.ie; dkim=none (message not signed) header.d=none;cs.tcd.ie; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.17) by BL2FFO11OLC012.mail.protection.outlook.com (10.173.160.159) with Microsoft SMTP Server (TLS) id 15.1.325.5 via Frontend Transport; Sun, 15 Nov 2015 07:48:37 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 14 Nov 2015 23:48:36 -0800 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id tAF7mYD78225; Sat, 14 Nov 2015 23:48:34 -0800 (PST) (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id F3CDA1149E; Sat, 14 Nov 2015 23:48:33 -0800 (PST) To: Niels =?utf-8?Q?M=C3=B6ller?= CC: Damien Miller , Peter Gutmann , denis bider , "Jeffrey Hutzelman" , "ietf-ssh@NetBSD.org" , "stephen.farrell@cs.tcd.ie" , "jon@siliconcircus.com" Subject: Re: DH group exchange (Re: SSH key algorithm updates) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73F4B5993D@uxcn10-5.UoA.auckland.ac.nz> <2096379125-720@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B599ED@uxcn10-5.UoA.auckland.ac.nz> <55190.1447001241@eng-mail01.juniper.net> <9A043F3CF02CD34C8E74AC1594475C73F4B5A9BC@uxcn10-5.UoA.auckland.ac.nz> <65113.1447107876@eng-mail01.juniper.net> <90378.1447145301@eng-mail01.juniper.net> <41119.1447226323@eng-mail01.juniper.net> <67048.1447534953@eng-mail01.juniper.net> Comments: In-reply-to: Niels =?utf-8?Q?M=C3=B6ller?= message dated "Sun, 15 Nov 2015 08:16:19 +0100." From: "Mark D. Baushke" Date: Sat, 14 Nov 2015 23:48:33 -0800 Message-ID: <26466.1447573713@eng-mail01.juniper.net> MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1;BL2FFO11OLC012;1:jXonINxUoOHWxXEg4+UteZTLz0aoy6/oEWsMz4ejko+r/S8MOr4jNQT4jOUozYS/ySTBCX6BGa+BBn42Ei+ZA8hBoUZymjL/Ib/4pISjDCx+oE0F0e/0Vv5+ir8Xl+M9HhRYpMCzCznhl5kL9Pb9JVxG7G/QQZ8TGFB3nspCJojNoHVn1KUvoiYElpPjZbcEs4Nuq5nMSpn6twIT8U4iyKpU8g5t039QVxHApm+iPISrmmTFEZpfPGM2vd1/+VnWUZcnifkBwCV700wp35xnvgheYoUqX2C4nt72qLqTwtxNdpfuno/zF8fr1vTewPYUe1r0trPz7T6VD4k2Rkd5NL9xlvLckiab3bUCNiI0W4Aa3cw/csjrHZaCZlfdoiGbrEWjW1Ctsqr019UXeS20xQ== X-Forefront-Antispam-Report: CIP:66.129.239.17;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(2980300002)(199003)(189002)(106466001)(93886004)(50986999)(53416004)(105596002)(54356999)(2950100001)(76176999)(77096005)(117636001)(76506005)(19580395003)(5007970100001)(11100500001)(48376002)(5003600100002)(97736004)(189998001)(81156007)(5001920100001)(87936001)(92566002)(86362001)(50466002)(19580405001)(5001960100002)(110136002)(69596002)(6806005)(5003940100001)(47776003)(586003)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:DM2PR0501MB1391;H:p-emfe01a-sac.jnpr.net;FPR:;SPF:SoftFail;PTR:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;DM2PR0501MB1391;2:SFWnUuDyWmrURndjuYuP1CV4g5N7jet5mEtlFaaCe7CbcGGeGompJi8NNY+FzvrpFJShNFcQBMfgoUlqFATtY42z4tuutzdTNIFi7fs/PfrY2DyU44sz7KkHynMcuN1IGb2VaBp4O84jpQkmQHshanhqLwsdsUh+cdHrJtXt6uY=;3:+lljEwufoEtbfNQejHThoOP7DDySohbjKKZ2D/FKC5N2FKf2DCtDr2jdrJ56TK7ZWlKFt5lTNlbmxbyTMatC50KHx7i2GABgLQrpn/JE2n/2dqWjpttL3GCXeOD2D1Bc0/RKl0eZ8Xw4aqP/Z7VZ2Dgy7UcYX8Lx6fi9IYJcukiuqEHH/0hMOGeh/OnP9Jf9SGD+9WkuL6Kp0ifMYvXvvEH0cXWlTO/IXk+3xK6p8SE=;25:WfRZMGaU7bRWlylO66c3yE8noauaVOYywHqnBeI0kkKiWC0/bGxtwMRm2f8OGmZ7IHn12lI/yKTOs4+vqumQQxbxSQzq8os/zf6SqO8FwqAUIeRoRPVJ8UCfn4IY8J2BOrYuFP6Dj1uDYTeaWaIiWl0vKglmLQ6I6sqeqUmR2JznPAigtL1U8hKW41bDw8EuexiRYpVSjAX0jnEPg+tUstk4aCJ8dNV6dks8DTsyY80TNc/49c2alsUeYcYjazAtK4EeUcG7kTpHLuGLX8nMEw== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1391; X-Microsoft-Exchange-Diagnostics: 1;DM2PR0501MB1391;20:mU2OjaI0kB3QhiTywAyDzGv4VrtVVlz1XwqOj/rAgI70ULpAdsuPtNRfp5RGBUfDLEMkLzZLd0WT1sMrN61jBKlzZy5e6abGOcuhOdvGw93Mm8LORoEP5AW8kMBewOxecaVjV4TIISs0Htkhj3hYN3md1cw0+4wac8Mv5G2RipCJMcujdxn9WZD5+SH0tulqgdzV/SEHl5xaeXCMmpdpy+y/s+ALICPtlon1oxPT018Zdap3M/oIzukSzs9HrvtnWhpNjXcGgsRC+eDSqar0B7eybeKszi4inwuIzjfp0FAmS/KQOSagPEnpwYJYKBxrsF0jFRHAflo6CX6DcvXROCxsUE0bc+pFrw/35ZtD+BRRSPKOAVfD338mWg0F+IETMtRBZEq3WnAyfys1FHnijds5NdkgVmdZy3+L+BHK7tjAkaIta3khch8XbwS7lUjmeroRajCeL7hxH9gMZvha0p0YrbmgZKneeu9G/RHzAOR1LjadmMyKQZGEVU6Wk+ds;4:wW5knE89HrJSfM3WUwu9IkE4fQCSYMmKD75EMljHj3K9hohQ/zn7i1qPpafbtl9jpu8ibSq57nN5PLFH04EuJfUfGHNMPZyaRyZOUyTevUEpFBtNpcg7N6s0MPnrT+Rxm/Ea7VFGqMV7fl0/n9N9AIVV6CyCzHwd+5y9JbJCuJ3N3cXsnckcQftJoi3CXJUndnOGrx11lnWmuCmzhzZ9xOqZ4BhyBZ65PfNzqIy9CNhbRzd9hPyXgR2y/5VBmqyVaP65GFao/DFBqvffLJIvrIIbL45tN5840FFn8lMGDSdTc7NaAij+fn25zq10IpmwMa2RtM4eFo7ZQNRpL/k96J3LX+TvMzB7zA/8G/Xg/f/cV9d52yU9fxD1O+5JC10u X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001)(10201501046);SRVR:DM2PR0501MB1391;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1391; X-Forefront-PRVS: 0761DE1EDD X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;DM2PR0501MB1391;23:qJCO/q1E6Sd6CC9u16WyjaV1atYjE2jTKpAvCff?= =?us-ascii?Q?173aUiFTB+C8kETnKgdWH/nf2iZCQkwk9Dr3n0jI2DRo8xPSwU9wi3u5NsR1?= =?us-ascii?Q?9Jk5BF5c+mZ3fRsuQkrLvm8D5QbLC/LK6Cc7OqF/phoQIoFZKdxQDFkAWiDK?= =?us-ascii?Q?kLLVYTznO7X7EI0zRSakkFxEfQtCYwsCttAvue+D4qWgjMRbG0eGLUBeaQLh?= =?us-ascii?Q?8N6a+Ydpc7uxqKa295Hm8Ij5xHkWnkV92VzdjyCSv3uQdvE2zEu4KF7fhtt6?= =?us-ascii?Q?X4MxdwVrT5hKwZX66SSFUQrzxAxE29opQ/eXAjuzoskTwr5BeDthUWGmZ3Nj?= =?us-ascii?Q?9QIY/ZxQQvc8FZBPG+KSzSZdEQuFNA+56nvzk4Mcd6abnGX11rZ8BtvcyL9r?= =?us-ascii?Q?IP9y2YahLRD+mizeiacZoYcbplTMhaUcV67FJrc0Pl5ArH6khb22tXBzyyF0?= =?us-ascii?Q?4CTLqQp1Bor0HHi4zeBLeibODLPCPHAgiLLhtJshHGiO2XRIhG1LtlYKnUpy?= =?us-ascii?Q?NB8z+f2fYmdlnKOPKlXEivm1CjQ8vVIoI6LuG0onXdNFkgDTZP2nrhMbJr2V?= =?us-ascii?Q?CNADbLa/Q3FgQ+nT6dZS9yIj1ZxYPklYvUR4SiT4HK4CfkVp0LZOeAgIwD3F?= =?us-ascii?Q?JApk4IFGObYRZcBiLnKdkCj0Ty0zXnWqxMb35dUesvRKq9P370x9gbrLah5O?= =?us-ascii?Q?0sVGaLxWZRdxay7U5hmn4zkw8TPOWk8qKXORhegBfQCdH4R5FuMDDLJXycCj?= =?us-ascii?Q?f0cLHy3XxxV5KG3B5aDzLvZDlDk1HYZEJi0X2x//GkX/dVToMOq4EGnd0PM9?= =?us-ascii?Q?aiTby0vD2MZItsAamJ/3gjU2my/lgkvw/Cqzuj9KdRnS+voDamGxWtTDxWEv?= =?us-ascii?Q?N0itFZw3JipNHPxl4uYqEl1zmeY4btRsX/noAZ3NO29m4G1ICvSyKGxDM5Mt?= =?us-ascii?Q?ff8l2jXCdKDHICtZFttgdCxjcEBmif1q0uRiy3ysG0ew4VIAXCqL1UFB0jg6?= =?us-ascii?Q?kLcsNb/OwLgaV55I//c+pJh48ZSePlYFSih6vQv4VOaBrAA=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1;DM2PR0501MB1391;5:KjGQwA8PvXw8uDe90JeGDxD7to/qEocsit3CpwxOSR52yljLkmIZfrrY2nCE6fvxsTJYQgEafs3Ex58RFMW7FCgjKKga7mlG9yTpmudDa2DfwzOsKx47dYQazQ1Yyq8fz77sxQBwkwfWyoXKmfPrzQ==;24:M7vrKMNar7sFKMnbJ1dGH091UVWabeZpoWkUJDcEX8Jcl2sg23eeAkVZHJid/RLDSuNFfSU4PxT5YiwN2TtVVHzrZQ28a/W+mqUvS0tNkXU=;20:npqOO41WK5gpFdQ5TTkz1KYbAtd2S2iQ2WOchICjLYct/0pRzlCOnvhGcNAkKLIhb9mlJ5ObJiME8JOSyruiMg== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Nov 2015 07:48:37.6004 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.17];Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1391 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Niels =?utf-8?Q?M=C3=B6ller?= writes: > "Mark D. Baushke" writes: > > > For now, does it seem reasonable to add RFC 3526 group15 & group16 to > > the protocol? > > > > diffie-hellman-group15-sha256 (3072-bit MODP group ~130 bits of securit= > y) > > diffie-hellman-group16-sha256 (4096-bit MODP group ~150 bits of securit= > y) > > I think it makes sense. It's good to have some specified algorithms > with security a bit beyond what's currently used, to make it easy to > move if/when needed attacks on the current algorithms emerge. Agreed. > Next question is what status they should have. I think it makes sense to > have group15 as RECOMMENDED. I agree with this suggestion. > (By the same argument, I think it makes sense to specify some > alternative to sha256 too, which I guess would be either sha512 or > sha3-384 (sha384 makes litte sense to me, since it's essentially a > truncated sha512, with same performance and shorter output)). Given your point about sha2-384, I think there are three possibilities that remain: sha2-512 sha3-256 sha3-512 There are aguments both in favor and against each of the alternatives. fwiw: I have no idea if the SSH community is ready to consider the use of sha3 (FIPS PUB 202 style) at this time, but it is more likely to be a challenge to the attacks on diffie-hellman I heard of to date. -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Nov 15 02:50:10 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A79101B306A for ; Sun, 15 Nov 2015 02:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Cvv070ZbYOsa for ; Sun, 15 Nov 2015 02:50:07 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 150621B305A for ; Sun, 15 Nov 2015 02:50:07 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id C5FBD14A208; Sun, 15 Nov 2015 10:50:03 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 970EB14A200 for ; Sun, 15 Nov 2015 10:49:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id PnH-XiqI4VAH for ; Sun, 15 Nov 2015 10:49:58 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 370F914A1F5 for ; Sun, 15 Nov 2015 10:49:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1447584598; x=1479120598; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ch3LjP16yxRyGmOxKIcxaR0X20CfgM/pYV/FsNIVDAY=; b=4XdaW58nnpRNK7NHg+lw3vFGWnsE/e7pVzhetyiziKuI6zlKEWz9DF4h pcJdiMe9nPZr/oZ/eOgw634eQ+CwZeGO41kL2YFaYwbdAYZM6onXkMCbk 3KHsFftJ+1ul1/r0rthbQEUwo6/IL74uZ3pht/nBWnhv6y1+MUczyxWOB 8ip7oo1ObvpklRmQcUanncxSp8n9gI+Ka8uF/ggKUgqPH+ipvRHvtNpFe j/oxx7kFlG3veAPZPl9tsgzF+nGFL1Kncog0G3tyBMHhhyfjGJYSzSYxz a4SNadOeOFcHjmP1Bx152tRcc12ky/QOLRditxMfJGQWrbDeyFT0KOsEP Q==; X-IronPort-AV: E=Sophos;i="5.20,296,1444647600"; d="scan'208";a="54253838" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 15 Nov 2015 23:49:50 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Sun, 15 Nov 2015 23:49:50 +1300 From: Peter Gutmann To: denis bider CC: "ietf-ssh@netbsd.org" , "djm@mindrot.org" , "terrafrost@gmail.com" , "thierry.moreau@connotech.com" Subject: RE: New version of rsa-sha2-256 draft: Back to PKCS#1 v1.5 Thread-Topic: New version of rsa-sha2-256 draft: Back to PKCS#1 v1.5 Thread-Index: AQHRHhI/sq8SN1Tfz0+kbj2q9UYctp6c6kqI Date: Sun, 15 Nov 2015 10:49:49 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B64A2E@uxcn10-5.UoA.auckland.ac.nz> References: <540590-3304@skroderider.denisbider.com> In-Reply-To: <540590-3304@skroderider.denisbider.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list denis bider writes:=0A= =0A= >I'm not sure we're referring to the same attack. The most critical SSH + C= BC=0A= >attack I can think of right now is this:=0A= >=0A= >http://isg.rhul.ac.uk/~kp/SandPfinal.pdf=0A= =0A= Ah, OK, I was thinking of the original attack(s) that motivated the suggest= ion=0A= to use CTR.=0A= =0A= >This requires only a MITM position and allows recovery of up to 32 plainte= xt=0A= >bits once per about ~200k intercepted connections. That's perfectly feasib= le=0A= >if the connections are being automatically retried over some time without= =0A= >supervision (which is not unusual in deployment).=0A= =0A= Hmm, I wouldn't necessarily call it a feasible attack, more a certification= al=0A= weakness (meaning the protocol doesn't meet its design requirements).=0A= =0A= >Our defense against this is to not obviously leak info about whether the= =0A= >result of packet length decryption was something sensible or not. But it m= ay=0A= >be that most implementations don't do this.=0A= =0A= Same here, I do a lot more rigorous checking than OpenSSH (as described in = the=0A= paper) does, checking lengths, packet types, and padding size, and the=0A= disconnect notification is an empty string. As you say though, the problem= =0A= isn't necessarily your code but the other side. OTOH I think that an=0A= implementation that does little checking and so is particularly vulnerable= =0A= probably won't know about using CTR mode either...=0A= =0A= Peter.= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Nov 15 21:04:55 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A081B2C8A for ; Sun, 15 Nov 2015 21:04:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.285 X-Spam-Level: X-Spam-Status: No, score=-0.285 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.585] autolearn=ham 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 5EiAW3_B8jOV for ; Sun, 15 Nov 2015 21:04:52 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AF311B2C88 for ; Sun, 15 Nov 2015 21:04:52 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 0728B14A19D; Mon, 16 Nov 2015 05:04:51 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 98C6814A19C; Mon, 16 Nov 2015 05:04:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id D0EF214A1EF for ; Sun, 15 Nov 2015 19:09:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id ZXcGQ6T7ipEk for ; Sun, 15 Nov 2015 19:09:35 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id CD0F114A1BC for ; Sun, 15 Nov 2015 19:09:35 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for nisse@lysator.liu.se; Sun, 15 Nov 2015 19:09:34 +0000 Date: Sun, 15 Nov 2015 19:09:34 +0000 Subject: Re: DH group exchange (Re: SSH key algorithm updates) X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <143628170-1432@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: =?UTF-8?q?Niels_M=C3=B6ller?= , "Mark D. Baushke" Cc: Damien Miller , Peter Gutmann , Jeffrey Hutzelman , stephen.farrell@cs.tcd.ie, jon@siliconcircus.com, ietf-ssh@NetBSD.org Content-Type: multipart/alternative; boundary="=-tl6WQl8Mg68pg4cF276K" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-tl6WQl8Mg68pg4cF276K Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I agree, and would like to see algorithm names for these groups defined. We have a bit of an inconsistency going on, in the way we refer to SHA-2 25= 6. We standardized hmac-sha2-256, but on the other hand we have "sha256" el= sewhere, including as discussed for DH here. I suggest "sha2-256" for the same reason this was suggested in the hmac-sha= 2-256 case: to make it clear it isn't sha3-256. I have previously argued that consistency for the sake of consistency is ov= ervalued. Therefore, in order to be consistent, I should be fine either way= . :) I think it's worthwhile to point out, however. ----- Original Message ----- From: Niels "M=C3=B6ller"=20 Sent: Sunday, November 15, 2015 01:16 To: Mark D. Baushke=20 Cc: Damien Miller ; Peter Gutmann ; denis bider ; Jeffrey Hutzelman ; ietf-= ssh@NetBSD.org ; stephen.farrell@cs.tcd.ie ; jon@siliconcircus.com=20 Subject: Re: DH group exchange (Re: SSH key algorithm updates) "Mark D. Baushke" writes: > For now, does it seem reasonable to add RFC 3526 group15 & group16 to > the protocol? > >=C2=A0=C2=A0 diffie-hellman-group15-sha256 (3072-bit MODP group ~130 bits = of security) >=C2=A0=C2=A0 diffie-hellman-group16-sha256 (4096-bit MODP group ~150 bits = of security) I think it makes sense. It's good to have some specified algorithms with security a bit beyond what's currently used, to make it easy to move if/when needed attacks on the current algorithms emerge.=20 Next question is what status they should have. I think it makes sense to have group15 as RECOMMENDED. (By the same argument, I think it makes sense to specify some alternative to sha256 too, which I guess would be either sha512 or sha3-384 (sha384 makes litte sense to me, since it's essentially a truncated sha512, with same performance and shorter output)). Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. = --=-tl6WQl8Mg68pg4cF276K Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable I agree, and would like to see algorithm names for= these groups defined.

We have a bit of an inconsistency going on, i= n the way we refer to SHA-2 256. We standardized hmac-sha2-256, but on the = other hand we have "sha256" elsewhere, including as discussed for DH here.<= br>
I suggest "sha2-256" for the same reason this was suggested in the h= mac-sha2-256 case: to make it clear it isn't sha3-256.

I have previo= usly argued that consistency for the sake of consistency is overvalued. The= refore, in order to be consistent, I should be fine either way. :) I think = it's worthwhile to point out, however.


----- Original Message --= ---
From: Niels "M=C3=B6ller"
Sent: Sunday, November 15, 2015 01:16<= br>To: Mark D. Baushke
Cc: Damien Miller ; Peter Gutmann ; denis bider = ; Jeffrey Hutzelman ; ietf-ssh@NetBSD.org ; stephen.farrell@cs.tcd.ie ; jon= @siliconcircus.com
Subject: Re: DH group exchange (Re: SSH key algorith= m updates)

"Mark D. Baushke" <mdb@juniper.net> writes:

= > For now, does it seem reasonable to add RFC 3526 group15 & group16= to
> the protocol?
>
>   diffie-hellman-group1= 5-sha256 (3072-bit MODP group ~130 bits of security)
>   di= ffie-hellman-group16-sha256 (4096-bit MODP group ~150 bits of security)
=
I think it makes sense. It's good to have some specified algorithms wit= h
security a bit beyond what's currently used, to make it easy to moveif/when needed attacks on the current algorithms emerge.

Next que= stion is what status they should have. I think it makes sense to
have gr= oup15 as RECOMMENDED.

(By the same argument, I think it makes sense = to specify some
alternative to sha256 too, which I guess would be either= sha512 or
sha3-384 (sha384 makes litte sense to me, since it's essentia= lly a
truncated sha512, with same performance and shorter output)).
<= br>Regards,
/Niels

--
Niels M=C3=B6ller. PGP-encrypted email = is preferred. Keyid C0B98E26.
Internet email is subject to wholesale gov= ernment surveillance.

= --=-tl6WQl8Mg68pg4cF276K-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Nov 15 21:06:39 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1BAD1B2C90 for ; Sun, 15 Nov 2015 21:06:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.585] autolearn=ham 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 gjTY7wDsrTmw for ; Sun, 15 Nov 2015 21:06:38 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 941441B2C8E for ; Sun, 15 Nov 2015 21:06:38 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id B984814A1C6; Mon, 16 Nov 2015 05:06:37 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 61CFC14A1BD; Mon, 16 Nov 2015 05:06:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id D198014A207 for ; Sun, 15 Nov 2015 07:16:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id wWRr8HNoryGA for ; Sun, 15 Nov 2015 07:16:27 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 0271814A201 for ; Sun, 15 Nov 2015 07:16:25 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 4012B4007B; Sun, 15 Nov 2015 08:16:23 +0100 (CET) Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id 1367E40079; Sun, 15 Nov 2015 08:16:19 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Sun, 15 Nov 2015 08:16:19 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: "Mark D. Baushke" Cc: Damien Miller , Peter Gutmann , denis bider , "Jeffrey Hutzelman" , "ietf-ssh\@NetBSD.org" , "stephen.farrell\@cs.tcd.ie" , "jon\@siliconcircus.com" Subject: Re: DH group exchange (Re: SSH key algorithm updates) References: <9A043F3CF02CD34C8E74AC1594475C73F4B5993D@uxcn10-5.UoA.auckland.ac.nz> <2096379125-720@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B599ED@uxcn10-5.UoA.auckland.ac.nz> <55190.1447001241@eng-mail01.juniper.net> <9A043F3CF02CD34C8E74AC1594475C73F4B5A9BC@uxcn10-5.UoA.auckland.ac.nz> <65113.1447107876@eng-mail01.juniper.net> <90378.1447145301@eng-mail01.juniper.net> <41119.1447226323@eng-mail01.juniper.net> <67048.1447534953@eng-mail01.juniper.net> Date: Sun, 15 Nov 2015 08:16:19 +0100 In-Reply-To: <67048.1447534953@eng-mail01.juniper.net> (Mark D. Baushke's message of "Sat, 14 Nov 2015 13:02:33 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list "Mark D. Baushke" writes: > For now, does it seem reasonable to add RFC 3526 group15 & group16 to > the protocol? > > diffie-hellman-group15-sha256 (3072-bit MODP group ~130 bits of securit= y) > diffie-hellman-group16-sha256 (4096-bit MODP group ~150 bits of securit= y) I think it makes sense. It's good to have some specified algorithms with security a bit beyond what's currently used, to make it easy to move if/when needed attacks on the current algorithms emerge.=20 Next question is what status they should have. I think it makes sense to have group15 as RECOMMENDED. (By the same argument, I think it makes sense to specify some alternative to sha256 too, which I guess would be either sha512 or sha3-384 (sha384 makes litte sense to me, since it's essentially a truncated sha512, with same performance and shorter output)). Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Nov 15 21:06:48 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043FF1B2C90 for ; Sun, 15 Nov 2015 21:06:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.585] autolearn=ham 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 fQ-xAalhN95Y for ; Sun, 15 Nov 2015 21:06:46 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D07851B2C8E for ; Sun, 15 Nov 2015 21:06:46 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 4060E14A1BD; Mon, 16 Nov 2015 05:06:46 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id CDE3914A1AC; Mon, 16 Nov 2015 05:06:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id EE5E014A224 for ; Sun, 15 Nov 2015 08:14:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id TuHFZ7xZlOOk for ; Sun, 15 Nov 2015 08:14:06 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 2D60A14A218 for ; Sun, 15 Nov 2015 08:14:05 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 19FEB40079; Sun, 15 Nov 2015 09:14:04 +0100 (CET) Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id 931BE40016; Sun, 15 Nov 2015 09:14:01 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Sun, 15 Nov 2015 09:14:01 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: "Mark D. Baushke" Cc: Damien Miller , Peter Gutmann , denis bider , "Jeffrey Hutzelman" , "ietf-ssh\@NetBSD.org" , "stephen.farrell\@cs.tcd.ie" , "jon\@siliconcircus.com" Subject: Re: DH group exchange (Re: SSH key algorithm updates) References: <9A043F3CF02CD34C8E74AC1594475C73F4B5993D@uxcn10-5.UoA.auckland.ac.nz> <2096379125-720@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B599ED@uxcn10-5.UoA.auckland.ac.nz> <55190.1447001241@eng-mail01.juniper.net> <9A043F3CF02CD34C8E74AC1594475C73F4B5A9BC@uxcn10-5.UoA.auckland.ac.nz> <65113.1447107876@eng-mail01.juniper.net> <90378.1447145301@eng-mail01.juniper.net> <41119.1447226323@eng-mail01.juniper.net> <67048.1447534953@eng-mail01.juniper.net> <26466.1447573713@eng-mail01.juniper.net> Date: Sun, 15 Nov 2015 09:14:01 +0100 In-Reply-To: <26466.1447573713@eng-mail01.juniper.net> (Mark D. Baushke's message of "Sat, 14 Nov 2015 23:48:33 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list "Mark D. Baushke" writes: > Given your point about sha2-384, I think there are three possibilities > that remain: > > sha2-512 > sha3-256 > sha3-512 sha3-384 could also be on that list. Unlike for sha*2*-384, it's a different security/performance tradeoff than sha3-512. > fwiw: I have no idea if the SSH community is ready to consider the use > of sha3 (FIPS PUB 202 style) at this time, Me neither. Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Nov 15 21:07:09 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8BF1B2C93 for ; Sun, 15 Nov 2015 21:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.485 X-Spam-Level: X-Spam-Status: No, score=-4.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585] autolearn=ham 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 j6B5UkwuKkWB for ; Sun, 15 Nov 2015 21:07:08 -0800 (PST) Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE4C91B2C90 for ; Sun, 15 Nov 2015 21:07:08 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 5601114A1D5; Mon, 16 Nov 2015 05:07:08 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id EEF0714A1D0; Mon, 16 Nov 2015 05:07:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 90A0914A260 for ; Sun, 15 Nov 2015 21:01:18 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 3CKJG2tYhxCZ for ; Sun, 15 Nov 2015 21:01:18 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id B63E514A248 for ; Sun, 15 Nov 2015 21:01:16 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 7E8DA40034; Sun, 15 Nov 2015 22:01:13 +0100 (CET) Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id 2A4714007E; Sun, 15 Nov 2015 22:01:10 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Sun, 15 Nov 2015 22:01:10 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: denis bider Cc: "Mark D. Baushke" , Damien Miller , Peter Gutmann , Jeffrey Hutzelman , stephen.farrell@cs.tcd.ie, jon@siliconcircus.com, ietf-ssh@NetBSD.org Subject: Re: DH group exchange (Re: SSH key algorithm updates) References: <143628170-1432@skroderider.denisbider.com> Date: Sun, 15 Nov 2015 22:01:10 +0100 In-Reply-To: <143628170-1432@skroderider.denisbider.com> (denis bider's message of "Sun, 15 Nov 2015 19:09:34 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list denis bider writes: > I suggest "sha2-256" for the same reason this was suggested in the > hmac-sha2-256 case: to make it clear it isn't sha3-256. Here's a note I wrote for a Nettle release announcement, about this naming mess, after some discussion on the devel list: Finally, a note on the naming of the various "SHA" hash functions. Naming is a bit inconsistent; we have, e.g., SHA1: sha1_digest SHA2: sha256_digest (not sha2_256_digest) SHA3: sha3_256_digest Renaming the SHA2 functions to make Nettle's naming more consistent has been considered, but the current naming follows common usage. Most documents (including the specification for SHA2) refer to 256-bit SHA2 as "SHA-256" or "SHA256" rather than "SHA2-256". I think it will cause least additional confusion to follow the admittedly confused common usage, "sha256", not "sha2-256". But I don't have a strong opinion. Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 16 09:32:34 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0351A897B for ; Mon, 16 Nov 2015 09:32:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FAKE_REPLY_C=1.486, RP_MATCHES_RCVD=-0.585] autolearn=ham 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 VUOQ6UCjPImO for ; Mon, 16 Nov 2015 09:32:33 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 386201A88A3 for ; Mon, 16 Nov 2015 09:32:33 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id B278914A1B2; Mon, 16 Nov 2015 17:32:32 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 8BB4B14A1AE for ; Mon, 16 Nov 2015 17:32:30 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (1024-bit key) header.d=jhcloos.com Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id bQT6puvnMhei for ; Mon, 16 Nov 2015 17:32:30 +0000 (UTC) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 1414914A14F for ; Mon, 16 Nov 2015 17:32:30 +0000 (UTC) Received: by ore.jhcloos.com (Postfix, from userid 10) id 7182A22AA7; Mon, 16 Nov 2015 17:32:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1447695146; bh=I6M+Rw6fA6WDxBPlJXMjcVbYZL8Ro/GfLYZPKGZXpYs=; h=From:To:Subject:Date:From; b=Xhu4nsyHImI6a0epxMmmN+uefOUtEfxv6I5upFF83EzgB+Mu2nNm7VPlIFH0Ifijt me9VQbxgGsTcbPk3mIEhq2ZaYPu4fLXZf05AWpz6VXiTgM4JqVyHG3ZpLzZJCnytBY jEWe2WDixDHe76csUMisff5XMMySPck+C37Yfq0I= Received: by carbon.jhcloos.org (Postfix, from userid 500) id EB524100CD541; Mon, 16 Nov 2015 17:32:06 +0000 (UTC) From: James Cloos To: Subject: Re: Curve25519/448 key agreement for SSH User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2015 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Mon, 16 Nov 2015 12:32:06 -0500 Message-ID: Lines: 14 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:151116:ietf-ssh@netbsd.org::o9vr7dPp4nQOfwaG:000000000000000000000000000000000000000005gfHn Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Given that one of the design goals of the modern curves is to exchange the public data as opaque bit strings, the protocol should not use anything like a mpint to exchange the keys but instead should exchange them as the opaque bit strings they are. How the crypto primitives use them is irrelevant to how they should be exchanged. Every 25519 public key should be exactly 32 octets and every goldilocks public key should be exactly 60 octets. Full stop. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 16 11:28:53 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5238C1A887B for ; Mon, 16 Nov 2015 11:28:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.585] autolearn=ham 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 mktKOFwf37Zv for ; Mon, 16 Nov 2015 11:28:52 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0087B1A8879 for ; Mon, 16 Nov 2015 11:28:51 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id BA19E14A187; Mon, 16 Nov 2015 19:28:49 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 709E514A178 for ; Mon, 16 Nov 2015 19:28:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id k9_Hq4Edgl1J for ; Mon, 16 Nov 2015 19:28:45 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id A3F2814A172 for ; Mon, 16 Nov 2015 19:28:42 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 7E93C40007; Mon, 16 Nov 2015 20:28:40 +0100 (CET) Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id E19D540009; Mon, 16 Nov 2015 20:28:38 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Mon, 16 Nov 2015 20:28:38 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: denis bider Cc: Simon Josefsson , ietf-ssh@netbsd.org, djm@mindrot.org Subject: Re: Curve25519/448 key agreement for SSH References: <23975746-2988@skroderider.denisbider.com> Date: Mon, 16 Nov 2015 20:28:38 +0100 In-Reply-To: <23975746-2988@skroderider.denisbider.com> (denis bider's message of "Thu, 12 Nov 2015 12:07:08 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list denis bider writes: >> If implementers are interested in "fixing" this while we go >> through this process, we have that opportunity. There is >> no direct backwards compatibility problem to care about, >> since we are registering a new name.=C2=A0=20 > > I agree, but it does seem like it would really require re-specifying K > to be a "string", and just for these particular algorithms. That sounds a bit awkward, but maybe it's not a big deal to actually implement? Do we ever do any integer operations of K? (Except internal to the key exchange). And for the old dh key exhange algorithms, we're converting the integer to a string, and it shouldn't be a big deal if we think of "K" as the value before or after that conversion. So I think we should seriously consider thinking about K as a string, and specify curve25519 with that view. James Cloos writes: > Given that one of the design goals of the modern curves is to exchange > the public data as opaque bit strings, the protocol should not use > anything like a mpint to exchange the keys but instead should exchange > them as the opaque bit strings they are. I think the issue is not the messages in the curve25519 dh exchange itself, but the representation of the *output* of the key exchange. Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 16 12:50:30 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 371521B3150 for ; Mon, 16 Nov 2015 12:50:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.585 X-Spam-Level: X-Spam-Status: No, score=-1.585 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_41=0.6, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.585] autolearn=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 VatjWW2EutfH for ; Mon, 16 Nov 2015 12:50:29 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B2211B315C for ; Mon, 16 Nov 2015 12:50:29 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id B05C214A18D; Mon, 16 Nov 2015 20:50:24 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id A0ABC14A180 for ; Mon, 16 Nov 2015 20:50:20 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id fUdGIyBHeBxm for ; Mon, 16 Nov 2015 20:50:20 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id BC26A14A17C for ; Mon, 16 Nov 2015 20:50:18 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 21CA240009; Mon, 16 Nov 2015 21:50:16 +0100 (CET) Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id 4743640007; Mon, 16 Nov 2015 21:50:14 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Mon, 16 Nov 2015 21:50:13 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: denis bider Cc: Simon Josefsson , ietf-ssh@netbsd.org, djm@mindrot.org Subject: Re: Curve25519/448 key agreement for SSH References: <23975746-2988@skroderider.denisbider.com> Date: Mon, 16 Nov 2015 21:50:13 +0100 In-Reply-To: ("Niels =?utf-8?Q?M?= =?utf-8?Q?=C3=B6ller=22's?= message of "Mon, 16 Nov 2015 20:28:38 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list nisse@lysator.liu.se (Niels M=C3=B6ller) writes: > That sounds a bit awkward, but maybe it's not a big deal to actually > implement? Do we ever do any integer operations of K? (Except internal > to the key exchange). And for the old dh key exhange algorithms, we're > converting the integer to a string, and it shouldn't be a big deal if we > think of "K" as the value before or after that conversion. I've now reread RFC 4253, section 7.2, and my corresponding source code, to have a closer look. : The key exchange produces two values: a shared secret K, and an : exchange hash H. Here, H is clearly a string, and it's construction depends on the key exchange method. That K is an integer is stated in a parenthesis, : o Initial IV client to server: HASH(K || H || "A" || session_id) : (Here K is encoded as mpint and "A" as byte and session_id as raw : data. "A" means the single character A, ASCII 65). So K's contribution to the hash input is a length field, followed by network-byte order bytes, following ssh rules on how to deal with sign bit, etc. (The specification really isn't crystal clear, e.g., I think H too is "raw data", not preceded by a length field like a string). I don't see any serious practical problem if we for curve25519 specify that we do HASH(K || H || ...) where K is encoded as a string, i.e., four octets length, 0,0,0,32, followed by the curve25519 fixed-size output string (which happens to be an x-coordinate in little-endian order, iirc). My implementation actually represents K as a string already, with the conversion from integer to string done in the dh code, not in the generic key exchange code, which I think at least shows that there should be no great difficulty in treating K as a string. I think I'd prefer that we do the right thing here, even if that means we specify something not quite compatible with curve25519-sha256@libssh.org. Other opinions? Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 16 20:29:51 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01A811ACF09 for ; Mon, 16 Nov 2015 20:29:51 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, MIME error: error: part did not end with expected boundary; ; error: unexpected end of parts before epilogue X-Spam-Flag: NO X-Spam-Score: -0.586 X-Spam-Level: X-Spam-Status: No, score=-0.586 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.585] autolearn=ham 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 TMpRHRxzinVi for ; Mon, 16 Nov 2015 20:29:50 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F6651ACF04 for ; Mon, 16 Nov 2015 20:29:50 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 9979514A173; Tue, 17 Nov 2015 04:29:47 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 1062F14A16C; Tue, 17 Nov 2015 04:29:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 7A15A14A1A0 for ; Tue, 17 Nov 2015 01:03:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id WzXBttXBma_G for ; Tue, 17 Nov 2015 01:03:39 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id E4D4C14A196 for ; Tue, 17 Nov 2015 01:03:38 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for cloos@jhcloos.com; Tue, 17 Nov 2015 01:03:37 +0000 Date: Tue, 17 Nov 2015 01:03:37 +0000 Subject: Re: Curve25519/448 key agreement for SSH X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <251371587-2064@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: James Cloos Cc: ietf-ssh@NetBSD.org Content-Type: multipart/alternative; boundary="=-a0cuxAQajOrG5+dDWbzc" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-a0cuxAQajOrG5+dDWbzc Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable James, this reads like an ideological pamphlet from someone triggered by the wrong= hot button words. It seems you're unfamiliar with details. No one is exchanging 25519 or 448 keys as anything but fixed-length strings= . The mpint encoding of the shared secret isn't sent on the wire. It is inv= olved strictly in the SSH parties' private calculation of the exchange hash= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 16 20:30:22 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0001ACF1A for ; Mon, 16 Nov 2015 20:30:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.584 X-Spam-Level: X-Spam-Status: No, score=-1.584 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.585] autolearn=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 SQ7bZW0YAHeI for ; Mon, 16 Nov 2015 20:30:21 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E8261ACF19 for ; Mon, 16 Nov 2015 20:30:21 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id AF79014A174; Tue, 17 Nov 2015 04:30:20 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 5680614A16C; Tue, 17 Nov 2015 04:30:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 0B0D914A1A4 for ; Tue, 17 Nov 2015 01:14:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id ejLvEVAQUD62 for ; Tue, 17 Nov 2015 01:14:42 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id F18D614A1A0 for ; Tue, 17 Nov 2015 01:14:41 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for nisse@lysator.liu.se; Tue, 17 Nov 2015 01:14:35 +0000 Date: Tue, 17 Nov 2015 01:14:35 +0000 Subject: Re: Curve25519/448 key agreement for SSH X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <251992299-2064@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: =?UTF-8?q?Niels_M=C3=B6ller?= , Simon Josefsson , djm@mindrot.org Cc: ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-sr55TPui+/SysVApwfaf" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-sr55TPui+/SysVApwfaf Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable In a new algorithm, yes. But in this case, I am inclined to be against chan= ging the K encoding, simply because: - I consider the encoding to be a non-issue, as long as it's unambiguously = specified; and - this would be a departure from the existing libssh and OpenSSH implementa= tions; which is not a huge deal, cause it's a new algorithm name; but it's = awkward anyway. This is unless Damien comes out with a new finding - for example, that thei= r existing conversion from byte string X to mpint K is broken in 1/256 of c= ases. If it turned out that the existing implementation is adding a leading= zero if high bit of X is set; but is not removing the leading zero if the = 9 high bits of X are NOT set; then this would make it something that follow= s the rules of neither mpint, nor string. If that were the case, I would be= highly inclined to fix that. I have no reason to believe that's the case, however. And in that case, as = long as it is reasonable, which I believe it is, I'm inclined to support wh= atever their current implementation is doing. ----- Original Message ----- From: Niels "M=C3=B6ller"=20 Sent: Monday, November 16, 2015 14:50 To: denis bider=20 Cc: Simon Josefsson ; ietf-ssh@netbsd.org ; djm@mindrot.org=20 Subject: Re: Curve25519/448 key agreement for SSH nisse@lysator.liu.se (Niels M=C3=B6ller) writes: > That sounds a bit awkward, but maybe it's not a big deal to actually > implement? Do we ever do any integer operations of K? (Except internal > to the key exchange). And for the old dh key exhange algorithms, we're > converting the integer to a string, and it shouldn't be a big deal if we > think of "K" as the value before or after that conversion. I've now reread RFC 4253, section 7.2, and my corresponding source code, to have a closer look. : The key exchange produces two values: a shared secret K, and an : exchange hash H. Here, H is clearly a string, and it's construction depends on the key exchange method. That K is an integer is stated in a parenthesis, :=C2=A0=C2=A0=C2=A0 o=C2=A0 Initial IV client to server: HASH(K || H || "A"= || session_id) :=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (Here K is encoded as mpint and "A" a= s byte and session_id as raw :=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 data.=C2=A0 "A" means the single char= acter A, ASCII 65). So K's contribution to the hash input is a length field, followed by network-byte order bytes, following ssh rules on how to deal with sign bit, etc. (The specification really isn't crystal clear, e.g., I think H too is "raw data", not preceded by a length field like a string). I don't see any serious practical problem if we for curve25519 specify that we do HASH(K || H || ...) where K is encoded as a string, i.e., four octets length, 0,0,0,32, followed by the curve25519 fixed-size output string (which happens to be an x-coordinate in little-endian order, iirc). My implementation actually represents K as a string already, with the conversion from integer to string done in the dh code, not in the generic key exchange code, which I think at least shows that there should be no great difficulty in treating K as a string. I think I'd prefer that we do the right thing here, even if that means we specify something not quite compatible with curve25519-sha256@libssh.org. Other opinions? Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. = --=-sr55TPui+/SysVApwfaf Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable In a new algorithm, yes. But in this case, I am in= clined to be against changing the K encoding, simply because:

- I co= nsider the encoding to be a non-issue, as long as it's unambiguously specif= ied; and
- this would be a departure from the existing libssh and OpenSS= H implementations; which is not a huge deal, cause it's a new algorithm nam= e; but it's awkward anyway.

This is unless Damien comes out with a n= ew finding - for example, that their existing conversion from byte string X= to mpint K is broken in 1/256 of cases. If it turned out that the existing= implementation is adding a leading zero if high bit of X is set; but is no= t removing the leading zero if the 9 high bits of X are NOT set; then this = would make it something that follows the rules of neither mpint, nor string= . If that were the case, I would be highly inclined to fix that.

I h= ave no reason to believe that's the case, however. And in that case, as lon= g as it is reasonable, which I believe it is, I'm inclined to support whate= ver their current implementation is doing.


----- Original Messag= e -----
From: Niels "M=C3=B6ller"
Sent: Monday, November 16, 2015 14= :50
To: denis bider
Cc: Simon Josefsson ; ietf-ssh@netbsd.org ; djm@= mindrot.org
Subject: Re: Curve25519/448 key agreement for SSH

ni= sse@lysator.liu.se (Niels M=C3=B6ller) writes:

> That sounds a bi= t awkward, but maybe it's not a big deal to actually
> implement? Do = we ever do any integer operations of K? (Except internal
> to the key= exchange). And for the old dh key exhange algorithms, we're
> conver= ting the integer to a string, and it shouldn't be a big deal if we
> = think of "K" as the value before or after that conversion.

I've now = reread RFC 4253, section 7.2, and my corresponding source code,
to have = a closer look.

: The key exchange produces two values: a shared secr= et K, and an
: exchange hash H.

Here, H is clearly a string, and = it's construction depends on the key
exchange method. That K is an integ= er is stated in a parenthesis,

:    o  Initial I= V client to server: HASH(K || H || "A" || session_id)
:   = ;    (Here K is encoded as mpint and "A" as byte and session= _id as raw
:       data.  "A" means t= he single character A, ASCII 65).

So K's contribution to the hash in= put is a length field, followed by
network-byte order bytes, following s= sh rules on how to deal with sign
bit, etc. (The specification really is= n't crystal clear, e.g., I think H
too is "raw data", not preceded by a = length field like a string).

I don't see any serious practical probl= em if we for curve25519 specify
that we do HASH(K || H || ...) where K i= s encoded as a string, i.e.,
four octets length, 0,0,0,32, followed by t= he curve25519 fixed-size
output string (which happens to be an x-coordin= ate in little-endian
order, iirc).

My implementation actually rep= resents K as a string already, with the
conversion from integer to strin= g done in the dh code, not in the
generic key exchange code, which I thi= nk at least shows that there
should be no great difficulty in treating K= as a string.

I think I'd prefer that we do the right thing here, ev= en if that means
we specify something not quite compatible with
curve= 25519-sha256@libssh.org. Other opinions?

Regards,
/Niels

-= -
Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26.<= br>Internet email is subject to wholesale government surveillance.

<= /body>= --=-sr55TPui+/SysVApwfaf-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 16 21:46:29 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9EEF1B2A0A for ; Mon, 16 Nov 2015 21:46:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.585] autolearn=ham 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 2AJRPginGuWo for ; Mon, 16 Nov 2015 21:46:28 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 959231B2A07 for ; Mon, 16 Nov 2015 21:46:28 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 2ACB614A167; Tue, 17 Nov 2015 05:46:26 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id EEA1D14A166 for ; Tue, 17 Nov 2015 05:46:23 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 70NXN2gxgK4K for ; Tue, 17 Nov 2015 05:46:23 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 4390E14A15C for ; Tue, 17 Nov 2015 05:46:22 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 3E1454000B; Tue, 17 Nov 2015 06:46:20 +0100 (CET) Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id 9CC5340009; Tue, 17 Nov 2015 06:46:18 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Tue, 17 Nov 2015 06:46:18 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: denis bider Cc: Simon Josefsson , djm@mindrot.org, ietf-ssh@netbsd.org Subject: Re: Curve25519/448 key agreement for SSH References: <251992299-2064@skroderider.denisbider.com> Date: Tue, 17 Nov 2015 06:46:18 +0100 In-Reply-To: <251992299-2064@skroderider.denisbider.com> (denis bider's message of "Tue, 17 Nov 2015 01:14:35 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list denis bider writes: > In a new algorithm, yes. But in this case, I am inclined to be against > changing the K encoding, simply because: > > - I consider the encoding to be a non-issue, as long as it's unambiguousl= y specified; and Do you agree that it adds a little implementation complexity, for no technical benefit?=20 Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Nov 17 07:27:13 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC4F1A9115 for ; Tue, 17 Nov 2015 07:27:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.585] autolearn=ham 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 Lx13mLEdKz-5 for ; Tue, 17 Nov 2015 07:27:11 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B5541A9104 for ; Tue, 17 Nov 2015 07:27:11 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id BC68F14A164; Tue, 17 Nov 2015 15:27:08 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 8C51014A158 for ; Tue, 17 Nov 2015 15:27:03 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id Xxe1KWuUbU0s for ; Tue, 17 Nov 2015 15:27:03 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id C4A2C14A157 for ; Tue, 17 Nov 2015 15:27:01 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 3E1C040013; Tue, 17 Nov 2015 16:26:59 +0100 (CET) Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id 871FA40012; Tue, 17 Nov 2015 16:26:57 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Tue, 17 Nov 2015 16:26:57 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: denis bider Cc: Simon Josefsson , djm@mindrot.org, ietf-ssh@netbsd.org Subject: Re: Curve25519/448 key agreement for SSH References: <295542474-788@skroderider.denisbider.com> Date: Tue, 17 Nov 2015 16:26:57 +0100 In-Reply-To: <295542474-788@skroderider.denisbider.com> (denis bider's message of "Tue, 17 Nov 2015 13:15:48 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list denis bider writes: > You've described that in your implementation K encoding is > method specific. Then I was unclear. The key exchange output is *always* represented as a string, even for the plain dh exchange methods. I view any integer-ness as an internal detail of the keyexchange mechanism. > Overall, though, it seems to be a bikeshed issue - it doesn't really matt= er either way. I agree it's not terribly important, but I'm going to get a bit annoyed when I implement curve25519 key exchange, if I have to tweak the length of K depending on contents of the secret value. I'd really like to hear more opinions. Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Nov 17 21:53:28 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE461ACDF1 for ; Tue, 17 Nov 2015 21:53:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.184 X-Spam-Level: X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.585] autolearn=ham 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 UQJahm6NgDS7 for ; Tue, 17 Nov 2015 21:53:27 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 491FF1ACDF2 for ; Tue, 17 Nov 2015 21:53:27 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id C81F014A17E; Wed, 18 Nov 2015 05:53:23 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 5CC1E14A169; Wed, 18 Nov 2015 05:53:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 0D84314A16B for ; Tue, 17 Nov 2015 13:16:10 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id nEIBJR2t_Ots for ; Tue, 17 Nov 2015 13:16:09 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 66BF314A13E for ; Tue, 17 Nov 2015 13:16:09 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for nisse@lysator.liu.se; Tue, 17 Nov 2015 13:15:48 +0000 Date: Tue, 17 Nov 2015 13:15:48 +0000 Subject: Re: Curve25519/448 key agreement for SSH X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <295542474-788@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: =?UTF-8?q?Niels_M=C3=B6ller?= , Simon Josefsson , djm@mindrot.org Cc: ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-wjhh80FcIknX3hJ3YsLf" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-wjhh80FcIknX3hJ3YsLf Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Yes, but: - Other kex methods use mpint, so you need to support K as mpint anyway. Yo= u've described that in your implementation K encoding is method specific. B= ut maybe in another implementation K encoding is common between methods, an= d it now needs to have a special case for when K is string. This adds compl= exity to that implementation. - If libssh and OpenSSH have to implement two subtly different versions of = the same algorithm, that's implementation complexity for no technical benef= it also. Overall, though, it seems to be a bikeshed issue - it doesn't really matter= either way. ----- Original Message ----- From: Niels "M=C3=B6ller"=20 Sent: Monday, November 16, 2015 23:46 To: denis bider=20 Cc: Simon Josefsson ; djm@mindrot.org ; ietf-ssh@netbsd.org=20 Subject: Re: Curve25519/448 key agreement for SSH denis bider writes: > In a new algorithm, yes. But in this case, I am inclined to be against > changing the K encoding, simply because: > > - I consider the encoding to be a non-issue, as long as it's unambiguousl= y specified; and Do you agree that it adds a little implementation complexity, for no technical benefit?=20 Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. = --=-wjhh80FcIknX3hJ3YsLf Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Yes, but:

- Other kex methods use mpint, so= you need to support K as mpint anyway. You've described that in your imple= mentation K encoding is method specific. But maybe in another implementatio= n K encoding is common between methods, and it now needs to have a special = case for when K is string. This adds complexity to that implementation.
=
- If libssh and OpenSSH have to implement two subtly different versions= of the same algorithm, that's implementation complexity for no technical b= enefit also.

Overall, though, it seems to be a bikeshed issue - it d= oesn't really matter either way.


----- Original Message -----From: Niels "M=C3=B6ller"
Sent: Monday, November 16, 2015 23:46
To:= denis bider
Cc: Simon Josefsson ; djm@mindrot.org ; ietf-ssh@netbsd.or= g
Subject: Re: Curve25519/448 key agreement for SSH

denis bider = <ietf-ssh3@denisbider.com> writes:

> In a new algorithm, ye= s. But in this case, I am inclined to be against
> changing the K enc= oding, simply because:
>
> - I consider the encoding to be a no= n-issue, as long as it's unambiguously specified; and

Do you agree t= hat it adds a little implementation complexity, for no
technical benefit= ?

Regards,
/Niels

--
Niels M=C3=B6ller. PGP-encrypted= email is preferred. Keyid C0B98E26.
Internet email is subject to wholes= ale government surveillance.

= --=-wjhh80FcIknX3hJ3YsLf-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Nov 18 03:34:13 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2014A1B2C95 for ; Wed, 18 Nov 2015 03:34:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.985 X-Spam-Level: X-Spam-Status: No, score=-1.985 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_52=0.6, RP_MATCHES_RCVD=-0.585] autolearn=ham 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 nEwEBwY5YuJB for ; Wed, 18 Nov 2015 03:34:11 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E27AC1B2CC1 for ; Wed, 18 Nov 2015 03:34:05 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 7C00E14A1C3; Wed, 18 Nov 2015 11:34:02 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 08B5514A14C for ; Wed, 18 Nov 2015 11:33:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 8DLswFxf9HRJ for ; Wed, 18 Nov 2015 11:33:56 +0000 (UTC) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 07C2614A14A for ; Wed, 18 Nov 2015 11:33:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 42E01BE47 for ; Wed, 18 Nov 2015 11:33:51 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXCv8i_6-xgU for ; Wed, 18 Nov 2015 11:33:51 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5F5D8BDD6 for ; Wed, 18 Nov 2015 11:33:50 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1447846431; bh=3osBI0muEEB9xk4FI1K0b7e+lWWPyUxfD/O3c4g2Mc4=; h=Subject:References:To:From:Date:In-Reply-To:From; b=GtDCrWLJHLmyhLjfhGsF5duSTqkyotfKvVAcNufEoekrYP8bLV941eQNVxJtQg3G2 4pVILJMgPYzc0pADDlGrRLu1+xyacOYNhUtlwj2G+Lkjy2hs2SDKpPbcubarNZaAJh 9VIIn0MliBQMThzo07ObNVGYVyfLrJySTjhf5WFg= Subject: Fwd: [saag] potential new wg - curdle... References: <564C5FCC.8080107@cs.tcd.ie> To: ietf-ssh@NetBSD.org From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Forwarded-Message-Id: <564C5FCC.8080107@cs.tcd.ie> Message-ID: <564C621D.90300@cs.tcd.ie> Date: Wed, 18 Nov 2015 11:33:49 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <564C5FCC.8080107@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hiya, Here's how we're thinking of doing IETF processing of some of the new work that's been discussed on here. Please say what you think. I've not followed all the recent mails on here though about new work, so I'm not sure if this captures everything that folks want to get done. Figuring that out here would be good. Comments on non-SSH aspects of this are probably better sent to the saag list. Thanks, S. -------- Forwarded Message -------- Subject: [saag] potential new wg - curdle... Date: Wed, 18 Nov 2015 11:23:56 +0000 From: Stephen Farrell To: saag@ietf.org Hiya, Following on from the earlier discussion about adding curves etc. a few folks (*) helped Kathleen and I craft an initial cut at charter text. [1] I think we have people (well, mostly Simon:-) to do the editing work for this. If you'd be willing to be a chair, please send an offlist mail to Kathleen and I. If you think this is useful and would review documents please respond to this mail saying so. I'd like to see that we have enough folks interested to make this work. If you have changes to charter text to suggest please do so, preferably in OLD/NEW form. If you think this is a bad idea, I'm sure you'll not be shy in saying so too:-) If there's not enough interest or if there're sound objections then we can abandon the idea and fall back to processing this stuff more slowly and more ad-hoc as AD sponsored drafts. (The main point of curdle is to be more organised and hopefully quicker at this.) Thanks, S. [1] https://datatracker.ietf.org/doc/charter-ietf-curdle/ (*) Thanks to Simon Josefsson, Yoav Nir, Russ Housley and Sean Turner for help with the text. The fault however is mine, if it's bad text or a dumb idea:-) _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Nov 18 07:37:19 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC9CD1B3359 for ; Wed, 18 Nov 2015 07:37:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.585] autolearn=ham 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 jxGB6ZOnoirY for ; Wed, 18 Nov 2015 07:37:18 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84A281B32AA for ; Wed, 18 Nov 2015 07:37:18 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 8416314A195; Wed, 18 Nov 2015 15:37:10 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id AB04314A190 for ; Wed, 18 Nov 2015 15:37:07 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id V5tdha8t2nB5 for ; Wed, 18 Nov 2015 15:37:07 +0000 (UTC) Received: from mail-ext-sout2.uwa.edu.au (mail-ext-sout2.uwa.edu.au [130.95.128.73]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 3D0C914A132 for ; Wed, 18 Nov 2015 15:37:04 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CqBADzhExW/8+AX4JehA5vwEgjhWIKAoISAQEBAQEBgQuENQEBBDIBRhALGAklDwUYMROILg2+WwEBAQEBBQEBAQEBAQEYBItSiTkFjhGIOYUhiAJlm2hjgg4ggWNlAQEBhQkBAQE X-IPAS-Result: A2CqBADzhExW/8+AX4JehA5vwEgjhWIKAoISAQEBAQEBgQuENQEBBDIBRhALGAklDwUYMROILg2+WwEBAQEBBQEBAQEBAQEYBItSiTkFjhGIOYUhiAJlm2hjgg4ggWNlAQEBhQkBAQE X-IronPort-AV: E=Sophos;i="5.20,313,1444665600"; d="scan'208";a="184457232" Received: from f5-new.net.uwa.edu.au (HELO mooneye.ucc.gu.uwa.edu.au) ([130.95.128.207]) by mail-ext-out2.uwa.edu.au with ESMTP/TLS/ADH-AES256-SHA; 18 Nov 2015 22:05:44 +0800 Received: by mooneye.ucc.gu.uwa.edu.au (Postfix, from userid 801) id D6AF266003; Wed, 18 Nov 2015 22:05:44 +0800 (AWST) Received: from motsugo.ucc.gu.uwa.edu.au (motsugo.ucc.gu.uwa.edu.au [130.95.13.7]) by mooneye.ucc.gu.uwa.edu.au (Postfix) with ESMTP id 9732C66001; Wed, 18 Nov 2015 22:05:44 +0800 (AWST) Received: by motsugo.ucc.gu.uwa.edu.au (Postfix, from userid 11154) id 903DB20082; Wed, 18 Nov 2015 22:05:44 +0800 (AWST) Date: Wed, 18 Nov 2015 22:05:44 +0800 From: Matt Johnston To: Niels =?iso-8859-1?Q?M=F6ller?= Cc: denis bider , Simon Josefsson , djm@mindrot.org, ietf-ssh@netbsd.org Subject: Re: Curve25519/448 key agreement for SSH Message-ID: <20151118140544.GG7184@ucc.gu.uwa.edu.au> Mail-Followup-To: Niels =?iso-8859-1?Q?M=F6ller?= , denis bider , Simon Josefsson , djm@mindrot.org, ietf-ssh@netbsd.org References: <295542474-788@skroderider.denisbider.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-snowman: =?utf-8?B?4piD?= User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Tue, Nov 17, 2015 at 04:26:57PM +0100, Niels Möller wrote: > denis bider writes: > > > Overall, though, it seems to be a bikeshed issue - it doesn't really matter either way. > > I'd really like to hear more opinions. Dropbear implements curve25519-sha256@libssh.org. My 2c is to stick with K as an mpint just to avoid unnecessary change/confusion with RFC 4253 (7.2, deriving keys) and 5656. In terms of implementation a fixed 32 byte string would have been simpler, but not worth changing. A small thing, 'k' in draft-josefsson-ssh-curves-01 should probably be upper case? Is it worth keeping the "Verify that client public key length is 32 bytes" (or 56) text of curve25519-sha256@libssh.org.txt ? Cheers, Matt https://git.libssh.org/projects/libssh.git/tree/doc/curve25519-sha256@libssh.org.txt From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Nov 18 09:58:25 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A94511A03AB for ; Wed, 18 Nov 2015 09:58:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.885 X-Spam-Level: X-Spam-Status: No, score=-1.885 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_52=0.6, RP_MATCHES_RCVD=-0.585] autolearn=ham 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 g4Sq8RtFFAKh for ; Wed, 18 Nov 2015 09:58:24 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12A0E1A039F for ; Wed, 18 Nov 2015 09:58:24 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id D290914A185; Wed, 18 Nov 2015 17:58:15 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id BA3DD14A158 for ; Wed, 18 Nov 2015 17:58:09 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id SDNufDIVUSIW for ; Wed, 18 Nov 2015 17:58:09 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0732.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::732]) by mail.netbsd.org (Postfix) with ESMTP id 66E0614A14E for ; Wed, 18 Nov 2015 17:58:07 +0000 (UTC) Received: from BLUPR05CA0059.namprd05.prod.outlook.com (10.141.20.29) by BN1PR05MB059.namprd05.prod.outlook.com (10.255.202.149) with Microsoft SMTP Server (TLS) id 15.1.325.17; Wed, 18 Nov 2015 17:24:37 +0000 Received: from BY2FFO11FD012.protection.gbl (207.46.163.244) by BLUPR05CA0059.outlook.office365.com (10.141.20.29) with Microsoft SMTP Server (TLS) id 15.1.331.20 via Frontend Transport; Wed, 18 Nov 2015 17:24:38 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=juniper.net; cs.tcd.ie; dkim=none (message not signed) header.d=none;cs.tcd.ie; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.17) by BY2FFO11FD012.mail.protection.outlook.com (10.1.14.130) with Microsoft SMTP Server (TLS) id 15.1.325.5 via Frontend Transport; Wed, 18 Nov 2015 17:24:36 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 18 Nov 2015 09:24:36 -0800 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id tAIHOZD02087; Wed, 18 Nov 2015 09:24:35 -0800 (PST) (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id ACC4C1148F; Wed, 18 Nov 2015 09:24:34 -0800 (PST) To: Stephen Farrell CC: "saag@ietf.org" , Subject: Re: [saag] potential new wg - curdle... In-Reply-To: <564C5FCC.8080107@cs.tcd.ie> References: <564C5FCC.8080107@cs.tcd.ie> Comments: In-reply-to: Stephen Farrell message dated "Wed, 18 Nov 2015 11:23:56 +0000." From: "Mark D. Baushke" Date: Wed, 18 Nov 2015 09:24:34 -0800 Message-ID: <89505.1447867474@eng-mail01.juniper.net> MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1;BY2FFO11FD012;1:QBXBSYTs3DMUFzdOB+wWXTavVFgtR7FEJtPlG/2qNrsl3jbx7dxND5qpGSa6WMOeCfV5ZBvvMdIkFq1dZSzh67VGTHfa1t0gEmwE92tyMl30KzXyMdPFbz4VkF36XUI78b9GC/PX6VDjPZVXXtQUTMsz1rzFve9KVwOvBAfQYzzmzIxUyMjEr11fwAbbJKr2SHvnggnLvCh2Fz45LnOa5wkpJPJxbIbhebfB8etQgM3Go7iigwkW7cssSU+KgUF80TSiWGDX5akgP3eLLjNl+23xvgxpXYkNWXM6LbhbYhs5ya3rwvpgoON3/Y6hkp+Atp8USv7eUamDCxk9vmhbOxpHyR8LzwXVkbY+aRc6WqeqHTV7rIlurM+EVDDrDH/K X-Forefront-Antispam-Report: CIP:66.129.239.17;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(2980300002)(54094003)(199003)(189002)(164054003)(92566002)(81156007)(5001960100002)(5007970100001)(76506005)(97736004)(54356999)(189998001)(110136002)(53416004)(117636001)(105596002)(5001920100001)(106466001)(21840400001)(5003940100001)(6806005)(87936001)(50986999)(19580405001)(69596002)(19580395003)(76176999)(50466002)(48376002)(77096005)(2950100001)(15975445007)(586003)(47776003)(86362001)(5003600100002)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:BN1PR05MB059;H:p-emfe01a-sac.jnpr.net;FPR:;SPF:SoftFail;PTR:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BN1PR05MB059;2:ZPME2ANboMQTV6XOTp8bARG0h46oc6dzcK0EmmHu3A5cRrKtY0LKLBr3dACV6/7ldwpE7/b6JlZ1FkZj/kvOHIrKQ2pkFcvAnhtXACVZ8105xaTjiUzgUvv7G50VW4Nl/+dldVGwXrSU2qkGi45KpjeTHxk0ISL34OAQi6TeA9A=;3:EYyAHHp9ARiJt8+hvB8v8qFjcpTUMaxGur2p1IfCt1H5it7mBiV2XAE/ofaJ1XefIQntgcMr/0byY7XhJrz2U1Jug3r+z9NCm3qh0QGe7egMzz6dMgOdGJ7s8BOAUScPgi9jTsTbg8x+PxOPCfzZGbfoYFcSdiAz/RQT7pm6u4rgIB5XVzhKJXXbGZmSbspzAY9ilqZNTVB4ErUV6QJSbiK8+YJWn6MN30v1vY1sEbk=;25:8aSop6xTgIocQYwNDkj/cGVlzVBsaQa2J65fZLqFhQXaHjP8S8jNHNisRE25q29b9MPnba7rFHTkVnNgUf8yhn7vx3awFb0WNDKsnuHZk2Wm15EHw2ElIJy8WOzMkelyfOHZVpA+gi+XohTLG95ascmrVOUATBwVmehsSyhhZ1ooyMTh5H0j2UfEAmczVs5l09zI6TJyTuT2/w18tGyz6yMOxlRJquqdifR8nQSccHD83tfvnXNKPrmRMWmB/F/5a9GiatnF/+G1thxjyFOMrA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB059; X-Microsoft-Exchange-Diagnostics: 1;BN1PR05MB059;20:IHRa+FRueXQxxSIdLizGWuy4wy4ezb0wQ90upbU21rVb3Pf9OTYQmrtfGqBOEfrPj9NDTrTqZ4VZeraUoVr6VHyTW0bXLqHNZMMwlqzlYWnzoMBXdi2jkUDaMEYFmsumR+EgEh+v+yeoziVLULW7RctuvOnIw0ITAMAiGU2md/1rtpeMnGlirg5OOR7VFmBWdliWVupkn5xs48/K865AMz/7V9rh6Fmkik4fyiAL9of/lEMuADdLFIcSI8PqbTP6f9WulcHkFgFV2hKk+bJ5iRBoD0PjqzNBKCUCfaQXuGzwlt+1v2iXf4UIUGSW9TSI8MMnOCrAAd3NQfSnTl4YTDNaM96pwN1Mv2nBmRwniz5KpgrADfLzbRlLV+n8TyFVfz8gMvBR4b9gSjxxFlGQTeQBMI1u6phZbToUNa4tMIvv2qC0/A99Nm7pw0Bn84lgATW3DSjzfykhkuTrnTQFtDa6qaR/zkuEeMx/TFvr2aepyrFp8ZR/VYZDjgAtt5LM;4:QhZpB3YC17F7B5cQv+1vnz7Pi2y69EGM1VJzWZ/xv16oTwXtOQDqcWPjdJtDJeSYn0J0WJVbgoc7nP/RW2Ux0Qc8d6vB4ZWTQVwupwnKP0WCyE5W962Y4JyXcqROK3jBwO+BRw5uqHrqEhhmMfm2eiIsyzd11I0y5sJgOdO89uzVSYeyWn9R2EMrIDmEhyjBJIQQpz/TRxLCO2zwUXDKmzXXHw9DxojU2ZwZmXoN3dMRgvu94lXJNvypwfUX/TaLVT2/wDN6avC62PNtgH7u1LzNKm0EirIATytErEzuNOTYMenQXeje4j2x5ilMHvGnBPDIpWcg9iarse29RkFXZjhfm4jSp5o5+YqO+3HBOkfVWM1pzMP93EXyswHh8JzE X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(32856632585715); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001);SRVR:BN1PR05MB059;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB059; X-Forefront-PRVS: 0764C4A8CD X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;BN1PR05MB059;23:Msr+o6Kk3USbWvsvdGKbHMjpe3TDyj/7CU0+fNB2Ty?= =?us-ascii?Q?UixX9eAx+hY5x2EdV/YGT9H7sBKCYWl/qqzV51/NO49e1JLanB4Vul71Ga1S?= =?us-ascii?Q?qhFc3g7fCUNLw82IxSI99RCWANuvYdkhmwl+i2q8bQjJ3frd1tkh3HuuOM4B?= =?us-ascii?Q?M4MRPgv2Pn2ss50njNE1WAgt3aTuoJcW6dSfStnAywcv1mV5Wqb4+te/bDvC?= =?us-ascii?Q?RICrOBlp657Qwvzjz2PFk+lMh86Q/wUDIfLlUlMMeykNtAcM/tx0y6weaZ3I?= =?us-ascii?Q?rM5/60GNaWW0UyI21R3InLRLul8gA6dY52jZMISQUDRHetOmRh/G5nEe3vT6?= =?us-ascii?Q?N0ETDjl/mT7qoXffa/vuvP4yHad6UxRf9qgrpj2MHQi4lPw1ANw3H6A7/Mtm?= =?us-ascii?Q?0FO9GeajOmXWHra3WtqB/MCibuzcrFOcIw1Yy9dibkzr5I9KzXF2SshQko3I?= =?us-ascii?Q?xDauenfT9oMWcNrJniD5l1YVaXr9uBqJL9ycFteaO9Ph7A5YcQ3NFHY0hHMz?= =?us-ascii?Q?QHx/m7TO79oB4mNd33m8UwyBp3DGOStVm/ar6Y+D0+yo4pSJdBUjHcOduvc9?= =?us-ascii?Q?CcpAWcNF0VTpJMsiZMaHnlvwJGls3wQdXSD+r3tNsK4LwmOgmDdYcIKOM/v6?= =?us-ascii?Q?zX8kSB/euyo1apOqTlgn+dFzjJVJsrjvW/cUDCbPmljtHa2MFqs99rqqeC9X?= =?us-ascii?Q?LYtwWBNsSQGmKiVkWyMliljTTouaXIq4jivfsoMtJ+DdLdUIo2QtHeX3Yn3X?= =?us-ascii?Q?7gk0dSExZgp78F+0JjiWKdyHqL2xtkk/WnBhD742t3UHg8MXiGweFew4sSOc?= =?us-ascii?Q?Zpqb5HigbQXvEwqc4Q09qrlR6f8IyCMxUROqOMkIpBfU3hdn8cLPUWh9Qypu?= =?us-ascii?Q?HCflIRuLkUjTg9SWXJSSa8YW7fzVykKWRkuRl3Wah9cIqLXVU50E0MJlpt0y?= =?us-ascii?Q?JfLbeS+X/gA9p5snGDsN6WUk3JCCOzokmjlZzlw6xiDiFEKHxssK6DEY8ZQJ?= =?us-ascii?Q?1gYe+jxuGSDuVLkYKaqSqrMsvF+uWxgGVeDBeYNkQ8wWbds08pD1wmziktcw?= =?us-ascii?Q?EkQ3wsJiKeIHxCroHI1tvqN63a?= X-Microsoft-Exchange-Diagnostics: 1;BN1PR05MB059;5:AeSj89Y0K2FDakNgmZDue7qQvB6HzP8vTi03XsJ0nYPMS8d/Gp/wxqNIqQL7qwt3BcqQLaNZ949qtleO34Aw1KIg7IQLUzxFN1vQFML45hC7GP8YLVC2Ygjtf1N+0CWP/qvb3v4ShxD+35Es733qHA==;24:AXpczq7PrDQ/EUAT59ovvTNyOZmqq9Xrre+5XawIYTLuh4XslJbFf9rysvhmEI0Br9NIZdrZmx8GJXGU0fvkUAn0dVzFvAFyY5C/VQjGuTk=;20:12iNQr0Vy3cUu8g7qjMnPNfqdHOwhM4XEvPIC9D2d9kplCgyaIbn98weymNdyH3SyGisklYf0hvIQWO2lo2sbQ== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Nov 2015 17:24:36.8621 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.17];Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB059 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hi Stephen, Stephen Farrell writes: > If you have changes to charter text to suggest please do so, > preferably in OLD/NEW form. The charter seems reasonable to me. > If there's not enough interest or if there're sound objections then > we can abandon the idea and fall back to processing this stuff more > slowly and more ad-hoc as AD sponsored drafts. (The main point of > curdle is to be more organised and hopefully quicker at this.) > > Thanks, > S. > > [1] https://datatracker.ietf.org/doc/charter-ietf-curdle/ > > (*) Thanks to Simon Josefsson, Yoav Nir, Russ Housley and > Sean Turner for help with the text. The fault however is mine, > if it's bad text or a dumb idea:-) > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag I wonder if RFC 5647 which is an information RFC for "AES Galois Counter Mode for the Secure Shell Transport Layer Protocol" could be cleaned up to address the problems of the key exchange as expressed by the OpenSSH team and made into a standard track document? To quote the objection from the OpenSSH PROTOCOL document: | 1.6 transport: AES-GCM | | OpenSSH supports the AES-GCM algorithm as specified in RFC 5647. | Because of problems with the specification of the key exchange | the behaviour of OpenSSH differs from the RFC as follows: | | AES-GCM is only negotiated as the cipher algorithms | "aes128-gcm@openssh.com" or "aes256-gcm@openssh.com" and never as | an MAC algorithm. Additionally, if AES-GCM is selected as the cipher | the exchanged MAC algorithms are ignored and there doesn't have to be | a matching MAC. Given that current implementatons of this informational RFC are using AEAD_AES_128_GCM and AEAD_AES_256_GCM and all of the standards track Cipher algorithms use lowercase with '-' as word separators, I would suggest that 'aes128-gcm' and 'aes256-gcm' may be more appropriate and that they should NOT be added to the MAC Algorithms Names in IANA. This same objection would arise to any AEAD Cipher, so I think it might be well to do something similar for SSH for standardize "chacha20-poly1305" for Secure Shell again as a Cipher name only with the MAC Algorithm Name ignored. Thank you, -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Nov 18 12:31:16 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B82FD1B2B02 for ; Wed, 18 Nov 2015 12:31:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.585] autolearn=ham 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 gkne0cQN_8QA for ; Wed, 18 Nov 2015 12:31:15 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B8C61B2AF5 for ; Wed, 18 Nov 2015 12:31:15 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 401EC14A1BE; Wed, 18 Nov 2015 20:31:13 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 0DF1C14A14F for ; Wed, 18 Nov 2015 20:31:08 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id EiCJeF_hZX9G for ; Wed, 18 Nov 2015 20:31:07 +0000 (UTC) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id D519514A14E for ; Wed, 18 Nov 2015 20:31:04 +0000 (UTC) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id tAIKUbiS022958 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 18 Nov 2015 21:30:39 +0100 From: Simon Josefsson To: Niels =?iso-8859-1?Q?M=F6ller?= Cc: denis bider , djm@mindrot.org, ietf-ssh@netbsd.org Subject: Re: Curve25519/448 key agreement for SSH References: <295542474-788@skroderider.denisbider.com> <20151118140544.GG7184@ucc.gu.uwa.edu.au> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:151118:nisse@lysator.liu.se::HMtUFcjWDXReYXRW:3xHR X-Hashcash: 1:22:151118:ietf-ssh@netbsd.org::77cG7GSBFXDRea0T:GPuL X-Hashcash: 1:22:151118:djm@mindrot.org::zpJ2PDjlmeTbgLZZ:LQZO X-Hashcash: 1:22:151118:ietf-ssh3@denisbider.com::eTGcUWId3Ghe/Ydm:ARv3 Date: Wed, 18 Nov 2015 21:30:36 +0100 In-Reply-To: <20151118140544.GG7184@ucc.gu.uwa.edu.au> (Matt Johnston's message of "Wed, 18 Nov 2015 22:05:44 +0800") Message-ID: <87poz7124z.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Matt Johnston writes: > On Tue, Nov 17, 2015 at 04:26:57PM +0100, Niels M=F6ller wrote: >> denis bider writes: >>=20 >> > Overall, though, it seems to be a bikeshed issue - it doesn't >> > really matter either way. >>=20 >> I'd really like to hear more opinions. > > Dropbear implements curve25519-sha256@libssh.org. My 2c is > to stick with K as an mpint just to avoid unnecessary > change/confusion with RFC 4253 (7.2, deriving keys) and 5656.=20 > In terms of implementation a fixed 32 byte string would have > been simpler, but not worth changing.=20 Agreed. > A small thing, 'k' in draft-josefsson-ssh-curves-01 should > probably be upper case?=20 Yep, fixed. > Is it worth keeping the "Verify that client public key length is 32 > bytes" (or 56) > text of curve25519-sha256@libssh.org.txt ? I added it. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWTN/tAAoJEIYLf7sy+BGdJwYIAJiqxDO8GSAUt5Gd351nc4LL 2qxKb8bHh0RDxgPT8J7+HlTsdabns4/O5B0QD2yY8SpTSzC5c/mbZ63QjJlGrVe/ DV/v02mQij/r16nNk0mpSu6pIGWKUZDULw8cnc6OoHnFLCEHhSJyxKpOMipy3i+S Ym2aIBFf5OuHt09YEpABSDpc0yAOVhnCfK2HdA9bVma4IAoOUwoQHJ4odWH8qNWW Z5/3qbT0G0jFS4I/S0hkrYoomQAVYM9AHy5k7Frs2o9y3QGgUungTBMUfE1o2MKT LBVZL/DueUz8pXrGUIIgwncCNuwQvPQknEukBcVtDaD5++l4rzZYKrIMFgg6D1w= =5/FI -----END PGP SIGNATURE----- --=-=-=-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Nov 18 12:39:43 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E25AF1B2C16 for ; Wed, 18 Nov 2015 12:39:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585] autolearn=ham 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 d0o7rvA8kz-7 for ; Wed, 18 Nov 2015 12:39:39 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADCFF1B2BF8 for ; Wed, 18 Nov 2015 12:39:39 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id E37DF14A1C4; Wed, 18 Nov 2015 20:39:37 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 9763F14A1C2 for ; Wed, 18 Nov 2015 20:39:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 68Ms8E1z_OEi for ; Wed, 18 Nov 2015 20:39:33 +0000 (UTC) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id A263B14A14F for ; Wed, 18 Nov 2015 20:39:32 +0000 (UTC) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id tAIKdFRr023776 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 18 Nov 2015 21:39:16 +0100 From: Simon Josefsson To: ietf-ssh@netbsd.org Subject: Re: Curve25519/448 key agreement for SSH References: <87pozjyzxc.fsf@latte.josefsson.org> <87wptntvsn.fsf@latte.josefsson.org> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:151118:ietf-ssh@netbsd.org::FnabkUQLRartA3JY:9eNk Date: Wed, 18 Nov 2015 21:39:14 +0100 In-Reply-To: <87wptntvsn.fsf@latte.josefsson.org> (Simon Josefsson's message of "Thu, 12 Nov 2015 10:24:24 +0100") Message-ID: <87lh9v11ql.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-=-= Content-Type: text/plain This is another update, clarifying the encoding issue a bit further and improving language (thank you Denis). https://tools.ietf.org/html/draft-josefsson-ssh-curves-02 A discussion on CFRG came up recently about checking for the all-zero shared secret. Does anyone know if libssh or OpenSSH (or anyone else) performs this check? Not doing that has apparently led to real security problems. For more background, see: http://thread.gmane.org/gmane.ietf.irtf.cfrg/6228 Thoughts on whether we should add a MUST to require checking the derived secret for the all-zero value? /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWTOHyAAoJEIYLf7sy+BGdLkwH/16XJUaxsddNhMV+lZwEKfpZ U5nR2jLs8VD8ILZHrXEkDSVI1OYtjRydZJBslfDFbg+hemU9yctsfAin6vmcRCyM 7P2m2bUoAnFVDqZB8PWsPyJu3nFvbiTbWSkvOsLhlTejHpNyG0Bb3p13LSymYRuq QHmoemwgfxd5mHPacyzM6vi9tsbT+F0SsrW82h3mVLnMzrvPse7gtfYac/PwQ2lD o//OHMoinXbBhIucJse+bQbp1khZOpzoQ4o+FKL0RJ8+rNa3p7lDttMKmnT8opbn U+r9600WPSc92d3wp2GrtotJTfadE4Ecg4IA/fRKmrv0Gt8Q0bbX63RbS+FGbWo= =TmR8 -----END PGP SIGNATURE----- --=-=-=-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Nov 18 20:57:29 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A30041A8794 for ; Wed, 18 Nov 2015 20:57:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.585] autolearn=ham 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 pcoFokl8y7CW for ; Wed, 18 Nov 2015 20:57:24 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D06021A878E for ; Wed, 18 Nov 2015 20:57:24 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 0216314A1DA; Thu, 19 Nov 2015 04:57:16 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id AB4FC14A1CD for ; Thu, 19 Nov 2015 04:57:14 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id zprLxIJk_vsz for ; Thu, 19 Nov 2015 04:57:14 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 78B6314A127 for ; Thu, 19 Nov 2015 04:57:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1447909033; x=1479445033; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=YZAToojXscj7XoIUwTq9XWYedC05w5TqSc1S/CZ9CLs=; b=L5WtQZc7mImYbsNfeS+cbpJTlbdawoacZi30k+KVBaf47SqhEfuUR74G KqaLJd4si2m6cl5driwCmk1UBK54DRRaLV7RbRWYu2FIkU3W6B5bDm/lw jy2ncabCi211xuWlA5yZlTtMJeXPD+K8rH8QF9DrKw66kM7SlU/O6Vvzi kH3ATraofr5VHtlz5fvNj8Xtp+iUVddiN7YU6nBgBhX2OxWxbyFz3AqMW tloO+pMzBfrk4KziC8UYORIfDkNr82y6XIGB7IM6pwZQpcFck/GNYzAXb AOK/zXGcFU1F3dF2HDAvS6mDaN0bHSPe6TcIunUFMvs1Az5iJH31J9gSb Q==; X-IronPort-AV: E=Sophos;i="5.20,316,1444647600"; d="scan'208";a="54938162" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe2.UoA.auckland.ac.nz) ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 19 Nov 2015 17:57:06 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Thu, 19 Nov 2015 17:57:06 +1300 From: Peter Gutmann To: Simon Josefsson , "ietf-ssh@netbsd.org" Subject: RE: Curve25519/448 key agreement for SSH Thread-Topic: Curve25519/448 key agreement for SSH Thread-Index: AQHRIkEvKhWpAat3z02TuLI5XWbRcZ6iyMyD Date: Thu, 19 Nov 2015 04:57:05 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B6932A@uxcn10-5.UoA.auckland.ac.nz> References: <87pozjyzxc.fsf@latte.josefsson.org> <87wptntvsn.fsf@latte.josefsson.org>,<87lh9v11ql.fsf@latte.josefsson.org> In-Reply-To: <87lh9v11ql.fsf@latte.josefsson.org> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Simon Josefsson writes:=0A= =0A= >A discussion on CFRG came up recently about checking for the all-zero=0A= >shared secret. Does anyone know if libssh or OpenSSH (or anyone else)=0A= >performs this check? =0A= =0A= I check for too-small values (too many leading zeroes), of which all-zero= =0A= is a special case, as well as a few other oddball things.=0A= =0A= Peter.=0A= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Nov 18 22:13:01 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3BE1A8938 for ; Wed, 18 Nov 2015 22:13:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.585] autolearn=unavailable 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 H6DENiDR2NtG for ; Wed, 18 Nov 2015 22:13:01 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 273BE1A8937 for ; Wed, 18 Nov 2015 22:13:01 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 688F514A1EF; Thu, 19 Nov 2015 06:12:58 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 0D63914A1E5 for ; Thu, 19 Nov 2015 06:12:54 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 6NEh9m1A8wIt for ; Thu, 19 Nov 2015 06:12:52 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id B7B4114A1ED for ; Thu, 19 Nov 2015 06:12:50 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id DA5C74002D; Thu, 19 Nov 2015 07:12:47 +0100 (CET) Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id E7F424000A; Thu, 19 Nov 2015 07:12:45 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Thu, 19 Nov 2015 07:12:45 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: "Mark D. Baushke" Cc: Stephen Farrell , "saag\@ietf.org" , Subject: Re: [saag] potential new wg - curdle... References: <564C5FCC.8080107@cs.tcd.ie> <89505.1447867474@eng-mail01.juniper.net> Date: Thu, 19 Nov 2015 07:12:45 +0100 In-Reply-To: <89505.1447867474@eng-mail01.juniper.net> (Mark D. Baushke's message of "Wed, 18 Nov 2015 09:24:34 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list "Mark D. Baushke" writes: > Given that current implementatons of this informational RFC are using > AEAD_AES_128_GCM and AEAD_AES_256_GCM and all of the standards track > Cipher algorithms use lowercase with '-' as word separators, I would > suggest that 'aes128-gcm' and 'aes256-gcm' may be more appropriate and > that they should NOT be added to the MAC Algorithms Names in IANA. THe openssh way of ignoring the mac negotiation completely, if an aead cipher is negotiated, seems nice and simple. How does it interact with first_kex_packet_follows logic, does that need any clarification (a simple rule is to say that if both sides advertise the same aead cipher as the first cipher, then for first_kex_packet_follows purposes, the mac negotiation is considered successful and correctly guessed)? Not sure if it has a place in the same rfc, but I think a proper specification for use aead is quite inportant. Regards, /niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Nov 18 23:17:49 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3D91A903C for ; Wed, 18 Nov 2015 23:17:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.585] autolearn=ham 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 huSfc2IHzeha for ; Wed, 18 Nov 2015 23:17:46 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F29EF1A9035 for ; Wed, 18 Nov 2015 23:17:45 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id F24AB14A1EE; Thu, 19 Nov 2015 07:17:42 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 9D01414A1ED; Thu, 19 Nov 2015 07:17:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 766F114A15C for ; Thu, 19 Nov 2015 02:00:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id aCz7D7QxfiNE for ; Thu, 19 Nov 2015 02:00:05 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id D1CF914A13B for ; Thu, 19 Nov 2015 02:00:05 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for ietf-ssh@netbsd.org; Thu, 19 Nov 2015 01:59:41 +0000 Date: Thu, 19 Nov 2015 01:59:41 +0000 Subject: Re: Curve25519/448 key agreement for SSH X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <427557228-1432@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: ietf-ssh@netbsd.org Cc: Simon Josefsson Content-Type: multipart/alternative; boundary="=-TDopGbXkxK0uGabPa1Ba" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-TDopGbXkxK0uGabPa1Ba Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Regarding the check, it seems to me that SSH has an advantage over TLS, in = that it includes hashes of negotiation content in the key exchange. Therefo= re, perhaps SSH is not as vulnerable to attacks of this type (such as the T= riple Handshake attack in TLS). It still seems a better practice to check than not to check, though, just i= n case foresight is not 20/20. Surely, if the value is zero, the other part= y is sabotaging the key exchange (chances of this occurring randomly are as= tronomically close to zero). If the other party is sabotaging key exchange,= it's doing this for some reason. I'm not sure that we need to know the rea= son in order to refuse to cooperate. ----- Original Message ----- From: Simon Josefsson=20 Sent: Wednesday, November 18, 2015 14:39 To: ietf-ssh@netbsd.org=20 Subject: Re: Curve25519/448 key agreement for SSH This is another update, clarifying the encoding issue a bit further and improving language (thank you Denis). =C2=A0 https://tools.ietf.org/html/draft-josefsson-ssh-curves-02 A discussion on CFRG came up recently about checking for the all-zero shared secret.=C2=A0 Does anyone know if libssh or OpenSSH (or anyone else) performs this check?=C2=A0 Not doing that has apparently led to real securi= ty problems.=C2=A0 For more background, see: =C2=A0 http://thread.gmane.org/gmane.ietf.irtf.cfrg/6228 Thoughts on whether we should add a MUST to require checking the derived secret for the all-zero value? /Simon = --=-TDopGbXkxK0uGabPa1Ba Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Regarding the check, it seems to me that SSH has a= n advantage over TLS, in that it includes hashes of negotiation content in = the key exchange. Therefore, perhaps SSH is not as vulnerable to attacks of= this type (such as the Triple Handshake attack in TLS).

It still se= ems a better practice to check than not to check, though, just in case fore= sight is not 20/20. Surely, if the value is zero, the other party is sabota= ging the key exchange (chances of this occurring randomly are astronomicall= y close to zero). If the other party is sabotaging key exchange, it's doing= this for some reason. I'm not sure that we need to know the reason = in order to refuse to cooperate.


----- Original Message -----From: Simon Josefsson
Sent: Wednesday, November 18, 2015 14:39
To: = ietf-ssh@netbsd.org
Subject: Re: Curve25519/448 key agreement for SSH
This is another update, clarifying the encoding issue a bit further a= nd
improving language (thank you Denis).

  https://tools.iet= f.org/html/draft-josefsson-ssh-curves-02

A discussion on CFRG came u= p recently about checking for the all-zero
shared secret.  Does any= one know if libssh or OpenSSH (or anyone else)
performs this check? = ; Not doing that has apparently led to real security
problems.  For= more background, see:

  http://thread.gmane.org/gmane.ietf.irt= f.cfrg/6228

Thoughts on whether we should add a MUST to require chec= king the derived
secret for the all-zero value?

/Simon

= --=-TDopGbXkxK0uGabPa1Ba-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Nov 19 09:15:18 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8468B1B2D0D for ; Thu, 19 Nov 2015 09:15:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585] autolearn=unavailable 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 jI7w8BOBNRQD for ; Thu, 19 Nov 2015 09:15:17 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DDC61B2CFF for ; Thu, 19 Nov 2015 09:15:17 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 3FEBD14A202; Thu, 19 Nov 2015 17:15:16 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 89BFC14A1FE for ; Thu, 19 Nov 2015 17:15:11 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id wYNb6w8M4PpU for ; Thu, 19 Nov 2015 17:15:10 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0748.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:748]) by mail.netbsd.org (Postfix) with ESMTP id 6EBD214A14F for ; Thu, 19 Nov 2015 17:15:09 +0000 (UTC) Received: from BLUPR05CA0046.namprd05.prod.outlook.com (10.141.20.16) by BN3PR0501MB1378.namprd05.prod.outlook.com (10.160.117.12) with Microsoft SMTP Server (TLS) id 15.1.331.20; Thu, 19 Nov 2015 16:59:44 +0000 Received: from BN1AFFO11FD022.protection.gbl (2a01:111:f400:7c10::152) by BLUPR05CA0046.outlook.office365.com (2a01:111:e400:855::16) with Microsoft SMTP Server (TLS) id 15.1.331.20 via Frontend Transport; Thu, 19 Nov 2015 16:59:44 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.17) by BN1AFFO11FD022.mail.protection.outlook.com (10.58.52.82) with Microsoft SMTP Server (TLS) id 15.1.325.5 via Frontend Transport; Thu, 19 Nov 2015 16:59:43 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 19 Nov 2015 08:59:42 -0800 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id tAJGxcD18982; Thu, 19 Nov 2015 08:59:39 -0800 (PST) (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 53A021144F; Thu, 19 Nov 2015 08:59:38 -0800 (PST) To: Niels =?us-ascii?Q?=3D=3Futf-8=3FQ=3FM=3DC3=3DB6ller=3F=3D?= CC: Stephen Farrell , "saag@ietf.org" , Subject: Re: [saag] potential new wg - curdle... In-Reply-To: References: <564C5FCC.8080107@cs.tcd.ie> <89505.1447867474@eng-mail01.juniper.net> Comments: In-reply-to: Niels =?us-ascii?Q?=3D=3Futf-8=3FQ=3FM=3DC3=3DB6lle?= =?us-ascii?Q?r=3F=3D?= message dated "Thu, 19 Nov 2015 07:12:45 +0100." From: "Mark D. Baushke" MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Nov 2015 08:59:38 -0800 Message-ID: <89694.1447952378@eng-mail01.juniper.net> X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1;BN1AFFO11FD022;1:Ox0+zLqd/g7Gf3fM8BZthc7BT3xbpZGbLsnC9ENHiH74ZZiAFPSjP5no+9c+jPlBKshclkEp+6h8sv/tr+z8JUEjQJHvSJ5kQNIH3LGV0zMX77gLYiezGQAXIuSGDP/2+3C0EXxqYhQlg7PyEZAhVVzKgK+J9k22DPKcEBcp327UZI+w3LlEig80uQTbKIZcqpeBNNXfkKl9eYU/osGwIh2loeZvRdseGOJzI9kL+H5WJRcP1ZtECUTW/AAsUgqXsy54hGRd5+o5mdUtmd14eJGd9l8CgiBP8NjrEQwQlwU0RVIl3aAwOx01e0XRZsCzG7RReI7+WVy9Au9mGgT/5vrCf5BJa3TWZ3+9IZN2oTFdCOxjKjQh905MYHo291K7JopkGdIa/3HBA26gvjZQ5ak4RkZoLkr4EPBcCkiyVjQ= X-Forefront-Antispam-Report: CIP:66.129.239.17;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(2980300002)(199003)(189002)(164054003)(2950100001)(19580395003)(6806005)(19580405001)(5001960100002)(76176999)(106466001)(50986999)(117636001)(54356999)(92566002)(110136002)(86362001)(53416004)(105596002)(47776003)(189998001)(87936001)(76506005)(586003)(23676002)(5003600100002)(11100500001)(97736004)(77096005)(81156007)(50466002)(69596002)(5007970100001)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:BN3PR0501MB1378;H:p-emfe01a-sac.jnpr.net;FPR:;SPF:SoftFail;PTR:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BN3PR0501MB1378;2:vrQjLkNYG0aOji9vcHvB15XFmBgoq5+yT3V6uvS+f226I1yCbmALNZjl0Zmm++q1RyinNJl0BFYX1vSETg0ZKiQFBX/xDiyyZtS2mLagZC2CxgK2RhdxZBQ3GpgwvB0Xyf9wo+jLBn+wU2uVkVQUsA==;3:WUx5FNu+XDGkiOage1QjfMBihXSMgnRXrmYDGrz37lNtZ87poebSb5b/CU0DLmsa8S8PVNv4ZwsWl6s8qN0n6LTPEHOAnjyWWo0IRUV8Y0gJq4HgenVuV/8e+KoPd99+bwYH86eUHNBt7iqGPs6ghAz5SJimJ4RmTuYGIDsihgLGR6d/mF4liH0/16HWao3lUoMPm9+jozTBWht2N+AiOQQG4VSy/2v/eK0dljhLZpc=;25:5xA3BARHg7TQDyGzhQR55V+TKj/6HB51VLycvroXUan8AYe+xsNh/lY08KIGUi4vz+gBdsfPrJFoC3yQ3OCXHwLzWBUD5JmxWsrqkL4ZZYRsDFOdTKCXp7a850+jdyW68rG0snUOQtn/0je88gLzH1il9IDZM6h0oi8QzYL2dlmblrh/F5T/b4aKM6W1jWldwqTpCKfO5pnaV6PWH5hTaT5WHBBypkdOONKWIbCMSOArwERqipFJL0xoSbxcpcSIwLz6PIwA726t1j1Hxa6kyA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1378; X-Microsoft-Exchange-Diagnostics: 1;BN3PR0501MB1378;20:m41o9RoGt921dy8UCSUybpW6qUG9Kp5+WucGhwvK/jV3iFotaMXqchJLE3X10wr8yS5+aeQ8UKNErH6m+/gWfF53NVGiBu/NImfLSeZmPUo64zeu/o8jkmmwfnekFYWkgrCEQwwyqsmtnQYMJlVBWwewwU4JkYvW/MZn5hPcsHdbEZjLLvQoTaYV+FdsTnayomnMHgzChpGpM+yJ2BW0l7BYNXGSGmWf1PlwEXdVMscrHBGZH5j0H5Afg9375l2xYoRolMXb5s5P9M95/aMowm5MgK/938jvWdLPfgvhVGn9WnBZZIwviKNVLFZ+c6fsPLN1pGP81Lt05/zbCdCqOR/e8hOQbGacO/yMhUXdDGrZAbd5ib4FyO1svcQ655t80PYrl3E9CORrGfPIJyew+NdIKHaQSEvlYRr62VnRE0DqmrBWz4X9wkC2qHCr8q6z6Gniy1DjeeCAl9BW7t+WB30uwhzhkJinH/k9Uf8FeX8ZWwW2ZAcScgZOEFlWRWWr;4:AyUOwhjIlyo8w3d9Yz1QPkWENkwzfniXqzL2+lOckz1fSh6rLwfYl2GqbW5ev8KITEAbONTyp4h2aPek68VbT9OW4TQRJnUbKdDhh6OEeYaFVz1gYEHiBpYqy8hK9RSXdrIarxW1m0of3UKG9UK8m4wnDjmhEBgsro+M11w1f8uviWpfCw228UKONWiTA3x44WcFimasdLtjy3NNVrmOtsZAlIw7HxAyMEkHaJpUD3PsFz0I1hKKtnRPoxuyu/NeyCxurgzxTnBVEATbtfuDCHZaM3pDw59u8WQZcy9ae2/nJ9Bpad+b106owRup+/1Mypouhd3+6TZ1FELpV3SlDAN+ftZuei9oM4P+NwJUPZJiltSp26oJUnmiIZjaJKOCD7xqVcrL6VS297IwGKQ5JeRxYvP6kFXigjjMvwn30wx0NdVePl4fIq9q6Ioh9Q0I X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001);SRVR:BN3PR0501MB1378;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1378; X-Forefront-PRVS: 07658B8EA3 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjNQUjA1MDFNQjEzNzg7MjM6RzFkVXhsTU5xTGFKVUcwaEJwMFVIeDFV?= =?utf-8?B?bE9kMzBFaWphRVBSMFkwcGl6QUIxeExhTEV3OWFaQkh1RTBoeU92SDJBQTU2?= =?utf-8?B?QUg3M09WQmRwL1JkbmU5bEZLSnlMTnEzd0FrN1RjcDNUeGo4SkhGS3dQTmxr?= =?utf-8?B?YkUyR2IvMnVQUzgrRnlqWWhDblhCWldYdi84NEwrU3dESjNCNGlnQXViSDZZ?= =?utf-8?B?dkEvMUFtMzJld0toYWM5SEErNGJtUmJTUnFiNGw1V3kvVzArQjdmK2tIVkZV?= =?utf-8?B?YlI5Zlc3YlFMV0ZzeG1UUE1UMnBNVXhISFEwdmFpdjRUSEl4eGdVak90MXE3?= =?utf-8?B?RWNWWlhZU29WOE55cEJXdVdRRS9KbmRhZHRaL0dla25SV0hoUHdLWUJkQzZE?= =?utf-8?B?NFR2UDM3WkZkZ2I4RXBRMlVRYlpMNWwvUEd2aHRXUDJuRlBMYTN3QnoxWHVM?= =?utf-8?B?Ry9MUU5GcnlSQ2Ywc1NQR2FyejgrdWk3Um5HT2JRVDBoUGhzUGpaSDZLOGtH?= =?utf-8?B?Z1NnTjcxODBub0lodVc3enVOczZ0Vk0ra2lqZ21VOUdBTVlyQ3JDc0xJSzZz?= =?utf-8?B?K25XYnVxWEtCVmR5MzRlc3JNa0xHV2l6UW9JMXNGYjlkUHpwaGZJN3plUVBO?= =?utf-8?B?MTBPSVVzaXRrS2hvaWpxZUhLQStBU0UwZnZobDdDS1p6a05sWnArYzBaOUFV?= =?utf-8?B?NGFpMGpXdTBLQmYzUnJkaHRnejU4S21FNHU3S1lZUFVrRFlPZVYzdUkwOW9v?= =?utf-8?B?OXRXc0JNQVkzclNtNXB3RFdRNGJxc29Kbmw5NXVBdXgyWm9PYjJTUlpmd3Uv?= =?utf-8?B?OS83WEFBWlZIMDJxYWJTYzcvSTYwTWZTQWlEd0h6eHFnMDRDZXlpU0RRODZi?= =?utf-8?B?NkFHVHQ0S2RJODE3cGVBZVZyWC8zSFRWcmZ0Q0Y0Y21XUjM5TEl5Y2tuZlQ5?= =?utf-8?B?ZFNYVnJUeHlIY2pDVTVPSDB3czVWbXR5bDZRbkM2d2g4cGduRXdEWmtsQTVx?= =?utf-8?B?Um9vNExpUkFCZUN2dUEyWVZaR1dDOWZRbFh0ZHliZmUyMDJaUFZXalU2Sjdu?= =?utf-8?B?ZUJpVTVlTmJ4bVhhbzFoRHBVaUdmd3BSNW1KalplYW8xMDNaR2RLblVsZm9u?= =?utf-8?B?MEVsR1VHVXlFOVRGeXgyNng0NTF6MWpDS0FDTWc3SHdqV01wOTFNK1Q0SXZR?= =?utf-8?B?alFVOUV2enRsOEFvZ041bTdJNUYxWlRHYkh2Zm1wcUZYNE0wQi9ITDF4bmhx?= =?utf-8?B?cWpOMVhwRUNyYWs1Qlp4Q2RFZTZnK2ZsMmRCZGhBVzByZm42M2V0bmNsaG51?= =?utf-8?B?ZXpZQ0Y3UUpnbTQrQT09?= X-Microsoft-Exchange-Diagnostics: 1;BN3PR0501MB1378;5:YNqN1nqQfC5QNlX6tNbqUBj38CSogT60G0r6PpPPto6QLLVdjjtDzzgpmxG1G3Augsk+TgoScTPin+28cmIerWHsruKSHbSd4HnwVkKPZiXVZbIgMb9z2tqEYsRWxrYiHS7Ca4FYrQSPaGudO0ZMVw==;24:lfQ+AvqjljWOxtph0ezWjQSQ8lNi7kzdWayWD0PEmY2mRqqjatprHjrM5TEi+SlcwhnipfCtTXuhZ/P9QrpZxYbf4ePWH0XPYGNgit5fcfs= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Nov 2015 16:59:43.6334 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.17];Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1378 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Niels M=C3=B6ller writes: > "Mark D. Baushke" writes: >=20 > > Given that current implementatons of this informational RFC are using > > AEAD_AES_128_GCM and AEAD_AES_256_GCM and all of the standards track > > Cipher algorithms use lowercase with '-' as word separators, I would > > suggest that 'aes128-gcm' and 'aes256-gcm' may be more appropriate and > > that they should NOT be added to the MAC Algorithms Names in IANA. >=20 > THe openssh way of ignoring the mac negotiation completely, if an aead > cipher is negotiated, seems nice and simple. How does it interact with > first_kex_packet_follows logic, does that need any clarification (a > simple rule is to say that if both sides advertise the same aead cipher > as the first cipher, then for first_kex_packet_follows purposes, the mac > negotiation is considered successful and correctly guessed)? I am not sure that first_kex_packet_follows would guess properly because the first listed algorithm must be the same on both sides and I am not sure that will be true very often given the number of different host key algorithms that exist. > Not sure if it has a place in the same rfc, but I think a proper > specification for use aead is quite inportant. Okay. Thanks, -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Nov 20 02:51:22 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 152211B2D5F for ; Fri, 20 Nov 2015 02:51:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.585] autolearn=unavailable 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 JacM3Kh4vMzA for ; Fri, 20 Nov 2015 02:51:21 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AE1A1B2D5D for ; Fri, 20 Nov 2015 02:51:21 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 420AC14A23B; Fri, 20 Nov 2015 10:51:20 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id E423D14A23A for ; Fri, 20 Nov 2015 10:51:16 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id P0MYZd7b9XXG for ; Fri, 20 Nov 2015 10:51:16 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 98D9514A238 for ; Fri, 20 Nov 2015 10:51:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1448016675; x=1479552675; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=H7vdiTMYgkiKsqvZYQagtHi7q/gkjBex/8PTOBTQue0=; b=ASSDx8ul8LsUE1fBF3kGcwwIvLrPVs9uIYQoWmKwQg5ClUbMH5zGy1w7 iBJvg2wuhIQOdEGAQ2xLyH0Dv77jNbUe1R5U0ra75tHS6+5T55zklY+ce kMTO6YNh2HCRmxLKOK2afnIzHW2uKrMLBa8KKozxOSeueJUQxIg/KLdYu 76x3m75mGFjbrXhzCQIwmIq2gkDpot1RCUcsDuore5SAxKkSq9qJzU5FJ t2LdqSiu59SbQVLzCF/EyCn3H5axeIP6F8MCWQ+d89XmMSc6ojK7TW2EK aUt8wQUUi0OJ6eeMgxBJjhfqN6X+ErpXPCLIFUmKt3RoGdl+I+t6RoSRL Q==; X-IronPort-AV: E=Sophos;i="5.20,321,1444647600"; d="scan'208";a="55197602" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe4.UoA.auckland.ac.nz) ([130.216.4.171]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 20 Nov 2015 23:51:09 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Fri, 20 Nov 2015 23:51:09 +1300 From: Peter Gutmann To: "Mark D. Baushke" , =?iso-8859-1?Q?Niels_M=F6ller?= CC: "ietf-ssh@NetBSD.org" , "saag@ietf.org" Subject: RE: [saag] potential new wg - curdle... Thread-Topic: [saag] potential new wg - curdle... Thread-Index: AQHRIpFOlpipP2MZvkGbJ40Yn5ajpZ6jklENgAEqGXU= Date: Fri, 20 Nov 2015 10:51:07 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B6AA52@uxcn10-5.UoA.auckland.ac.nz> References: <564C5FCC.8080107@cs.tcd.ie> <89505.1447867474@eng-mail01.juniper.net> ,<89694.1447952378@eng-mail01.juniper.net> In-Reply-To: <89694.1447952378@eng-mail01.juniper.net> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Mark D. Baushke writes:=0A= =0A= >I am not sure that first_kex_packet_follows would guess properly because t= he=0A= >first listed algorithm must be the same on both sides and I am not sure th= at=0A= >will be true very often given the number of different host key algorithms= =0A= >that exist.=0A= =0A= How widely is first_kex_packet_follows used in practice? That's another th= ing=0A= I'd like to see deprecated in any future changes (see the SimpleSSH proposa= l I=0A= mentioned a week or so back), it vastly complicates the handshake when you= =0A= have to guess at things and potentially roll back to the previous state and= =0A= try again. Best-case if you've got identical, identially-configured=0A= implementations at both ends you save a whole RTT, but more common case you= =0A= have a lot of extra complexity and overhead as you roll back from the=0A= incorrectly-guessed keyex and try again.=0A= =0A= Peter.=0A= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 23 16:12:55 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 428461B29AB for ; Mon, 23 Nov 2015 16:12:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.215 X-Spam-Level: X-Spam-Status: No, score=0.215 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.585] autolearn=ham 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 IdAj96JocTUu for ; Mon, 23 Nov 2015 16:12:53 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF0421B29AA for ; Mon, 23 Nov 2015 16:12:53 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 8FC0314A205; Tue, 24 Nov 2015 00:12:51 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 426EF14A1FF for ; Tue, 24 Nov 2015 00:12:47 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id T7bHJcfTg7V2 for ; Tue, 24 Nov 2015 00:12:46 +0000 (UTC) Received: from newmailhub.uq.edu.au (mailhub2.soe.uq.edu.au [130.102.132.209]) by mail.netbsd.org (Postfix) with ESMTP id 56E1114A145 for ; Tue, 24 Nov 2015 00:12:42 +0000 (UTC) Received: from smtp1.soe.uq.edu.au (smtp1.soe.uq.edu.au [10.138.113.40]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id tAO0CKV6025875; Tue, 24 Nov 2015 10:12:22 +1000 Received: from mailhub.eait.uq.edu.au (hazel.eait.uq.edu.au [130.102.60.17]) by smtp1.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id tAO0CKgx020237 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Nov 2015 10:12:20 +1000 Received: from natsu.mindrot.org (natsu.mindrot.org [130.102.96.2]) by mailhub.eait.uq.edu.au (8.15.1/8.15.1) with ESMTP id tAO0CKrk030238; Tue, 24 Nov 2015 10:12:20 +1000 (AEST) Received: by natsu.mindrot.org (Postfix, from userid 1000) id 46E0CA4F2F; Tue, 24 Nov 2015 11:12:20 +1100 (AEDT) Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id 46413A4F2E; Tue, 24 Nov 2015 11:12:20 +1100 (AEDT) Date: Tue, 24 Nov 2015 11:12:20 +1100 (AEDT) From: Damien Miller To: Simon Josefsson cc: ietf-ssh@netbsd.org Subject: Re: Curve25519/448 key agreement for SSH In-Reply-To: <87lh9v11ql.fsf@latte.josefsson.org> Message-ID: References: <87pozjyzxc.fsf@latte.josefsson.org> <87wptntvsn.fsf@latte.josefsson.org> <87lh9v11ql.fsf@latte.josefsson.org> User-Agent: Alpine 2.20 (BSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub X-Scanned-By: MIMEDefang 2.75 on 130.102.60.17 X-UQ-FilterTime: 1448323942 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Wed, 18 Nov 2015, Simon Josefsson wrote: > This is another update, clarifying the encoding issue a bit further and > improving language (thank you Denis). > > https://tools.ietf.org/html/draft-josefsson-ssh-curves-02 > > A discussion on CFRG came up recently about checking for the all-zero > shared secret. Does anyone know if libssh or OpenSSH (or anyone else) > performs this check? Not doing that has apparently led to real security > problems. For more background, see: > > http://thread.gmane.org/gmane.ietf.irtf.cfrg/6228 > > Thoughts on whether we should add a MUST to require checking the derived > secret for the all-zero value? OpenSSH performs the all-zero check https://anongit.mindrot.org/openssh.git/tree/kexc25519.c?id=8ca915fc761519dd1f7766a550ec597a81db5646#n69 I think it should be a MUST. -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Nov 25 15:06:01 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF89B1B323D for ; Wed, 25 Nov 2015 15:06:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585] autolearn=ham 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 S08Fqkwq0SJD for ; Wed, 25 Nov 2015 15:06:00 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FB201B324E for ; Wed, 25 Nov 2015 15:06:00 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 31CD614A1F3; Wed, 25 Nov 2015 23:05:57 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id EEA9E14A1EB for ; Wed, 25 Nov 2015 23:05:53 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id MxQFrKdRoqfr for ; Wed, 25 Nov 2015 23:05:53 +0000 (UTC) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 0A12314A1E9 for ; Wed, 25 Nov 2015 23:05:50 +0000 (UTC) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id tAPN5ZTQ004955 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 26 Nov 2015 00:05:36 +0100 From: Simon Josefsson To: ietf-ssh@netbsd.org Subject: Re: Curve25519/448 key agreement for SSH References: <87pozjyzxc.fsf@latte.josefsson.org> <87wptntvsn.fsf@latte.josefsson.org> <87lh9v11ql.fsf@latte.josefsson.org> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:151125:djm@mindrot.org::RR15F51UVAZTINGR:3RU/ X-Hashcash: 1:22:151125:ietf-ssh@netbsd.org::x9/rxB1fshHlsr9A:5zJh Date: Thu, 26 Nov 2015 00:05:34 +0100 In-Reply-To: (Damien Miller's message of "Tue, 24 Nov 2015 11:12:20 +1100 (AEDT)") Message-ID: <878u5ly91d.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I have submited -03 which adds a MUST check for the all-zero secret, and clarifies the mpint conversion further -- a reference to section 5 of RFC 4251 is added which explains this properly. Unfortunately, 4251=A75 doesn't say that mpint's are prepended by an uint32 with the length of the data (or the example is wrong). Please holler if implementations do not have the uint32 in the mpint that is hashed, or generally if you believe the new section 2.1 could be clarified further. https://tools.ietf.org/html/draft-josefsson-ssh-curves-03 /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWVj6+AAoJEIYLf7sy+BGd9ysH/RRpKVIJkrLRVRk1fdsIqVX0 KvVisPW6PJVafiKXYm5T3Ggw7AFAzEoYlYmy/WbSR8ovE9ZZBvqXwMvPo4xGmTh7 n//W7PoQWtC/ZtunvtawpsTYd+mY/SGLeR3qV6ZsJMX+f0C//dd2G/75RVrNvyV/ 0ACPibWStT2ZlDVFFPkvdvZXv/xFJ8itUXpeB/wP8mfeVTr8vE/jDey+cjlbtI4l 1ycdlPqd4hnLruduPNr5E55vCdA0BdG2cnAe/hHAs4c93ON0kP5/OF9NiswWeuLv Fb7NrWUrcDnYeuMdJ5M/iibYNrikmGO9VVG+ws06xRlrUuqvddtg1B88Z/y+Y88= =r+as -----END PGP SIGNATURE----- --=-=-=-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Nov 25 15:33:16 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63CD61B328B for ; Wed, 25 Nov 2015 15:33:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585] autolearn=ham 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 T1AeTgVU-Qae for ; Wed, 25 Nov 2015 15:33:15 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E686B1B3289 for ; Wed, 25 Nov 2015 15:33:14 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 4306614A24E; Wed, 25 Nov 2015 23:33:13 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id B596A14A0D8 for ; Wed, 25 Nov 2015 23:33:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id d30waiMHmq1x for ; Wed, 25 Nov 2015 23:33:04 +0000 (UTC) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 6E8D614A0BB for ; Wed, 25 Nov 2015 23:33:03 +0000 (UTC) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id tAPNWdxG007299 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 26 Nov 2015 00:32:40 +0100 From: Simon Josefsson To: denis bider Cc: ietf-ssh@netbsd.org Subject: Re: Curve25519/448 key agreement for SSH References: <1023314969-1152@skroderider.denisbider.com> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:151125:ietf-ssh@netbsd.org::1d3aQm6hy+6RA8Ze:AbaO X-Hashcash: 1:22:151125:ietf-ssh3@denisbider.com::sC7SAzN/By7rgeOy:Fr7o Date: Thu, 26 Nov 2015 00:32:38 +0100 In-Reply-To: <1023314969-1152@skroderider.denisbider.com> (denis bider's message of "Wed, 25 Nov 2015 23:21:07 +0000") Message-ID: <874mg9y7s9.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable denis bider writes: > What do you find ambiguous about the definition of mpint in RFC 4251? It = states: > > "Represents multiple precision integers in two's complement format, store= d as a string" > > That's a reference to the SSH string type defined immediately before mpin= t, which defines its encoding as uint32 length + data. > > I think this is fairly unambiguous? Furthermore, any implementation > that has different ideas will already be incompatible with others. Thanks for precise pointer! I didn't register the importance of the word "string" here, and was looking for the "uint32" keyword. Ok no problem then. Btw, one of the changes between -02 and -03 is related to this, before it said that K and X often will be identical, but I don't believe that is ever the case since K have the 4-byte prefix. I hope -03 is clearer on this. /Simon > > ----- Original Message ----- > From: Simon Josefsson=20 > Sent: Wednesday, November 25, 2015 17:05 > To: ietf-ssh@netbsd.org=20 > Subject: Re: Curve25519/448 key agreement for SSH > > I have submited -03 which adds a MUST check for the all-zero secret, and > clarifies the mpint conversion further -- a reference to section 5 of > RFC 4251 is added which explains this properly.=A0 Unfortunately, 4251=A75 > doesn't say that mpint's are prepended by an uint32 with the length of > the data (or the example is wrong).=A0 Please holler if implementations do > not have the uint32 in the mpint that is hashed, or generally if you > believe the new section 2.1 could be clarified further. > > https://tools.ietf.org/html/draft-josefsson-ssh-curves-03 > > /Simon > --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWVkUWAAoJEIYLf7sy+BGd2EAH+gLx6Htocja8nZc1V/ibcdTp lIpcsgyaEceCjvuY2lqVE/+8HlecVKLxMGPTeh9E04Hpp+vMIopca+nLvo39rrq0 7SqTlE31umeifZxnhFg9ebTzvN+2yoKudMV5XeB1l4nSn+Awh4ugt3XpFMaT21ne aZEhQlrLQ85TOE1xfn4TALx9cYKBzXr5/rexlZqtBk5vofsYeQ/0799ZbUKyqfvh l7g5dlg11X6yt6zQyAgLrOQwRyajOL1oWGnhpu5ju6s4rDM4YBR3fnZfFTfjXEUH VqttXhA50mySD7qxthRM681NWmdRRT6C/qBwwUH92XzVhovaMU5rAE6KqRQjx3o= =DQ75 -----END PGP SIGNATURE----- --=-=-=-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Nov 26 02:09:30 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0A6C1B3809 for ; Thu, 26 Nov 2015 02:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585] autolearn=ham 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 xUn0gVdsmrWT for ; Thu, 26 Nov 2015 02:09:28 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9E421A036A for ; Thu, 26 Nov 2015 02:09:28 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id CF1FF14A1C8; Thu, 26 Nov 2015 10:09:26 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 7D28314A1C5 for ; Thu, 26 Nov 2015 10:09:18 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id jLQEm6XI6ypV for ; Thu, 26 Nov 2015 10:09:17 +0000 (UTC) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 4F93814A1B7 for ; Thu, 26 Nov 2015 10:09:15 +0000 (UTC) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id tAQA8x8V003857 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 26 Nov 2015 11:09:01 +0100 X-Hashcash: 1:22:151126:ietf-ssh@netbsd.org::uFUF5vmXLBNMMeDE:UN7l From: Simon Josefsson To: ietf-ssh@netbsd.org Subject: ChaCha20-Poly1305 for SSH OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt Date: Thu, 26 Nov 2015 11:08:59 +0100 Message-ID: <87egfdxebo.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-=-= Content-Type: text/plain Hi. I've taken Damien writeup on Damien/Markus's chacha20-poly1305@openssh.com and put that into an IETF draft: https://tools.ietf.org/html/draft-josefsson-ssh-chacha20-poly1305-openssh-00 There have been some offlist conversation about how to move forward with this in the IETF. The challenge is that the construct differs from the ChaCha20-Poly1305 construct used in RFC 7539. To have something to start IETF discussions, I thought it would be useful to have the OpenSSH-specific construct described in a draft. We could turn this into an IETF blessed approach by stripping "@openssh.com" and register that with IANA, similar to what is done for curve25519. We could also describe a new SSH encryption algorithm that is based on the RFC 7539 construct. Still using ChaCha20-Poly1305, of course, but it would work differently. As far as I understand, the critical technical difference between these approaches is whether encrypting the length field is useful or not. I'm told that encryption the field is of limited use because traffic analysis would see the packet lengths anyway. Regardless of whether it is useful to do this, I believe it would be a bad idea to push something in IETF that SSH implementers aren't interested in implementing. So if we do something other than stripping @openssh.com I believe we will need to build consensus for doing that among implementers first. For consistency and simplicity of algorithm description, I do want to see a RFC 7539 based approach explored though, and we may end up writing a different draft on that. If you are an SSH implementer that supports chacha20-poly1305@openssh.com, are you interested in implementing support for a more streamlined variant that would lack encryption of the length field? Does anyone see a strong need for encrypting the length field? /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWVto7AAoJEIYLf7sy+BGdsEEH/jfC46yqTqYlFipZ5E1EoaVm A7yd+MbpvUeZbK1WxlPVh7IwGQDtYLR9jC4pqUl4i7zeHo3nPnb8CChs+M2r2fVZ nESjweZjW8o+Kwn/og+3Ir/bJFUs7o+9sOCkwtdnGamG/jCdh/MjLe9xmbBYwGea sTVzC/z9lI8TLZv+ntLyN2ae8FwHpTA+gxs3Owbc67y33GU8EUcL+VoeXnGQyEyR BulsYBa+TtOR7LVNlGydR8Ace84GR58ZXy1zoQM5Lksfj7LcgpfRHWKiiZCtbIJP zWJ4dh6hYb5EKm8Vv7I/L5BCDyomiHW3n4T0UyK6ga7XthVzIW02jpBpitBXjtM= =/QY/ -----END PGP SIGNATURE----- --=-=-=-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Nov 26 07:44:34 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 252FD1B3B69 for ; Thu, 26 Nov 2015 07:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.585] autolearn=ham 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 3NGt_4rkDH9D for ; Thu, 26 Nov 2015 07:44:32 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CB8A1B3B36 for ; Thu, 26 Nov 2015 07:44:32 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 3953814A18F; Thu, 26 Nov 2015 15:44:29 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 20DA214A18E for ; Thu, 26 Nov 2015 15:44:24 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id TP5IC8-5hRT8 for ; Thu, 26 Nov 2015 15:44:23 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 3977914A14B for ; Thu, 26 Nov 2015 15:44:21 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 911C840027; Thu, 26 Nov 2015 16:44:18 +0100 (CET) Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id 710964000B; Thu, 26 Nov 2015 16:44:17 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Thu, 26 Nov 2015 16:44:17 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: Simon Josefsson Cc: ietf-ssh@netbsd.org Subject: Re: ChaCha20-Poly1305 for SSH References: <87egfdxebo.fsf@latte.josefsson.org> Date: Thu, 26 Nov 2015 16:44:17 +0100 In-Reply-To: <87egfdxebo.fsf@latte.josefsson.org> (Simon Josefsson's message of "Thu, 26 Nov 2015 11:08:59 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Simon Josefsson writes: > We could also describe a new SSH encryption algorithm that is based on > the RFC 7539 construct. Still using ChaCha20-Poly1305, of course, but > it would work differently. > > As far as I understand, the critical technical difference between these > approaches is whether encrypting the length field is useful or not. It also uses a different formatting of the poly1305 input, which aligns the poly1305 blocks with the chacha blocks. Which should be beneficial in particular for hardware implementations. > I'm told that encryption the field is of limited use because traffic > analysis would see the packet lengths anyway. I don't think that analysis is correct. (See below). Nevertheless, I think it makes sense to use the rfc 7539 construction. So my suggestion is to go with rfc 7539, and in addition, encrypt the length field by something lietk encrypt_length(key, nonce, length) counter =3D 0 block =3D chacha20_block(key,counter,nonce) return block[32..35] ^ length end using the same key and nonce as input as with poly1305_key_gen in RFC 7539. (It's then possible, but not at all necessary, to generate the poly1305 key and encrypt the length key using a single call to chacha20_block. In contrast to chacha20-poly1305@openssh.com, which, iirc, uses a separate chacha key just for encrypting the lengths). Care is needed to specify the negotiation of aead algorithms, and the details of what goes into the associated data. > Does anyone see a strong need for encrypting the length field? Yes. I think it's valuable defence-in-depth to hide packet lengths and message boundaries. Note that in the ssh protocol, the boundaries of the TCP segments need not match the SSH message boundaries at all. It's not too difficult to arrange that most or all segment boundaries are in the middle of an ssh message, using SSH_MSG_IGNORE packets when needed. I won't argue that it is easy to make traffic analysis impossible, but I believe it's still valuable to make traffic analysis harder. Best regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Nov 26 12:42:34 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0911B2EA5 for ; Thu, 26 Nov 2015 12:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.585] autolearn=ham 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 1On8dQ6U1ecS for ; Thu, 26 Nov 2015 12:42:32 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8B8E1B2EA4 for ; Thu, 26 Nov 2015 12:42:32 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 084B014A290; Thu, 26 Nov 2015 20:42:30 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id B361114A28C for ; Thu, 26 Nov 2015 20:42:23 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id W1jSu9vj1dSf for ; Thu, 26 Nov 2015 20:42:22 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 992CE14A267 for ; Thu, 26 Nov 2015 20:42:21 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 4ACD54002E; Thu, 26 Nov 2015 21:42:19 +0100 (CET) Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id 02AAB4001D; Thu, 26 Nov 2015 21:42:17 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Thu, 26 Nov 2015 21:42:17 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: Simon Tatham Cc: Simon Josefsson , ietf-ssh@netbsd.org Subject: Re: Binary packet protocol rethink References: <87egfdxebo.fsf@latte.josefsson.org> <87egfdxebo.fsf@latte.josefsson.org> <1448554180-sup-7145@atreus.tartarus.org> Date: Thu, 26 Nov 2015 21:42:17 +0100 In-Reply-To: <1448554180-sup-7145@atreus.tartarus.org> (Simon Tatham's message of "Thu, 26 Nov 2015 16:41:26 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Simon Tatham writes: > Is there any possible way - and would people be interested in pursuing > it if there were - to invent a replacement binary packet protocol for > SSH which decouples the unit of encryption and the unit of protocol > semantics into completely separate layers? I think it's interesting to explore, but I'm not sure it's possible to get it much better than the ssh protocol with careful use of IGNORE packets. The problem is the interactivity. Let's consider the simplest example (but I'm not saying this example captures all essentials of the problem). Say I let my shell connection idle for some time, then I type a couple of characters, and I want a timely response before I type the next command. Then my typing has to correspond to a TCP segment that can be decrypted and authenticated and passed on to the remote shell. With the current ssh protocol, that TCP segment will carry a single CHANNEL_DATA packet, possibly in combination with fragments of IGNORE messages and possibly other piggybacking messages, e.g., WINDOW_ADJUST. To hide the user's typing from traffic analysis is a tradeoff, with varying amounts of cover traffic (preferably including responses; there's maybe some use for an IGNORE_CONTENTS_BUT_PLEASE_REPLY message type). It's highly desirable to hide details of the user's typing; some reasonable counter measures are to collect keystrokes for a few 100 ms before generating any packet, and use padding to hide the number of keystrokes included in each packet. > And even if you encrypt the length field in a way > that avoids that mistake, you still don't reliably hide your _padded_ > packet lengths anyway, in the face of an active attacker who can proxy > the TCP stream, dribble it out a byte at a time, and wait to see which > byte triggers a response. I suspect some defensive uses of > SSH_MSG_IGNORE may still have this issue. This is a good point which is easy to overlook. The lesson here is that it is better to add the padding data at the start of the TCP segment rather than at the end; the boundary between initial padding and the start of the message is *not* revealed by the dribbel attack. And we should also keep in mind that there are relevant attackers which are only passive eavesdroppers, so a defense which is effective only against passive adverseries but fails with an active adversary still has value. For design of a cryptographic transport protocol, interactivity implies that there has to be some kind of flush/sync mechanism. The input can't be just a cleartext byte stream, it has to be a byte stream with syncronization points. A syncronization point means that data up to that point must be delivered without waiting for further input. So the cryptographic transport protocol must encrypt it, send it out on the wire in a timely manner, and attach an authentication tag and any other signalling needed for the receiver to decrypt, authenticate, and process the data. Which breaks a pure separation between layers. And those synchronization points are going to be revealed by the dribble attack. One possible design would be to make the block of the crypto layer a fixed size, say around 200 bytes, and then to get a synchronization point, just insert an ignore message of at least 200 bytes (possibly with randomized larger size). Probably not a good idea for a general purpose crypto protocol, though. > I've always thought a good way to solve this _in principle_ would be to > replace our current all-in-one message/packet structure with two > independent layers. It's long time since I looked into the details of TLS, but doesn't it have more of this kind of separation? How does it handle the syncronization issue? > Is this an idea that appeals to anyone else? I definitely see the appeal, but I'm a bit skeptic that it can work out. Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Nov 26 21:20:04 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25BEE1AC3C1 for ; Thu, 26 Nov 2015 21:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.286 X-Spam-Level: X-Spam-Status: No, score=-0.286 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.585] autolearn=ham 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 vJ1KUfwZcRfO for ; Thu, 26 Nov 2015 21:20:02 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E8661AC3BF for ; Thu, 26 Nov 2015 21:20:02 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id E8FC814A2BC; Fri, 27 Nov 2015 05:19:59 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 93B0F14A2B9; Fri, 27 Nov 2015 05:19:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 69B1314A27F for ; Thu, 26 Nov 2015 17:52:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id B-HQQ_xbg8XN for ; Thu, 26 Nov 2015 17:52:58 +0000 (UTC) Received: from atreus.tartarus.org (atreus.tartarus.org [80.252.125.10]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 5179D14A267 for ; Thu, 26 Nov 2015 17:52:57 +0000 (UTC) Received: from simon by atreus.tartarus.org with local (Exim 4.69) (envelope-from ) id 1a1zbq-0006VF-UT; Thu, 26 Nov 2015 16:41:27 +0000 Content-Type: text/plain; charset=UTF-8 From: Simon Tatham To: =?utf-8?q?Niels_M=C3=B6ller?= Cc: Simon Josefsson , ietf-ssh@netbsd.org Subject: Binary packet protocol rethink (was: Re: ChaCha20-Poly1305 for SSH) In-reply-to: References: <87egfdxebo.fsf@latte.josefsson.org> <87egfdxebo.fsf@latte.josefsson.org> Date: Thu, 26 Nov 2015 16:41:26 +0000 Message-Id: <1448554180-sup-7145@atreus.tartarus.org> User-Agent: Sup/git Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list > Simon Josefsson writes: >> Does anyone see a strong need for encrypting the length field? Niels Möller wrote: > Yes. I think it's valuable defence-in-depth to hide packet lengths and > message boundaries. Note that in the ssh protocol, the boundaries of the > TCP segments need not match the SSH message boundaries at all. It's not > too difficult to arrange that most or all segment boundaries are in the > middle of an ssh message, using SSH_MSG_IGNORE packets when needed. On that subject, perhaps this is a good moment to re-raise a thing I've been wondering about for ages. Not for immediate consideration as part of any of the current set of RFCs-in-progress, but as a thought for the further future. Is there any possible way - and would people be interested in pursuing it if there were - to invent a replacement binary packet protocol for SSH which decouples the unit of encryption and the unit of protocol semantics into completely separate layers? Handling of packet length fields in SSH has always been tricky, and we've got it wrong several times. The cleartext _unpadded_ lengths in SSH-1 had very obvious flaws; the switch to encrypting the length field as part of the first cipher block in SSH-2 caused an accidental decryption oracle. And even if you encrypt the length field in a way that avoids that mistake, you still don't reliably hide your _padded_ packet lengths anyway, in the face of an active attacker who can proxy the TCP stream, dribble it out a byte at a time, and wait to see which byte triggers a response. I suspect some defensive uses of SSH_MSG_IGNORE may still have this issue. I think all of these problems ultimately arise from the fact that the SSH protocol messages and the encrypted packets are the same thing, so that the lengths of the former (being at least somewhat sensitive data) are at constant risk of being exposed by design flaws in the latter. So I've always thought a good way to solve this _in principle_ would be to replace our current all-in-one message/packet structure with two independent layers. The outer layer would interpret the incoming TCP stream as a series of what I'll refer to as 'encrypted chunks', each consisting of a length, some encrypted data, and a MAC. The validated and decrypted contents of those chunks would be concatenated into a single byte stream, with no remaining trace of the chunk boundaries, and passed on to the inner layer which would break that byte stream up into 'SSH protocol messages'. The inner layer would need no cryptography at all; it could be something very close to SFTP's bare (length,type,data) tuples, except that you'd probably want to make it easy to insert N bytes of padding in between messages for a wide variety of N (perhaps even all N). Then you really could have the length fields of the encrypted chunks be in cleartext, because they wouldn't be telling an attacker anything they couldn't have inferred from the TCP segment boundaries anyway. And at the same time, that would tell you nothing about the SSH message boundaries inside those chunks; you could have one chunk containing many messages, or one message split across many chunks, or chunks ending in mid-message, however the sending implementation saw fit. For concealing the length of a critical message (see past attempts at traffic-analysis defences relating to SSH_MSG_PASSWORD in particular), this would be much better than just squashing two successive messages into the same TCP segment, because now the dribbling attack completely stops working - a receiver isn't going to be replying anyway until the whole encrypted chunk is received, and the proxying attacker already knows when _that_ will happen. There would be no possible way to find out how much of a large chunk corresponded to a particular message without actually breaking the cryptography. Furthermore, by inserting padding at random between messages, it would be trivial to make the starting points of messages within a chunk unpredictable, so that you could make it impossible for an attacker to reliably identify (say) a cipher block containing part of a password. Is this an idea that appeals to anyone else? I've never been entirely sure whether there's any remaining space to introduce it in the current protocol while keeping intercompatibility with existing implementations; but it's only worth trying to solve that problem if anyone else would be interested in pursuing the idea anyway. Cheers, Simon -- for k in [pow(x,37,0x1a1298d262b49c895d47f) for x in [0x50deb914257022de7fff, 0x213558f2215127d5a2d1, 0x90c99e86d08b91218630, 0x109f3d0cfbf640c0beee7, 0xc83e01379a5fbec5fdd1, 0x19d3d70a8d567e388600e, 0x534e2f6e8a4a33155123]]: print "".join([chr(32+3*((k>>x)&1))for x in range(79)]) # -- for k in [pow(x,37,0x1a1298d262b49c895d47f) for x in [0x50deb914257022de7fff, 0x213558f2215127d5a2d1, 0x90c99e86d08b91218630, 0x109f3d0cfbf640c0beee7, 0xc83e01379a5fbec5fdd1, 0x19d3d70a8d567e388600e, 0x534e2f6e8a4a33155123]]: print "".join([chr(32+3*((k>>x)&1))for x in range(79)]) # From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Nov 26 21:21:59 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2561AC3CF for ; Thu, 26 Nov 2015 21:21:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.585] autolearn=ham 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 gTC2j6_5btyP for ; Thu, 26 Nov 2015 21:21:57 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1E351AC3CD for ; Thu, 26 Nov 2015 21:21:57 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 96C8B14A2C2; Fri, 27 Nov 2015 05:21:56 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 41F3514A2C0; Fri, 27 Nov 2015 05:21:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 6143714A1F6 for ; Wed, 25 Nov 2015 23:21:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id ugCo7gIgWnGi for ; Wed, 25 Nov 2015 23:21:42 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id C1F2D14A158 for ; Wed, 25 Nov 2015 23:21:42 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for simon@josefsson.org; Wed, 25 Nov 2015 23:21:07 +0000 Date: Wed, 25 Nov 2015 23:21:07 +0000 Subject: Re: Curve25519/448 key agreement for SSH X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <1023314969-1152@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: Simon Josefsson Cc: ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-EIKNG0hzpRag8EjfWXYI" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-EIKNG0hzpRag8EjfWXYI Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable What do you find ambiguous about the definition of mpint in RFC 4251? It st= ates: "Represents multiple precision integers in two's complement format, stored = as a string" That's a reference to the SSH string type defined immediately before mpint,= which defines its encoding as uint32 length + data. I think this is fairly unambiguous? Furthermore, any implementation that ha= s different ideas will already be incompatible with others. ----- Original Message ----- From: Simon Josefsson=20 Sent: Wednesday, November 25, 2015 17:05 To: ietf-ssh@netbsd.org=20 Subject: Re: Curve25519/448 key agreement for SSH I have submited -03 which adds a MUST check for the all-zero secret, and clarifies the mpint conversion further -- a reference to section 5 of RFC 4251 is added which explains this properly.=C2=A0 Unfortunately, 4251= =C2=A75 doesn't say that mpint's are prepended by an uint32 with the length of the data (or the example is wrong).=C2=A0 Please holler if implementations = do not have the uint32 in the mpint that is hashed, or generally if you believe the new section 2.1 could be clarified further. https://tools.ietf.org/html/draft-josefsson-ssh-curves-03 /Simon = --=-EIKNG0hzpRag8EjfWXYI Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable What do you find ambiguous about the definition of= mpint in RFC 4251? It states:

"Represents multiple precision intege= rs in two's complement format, stored as a string"

That's a referenc= e to the SSH string type defined immediately before mpint, which defines it= s encoding as uint32 length + data.

I think this is fairly unambiguo= us? Furthermore, any implementation that has different ideas will already b= e incompatible with others.


----- Original Message -----
From= : Simon Josefsson
Sent: Wednesday, November 25, 2015 17:05
To: ietf-= ssh@netbsd.org
Subject: Re: Curve25519/448 key agreement for SSH
I have submited -03 which adds a MUST check for the all-zero secret, andclarifies the mpint conversion further -- a reference to section 5 of
= RFC 4251 is added which explains this properly.  Unfortunately, 4251= =C2=A75
doesn't say that mpint's are prepended by an uint32 with the len= gth of
the data (or the example is wrong).  Please holler if implem= entations do
not have the uint32 in the mpint that is hashed, or general= ly if you
believe the new section 2.1 could be clarified further.
https://tools.ietf.org/html/draft-josefsson-ssh-curves-03

/Simon
= --=-EIKNG0hzpRag8EjfWXYI-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Nov 27 00:55:00 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 746AD1AD481 for ; Fri, 27 Nov 2015 00:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.585] autolearn=ham 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 Zue_f5IWJ7qh for ; Fri, 27 Nov 2015 00:54:55 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFD691AD49D for ; Fri, 27 Nov 2015 00:54:53 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 899A214A2C7; Fri, 27 Nov 2015 08:54:46 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id B41E514A2CB for ; Fri, 27 Nov 2015 08:54:41 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id CiaKu6XQLcYz for ; Fri, 27 Nov 2015 08:54:40 +0000 (UTC) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 5A90814A1E4 for ; Fri, 27 Nov 2015 08:54:37 +0000 (UTC) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id tAR8sNuw007337 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 27 Nov 2015 09:54:24 +0100 From: Simon Josefsson To: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Cc: Simon Tatham , ietf-ssh@netbsd.org Subject: Re: Binary packet protocol rethink References: <87egfdxebo.fsf@latte.josefsson.org> <87egfdxebo.fsf@latte.josefsson.org> <1448554180-sup-7145@atreus.tartarus.org> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:151127:ietf-ssh@netbsd.org::6P2pDR7q96ObbKD/:2gZV X-Hashcash: 1:22:151127:nisse@lysator.liu.se::fxnQX1IrLXtL4DUp:3ROH X-Hashcash: 1:22:151127:anakin@pobox.com::tqRIEpD8iIqg7cFv:nTHH Date: Fri, 27 Nov 2015 09:54:22 +0100 In-Reply-To: ("Niels \=\?iso-8859-1\?Q\?M\=F6ller\=22's\?\= message of "Thu, 26 Nov 2015 21:42:17 +0100") Message-ID: <874mg7yg8x.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable nisse@lysator.liu.se (Niels M=F6ller) writes: > The problem is the interactivity. Let's consider the simplest example > (but I'm not saying this example captures all essentials of the > problem). Say I let my shell connection idle for some time, then I type > a couple of characters, and I want a timely response before I type the > next command. Then my typing has to correspond to a TCP segment that can > be decrypted and authenticated and passed on to the remote shell. With > the current ssh protocol, that TCP segment will carry a single > CHANNEL_DATA packet, possibly in combination with fragments of IGNORE > messages and possibly other piggybacking messages, e.g., WINDOW_ADJUST. > > To hide the user's typing from traffic analysis is a tradeoff, with > varying amounts of cover traffic (preferably including responses; > there's maybe some use for an IGNORE_CONTENTS_BUT_PLEASE_REPLY message > type). In libssh2 there is a keepalive message that can be sent regulary. It is a SSH_MSG_GLOBAL_REQUEST with the want-reply bit set. It should be replied to (typically with a SSH_MSG_REQUEST_FAILURE message). That said, I'm also skeptic whether this is an effort that will pan out. I don't see the problem statement sufficiently strong to motivate work. In general that may be because the idea is too weak, but can also be that the problem statement is not fleshed out well enough. Right now it is hard to tell which case applies, but the end result is the same (=3Dnothing will happen). /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWWBo+AAoJEIYLf7sy+BGdu+UIAImqPQUz/HkzDs1uKP13MSUa LrwCfeMON5ZeRMyMxj6E99ZovaxbfgQ2zdoDyy6Qf8YR64xN7XeZigfxRu6NqgBl 8qGFKMe1bW4YFvg3n1MSvZUXAUUqZD03dT0jgNfA5BA8kO6EbO029gunEEtyaIZW Ix6GiAJQf8mtRE8FlxwXxI6pPSofZNJ5/kbiFOWyaDGpkENZXbmw1Gqv3Wuka1v5 VPMS+tAsKttyOxCnQbDUMCj+feqTGsWFgrX96gIW26sHh1bETXdvpCFfYnmBrmUf 8iyU/Ysaw5tdl0ly1uGltr1OUAaaQbiduTW371xFYsa2QP880c/DkrQjzBIoo90= =FGFr -----END PGP SIGNATURE----- --=-=-=-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Nov 27 02:48:21 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA9481B31E4 for ; Fri, 27 Nov 2015 02:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.585] autolearn=ham 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 Iz-Teold7OOa for ; Fri, 27 Nov 2015 02:48:17 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BEE31B31E2 for ; Fri, 27 Nov 2015 02:48:17 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id BBD1214A2D5; Fri, 27 Nov 2015 10:48:14 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id A560D14A2D4 for ; Fri, 27 Nov 2015 10:48:09 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id o0t1UbYpSOrI for ; Fri, 27 Nov 2015 10:48:08 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 5A45014A2D3 for ; Fri, 27 Nov 2015 10:48:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1448621288; x=1480157288; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=OgNOgJpNChBQuohgNwyrW+FLMHvRBTWgCcOlNDOZtqo=; b=2iYqlFyTXpusnMgs13Hnv3fQ/etZ14BxTeXANICUcsFQEV0O3zNHvF6U SIL73wxRK0uXLeVUqeiLv+d8zQAbXFtDsHIW3mqwXfGuOKuH6IZo6Urc4 r/sI9se6toKYEGWUyu0Yyz1wWlhL/rK7rdgAX38+3fyapd97w1LaNyyJc CK/VqPDimF0oesge+eDLgdkb7D6JXXbDvj2caqiQWtVBZaxGpNLePEVug DaW5en6dq8RiNMlbCOA9PQv+IjLFeq6Eo0Ghv/WKl98DTbaZZUM73C8l1 qbTFyuIZQZOGlsrHGnDx/2c44nNeZcfIkZOy0rDqMQxlnvJcmexcO/qdz g==; X-IronPort-AV: E=Sophos;i="5.20,351,1444647600"; d="scan'208";a="56426630" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 27 Nov 2015 23:48:03 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.11]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0266.001; Fri, 27 Nov 2015 23:48:02 +1300 From: Peter Gutmann To: Simon Tatham , =?iso-8859-1?Q?Niels_M=F6ller?= CC: Simon Josefsson , "ietf-ssh@netbsd.org" Subject: RE: Binary packet protocol rethink (was: Re: ChaCha20-Poly1305 for SSH) Thread-Topic: Binary packet protocol rethink (was: Re: ChaCha20-Poly1305 for SSH) Thread-Index: AQHRKNNHBRhQyFSywkSozIEr4kOK8p6vsC46 Date: Fri, 27 Nov 2015 10:48:02 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B857C7@uxcn10-5.UoA.auckland.ac.nz> References: <87egfdxebo.fsf@latte.josefsson.org> <87egfdxebo.fsf@latte.josefsson.org> ,<1448554180-sup-7145@atreus.tartarus.org> In-Reply-To: <1448554180-sup-7145@atreus.tartarus.org> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Simon Tatham writes:=0A= =0A= >Is there any possible way - and would people be interested in pursuing it = if=0A= >there were - to invent a replacement binary packet protocol for SSH which= =0A= >decouples the unit of encryption and the unit of protocol semantics into= =0A= >completely separate layers?=0A= =0A= I've asked for this in the past too. SSL/TLS have used unencrypted lengths= =0A= for twenty years without there being any (known) attack or weakness based o= n=0A= this. OTOH SSH has used encrypted lengths for nearly the same period, and= =0A= there have been several attacks/weaknesses based on that. Security-wise, i= t=0A= has the opposite effect of the one intended, it makes the protocol weaker, = not=0A= stronger.=0A= =0A= My real issue with it though is that, as you've pointed out, it makes it=0A= impossible to create an efficient streaming implementation. With TLS you r= ead=0A= the length at the start, stream the rest into the target memory location, a= nd=0A= decrypt in place. With SSH you have to read a single block, decrypt it, ma= ke=0A= sure you're not providing an oracle for the attacker, copy what's left arou= nd,=0A= read more encrypted data onto the end, decrypt the remainder, ugh.=0A= =0A= I would really like to see a protocol that:=0A= =0A= 1) Doesn't encrypt the length so you can create an efficient streaming=0A= implementation.=0A= =0A= 2) Uses encrypt-then-MAC for security rather than MAC-then-encrypt.=0A= =0A= This would solve several problems with the current format all at once.=0A= =0A= Peter.=0A= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Nov 28 23:11:00 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1002A1A9043 for ; Sat, 28 Nov 2015 23:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.516 X-Spam-Level: X-Spam-Status: No, score=0.516 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.585] autolearn=ham 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 Zxcf4CcYreJT for ; Sat, 28 Nov 2015 23:10:57 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6086E1A9044 for ; Sat, 28 Nov 2015 23:10:57 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id EB74914A2E1; Sun, 29 Nov 2015 07:10:53 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 8DE7214A2D2; Sun, 29 Nov 2015 07:10:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 4D1EF14A1EA for ; Fri, 27 Nov 2015 06:34:07 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id paXetohLWcuv for ; Fri, 27 Nov 2015 06:34:06 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 19AA614A1E4 for ; Fri, 27 Nov 2015 06:34:06 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for nisse@lysator.liu.se; Fri, 27 Nov 2015 06:33:42 +0000 Date: Fri, 27 Nov 2015 06:33:42 +0000 Subject: Re: Binary packet protocol rethink X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <1135300942-968@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: =?UTF-8?q?Niels_M=C3=B6ller?= , Simon Tatham , Simon Josefsson Cc: ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-PrhvpK3Tu515xZ/1d7kh" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-PrhvpK3Tu515xZ/1d7kh Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I agree with Niels's observation that there probably isn't a much better de= fense than SSH_MSG_IGNORE already offers. The fundamental problem of defending against traffic analysis is that if yo= u don't want the attacker to learn anything, then no observable aspect of t= he connection can change. In order to reconcile this with the need to USE t= he connection, if you want to maximize defense, the connection always has t= o operate at its maximum potential. You must always, and constantly, be str= eaming SSH_MSG_IGNORE packets in both directions at maximum bandwidth, or e= lse you must restrict your usage of the connection to a lower rate of strea= ming that you are comfortable maintaining indefinitely. Needless to say, this increases the cost of an otherwise idle connection ne= ar infinitely. Maybe there are users who want to go for that tradeoff. But in 15 years, we= haven't heard that request, yet. It seems to me that renders half-measures also kinda pointless. ----- Original Message ----- From: Niels "M=C3=B6ller"=20 Sent: Thursday, November 26, 2015 14:42 To: Simon Tatham=20 Cc: Simon Josefsson ; ietf-ssh@netbsd.org=20 Subject: Re: Binary packet protocol rethink Simon Tatham writes: > Is there any possible way - and would people be interested in pursuing > it if there were - to invent a replacement binary packet protocol for > SSH which decouples the unit of encryption and the unit of protocol > semantics into completely separate layers? I think it's interesting to explore, but I'm not sure it's possible to get it much better than the ssh protocol with careful use of IGNORE packets. The problem is the interactivity. Let's consider the simplest example (but I'm not saying this example captures all essentials of the problem). Say I let my shell connection idle for some time, then I type a couple of characters, and I want a timely response before I type the next command. Then my typing has to correspond to a TCP segment that can be decrypted and authenticated and passed on to the remote shell. With the current ssh protocol, that TCP segment will carry a single CHANNEL_DATA packet, possibly in combination with fragments of IGNORE messages and possibly other piggybacking messages, e.g., WINDOW_ADJUST. To hide the user's typing from traffic analysis is a tradeoff, with varying amounts of cover traffic (preferably including responses; there's maybe some use for an IGNORE_CONTENTS_BUT_PLEASE_REPLY message type). It's highly desirable to hide details of the user's typing; some reasonable counter measures are to collect keystrokes for a few 100 ms before generating any packet, and use padding to hide the number of keystrokes included in each packet. > And even if you encrypt the length field in a way > that avoids that mistake, you still don't reliably hide your _padded_ > packet lengths anyway, in the face of an active attacker who can proxy > the TCP stream, dribble it out a byte at a time, and wait to see which > byte triggers a response. I suspect some defensive uses of > SSH_MSG_IGNORE may still have this issue. This is a good point which is easy to overlook. The lesson here is that it is better to add the padding data at the start of the TCP segment rather than at the end; the boundary between initial padding and the start of the message is *not* revealed by the dribbel attack. And we should also keep in mind that there are relevant attackers which are only passive eavesdroppers, so a defense which is effective only against passive adverseries but fails with an active adversary still has value. For design of a cryptographic transport protocol, interactivity implies that there has to be some kind of flush/sync mechanism. The input can't be just a cleartext byte stream, it has to be a byte stream with syncronization points. A syncronization point means that data up to that point must be delivered without waiting for further input. So the cryptographic transport protocol must encrypt it, send it out on the wire in a timely manner, and attach an authentication tag and any other signalling needed for the receiver to decrypt, authenticate, and process the data. Which breaks a pure separation between layers. And those synchronization points are going to be revealed by the dribble attack. One possible design would be to make the block of the crypto layer a fixed size, say around 200 bytes, and then to get a synchronization point, just insert an ignore message of at least 200 bytes (possibly with randomized larger size). Probably not a good idea for a general purpose crypto protocol, though. > I've always thought a good way to solve this _in principle_ would be to > replace our current all-in-one message/packet structure with two > independent layers. It's long time since I looked into the details of TLS, but doesn't it have more of this kind of separation? How does it handle the syncronization issue? > Is this an idea that appeals to anyone else? I definitely see the appeal, but I'm a bit skeptic that it can work out. Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. = --=-PrhvpK3Tu515xZ/1d7kh Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable I agree with Niels's observation that there probab= ly isn't a much better defense than SSH_MSG_IGNORE already offers.

T= he fundamental problem of defending against traffic analysis is that if you= don't want the attacker to learn anything, then no observable aspect of th= e connection can change. In order to reconcile this with the need to USE th= e connection, if you want to maximize defense, the connection always has to= operate at its maximum potential. You must always, and constantly, be stre= aming SSH_MSG_IGNORE packets in both directions at maximum bandwidth, or el= se you must restrict your usage of the connection to a lower rate of stream= ing that you are comfortable maintaining indefinitely.

Needless to s= ay, this increases the cost of an otherwise idle connection near infinitely= .

Maybe there are users who want to go for that tradeoff. But in 15 = years, we haven't heard that request, yet.

It seems to me that rende= rs half-measures also kinda pointless.


----- Original Message --= ---
From: Niels "M=C3=B6ller"
Sent: Thursday, November 26, 2015 14:4= 2
To: Simon Tatham
Cc: Simon Josefsson ; ietf-ssh@netbsd.org
Sub= ject: Re: Binary packet protocol rethink

Simon Tatham <anakin@pob= ox.com> writes:

> Is there any possible way - and would people= be interested in pursuing
> it if there were - to invent a replaceme= nt binary packet protocol for
> SSH which decouples the unit of encry= ption and the unit of protocol
> semantics into completely separate l= ayers?

I think it's interesting to explore, but I'm not sure it's po= ssible to
get it much better than the ssh protocol with careful use of I= GNORE
packets.

The problem is the interactivity. Let's consider t= he simplest example
(but I'm not saying this example captures all essent= ials of the
problem). Say I let my shell connection idle for some time, = then I type
a couple of characters, and I want a timely response before = I type the
next command. Then my typing has to correspond to a TCP segme= nt that can
be decrypted and authenticated and passed on to the remote s= hell. With
the current ssh protocol, that TCP segment will carry a singl= e
CHANNEL_DATA packet, possibly in combination with fragments of IGNORE<= br>messages and possibly other piggybacking messages, e.g., WINDOW_ADJUST.<= br>
To hide the user's typing from traffic analysis is a tradeoff, with<= br>varying amounts of cover traffic (preferably including responses;
the= re's maybe some use for an IGNORE_CONTENTS_BUT_PLEASE_REPLY message
type= ). It's highly desirable to hide details of the user's typing; some
reas= onable counter measures are to collect keystrokes for a few 100 ms
befor= e generating any packet, and use padding to hide the number of
keystroke= s included in each packet.

> And even if you encrypt the length f= ield in a way
> that avoids that mistake, you still don't reliably hi= de your _padded_
> packet lengths anyway, in the face of an active at= tacker who can proxy
> the TCP stream, dribble it out a byte at a tim= e, and wait to see which
> byte triggers a response. I suspect some d= efensive uses of
> SSH_MSG_IGNORE may still have this issue.

T= his is a good point which is easy to overlook. The lesson here is that
i= t is better to add the padding data at the start of the TCP segment
rath= er than at the end; the boundary between initial padding and the
start o= f the message is *not* revealed by the dribbel attack. And we
should als= o keep in mind that there are relevant attackers which are
only passive = eavesdroppers, so a defense which is effective only against
passive adve= rseries but fails with an active adversary still has value.

For desi= gn of a cryptographic transport protocol, interactivity implies
that the= re has to be some kind of flush/sync mechanism. The input can't
be just = a cleartext byte stream, it has to be a byte stream with
syncronization = points. A syncronization point means that data up to that
point must be = delivered without waiting for further input. So the
cryptographic transp= ort protocol must encrypt it, send it out on the
wire in a timely manner= , and attach an authentication tag and any other
signalling needed for t= he receiver to decrypt, authenticate, and process
the data. Which breaks= a pure separation between layers.

And those synchronization points = are going to be revealed by the dribble
attack.

One possible desi= gn would be to make the block of the crypto layer a
fixed size, say arou= nd 200 bytes, and then to get a synchronization
point, just insert an ig= nore message of at least 200 bytes (possibly
with randomized larger size= ). Probably not a good idea for a general
purpose crypto protocol, thoug= h.

> I've always thought a good way to solve this _in principle_ = would be to
> replace our current all-in-one message/packet structure= with two
> independent layers.

It's long time since I looked = into the details of TLS, but doesn't it
have more of this kind of separa= tion? How does it handle the
syncronization issue?

> Is this a= n idea that appeals to anyone else?

I definitely see the appeal, but= I'm a bit skeptic that it can work out.

Regards,
/Niels

-= -
Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26.<= br>Internet email is subject to wholesale government surveillance.

<= /body>= --=-PrhvpK3Tu515xZ/1d7kh-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Nov 29 03:33:00 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D3F1A014F for ; Sun, 29 Nov 2015 03:33:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.085 X-Spam-Level: X-Spam-Status: No, score=-1.085 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.585] autolearn=ham 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 UatexdMwVLd5 for ; Sun, 29 Nov 2015 03:32:58 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D72F31A0149 for ; Sun, 29 Nov 2015 03:32:58 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id ACC8614A2E1; Sun, 29 Nov 2015 11:32:55 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 7A62A14A2A2 for ; Sun, 29 Nov 2015 11:32:52 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id OX4Uw_JCzu_c for ; Sun, 29 Nov 2015 11:32:51 +0000 (UTC) Received: from newmailhub.uq.edu.au (mailhub2.soe.uq.edu.au [130.102.132.209]) by mail.netbsd.org (Postfix) with ESMTP id 79ADA14A23B for ; Sun, 29 Nov 2015 11:32:49 +0000 (UTC) Received: from smtp1.soe.uq.edu.au (smtp1.soe.uq.edu.au [10.138.113.40]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id tATBWMbO048137; Sun, 29 Nov 2015 21:32:22 +1000 Received: from mailhub.eait.uq.edu.au (hazel.eait.uq.edu.au [130.102.60.17]) by smtp1.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id tATBWMGd023231 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 29 Nov 2015 21:32:22 +1000 Received: from natsu.mindrot.org (natsu.mindrot.org [130.102.96.2]) by mailhub.eait.uq.edu.au (8.15.1/8.15.1) with ESMTP id tATBWLAh008060; Sun, 29 Nov 2015 21:32:21 +1000 (AEST) Received: by natsu.mindrot.org (Postfix, from userid 1000) id 9AE39A4F2E; Sun, 29 Nov 2015 22:32:21 +1100 (AEDT) Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id 95B00A4F07; Sun, 29 Nov 2015 22:32:21 +1100 (AEDT) Date: Sun, 29 Nov 2015 22:32:21 +1100 (AEDT) From: Damien Miller To: Peter Gutmann cc: Simon Tatham , =?ISO-8859-15?Q?Niels_M=F6ller?= , Simon Josefsson , "ietf-ssh@netbsd.org" Subject: RE: Binary packet protocol rethink (was: Re: ChaCha20-Poly1305 for SSH) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B857C7@uxcn10-5.UoA.auckland.ac.nz> Message-ID: References: <87egfdxebo.fsf@latte.josefsson.org> <87egfdxebo.fsf@latte.josefsson.org> ,<1448554180-sup-7145@atreus.tartarus.org> <9A043F3CF02CD34C8E74AC1594475C73F4B857C7@uxcn10-5.UoA.auckland.ac.nz> User-Agent: Alpine 2.20 (BSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub X-Scanned-By: MIMEDefang 2.75 on 130.102.60.17 X-UQ-FilterTime: 1448796744 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Fri, 27 Nov 2015, Peter Gutmann wrote: > I've asked for this in the past too. SSL/TLS have used unencrypted lengths > for twenty years without there being any (known) attack or weakness based on > this. OTOH SSH has used encrypted lengths for nearly the same period, and > there have been several attacks/weaknesses based on that. Security-wise, it > has the opposite effect of the one intended, it makes the protocol weaker, not > stronger. There have been quite a few fingerprinting attack against websites using object sizes, e.g. Vincent Berg's work. > My real issue with it though is that, as you've pointed out, it makes it > impossible to create an efficient streaming implementation. With TLS you read > the length at the start, stream the rest into the target memory location, and > decrypt in place. With SSH you have to read a single block, decrypt it, make > sure you're not providing an oracle for the attacker, copy what's left around, > read more encrypted data onto the end, decrypt the remainder, ugh. > > I would really like to see a protocol that: > > 1) Doesn't encrypt the length so you can create an efficient streaming > implementation. > > 2) Uses encrypt-then-MAC for security rather than MAC-then-encrypt. OpenSSH has had this for some time in our *-etm MAC modes. https://anongit.mindrot.org/openssh.git/tree/PROTOCOL?id=b1d6b397#n54 -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Nov 29 03:40:02 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 470B01A1ABE for ; Sun, 29 Nov 2015 03:40:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585] autolearn=ham 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 6_oqIKa77nU8 for ; Sun, 29 Nov 2015 03:40:01 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52E781A1A92 for ; Sun, 29 Nov 2015 03:40:01 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 4571C14A2B9; Sun, 29 Nov 2015 11:39:59 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id BF0F914A2D2 for ; Sun, 29 Nov 2015 11:39:55 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 1hxxg6KLjvva for ; Sun, 29 Nov 2015 11:39:54 +0000 (UTC) Received: from newmailhub.uq.edu.au (mailhub1.soe.uq.edu.au [130.102.132.208]) by mail.netbsd.org (Postfix) with ESMTP id 80AC114A2A9 for ; Sun, 29 Nov 2015 11:39:54 +0000 (UTC) Received: from smtp2.soe.uq.edu.au (smtp2.soe.uq.edu.au [10.138.113.41]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id tATBdRrT008032; Sun, 29 Nov 2015 21:39:27 +1000 Received: from mailhub.eait.uq.edu.au (hazel.eait.uq.edu.au [130.102.60.17]) by smtp2.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id tATBdQ1r027605 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 29 Nov 2015 21:39:26 +1000 Received: from natsu.mindrot.org (natsu.mindrot.org [130.102.96.2]) by mailhub.eait.uq.edu.au (8.15.1/8.15.1) with ESMTP id tATBdQtn013557; Sun, 29 Nov 2015 21:39:26 +1000 (AEST) Received: by natsu.mindrot.org (Postfix, from userid 1000) id 631D4A4F2E; Sun, 29 Nov 2015 22:39:26 +1100 (AEDT) Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id 626C5A4F07; Sun, 29 Nov 2015 22:39:26 +1100 (AEDT) Date: Sun, 29 Nov 2015 22:39:26 +1100 (AEDT) From: Damien Miller To: denis bider cc: =?ISO-8859-15?Q?Niels_M=F6ller?= , Simon Tatham , Simon Josefsson , ietf-ssh@netbsd.org Subject: Re: Binary packet protocol rethink In-Reply-To: <1135300942-968@skroderider.denisbider.com> Message-ID: References: <1135300942-968@skroderider.denisbider.com> User-Agent: Alpine 2.20 (BSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub X-Scanned-By: MIMEDefang 2.75 on 130.102.60.17 X-UQ-FilterTime: 1448797167 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Fri, 27 Nov 2015, denis bider wrote: > I agree with Niels's observation that there probably isn't a much better > defense than SSH_MSG_IGNORE already offers. > > The fundamental problem of defending against traffic analysis is that if you > don't want the attacker to learn anything, then no observable aspect of the > connection can change. In order to reconcile this with the need to USE the > connection, if you want to maximize defense, the connection always has to > operate at its maximum potential. You must always, and constantly, be > streaming SSH_MSG_IGNORE packets in both directions at maximum bandwidth, or > else you must restrict your usage of the connection to a lower rate of > streaming that you are comfortable maintaining indefinitely. I don't think this is correct - the chaff only needs to be sufficient to obscure the "real" packets' lengths and timings. It doesn't need to indefinitely saturate the link to achieve this. E.g. an implementation that quantised packet send times (e.g. send every 10ms) and which continued to send random chaff packets for some random interval after the last real packet and in approximate volume to the real ones would remove the worst of the timing channels. > Maybe there are users who want to go for that tradeoff. But in 15 years, we > haven't heard that request, yet. FWIW quite a people have told me that they like the OpenSSH chacha/poly1305 AEAD because it preserves privacy of length fields. I'm a little more ambivalent. -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Nov 29 03:42:43 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 413291A7D84 for ; Sun, 29 Nov 2015 03:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.585] autolearn=ham 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 GtfJ6jgIR_E6 for ; Sun, 29 Nov 2015 03:42:41 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 888531A6FB9 for ; Sun, 29 Nov 2015 03:42:41 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 562B514A2FA; Sun, 29 Nov 2015 11:42:40 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 0B25814A2F6 for ; Sun, 29 Nov 2015 11:42:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id GAk_L9rryA59 for ; Sun, 29 Nov 2015 11:42:34 +0000 (UTC) Received: from newmailhub.uq.edu.au (mailhub2.soe.uq.edu.au [130.102.132.209]) by mail.netbsd.org (Postfix) with ESMTP id DB4EE14A2F4 for ; Sun, 29 Nov 2015 11:42:33 +0000 (UTC) Received: from smtp2.soe.uq.edu.au (smtp2.soe.uq.edu.au [10.138.113.41]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id tATBgB2B004478; Sun, 29 Nov 2015 21:42:11 +1000 Received: from mailhub.eait.uq.edu.au (holly.eait.uq.edu.au [130.102.79.58]) by smtp2.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id tATBgBYR029489 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 29 Nov 2015 21:42:11 +1000 Received: from natsu.mindrot.org (natsu.mindrot.org [130.102.96.2]) by mailhub.eait.uq.edu.au (8.15.1/8.15.1) with ESMTP id tATBgA86023256; Sun, 29 Nov 2015 21:42:11 +1000 (AEST) Received: by natsu.mindrot.org (Postfix, from userid 1000) id 9289CA4F2E; Sun, 29 Nov 2015 22:42:10 +1100 (AEDT) Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id 91DA6A4F07; Sun, 29 Nov 2015 22:42:10 +1100 (AEDT) Date: Sun, 29 Nov 2015 22:42:10 +1100 (AEDT) From: Damien Miller To: =?ISO-8859-15?Q?Niels_M=F6ller?= cc: Simon Josefsson , ietf-ssh@netbsd.org Subject: Re: ChaCha20-Poly1305 for SSH In-Reply-To: Message-ID: References: <87egfdxebo.fsf@latte.josefsson.org> User-Agent: Alpine 2.20 (BSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="15775414878208-1685046499-1448797330=:12629" X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub X-Scanned-By: MIMEDefang 2.75 on 130.102.79.58 X-UQ-FilterTime: 1448797331 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --15775414878208-1685046499-1448797330=:12629 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT On Thu, 26 Nov 2015, Niels Möller wrote: > So my suggestion is to go with rfc 7539, and in addition, encrypt the > length field by something lietk > > encrypt_length(key, nonce, length) > counter = 0 > block = chacha20_block(key,counter,nonce) > return block[32..35] ^ length > end > > using the same key and nonce as input as with poly1305_key_gen in RFC > 7539. (It's then possible, but not at all necessary, to generate the > poly1305 key and encrypt the length key using a single call to > chacha20_block. In contrast to chacha20-poly1305@openssh.com, which, > iirc, uses a separate chacha key just for encrypting the lengths). IMO if you're going to the trouble of preserving packet length privacy then you should do it properly and use a separate cipher instance to do it. In the case of chacha20, it's ridiculously cheap to do so; the cipher has negligible state. -d --15775414878208-1685046499-1448797330=:12629-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Nov 29 03:49:22 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F761A8A5A for ; Sun, 29 Nov 2015 03:49:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585] autolearn=ham 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 3Z9LXtEPiea2 for ; Sun, 29 Nov 2015 03:49:21 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C7FC1A8A59 for ; Sun, 29 Nov 2015 03:49:21 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id EEB1714A200; Sun, 29 Nov 2015 11:49:19 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 1A46814A181 for ; Sun, 29 Nov 2015 11:49:17 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id p8NAfyKiHImm for ; Sun, 29 Nov 2015 11:49:16 +0000 (UTC) Received: from newmailhub.uq.edu.au (mailhub2.soe.uq.edu.au [130.102.132.209]) by mail.netbsd.org (Postfix) with ESMTP id 26DCA14A17F for ; Sun, 29 Nov 2015 11:49:15 +0000 (UTC) Received: from smtp1.soe.uq.edu.au (smtp1.soe.uq.edu.au [10.138.113.40]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id tATBmn00010856; Sun, 29 Nov 2015 21:48:49 +1000 Received: from mailhub.eait.uq.edu.au (hazel.eait.uq.edu.au [130.102.60.17]) by smtp1.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id tATBmnCV026470 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 29 Nov 2015 21:48:49 +1000 Received: from natsu.mindrot.org (natsu.mindrot.org [130.102.96.2]) by mailhub.eait.uq.edu.au (8.15.1/8.15.1) with ESMTP id tATBmm90029621; Sun, 29 Nov 2015 21:48:48 +1000 (AEST) Received: by natsu.mindrot.org (Postfix, from userid 1000) id A4719A4F2E; Sun, 29 Nov 2015 22:48:48 +1100 (AEDT) Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id A3DC1A4F07; Sun, 29 Nov 2015 22:48:48 +1100 (AEDT) Date: Sun, 29 Nov 2015 22:48:48 +1100 (AEDT) From: Damien Miller To: Simon Tatham cc: =?ISO-8859-15?Q?Niels_M=F6ller?= , Simon Josefsson , ietf-ssh@netbsd.org Subject: Re: Binary packet protocol rethink (was: Re: ChaCha20-Poly1305 for SSH) In-Reply-To: <1448554180-sup-7145@atreus.tartarus.org> Message-ID: References: <87egfdxebo.fsf@latte.josefsson.org> <87egfdxebo.fsf@latte.josefsson.org> <1448554180-sup-7145@atreus.tartarus.org> User-Agent: Alpine 2.20 (BSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub X-Scanned-By: MIMEDefang 2.75 on 130.102.60.17 X-UQ-FilterTime: 1448797729 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list While we're dropping wishlist items for SSH v.3, here's one of mine: Key exchange negotiates an AEAD rather than a cipher and a MAC separately, and does so from a greatly trimmed set of options. E.g. AES-GCM, chacha20+poly1305 and an AES-CTR+HMAC mode. IMO the AEAD primitive is the right metaphor for the security properties of the SSH transport protocol. Removing the large cartesian product of ciphers x MACs will make testing faster and binaries smaller too. -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Nov 29 09:58:31 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A877F1B2B70 for ; Sun, 29 Nov 2015 09:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585] autolearn=ham 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 ayOVOFjiffTy for ; Sun, 29 Nov 2015 09:58:30 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE1691B2B6F for ; Sun, 29 Nov 2015 09:58:29 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 6DF2114A3A9; Sun, 29 Nov 2015 17:58:27 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id A4D6B14A3A4 for ; Sun, 29 Nov 2015 17:58:22 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id sx0hc9pN3Xyt for ; Sun, 29 Nov 2015 17:58:22 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0765.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:765]) by mail.netbsd.org (Postfix) with ESMTP id 7D7D214A3A1 for ; Sun, 29 Nov 2015 17:58:20 +0000 (UTC) Received: from BY2PR05CA039.namprd05.prod.outlook.com (10.141.250.29) by BY2PR0501MB1670.namprd05.prod.outlook.com (10.163.154.148) with Microsoft SMTP Server (TLS) id 15.1.331.20; Sun, 29 Nov 2015 17:58:08 +0000 Received: from BL2FFO11FD029.protection.gbl (2a01:111:f400:7c09::134) by BY2PR05CA039.outlook.office365.com (2a01:111:e400:2c5f::29) with Microsoft SMTP Server (TLS) id 15.1.331.20 via Frontend Transport; Sun, 29 Nov 2015 17:58:08 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.241.18) smtp.mailfrom=juniper.net; lysator.liu.se; dkim=none (message not signed) header.d=none;lysator.liu.se; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.241.18 as permitted sender) Received: from p-emfe01b-sac.jnpr.net (66.129.241.18) by BL2FFO11FD029.mail.protection.outlook.com (10.173.160.69) with Microsoft SMTP Server (TLS) id 15.1.331.11 via Frontend Transport; Sun, 29 Nov 2015 17:58:07 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01b-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 29 Nov 2015 08:57:17 -0800 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id tATGvED38238; Sun, 29 Nov 2015 08:57:14 -0800 (PST) (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 1CD2A11446; Sun, 29 Nov 2015 08:57:14 -0800 (PST) To: Damien Miller CC: Simon Tatham , =?ISO-8859-15?Q?Niels_M=F6ller?= , Simon Josefsson , Subject: Re: Binary packet protocol rethink (was: Re: ChaCha20-Poly1305 for SSH) In-Reply-To: References: <87egfdxebo.fsf@latte.josefsson.org> <87egfdxebo.fsf@latte.josefsson.org> <1448554180-sup-7145@atreus.tartarus.org> Comments: In-reply-to: Damien Miller message dated "Sun, 29 Nov 2015 22:48:48 +1100." From: "Mark D. Baushke" Date: Sun, 29 Nov 2015 08:57:14 -0800 Message-ID: <46776.1448816234@eng-mail01.juniper.net> MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1;BL2FFO11FD029;1:uVZTG8lnKayHvfl6xwxzSr6zWAVDoJ+kTOg6fP2hvskON75cS1AsKQ6/rKkbsCu9Slv8SwCXSVIm0ldF6KGDgY5l+KzxVxK0P1GKLcKKUxr+UIxidJj+yRY6K7Ngr5c0bL5gUtaKDvGotXlgq0VLFhNnl4uWxgkI0tS7HgBdDrajYqI9lgU2isXJO+fqJAlpkZ7xRBkGHt4WzFAhgdrp5UeqxHbhNjkNZvTb3B/axLz6lZaHxx1SRl8RDq9AjdL/HlR2KSidshZlZ+cwPVGYVn/mVzH3R9a7IfWGALZBso+mLFiUTOZ7sKCCTfjLbMDA7esgoD1poYwbieYYVacJaBLqUalywe8vfpN5jtzQxXZjmsP5LfdFC52nE+xa7DM1ovvGkpFX+FnM1nFfHKjUQzFDO2omfraPVuYDGwFtq/2T3VYq/FwNnkQh+NkSojI5 X-Forefront-Antispam-Report: CIP:66.129.241.18;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(2980300002)(199003)(189002)(50466002)(105596002)(76176999)(106466001)(11100500001)(87936001)(189998001)(1096002)(5003600100002)(5003940100001)(586003)(50986999)(54356999)(47776003)(53416004)(86362001)(48376002)(1220700001)(76506005)(97736004)(81156007)(6806005)(77096005)(93886004)(92566002)(19580405001)(2950100001)(110136002)(69596002)(5001960100002)(117636001)(19580395003)(7059030)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:BY2PR0501MB1670;H:p-emfe01b-sac.jnpr.net;FPR:;SPF:SoftFail;PTR:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BY2PR0501MB1670;2:ACusnadA2UnIHc7AhvHRQbK+e1wBcnAaUehXy7TkRG9hKbNMGeSrpqzO0TeT9kQi8pwJS3Me5d0Sz/AASqgCxclrTmFhm8RbrvaPyt5xz9zhP7o7uA4BRCwmWeo7UkJxZVytolPrKzEbB0uT+gAfYg==;3:cm+RCJ1eaoiVjNzpyPcjkoQ4/gcK0C/wdBccdvw1eoF2DgBA+oTgLNQl7Uc47yKBTzzop2Kt1HIQ1w2UQ9/uZXl3KhSClKEfSEeKUj9XbFIvc5KQp7X9LofkfGg5gl1mvi7LoxKETe5o8J78WAKG5zQMRFvy4BdoswgvGwk+Uj4nBHXWoHrma9CXGyZF1k/Ask8Y7H60JGO+pRZNhaVQHZZYUpRSRyIJ8yQn7QERsI4=;25:f91jpi1+hJWrRXwj/e4959/QhQmOUHLKU0yOOV61Pv3OZ4qJIyxJuy4gYXhebuKJvc+3rCzvGacAwMW92tx2ywynn6Bkn5h9RkaokrVm4BQDZ5i2fflMBrgC/3bN864gJYc5BsOheYE7AbynCeK4YPbS64tCAmw2i5Up9oxUy8WBh9mQ4tU4c4pm7qSB3yUhpDeiGvF5Ve7/QvsqHqNsro7LPVsGZoG+jDE0x9IsL2DtgcsegwL7uSVHTYmtHCUr X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0501MB1670; X-Microsoft-Exchange-Diagnostics: 1;BY2PR0501MB1670;20:5dwol1/2+ohn4SbfYGYaOXcHv5VysSa2juQO0b00rYayAuFWzCCzvndocRay2zC/dV0jzl9LQ2QjeGAHnz7fdTpmWOFWWw1hFpuQCsAkeWn/RHEaXz3xu5c7vVITyW/vR2k7v3Eh25QeHKuzIfcZxh41clmbpug3hYQLBdtPHg6zqzO3DG4BG7QFqzLMldfcpjYodHlIy1pmSa+/WJV5OkOYuexp1bEUjOgypMRqgCYUtUgT4iRnSB3+qqFYZWvjSLy+vVdblkJA9JNrJ5jHuObdwCpB7bjC3dBZ4Z3uMPi180D6Q1RGm15Ie6+9x/set+DWrisMWNRIxVirzOrRDx3JlDNzlTszAi+k8GVWvkHOlWAHePhGvLzoQ4+5kAjgkbwkxyI5MhWGc2tBSqIGaQOsSNcMS5aut/pWKwo4rGMoTaMxF0JakJZ5xY09f57rlcf13YaCyxIzNgjaah8u6fpSaqLat5CvzjBmDEsP8ODIqoJp/O0DqFUgCBwBy2y8;4:7AaOItTEAHgR/S3CnxbZ8GckPk0H2xC2KWyML4i/JNGX7syDkVCfD9U34l8muzRLQDzGTOAJwkHkdEa2tuKm5TMArdvGaEWqCUV+++bHAXkOVJsFROrxnQKrI6BZzjDY7zoxY8vi9wWGSqTUyf+Rq07ENfMRsO+zFVx/KKFBFg+E/9huea+QnTzCn5lfRXTfrpvqs69UpJL6AJ8puU4pB0iMJyX4UxHK9ZlOa7jAN5CeruxQhV+l4d8Tew27Q/EiwehcIpSaWIq1ollfE0y7AjVo5l0wcr86L8Xa59a/Fe+GqSejLoaITJS9t7RIFbfnKGWMVI4sc8KOg/ek6A6EX7UFhrfU5sK1SB8fyUivbp94tqqNU6EnCqadwS07gPfg X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001);SRVR:BY2PR0501MB1670;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0501MB1670; X-Forefront-PRVS: 0775716B9D X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;BY2PR0501MB1670;23:BcKDT8OIP5EmUO9yZT1xJxjm/m0jrcr+iW4/+RG?= =?us-ascii?Q?Qk3R60zhFzZnVUBLP6Qv+jSWRFmmijVup0y5ed4ONI1jUZnamej3w8WWirTU?= =?us-ascii?Q?6x45CmoJXirn4kH4zMS9OZQy/ha5SRN0L66I3qJ7EDwHmDWNbsnNkHCUsZxN?= =?us-ascii?Q?nryIsgMPlRRLaRE8DMDZb7uzb9ev+7BjV4CPR1l8M2p+oER2py7SA3/B+2c+?= =?us-ascii?Q?L+k5cIfiIeDFT2LbxtGzK/K30WVQEU39dXD7b/MUfS0OlpggA55SacaKoA6a?= =?us-ascii?Q?dSgdwGeECjbtnwBoB8uaDo6kd2Pz+S72Zly69MWth2RHwVtaABGuZ90VhsEQ?= =?us-ascii?Q?9SakgIALK2fUohLx7pa+KZSBqnnb2bvIc/Rc07/fjjGtV9fVgumsSEMzuJEc?= =?us-ascii?Q?7FApFTsopPFiTokreDGuRVKu1C7iyOzr/nfZwitlZ9Ozo1ox0YqZNSgolCnQ?= =?us-ascii?Q?TT3Nj5IUF2k6Xnuz1NXy3oXtjA1IsbVjwZ1pkfSOJj4qqEIiGny0ILA3vkn8?= =?us-ascii?Q?gpnRWSG5oEnllRbw91xbAAGysgSz3fY/82KDRAeLuHJvMofZWR7rPMykFFrq?= =?us-ascii?Q?ByClfSiIm0puA8IYxPbOF/YG97Z23Sh/xjvOeBgZ98Wj3FmTGtHFVC2poADr?= =?us-ascii?Q?oGG7uZ4tkgQJweumaPkotuCy4G7CeSGBiKPoFk5fjkstVsfRQE14B3jCwpae?= =?us-ascii?Q?nUGgAf6ELb25/ACzNKWDLh28RkBU25odqDpRIV2/3Nq+HLnaS9yz6SiN/u+T?= =?us-ascii?Q?I5cCS/LUU1dbzZ9N/lh2dWFWJrDAO8cR+90bJH88rMj62l+g4uOAsfrrx+oM?= =?us-ascii?Q?CWFOPn2IPbaLaNwiEcSw4xlRKnL+q89N9/++HbTgpvujzAXBXW9I/lpIPPLO?= =?us-ascii?Q?L9A8PgZM/K5r7LDMWQxYQkL9mGwWZ3xnpNQvTApOi/K1fgxRKxUd+lXDgNkA?= =?us-ascii?Q?zkeGop+zWXCcnSTVm8PWBZhKsxGS36UqqkSnS+orLTQWsypSL0hcd+n5bF5B?= =?us-ascii?Q?XnYPxb3U4zy7LKza7lCXaSriU?= X-Microsoft-Exchange-Diagnostics: 1;BY2PR0501MB1670;5:Uz3C27wYlNSBAa9dfT0n5M5EkPulrCT4aPnLS8HD3eo4YPvz667Pp/RgcJwgW1vbyaab0uMiMcocQGE8uM2Yr3J8dD478Ir0MKNO1zMXdkGOLsRD3j//9HWnZIHuM+gGQLb9x9Y4w+umQwVKTLfn1Q==;24:kjKHJAY0f0+AUo+g5KanpEWUQnLCPc0l9EwXr7QT+u/nLcL1QoqpY+XXoUulNisTI1vJSGrpyO9piY0gKpUZtwo4WC9D2M4CDMfWJ426870= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Nov 2015 17:58:07.2258 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.241.18];Helo=[p-emfe01b-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0501MB1670 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Damien Miller writes: > While we're dropping wishlist items for SSH v.3, here's one of mine: > > Key exchange negotiates an AEAD rather than a cipher and a MAC > separately, and does so from a greatly trimmed set of options. E.g. > AES-GCM, chacha20+poly1305 and an AES-CTR+HMAC mode. +1 This would be useful. -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Nov 29 10:05:47 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E18551B2BFA for ; Sun, 29 Nov 2015 10:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.585] autolearn=ham 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 LkBXi1otnbmP for ; Sun, 29 Nov 2015 10:05:46 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 793241B2BDD for ; Sun, 29 Nov 2015 10:05:46 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 10AA314A243; Sun, 29 Nov 2015 18:05:46 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id AE0DD14A394 for ; Sun, 29 Nov 2015 18:05:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id MDhMe2GFdPUv for ; Sun, 29 Nov 2015 18:05:40 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id D94A514A243 for ; Sun, 29 Nov 2015 18:05:37 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id EDE5F40037; Sun, 29 Nov 2015 19:05:34 +0100 (CET) Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id A03F340036; Sun, 29 Nov 2015 19:05:33 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Sun, 29 Nov 2015 19:05:33 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: Damien Miller Cc: Simon Josefsson , ietf-ssh@netbsd.org Subject: Re: ChaCha20-Poly1305 for SSH References: <87egfdxebo.fsf@latte.josefsson.org> Date: Sun, 29 Nov 2015 19:05:33 +0100 In-Reply-To: (Damien Miller's message of "Sun, 29 Nov 2015 22:42:10 +1100 (AEDT)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Damien Miller writes: > IMO if you're going to the trouble of preserving packet length > privacy then you should do it properly and use a separate cipher > instance to do it. Does it matter if we xor it with some unused bytes in the same chacha key stream used for the rest of the data, or use a separate instance with a different key (but generated from the same key exchange secret)? > In the case of chacha20, it's ridiculously cheap > to do so; the cipher has negligible state. It just seems nice to me to not have to produce yet another session key just for this, when we have 32 perfectly good key stream bytes left over. I agree the per-message overhead with an extra chacha instance is very low, and it's no big deal, it's more about eliminating a little book-keeping. Or are you suggesting the even more proper thing to do, which would be to encrypt the length field *and* add separate authentication tag for it? Off the top of my head, I think it would make sense with some building-block which takes as input a per-session key, the 32-bit length, and per-message nonce, and produces, e.g., 64 random looking output bits, such that (1) the length can be recovered only by the receiver, with whome we share the key, and (2) any malicious modification of the 64 bits on the wire can be detected with probability close to 1. Or just use a separate chacha-poly1305 on the length, with it's larger tag. Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Nov 29 17:57:44 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F241A1B03 for ; Sun, 29 Nov 2015 17:57:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.585] autolearn=ham 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 Z2PKRLzTrlU8 for ; Sun, 29 Nov 2015 17:57:42 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF3721A1AFC for ; Sun, 29 Nov 2015 17:57:42 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 7DE2D14A39D; Mon, 30 Nov 2015 01:57:39 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id E254E14A39C for ; Mon, 30 Nov 2015 01:57:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id XhVKEnCLZ2ms for ; Mon, 30 Nov 2015 01:57:35 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 966EF14A39A for ; Mon, 30 Nov 2015 01:57:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1448848654; x=1480384654; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QN7RWBgFrDqcpweILryBSHzySRmrmL+WRbZrzZMuBmc=; b=OPJbaEgHeNWHJngP/ZD3IIlIFoODNgGpEp9YLupEkZspdjFl5/eNIML0 JXzaxLJcJzakWBGLip8Cpv51iMbkdUhBCdvV3FTujM3+0P9gD0goIoqak vbBNIB7flTEygmqJG6+i/sRa0RmlUKq0OsRdSlNV1PMDcLVXSAKrLrK4B vydmna1Cvb4AFtAGvHnIr6hc2A+BR/FxRNdwwjajzBV9HdKxM+/uJt0zQ iZKDBYmSRvs5dCxqcgShQsqgRUwDnk0gfgqJbtGDFxN8jKyEoO6bG8kol IgvexOlsuuzNCI4oz/oyPuSmvAL3JI4ADg8QTZqlr0+PKhUWU6vTXMEJp w==; X-IronPort-AV: E=Sophos;i="5.20,361,1444647600"; d="scan'208";a="56733849" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 30 Nov 2015 14:57:28 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0266.001; Mon, 30 Nov 2015 14:57:28 +1300 From: Peter Gutmann To: Damien Miller CC: Simon Tatham , =?iso-8859-1?Q?Niels_M=F6ller?= , Simon Josefsson , "ietf-ssh@netbsd.org" Subject: RE: Binary packet protocol rethink (was: Re: ChaCha20-Poly1305 for SSH) Thread-Topic: Binary packet protocol rethink (was: Re: ChaCha20-Poly1305 for SSH) Thread-Index: AQHRKNNHBRhQyFSywkSozIEr4kOK8p6vsC46gAJXdYCAAct5Jg== Date: Mon, 30 Nov 2015 01:57:28 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B92EF0@uxcn10-5.UoA.auckland.ac.nz> References: <87egfdxebo.fsf@latte.josefsson.org> <87egfdxebo.fsf@latte.josefsson.org> ,<1448554180-sup-7145@atreus.tartarus.org> <9A043F3CF02CD34C8E74AC1594475C73F4B857C7@uxcn10-5.UoA.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Damien Miller writes:=0A= =0A= >There have been quite a few fingerprinting attack against websites using = =0A= >object sizes, e.g. Vincent Berg's work.=0A= =0A= Sure, I'm aware of just under three dozen, but encrypted vs.unencrypted=0A= lengths don't play a major role, they're used because they're there, not=0A= because they're critical to the success of the process. You've got TCP=0A= packet sizes (which generally make length-encryption irrelevant), packet=0A= timing, message flows, everything that can be used will be used. In=0A= particular, "Timing Analysis of Keystrokes and Timing Attacks on SSH"=0A= worked against SSH even though the lengths were encrypted.=0A= =0A= More or less the same debate is currently occurring on the TLS list,=0A= where I commented that:=0A= =0A= If you want to thwart traffic analysis, you need to do something=0A= like what's done by designs like Aqua ("Towards Efficient Traffic-=0A= analysis Resistant Anonymity Networks"), or ideas from any of the =0A= other anti-traffic-analysis work that's emerged in the past decade =0A= or two. =0A= =0A= You get traffic analysis resistance by, for example, breaking data into = =0A= fixed-length packets, using cover traffic, and messing with packet =0A= timings, not by encrypting TLS headers.=0A= =0A= Peter.=0A= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 30 00:02:07 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21FAE1B2C10 for ; Mon, 30 Nov 2015 00:02:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.585] autolearn=ham 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 DlH_Dl_yUy5m for ; Mon, 30 Nov 2015 00:02:01 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15C151A8AF8 for ; Mon, 30 Nov 2015 00:02:01 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 9341E14A3E6; Mon, 30 Nov 2015 08:01:58 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 30B8714A3E5 for ; Mon, 30 Nov 2015 08:01:56 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id Qc50fVt7fxej for ; Mon, 30 Nov 2015 08:01:55 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 6583114A3DD for ; Mon, 30 Nov 2015 08:01:54 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id D96144003E; Mon, 30 Nov 2015 09:01:51 +0100 (CET) Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id A054940038; Mon, 30 Nov 2015 09:01:49 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Mon, 30 Nov 2015 09:01:49 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: Peter Gutmann Cc: Damien Miller , Simon Tatham , Simon Josefsson , "ietf-ssh\@netbsd.org" Subject: Re: Binary packet protocol rethink References: <87egfdxebo.fsf@latte.josefsson.org> <87egfdxebo.fsf@latte.josefsson.org> <1448554180-sup-7145@atreus.tartarus.org> <9A043F3CF02CD34C8E74AC1594475C73F4B857C7@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B92EF0@uxcn10-5.UoA.auckland.ac.nz> Date: Mon, 30 Nov 2015 09:01:49 +0100 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B92EF0@uxcn10-5.UoA.auckland.ac.nz> (Peter Gutmann's message of "Mon, 30 Nov 2015 01:57:28 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Peter Gutmann writes: > You get traffic analysis resistance by, for example, breaking data into= =20 > fixed-length packets, using cover traffic, and messing with packet=20 > timings, not by encrypting TLS headers. One can do all of these with the current ssh wire protocol. It's even straight-forward to do. But if we switch to clear text lengths (with no other, deeper, changes to the protocol), it gets a lot more difficult. So encrypted packet lengths aren't a solution, but they're a *prerequisite* for the more serious counter measures. Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 30 00:55:52 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9AD91B2D16 for ; Mon, 30 Nov 2015 00:55:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.585] autolearn=ham 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 9IMIuoq0DaDz for ; Mon, 30 Nov 2015 00:55:48 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2ED91B2D0E for ; Mon, 30 Nov 2015 00:55:48 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id EC49414A331; Mon, 30 Nov 2015 08:55:45 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 31ED614A329 for ; Mon, 30 Nov 2015 08:55:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 07WzPmiCcpUM for ; Mon, 30 Nov 2015 08:55:42 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 02A3C14A304 for ; Mon, 30 Nov 2015 08:55:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1448873742; x=1480409742; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=GF4WBYbT4NevRaFaL7+AYnmv+9mgt5D23lSM3IVUeTY=; b=fFnaJpKyyJJcT76NFmBx9PNbFwUaR/2/kO+bklVbpQLQKrfM/VhSFS/Z A3LXvKCs4xp76w1CZOtUJXzvth0wLs5ooUOCO+vARshF/QvBvBjZ3Iw8i 3IEhnDlvHN8bF8077EiV78seBnSA43ZQ7Yt9eIK1FbM2jbts1CKFY2g+z ZYXtvM5sNO8f6CaoTB2eqnMEe48M2RczLL2mZOd3VSX+2gci23tx5mxsB I2J+OmzwRpGpP9RdnjKwKOMMNUZ3EvkiP3qBNSMEynZIwMANV4uQsJ2Sm nuAMlaLBj5aiprOhrWEiXs2oLw93t+qPvRmQukGB5PRssC8yJGr6sHUWB w==; X-IronPort-AV: E=Sophos;i="5.20,364,1444647600"; d="scan'208";a="56786690" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 30 Nov 2015 21:55:36 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0266.001; Mon, 30 Nov 2015 21:55:37 +1300 From: Peter Gutmann To: =?iso-8859-1?Q?Niels_M=F6ller?= CC: Damien Miller , Simon Tatham , "Simon Josefsson" , "ietf-ssh@netbsd.org" Subject: RE: Binary packet protocol rethink Thread-Topic: Binary packet protocol rethink Thread-Index: AQHRK0VdMJRbFzQ1ukq+Xs4ulafSe560QstW Date: Mon, 30 Nov 2015 08:55:35 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B9321A@uxcn10-5.UoA.auckland.ac.nz> References: <87egfdxebo.fsf@latte.josefsson.org> <87egfdxebo.fsf@latte.josefsson.org> <1448554180-sup-7145@atreus.tartarus.org> <9A043F3CF02CD34C8E74AC1594475C73F4B857C7@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B92EF0@uxcn10-5.UoA.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Niels M=F6ller writes:=0A= =0A= >One can do all of these with the current ssh wire protocol. It's even=0A= >straight-forward to do. But if we switch to clear text lengths (with no=0A= >other, deeper, changes to the protocol), it gets a lot more difficult.=0A= =0A= Why? The length just tells you how much to decrypt in one block, what you = put=0A= inside it is up to you. At a lower level, the TCP headers already give len= gth=0A= information, and if you can deal with that then you can just as easily deal= =0A= with plaintext lengths.=0A= =0A= Peter.=0A= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 30 01:11:56 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F57C1B2D64 for ; Mon, 30 Nov 2015 01:11:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585] autolearn=ham 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 gMuEa3DjNwVA for ; Mon, 30 Nov 2015 01:11:55 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0629E1B2D62 for ; Mon, 30 Nov 2015 01:11:55 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 482C514A3DD; Mon, 30 Nov 2015 09:11:51 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id B500814A3D6 for ; Mon, 30 Nov 2015 09:11:47 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 0UfdK4QPOJJo for ; Mon, 30 Nov 2015 09:11:46 +0000 (UTC) Received: from atreus.tartarus.org (atreus.tartarus.org [80.252.125.10]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id A210E14A3DB for ; Mon, 30 Nov 2015 09:11:45 +0000 (UTC) Received: from simon by atreus.tartarus.org with local (Exim 4.69) (envelope-from ) id 1a3KUL-000260-7F; Mon, 30 Nov 2015 09:11:13 +0000 Content-Type: text/plain; charset=UTF-8 From: Simon Tatham To: Peter Gutmann Cc: =?utf-8?q?Niels_M=C3=B6ller?= , Damien Miller , "\"Simon Josefsson\"" , "ietf-ssh@netbsd.org" Subject: RE: Binary packet protocol rethink In-reply-to: <9A043F3CF02CD34C8E74AC1594475C73F4B9321A@uxcn10-5.UoA.auckland.ac.nz> References: <87egfdxebo.fsf@latte.josefsson.org> <1448554180-sup-7145@atreus.tartarus.org> <9A043F3CF02CD34C8E74AC1594475C73F4B857C7@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B92EF0@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B9321A@uxcn10-5.UoA.auckland.ac.nz> Date: Mon, 30 Nov 2015 09:11:13 +0000 Message-Id: <1448874084-sup-4376@atreus.tartarus.org> User-Agent: Sup/git Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Peter Gutmann wrote: > Why? The length just tells you how much to decrypt in one block, what > you put inside it is up to you. At a lower level, the TCP headers > already give length information, and if you can deal with that then > you can just as easily deal with plaintext lengths. Exactly. And, at the same time, it's precisely the encrypting of the 'how much to decrypt' length field which gives rise to all the previous protocol flaws: an attacker either guesses the true length by correlating to the TCP headers, or probes it by means of the byte-at-a-time dribbling attack, or actively corrupts the cipher block containing the length and waits to see when the resulting MAC failure is reported, and all of those attacks (unless carefully defended against) give rise to some kind of data you can use to attack the underlying cipher, like a (plaintext, ciphertext) pair, or a partial XOR of a plaintext block and the previous block in the CBC stream, or whatever. So it simplifies matters enormously if you just don't try: accept that the enemy _will_ be able to know the lengths of your encrypted blocks. Then you can send them in clear to avoid all of those subtle implementation goofs in trying to hide them, and instead, dedicate your effort to arranging that it _doesn't matter_ if the enemy knows those lengths, by making sure that the encrypted block boundaries do not also reveal the length or position of any actually important data, such as a particular SSH_MSG_anything. Hence, my original suggestion of separating the two conceptual halves of the current monolithic BPP. But it's looking so far as if there's not enough interest to pursue it. Ah well. Cheers, Simon -- for k in [pow(x,37,0x1a1298d262b49c895d47f) for x in [0x50deb914257022de7fff, 0x213558f2215127d5a2d1, 0x90c99e86d08b91218630, 0x109f3d0cfbf640c0beee7, 0xc83e01379a5fbec5fdd1, 0x19d3d70a8d567e388600e, 0x534e2f6e8a4a33155123]]: print "".join([chr(32+3*((k>>x)&1))for x in range(79)]) # From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 30 02:55:04 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 891101A905B for ; Mon, 30 Nov 2015 02:55:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 DEUv46yJDyek for ; Mon, 30 Nov 2015 02:55:02 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D0DE1A905A for ; Mon, 30 Nov 2015 02:55:02 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id B6B9B14A3E9; Mon, 30 Nov 2015 10:54:58 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 81A1014A3E8 for ; Mon, 30 Nov 2015 10:54:53 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id y-cKMgxIdWx4 for ; Mon, 30 Nov 2015 10:54:52 +0000 (UTC) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 66DE314A3AC for ; Mon, 30 Nov 2015 10:54:48 +0000 (UTC) Received: from latte.josefsson.org ([IPv6:2001:9b0:104:42::a86]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id tAUAsTBj011438 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 30 Nov 2015 11:54:31 +0100 Date: Mon, 30 Nov 2015 11:54:23 +0100 From: Simon Josefsson To: Damien Miller Cc: Simon Tatham , Niels =?UTF-8?B?TcO2bGxlcg==?= , ietf-ssh@netbsd.org Subject: Re: Binary packet protocol rethink (was: Re: ChaCha20-Poly1305 for SSH) Message-ID: <20151130115423.704a3d44@latte.josefsson.org> In-Reply-To: References: <87egfdxebo.fsf@latte.josefsson.org> <87egfdxebo.fsf@latte.josefsson.org> <1448554180-sup-7145@atreus.tartarus.org> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/sw3.32B.z5Ogc0BgJlZnuTW"; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --Sig_/sw3.32B.z5Ogc0BgJlZnuTW Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable > While we're dropping wishlist items for SSH v.3, here's one of mine: >=20 > Key exchange negotiates an AEAD rather than a cipher and a MAC > separately, and does so from a greatly trimmed set of options. E.g. > AES-GCM, chacha20+poly1305 and an AES-CTR+HMAC mode. >=20 > IMO the AEAD primitive is the right metaphor for the security > properties of the SSH transport protocol. Removing the large > cartesian product of ciphers x MACs will make testing faster and > binaries smaller too. I agree. I believe there is opportunity to deprecate all pre-AEAD modes, if there is interest on doing that. I believe the experience with TLS is that no non-AEAD mode has the properties that we desire. Generally, I believe the experience is that you cannot negotiate cipher and MAC separately, it has to be done together. Maybe we can draft something together, and bring it to the curdle IETF WG, it would be in scope of that process. Looking at these registries: http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-par= ameters-17 http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-par= ameters-18 I believe it would be possible to mark all as obsolete/historic, except for a list of a few known good combinations that we can actually recommend. As far as I can tell that list would include: aes128-ctr aes256-ctr chacha20-poly1305 (whatever that turns out to be) umac-* (same here..) hmac-sha1 (for older ciphers only?) hmac-sha2-256 (for older ciphers only?) Any others? I'm not sure what to make of the RFC 5647 AES-GCM mode. Nobody seems to implement that. /Simon --Sig_/sw3.32B.z5Ogc0BgJlZnuTW Content-Type: application/pgp-signature Content-Description: OpenPGP digital signatur -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWXCrfAAoJEIYLf7sy+BGdvlUH/2Mb6fNMM07l9LhUbnEJ/TRd U/vUfntsUq+h83NzEBLSHyH9kSdP+bcJIuZ7wZAFC4U/pcxeLQR1ESNzA6p3llXF QDukM6RpG2B7Q4ZZSdORrhMZ36iqHm9GuvGn8SE8npQo1RhXM7I5VaLLZnyuvMed 81Ax1ZOrz6Rvz9CJQB+7KkeVjfYL4Gyqj+B3XpoL4k1tEGeLHXg0wCxySluLQG9y AsgnQnq8oDef5riUY3baIbJcrthm9Cikvae0xxDDt7SFnUNwa2Y+LScIv7MmOm3m 8iAxSrB7ByAZAcah8hOWu3Ki6l9dhI90BAoRXRr1PFp8xKZMNxJ9LtasiM7e2rg= =jg1D -----END PGP SIGNATURE----- --Sig_/sw3.32B.z5Ogc0BgJlZnuTW-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 30 03:25:34 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 404DA1A9134 for ; Mon, 30 Nov 2015 03:25:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.29 X-Spam-Level: X-Spam-Status: No, score=0.29 tagged_above=-999 required=5 tests=[MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 UF5wfX6bAG2q for ; Mon, 30 Nov 2015 03:25:32 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B99121A9102 for ; Mon, 30 Nov 2015 03:25:32 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 0D95F14A347; Mon, 30 Nov 2015 11:25:30 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 2565C14A2E1 for ; Mon, 30 Nov 2015 11:25:26 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 1lEee_ajLRII for ; Mon, 30 Nov 2015 11:25:25 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 422A714A21C for ; Mon, 30 Nov 2015 11:25:24 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 73DF940038; Mon, 30 Nov 2015 12:25:21 +0100 (CET) Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id 9C8D940036; Mon, 30 Nov 2015 12:25:19 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Mon, 30 Nov 2015 12:25:19 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: Peter Gutmann Cc: Damien Miller , Simon Tatham , "Simon Josefsson" , "ietf-ssh\@netbsd.org" Subject: Re: Binary packet protocol rethink References: <87egfdxebo.fsf@latte.josefsson.org> <87egfdxebo.fsf@latte.josefsson.org> <1448554180-sup-7145@atreus.tartarus.org> <9A043F3CF02CD34C8E74AC1594475C73F4B857C7@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B92EF0@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B9321A@uxcn10-5.UoA.auckland.ac.nz> Date: Mon, 30 Nov 2015 12:25:19 +0100 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B9321A@uxcn10-5.UoA.auckland.ac.nz> (Peter Gutmann's message of "Mon, 30 Nov 2015 08:55:35 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Peter Gutmann writes: > Niels M=C3=B6ller writes: > >>One can do all of these with the current ssh wire protocol. It's even >>straight-forward to do. But if we switch to clear text lengths (with no >>other, deeper, changes to the protocol), it gets a lot more difficult. > > Why? The length just tells you how much to decrypt in one block, what yo= u put > inside it is up to you. With the current protocol, I must encrypt exactly one SSH message, hence cleartext lengths reveal number of SSH messages, and their lengths. TCP headers need *not* be so correlated. > At a lower level, the TCP headers already give length information, and > if you can deal with that then you can just as easily deal with > plaintext lengths. The ssh implementation generates a sequence of cleartext messages to be transported across the network. The ssh transport machinery can encrypt these, then split them into fixed size blocks and send off with pre-determined intervals, and whatever else you think is a useful counter measure to traffic analysis. When an input message or message fragment is too short, insert ignore messages (preferable in *front* of the real data, for the byte-by-byte dribble attack). I'm happy to discuss the tradeoffs here, but it seems that you keep repeating that the attacker gets as much useful info from observing tcp segment boundaries as from observing ssh message boundaries. I don't think that is correct description of the current protocol, and it seems our disagreement on this point kind-of blocks useful discussion. Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 30 03:34:36 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83AD91A9250 for ; Mon, 30 Nov 2015 03:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.29 X-Spam-Level: X-Spam-Status: No, score=0.29 tagged_above=-999 required=5 tests=[MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 cNGdSDFFbItu for ; Mon, 30 Nov 2015 03:34:35 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEF8F1A924B for ; Mon, 30 Nov 2015 03:34:35 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id B4AC214A2F4; Mon, 30 Nov 2015 11:34:33 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id C3A3614A234 for ; Mon, 30 Nov 2015 11:34:30 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id vAV-waiDmZPW for ; Mon, 30 Nov 2015 11:34:30 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id F108914A1C3 for ; Mon, 30 Nov 2015 11:34:29 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 26AC640038; Mon, 30 Nov 2015 12:34:28 +0100 (CET) Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id D390040036; Mon, 30 Nov 2015 12:34:26 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Mon, 30 Nov 2015 12:34:26 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: Simon Tatham Cc: Peter Gutmann , Damien Miller , "\"Simon Josefsson\"" , "ietf-ssh\@netbsd.org" Subject: Re: Binary packet protocol rethink References: <87egfdxebo.fsf@latte.josefsson.org> <1448554180-sup-7145@atreus.tartarus.org> <9A043F3CF02CD34C8E74AC1594475C73F4B857C7@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B92EF0@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B9321A@uxcn10-5.UoA.auckland.ac.nz> <1448874084-sup-4376@atreus.tartarus.org> Date: Mon, 30 Nov 2015 12:34:26 +0100 In-Reply-To: <1448874084-sup-4376@atreus.tartarus.org> (Simon Tatham's message of "Mon, 30 Nov 2015 09:11:13 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Simon Tatham writes: > an attacker either guesses the true length by correlating to the > TCP headers, or probes it by means of the byte-at-a-time dribbling > attack, or actively corrupts the cipher block containing the length and > waits to see when the resulting MAC failure is reported,=20 Would you be happier if the length field were independently authenticated? I'm not sure how strong an authenticator we need, it seems a bit silly to use an authentication tag which is much larger than the message, but maybe it's really needed. > by making sure that the encrypted block boundaries do not also > reveal the length or position of any actually important data, such as a > particular SSH_MSG_anything. Can we do that with the current protocol? If so, guidance is appreciated. What I object to is removing a feature (encrypted message lengths) which enables known counter measures to traffic analysis, and replace it by nothing. Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 30 04:11:02 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3193D1A904D for ; Mon, 30 Nov 2015 04:11:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 ju072PMD4Yc7 for ; Mon, 30 Nov 2015 04:11:00 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 915A81AC412 for ; Mon, 30 Nov 2015 04:10:56 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 7A35F14A420; Mon, 30 Nov 2015 12:10:55 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 8B13D14A41D for ; Mon, 30 Nov 2015 12:10:52 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id gbzyupU8BdQT for ; Mon, 30 Nov 2015 12:10:51 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id A94AB14A406 for ; Mon, 30 Nov 2015 12:10:51 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 6CFC340038; Mon, 30 Nov 2015 13:10:49 +0100 (CET) Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id E0A0640032; Mon, 30 Nov 2015 13:10:47 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Mon, 30 Nov 2015 13:10:47 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: Simon Josefsson Cc: Damien Miller , Simon Tatham , ietf-ssh@netbsd.org Subject: Re: Binary packet protocol rethink References: <87egfdxebo.fsf@latte.josefsson.org> <87egfdxebo.fsf@latte.josefsson.org> <1448554180-sup-7145@atreus.tartarus.org> <20151130115423.704a3d44@latte.josefsson.org> Date: Mon, 30 Nov 2015 13:10:47 +0100 In-Reply-To: <20151130115423.704a3d44@latte.josefsson.org> (Simon Josefsson's message of "Mon, 30 Nov 2015 11:54:23 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Simon Josefsson writes: >> IMO the AEAD primitive is the right metaphor for the security >> properties of the SSH transport protocol. Removing the large >> cartesian product of ciphers x MACs will make testing faster and >> binaries smaller too. > > I agree. I believe there is opportunity to deprecate all pre-AEAD > modes, if there is interest on doing that. I agree this makes a lot of sense. AEAD is exactly what the protocol needs, it just wasn't well established at the time. I'd like to see some discussion on how to do it within the ssh algorithm negotiation, since it doesn't quite fit in the original design. Maybe we can just do what openssh does, I'm not sure? I know that completely dropping support for "first_kex_packet_follows" has been suggested. Maybe that's appropriate, but I'd strongly prefer if we could keep that a separate issue, and for now just make sure that the key exchange details stay sane and unambiguous when we add AEAD. Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 30 13:45:21 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A16681B344E for ; Mon, 30 Nov 2015 13:45:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.709 X-Spam-Level: X-Spam-Status: No, score=-1.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 1veozGAvrA1k for ; Mon, 30 Nov 2015 13:45:18 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF2B71AD1A6 for ; Mon, 30 Nov 2015 13:45:18 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 1B83014A384; Mon, 30 Nov 2015 21:45:15 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 9B4C514A379; Mon, 30 Nov 2015 21:45:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id F03CD14A33C for ; Mon, 30 Nov 2015 15:40:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id AoAmGVV1BAZF for ; Mon, 30 Nov 2015 15:40:04 +0000 (UTC) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 8C45714A337 for ; Mon, 30 Nov 2015 15:40:03 +0000 (UTC) Received: by wmww144 with SMTP id w144so134889067wmw.1 for ; Mon, 30 Nov 2015 07:40:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=WAsbUV+fuw+BE/qvOvmhRDEqIM+OL4J1uVV4WWkueRY=; b=QaZsMga56GhkRKdHexv/EYo+J35hykbj430jf1JBoef8alqF5qPYP1vxL67OUoOXaU 7snUhPPE9bscQeqPFv6ff9t/9h1Tw7A9l6qQ4qBGf/CgHKZj6IbZ4pmd+DMbCP6CHiSZ UtBOGpSF1DWwqJgjjTHqkOJmXVDmlaztl1PHl4WbcuEJHNASWTjhuLkVYIQRGz4BbtZ0 nvNaA2EEd9cLe+tKtXpf/YvkQxr2UkEQzymiOPXZExNpnisXYaerMhZvoI8THG24IMCG QKXUFlyH+iBmyKJvSwmdLYqeWWJyf1bYNK8CgvAu8My5GOH4rYdXeNLIHEOiO7dXrAhp zNOg== X-Received: by 10.194.76.65 with SMTP id i1mr32070882wjw.99.1448898001992; Mon, 30 Nov 2015 07:40:01 -0800 (PST) Received: from icsil1noteb193.epfl.ch (icsil1noteb193.epfl.ch. [128.178.151.41]) by smtp.gmail.com with ESMTPSA id q9sm34422235wjo.9.2015.11.30.07.40.00 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 30 Nov 2015 07:40:01 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_9B43D559-FE4C-47EE-965C-DFFCBC6D26EC"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: Binary packet protocol rethink From: Bryan Ford In-Reply-To: <55D41D88-55E6-4FC7-890B-62B5E075B3B7@gmail.com> Date: Mon, 30 Nov 2015 16:40:00 +0100 Cc: Simon Tatham , Peter Gutmann , Damien Miller , Simon Josefsson , "ietf-ssh@netbsd.org" Message-Id: References: <87egfdxebo.fsf@latte.josefsson.org> <1448554180-sup-7145@atreus.tartarus.org> <9A043F3CF02CD34C8E74AC1594475C73F4B857C7@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B92EF0@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B9321A@uxcn10-5.UoA.auckland.ac.nz> <1448874084-sup-4376@atreus.tartarus.org> <55D41D88-55E6-4FC7-890B-62B5E075B3B7@gmail.com> To: =?utf-8?Q?Niels_M=C3=B6ller?= X-Mailer: Apple Mail (2.3096.5) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --Apple-Mail=_9B43D559-FE4C-47EE-965C-DFFCBC6D26EC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 In followup to my own message=E2=80=A6 On 30 Nov 2015, at 14:58, Bryan Ford wrote: > On 30 Nov 2015, at 12:34, Niels M=C3=B6ller = wrote: >> Simon Tatham writes: >>=20 >>> an attacker either guesses the true length by correlating to the >>> TCP headers, or probes it by means of the byte-at-a-time dribbling >>> attack, or actively corrupts the cipher block containing the length = and >>> waits to see when the resulting MAC failure is reported,=20 >>=20 >> Would you be happier if the length field were independently >> authenticated? I'm not sure how strong an authenticator we need, it >> seems a bit silly to use an authentication tag which is much larger = than >> the message, but maybe it's really needed. >=20 > It=E2=80=99s hard for me to see how separately authenticating the = length field would be a benefit; [=E2=80=A6] Sorry, on further thought I *do* see now what might be gained in = principle by authenticating the length field separately, and how that = might be implemented securely. So the SSH record stream might for = example alternate between fixed-size =E2=80=9Clength records=E2=80=9D = and variable-size =E2=80=9Cpayload records=E2=80=9D, each with its own = AEAD MAC. To ensure no mix-and-match vulnerabilities this distinction = must be encoded in the AEAD nonce: e.g., the least-significant bit might = always be 0 for the length record and 1 for the corresponding payload = record. The cost is the space overhead of two MACs per =E2=80=9Cuseful=E2= =80=9D payload record rather than just one, but the benefit is the = receiver obtains certainty that an attacker can never trick the receiver = into trying to read a different-length (e.g., longer) block than the = sender intended. That would indeed be nice, and I can see it = potentially being worth the cost. Just to brainstorm a bit further, here=E2=80=99s a different variant = that might mitigate the space cost somewhat. In every record, include a = length field that indicates the length of the *next* record. Then when = the sender has a batch of records to transmit, it can just send them = consecutively with one MAC per record. But when the sender is about to = go idle, i.e., is transmitting the last record in a batch for which the = sender doesn=E2=80=99t =E2=80=9Calready=E2=80=9D have a subsequent = record immediately ready to go, the sender sets the next-record-length = field to some standard minimum size. The sender can then go idle; the = receiver will wait for that minimum-size next record. When the sender = has something to send again, it sends the promised minimum-length = record, which might contain no useful data but merely get the pipeline = going again, with a next-record-length field appropriate for whatever = the sender actually wants to send next. So this way the protocol = actually pays the bandwidth cost of extra MACs only when the stream goes = idle, not on every record. This design direction does seem attractive in some ways. Bryan= --Apple-Mail=_9B43D559-FE4C-47EE-965C-DFFCBC6D26EC Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ+DCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUEwggQpoAMCAQICEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTA2MjQwMDAwMDBaFw0xNjA2 MjMyMzU5NTlaMCYxJDAiBgkqhkiG9w0BCQEWFWJyeW5vc2F1cnVzQGdtYWlsLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMA89U5ktW7a1k5qjaiycbEbBjLucLdRfzKh5us59o1a Qi0iRQfo1BEq6rG4MTvXburjxUdzuTCaDgOJ+g6PFKNfJP5H2lH962EXCNeJYKOwhpZtwVzpfsPV 8iKw7XjPwPiW4E7Ut7M1UHoN57yUy60/047gyYpZirf4lpv1G//cFcLKIMNB/GGK5YXNlBNalvMY Z/CK1yo8cf3s83gI4KGGE65RL1i3WpAFjwaffp5V6kp3PdiIXuKL8kO2HWID/McrynKKb46ARFzC joiV2qHn27LQiMwBwoDUxzfgCAxAl0uWaFgBqLmcws4lCIXN8jIHp6CNLKKyHHXWukv/EqUCAwEA AaOCAfMwggHvMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSlca2J DhGBY+vVSOfJ1I+3I9NqLzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wIAYDVR0RBBkwF4EVYnJ5bm9zYXVydXNAZ21haWwuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQAMNIE1FhYCtEA9JMwLoNKtQ4hZDcnUKYRcRihDhAHIKSTJtFQKBchp1MBTCP4P 1lfgdDHG+06Rv65VAKfBsjqMZmPQylvsxZg5kPJ5BPVgShQxGl5RSlMN3qLDcSbQt/6uPv9U+Vgq 8StMI6fIRSbbPwyKyZyM8gUnxR34dxzJ+mSGi0kdtUE36FIabTeXtjFVXN/2jDOrsvm8IHlp8nJM 23nHuqUsJyyIYFbaRKhApoMAzC5gynlg6APV2hz/JYlKSJABwpxZjYAtpyz5rQVIi2pPWs2Te2cd faykisGAOu/7nJtlcEGMCSd61tM43matZPa3MuBiko8kuzj0RMigMYIDwzCCA78CAQEwgbAwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQFqWbTcRwZIVaBthymnmm 6jAJBgUrDgMCGgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNTExMzAxNTQwMDBaMCMGCSqGSIb3DQEJBDEWBBQAQ3RE5Tz7chJeFNpOkzgdvdfZjTCBwQYJ KwYBBAGCNxAEMYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBalm03EcGSFWgbYcpp5puowgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcN AQEBBQAEggEAW6p6oxk9JJPVA5ddpte9d1nFJ6vACwwArikp3wLRAYOH9voB2WL61LTJhmg/9CAd xdioVWXPMtJ3JWpeA5IuBuatI8IwZ+6f0DdYFsa6/RzN7T++yITs9r72yF860f7M9oluCrvIDaPz 23T0KjKCkRyAPe0Vzn8h/IZb37Mq3MSc8XHfZhsF7iNWiSf7lEsqyDz9aSUHmogsUO7yeZR+G23j dm5WWmKSieYKH+9PjNLxOGAhgyVjnimCVU9wWti4CbC4y9pcE5nRhkrKdgrztX1esAZTSOA1GYNw TgvF1rjJLcSWM4ljHWGWPckApO40+RmssrW6gcrJFUx8PH3DywAAAAAAAA== --Apple-Mail=_9B43D559-FE4C-47EE-965C-DFFCBC6D26EC-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 30 13:45:29 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF8CF1B344E for ; Mon, 30 Nov 2015 13:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_22=0.6, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 PWknXFk3MGfy for ; Mon, 30 Nov 2015 13:45:27 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE82D1AD1A6 for ; Mon, 30 Nov 2015 13:45:26 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 8911014A3A2; Mon, 30 Nov 2015 21:45:26 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 070EA14A379; Mon, 30 Nov 2015 21:45:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 8212A14A426 for ; Mon, 30 Nov 2015 13:58:28 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id EtaWtf8J1HWQ for ; Mon, 30 Nov 2015 13:58:27 +0000 (UTC) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id C30C014A3A2 for ; Mon, 30 Nov 2015 13:58:26 +0000 (UTC) Received: by wmww144 with SMTP id w144so138718950wmw.0 for ; Mon, 30 Nov 2015 05:58:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=1a20k+AWMyXfZXyuALH4WaJ16e/DUgbLrIRIus+224g=; b=HmUe0M6XRshk7fRfXJWu/xCEH9KzH3grOELWb0ssPIbPeQd6BI+K4/cZWBTkwPDn2l /eJjVi8qURe+NPy+XK5QxVBlzVGgsp5LG1XEHI2LcFgbyIPidEOu62Buh8BNgg9mgDcz q7HTLAUTDtLzCOjOdBo6fX6KPYBmktZFezJ6cKidVFOCecBpcNlj9XH8TSjOQ4M2ycVJ R/O2YVUoeNSIW+BTzExwkE56L4O5LRkHbz7+xqSd3WuoI7XijYqJ2VxJ0ZEWPy7zEmvg 50hjxDlDL23eVW7BzgD7jv6Iy/t6m1LFFaCaRcnJA+EHlbGksXFePt/P4sI86Au+9NjB bIhg== X-Received: by 10.28.60.11 with SMTP id j11mr27175335wma.57.1448891905120; Mon, 30 Nov 2015 05:58:25 -0800 (PST) Received: from icsil1noteb193.epfl.ch (icsil1noteb193.epfl.ch. [128.178.151.41]) by smtp.gmail.com with ESMTPSA id bk2sm47109686wjc.3.2015.11.30.05.58.22 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 30 Nov 2015 05:58:23 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_E9D7C51F-4574-44C0-8CAA-F1151CD998B7"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: Binary packet protocol rethink From: Bryan Ford In-Reply-To: Date: Mon, 30 Nov 2015 14:58:22 +0100 Cc: Simon Tatham , Peter Gutmann , Damien Miller , Simon Josefsson , "ietf-ssh@netbsd.org" Message-Id: <55D41D88-55E6-4FC7-890B-62B5E075B3B7@gmail.com> References: <87egfdxebo.fsf@latte.josefsson.org> <1448554180-sup-7145@atreus.tartarus.org> <9A043F3CF02CD34C8E74AC1594475C73F4B857C7@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B92EF0@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B9321A@uxcn10-5.UoA.auckland.ac.nz> <1448874084-sup-4376@atreus.tartarus.org> To: =?utf-8?Q?Niels_M=C3=B6ller?= X-Mailer: Apple Mail (2.3096.5) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --Apple-Mail=_E9D7C51F-4574-44C0-8CAA-F1151CD998B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I learned about this discussion thread from Peter=E2=80=99s mention of = it on the TLS list, where as he mentioned a parallel debate is going = on=E2=80=A6 (Thanks Peter; hope you don=E2=80=99t mind me stalk=E2=80=A6e= r, following your hint over here. ;) ) On 30 Nov 2015, at 12:34, Niels M=C3=B6ller = wrote: > Simon Tatham writes: >=20 >> an attacker either guesses the true length by correlating to the >> TCP headers, or probes it by means of the byte-at-a-time dribbling >> attack, or actively corrupts the cipher block containing the length = and >> waits to see when the resulting MAC failure is reported,=20 >=20 > Would you be happier if the length field were independently > authenticated? I'm not sure how strong an authenticator we need, it > seems a bit silly to use an authentication tag which is much larger = than > the message, but maybe it's really needed. It=E2=80=99s hard for me to see how separately authenticating the length = field would be a benefit; in fact I would worry about whether it could = introduce a weakness, e.g., where an attacker could somehow contrive = =E2=80=9Cmix-and-match=E2=80=9D attacks that could get a receiver to use = one (correctly-MAC=E2=80=99d) length field with a different (correctly = but independently MAC=E2=80=99d) payload to cause Bad Things of whatever = kind to happen. I also don=E2=80=99t see any essential reason or even = important advantage of doing so. However, I do (think) I see the tension that might seem to suggest = treating the length independently from the payload: in a protocol like = SSH that encrypts both header and payload, you would like to read and = decrypt the length first, then separately read and decrypt the payload = (perhaps at a different location in memory). Especially if the protocol = moves to using AEAD ciphers, which has been suggested and I agree is = probably generally a worthwhile idea, the standard AEAD API wants to = assume the length is already known at decryption/integrity-check time, = e.g., by being carried in the normally-unencrypted Additional Data (AD) = field. On the TLS list I posted a proposal for one way (of many) to resolve = this seeming conflict between a desire to move to AEAD and a desire to = continue encrypting headers (which I strongly support, whether in TLS or = SSH or any other encrypted protocol). A copy of my proposal is attached = below, FWIW. In summary, you still only need one MAC, and you = integrity-check the header (including length) together with the payload = in the =E2=80=9Cmain=E2=80=9D AEAD decryption, but you separately = encrypt (without authentication) the header using either a stream cipher = or an AEAD used as a stream cipher. The fundamental argument for why = the unauthenticated encryption of the header is safe is because it just = changes the encoding of the header without affecting how the header is = authenticated (separately, while authenticating the body). Thus, = changing the header encoding while leaving the authentication and = body-encryption unchanged from standard AEAD practice cannot make = security any worse than just transmitting the header (AD part) in = cleartext, and can (sometimes) be a security benefit. >> by making sure that the encrypted block boundaries do not also >> reveal the length or position of any actually important data, such as = a >> particular SSH_MSG_anything. >=20 > Can we do that with the current protocol? If so, guidance is > appreciated. What I object to is removing a feature (encrypted message > lengths) which enables known counter measures to traffic analysis, and > replace it by nothing. Strongly agreed on this. The fact that a particular security measure = (like encrypting headers) isn=E2=80=99t by itself an end-all one-stop = solution to all the world=E2=80=99s traffic analysis problems doesn=E2=80=99= t make it not worthwhile. Cheers Bryan = =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94(snip= )=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 The idea of encrypting TLS record headers has come up before, the most important purpose being to hide record lengths and boundaries and make fingerprinting and traffic analysis harder. I had convinced myself that goal this would be "too hard" to accomplish in TLS 1.3, but after further thought I'm not so sure. So I would like to request comment on one approach that strikes me as a practical and requires only a rather minor change to the current spec. The quick summary: * To encrypt a record, we first AEAD-encrypt the record's payload, protecting the header fields via the additional_data, exactly as currently specified. But then we XOR-encrypt the 5-byte TLS header just before transmission, using a (separate) stream cipher indexed by a nonce that depends on record sequence number and *_write_iv, in exactly the same way the AEAD is already nonce-indexed. * To decrypt a record, we simply do the reverse: first use the stream cipher with the appropriate nonce to XOR-decrypt the 5-byte TLS header, then sanity-check it as usual to determine its length, read the rest of the record, and submit it to AEAD for decryption and full integrity checking as before. That's it, in a nutshell. Two likely concerns immediately arise, discussed below, but feel free to TL;DR the rest if you don't share these concerns. --- Concern #1: What if an active attacker messes with the TLS header, especially the length field, since stream ciphers don't protect integrity? The simple answer is that *exactly* the same thing happens as now: the AEAD decryption attempt fails, because the (stream-decrypted) header is AEAD-protected as additional_data. Nothing is gained or lost. SSH, which did something like this, ran into trouble with attackers being able to twiddle the record length field to make the record length look big, causing the receiver to try to receive a very large record, and hence appear to the user to hang, instead of immediately detecting the modification and terminating the connection. But there are three mitigating factors here: (1) TLS is not usually used for interactive terminal traffic like SSH is; (2) TLS's 2-byte record length field imposes a pretty reasonable upper-bound on the maximum size an attacker could maliciously make a record appear to be; and (3) if this risk of length-twiddling is at all a problem in this proposed encrypted-header protocol, then it's already a problem for the current TLS 1.3 spec without encrypted headers, because active attackers can twiddle the bits of a cleartext length field just as easily (and even be *certain* they are making the length appear large!). So I can't see any way this length-twiddling vulnerability becomes any worse, and maybe it gets a bit better (because the attacker can no longer be entirely certain whether he's setting a 1 bit to 0 or a 0 bit to 1). --- Concern #2: Do we want to have to go to the trouble of adding a stream cipher to every TLS 1.3-compatible ciphersuite? Answer: maybe not, but we don't necessarily need to. We could instead just specify a generic method of using the ciphersuite's main AEAD as a stream cipher for header encryption/decryption purposes. The conceptually simplest approach I can think of: In the specification of how AEAD nonces are generated (section 5.2.2 of draft-ietf-tls-tls13-07), reserve the least-significant bit of the record sequence number, so that sequence numbers increment by 2 rather than 1 each record. Thus, we get two unique nonces per record from the same set of symmetric keys. We first use the nonce with a '0' least-significant bit to perform the regular AEAD-encryption of the record with the header info as additional_data. Then for the same record we use the nonce with a '1' least-significant to AEAD-encrypt a sequence of five zero bytes ("\0\0\0\0\0"), and use the first five bytes of result as the cipherstream to XOR the 5-byte TLS header with before transmitting. The AEAD will of course uselessly append some kind of authenticator to this ciphertext that we won't end up using, but that's OK. The receiver will just use AEAD-encrypt (again) on the same five-zero-byte message to reproduce the 5 cipherstream bytes with which to decrypt the TLS header. Thus, senders perform two AEAD-encrypts per record, and receivers do one AEAD-encrypt and one AEAD-decrypt per record. This approach seems pretty conceptually clean and simple, but has the performance downside that we always need to invoke the AEAD twice per record rather than once, which might be (a bit) costly especially when records are small. So a simple refinement is to amortize this cost across records: e.g., once every 256 records (every sequence number ending in 0x00) we AEAD-encrypt a sequence of 5*256=3D1280 zero bytes, = and the result in 5-byte chunks as the cipherstream with which to encrypt and decrypt 256 consecutive TLS record headers. Thus, we're only adding one additional AEAD-encryption of a "normal-packet-sized" 1280-byte blob once every 256 records, which seems likely to be a pretty inconsequential performance cost. --- Comments? Thanks Bryan= --Apple-Mail=_E9D7C51F-4574-44C0-8CAA-F1151CD998B7 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ+DCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUEwggQpoAMCAQICEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTA2MjQwMDAwMDBaFw0xNjA2 MjMyMzU5NTlaMCYxJDAiBgkqhkiG9w0BCQEWFWJyeW5vc2F1cnVzQGdtYWlsLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMA89U5ktW7a1k5qjaiycbEbBjLucLdRfzKh5us59o1a Qi0iRQfo1BEq6rG4MTvXburjxUdzuTCaDgOJ+g6PFKNfJP5H2lH962EXCNeJYKOwhpZtwVzpfsPV 8iKw7XjPwPiW4E7Ut7M1UHoN57yUy60/047gyYpZirf4lpv1G//cFcLKIMNB/GGK5YXNlBNalvMY Z/CK1yo8cf3s83gI4KGGE65RL1i3WpAFjwaffp5V6kp3PdiIXuKL8kO2HWID/McrynKKb46ARFzC joiV2qHn27LQiMwBwoDUxzfgCAxAl0uWaFgBqLmcws4lCIXN8jIHp6CNLKKyHHXWukv/EqUCAwEA AaOCAfMwggHvMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSlca2J DhGBY+vVSOfJ1I+3I9NqLzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wIAYDVR0RBBkwF4EVYnJ5bm9zYXVydXNAZ21haWwuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQAMNIE1FhYCtEA9JMwLoNKtQ4hZDcnUKYRcRihDhAHIKSTJtFQKBchp1MBTCP4P 1lfgdDHG+06Rv65VAKfBsjqMZmPQylvsxZg5kPJ5BPVgShQxGl5RSlMN3qLDcSbQt/6uPv9U+Vgq 8StMI6fIRSbbPwyKyZyM8gUnxR34dxzJ+mSGi0kdtUE36FIabTeXtjFVXN/2jDOrsvm8IHlp8nJM 23nHuqUsJyyIYFbaRKhApoMAzC5gynlg6APV2hz/JYlKSJABwpxZjYAtpyz5rQVIi2pPWs2Te2cd faykisGAOu/7nJtlcEGMCSd61tM43matZPa3MuBiko8kuzj0RMigMYIDwzCCA78CAQEwgbAwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQFqWbTcRwZIVaBthymnmm 6jAJBgUrDgMCGgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNTExMzAxMzU4MjNaMCMGCSqGSIb3DQEJBDEWBBQzEEWij44vp7lZMCgu1I02g5Hk2TCBwQYJ KwYBBAGCNxAEMYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBalm03EcGSFWgbYcpp5puowgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcN AQEBBQAEggEAQ2gT6gwCW//uWQhNH43He2WbunYCsi0CaBBrCgNGjkDp2/TLgOt2Vy7dO50fqLFH qvJssI1Cys7tcnEX+1MImWCsMpxVVJENBf834eE8HaHfCB2pqfZlkir6ciqRpDCyb0LkHbcFMbuq hMY4t2nNvkTzh2K3f9woMj7WcpZWXXwv1QZHPzAw/hS2NLhMR3DYXlez9i8ZYhx6sqtQY+cLd27z Ltsno7vcT1qr1b6lKhyDgUyfnOL480EFycpcln93zkX2M91zsEy8Hapyqsn/DZCkuKZ6ziedb5pi TVERU7E6tSxHR8snC+jsbanDKzj+9FCiDug2PkiQN6sSqWbTfgAAAAAAAA== --Apple-Mail=_E9D7C51F-4574-44C0-8CAA-F1151CD998B7--
Niels M=C3=B6ller <nisse@lysator.liu.se> , 11/1= 0/2015 5:02 AM:
denis bider <ietf-ssh3@denisbider.com> writes:

> The current RSA SHA-2 draft defines signature algorithm names sepa= rate
> from public key format. I believe this is important: it allows for
> seamless upgrade of existing RSA host and user keys to use the new
> signature methods. If we do not allow for this seamless upgrade,
> adoption of SHA-2 for host and user authentication will be delayed= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 9 23:18:46 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2BA1A00DA for ; Mon, 9 Nov 2015 23:18:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 3qyTsJkIq1D8 for ; Mon, 9 Nov 2015 23:18:45 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 585541A00D5 for ; Mon, 9 Nov 2015 23:18:45 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id D933214A2BC; Tue, 10 Nov 2015 07:18:44 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 79A2C14A2B9; Tue, 10 Nov 2015 07:18:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id A321B14A2D0 for ; Tue, 10 Nov 2015 04:35:23 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id TtEKMnMpynt5 for ; Tue, 10 Nov 2015 04:35:23 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id D006214A2CC for ; Tue, 10 Nov 2015 04:35:21 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 430234003E; Tue, 10 Nov 2015 05:35:19 +0100 (CET) Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id D70BE40016; Tue, 10 Nov 2015 05:35:16 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Tue, 10 Nov 2015 05:35:16 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: "Mark D. Baushke" Cc: Peter Gutmann , denis bider , Jeffrey Hutzelman , "ietf-ssh\@NetBSD.org" , "stephen.farrell\@cs.tcd.ie" , "jon\@siliconcircus.com" Subject: Re: DH group exchange (Re: SSH key algorithm updates) References: <9A043F3CF02CD34C8E74AC1594475C73F4B5993D@uxcn10-5.UoA.auckland.ac.nz> <2096379125-720@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B599ED@uxcn10-5.UoA.auckland.ac.nz> <55190.1447001241@eng-mail01.juniper.net> <9A043F3CF02CD34C8E74AC1594475C73F4B5A9BC@uxcn10-5.UoA.auckland.ac.nz> <65113.1447107876@eng-mail01.juniper.net> Date: Tue, 10 Nov 2015 05:35:16 +0100 In-Reply-To: <65113.1447107876@eng-mail01.juniper.net> (Mark D. Baushke's message of "Mon, 9 Nov 2015 14:24:36 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list "Mark D. Baushke" writes: >> I still think it is inappropriate to use group-exchange for groups >> that are going to be widely used.=20 > > I suppose we disagree on this subject. Maybe not a very wide disagreement. I have no strong objection to including *reviewed* fixed groups in the list of group-exchange alternatives (even if I think using names to enable negotiation is desirable, adn that it's unfortunate that the client isn't informed whether a particular group is fixed or ephemeral). I do object to using fixed groups which have not been properly reviewed, e.g., generated at compile time for a widely used server binary. > It may also be desirable to setup a way that RFC 3526 groups: > > diffie-hellman-group14-sha256 (2048-bit MODP group - 112 bits of securi= ty) > diffie-hellman-group15-sha256 (3072-bit MODP group - 128 bits of securi= ty) > > diffie-hellman-group16-sha384 (4096-bit MODP group - ~150 bits of secur= ity) I think that is highly desirable. Implementation burden should be quite small. One of these could be RECOMMENDED or even REQUIRED. Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 9 23:19:06 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 693EB1A00EA for ; Mon, 9 Nov 2015 23:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 gmIqxAzkrSOE for ; Mon, 9 Nov 2015 23:19:05 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 850A91A00E2 for ; Mon, 9 Nov 2015 23:19:05 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 0E9DF14A2C4; Tue, 10 Nov 2015 07:19:05 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id A6A7414A2C1; Tue, 10 Nov 2015 07:19:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id AFCE114A2A1 for ; Tue, 10 Nov 2015 05:02:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id x7ybInlJTUTn for ; Tue, 10 Nov 2015 05:02:56 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id A12D014A29B for ; Tue, 10 Nov 2015 05:02:56 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 354F14003E; Tue, 10 Nov 2015 06:02:54 +0100 (CET) Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id DE4CA40016; Tue, 10 Nov 2015 06:02:52 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Tue, 10 Nov 2015 06:02:52 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: denis bider Cc: Peter Gutmann , ietf-ssh@netbsd.org, Jeffrey Hutzelman , "Mark D. Baushke" , stephen.farrell@cs.tcd.ie, jon@siliconcircus.com, djm@mindrot.org, Max Horn Subject: Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation References: <2251009843-932@skroderider.denisbider.com> Date: Tue, 10 Nov 2015 06:02:52 +0100 In-Reply-To: <2251009843-932@skroderider.denisbider.com> (denis bider's message of "Tue, 10 Nov 2015 04:20:10 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list denis bider writes: > The current RSA SHA-2 draft defines signature algorithm names separate > from public key format. I believe this is important: it allows for > seamless upgrade of existing RSA host and user keys to use the new > signature methods. If we do not allow for this seamless upgrade, > adoption of SHA-2 for host and user authentication will be delayed. I fully agree this makes sense. > You assert that the "ssh-" prefix is necessary to convey a hint about > the encoding. To me, this appears to be an arbitrary interpretation. I > personally do not see this as relevant. My understanding of this design is that the prefix simply means "encoding is ssh-specific", and that is applicable also to the new signature algorithm. I'm sorry if I sounded too harsh; I think consistent naming is important, but it is still a minor detail. > - The name of the public key format, which is the SSH-specific key > format, continues to be "ssh-rsa". This indulges the idea that an > "ssh-" prefix should be used if the format is SSH-specific. I view it sligtly differently. The "ssh-rsa" string inside the key encoding is not a name intended to be parsed (at least not when received over the wire), it's just required to be there. Which *is* a bit of a peculiar design. The name *identifying* the algorithm and format is the name used in negotiating the algorithm, in keyexchange and user authentication, and it must be known prior to parsing an encoded key or signature. And then it happens that the different algorithms named "ssh-rsa" and "rsa-sha2-256" are specified to use the same encoding of public keys (for good reasons as you explain above). > - The signature algorithm names are "rsa-sha2-256" and "rsa-sha2-512". > The signature encodings just contain the RSA signature blob, which is > defined in RFC 3447. This is not SSH-specific. That is a relevant detail I had missed at first reading. So you use a standard format for the signature (and just prepend a fixed string, for consistency with other signature algorithms in ssh), but keep using the ssh-specific encoding for the keys. To sum up the naming issue: We seem to disagree, but I can live with either name. I'll do my best to refrain from writing more on that issue, but I'd be happy to hear other's opinions. Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 9 23:29:58 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F12DA1A039E for ; Mon, 9 Nov 2015 23:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 sZcFGF5YkPpb for ; Mon, 9 Nov 2015 23:29:56 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B617F1A0383 for ; Mon, 9 Nov 2015 23:29:56 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id C00FF14A2CA; Tue, 10 Nov 2015 07:29:54 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 425CB14A2C1 for ; Tue, 10 Nov 2015 07:29:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id fkWSe-ANa70V for ; Tue, 10 Nov 2015 07:29:49 +0000 (UTC) Received: from newmailhub.uq.edu.au (mailhub2.soe.uq.edu.au [130.102.132.209]) by mail.netbsd.org (Postfix) with ESMTP id 0508514A2AD for ; Tue, 10 Nov 2015 07:29:46 +0000 (UTC) Received: from smtp1.soe.uq.edu.au (smtp1.soe.uq.edu.au [10.138.113.40]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id tAA7TGjS037160; Tue, 10 Nov 2015 17:29:16 +1000 Received: from mailhub.eait.uq.edu.au (holly.eait.uq.edu.au [130.102.79.58]) by smtp1.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id tAA7TGSo050525 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Nov 2015 17:29:16 +1000 Received: from natsu.mindrot.org (natsu.mindrot.org [130.102.96.2]) by mailhub.eait.uq.edu.au (8.15.1/8.15.1) with ESMTP id tAA7TEjO018798; Tue, 10 Nov 2015 17:29:14 +1000 (AEST) Received: by natsu.mindrot.org (Postfix, from userid 1000) id 672FAA4F2F; Tue, 10 Nov 2015 18:29:08 +1100 (AEDT) Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id 63186A4F07; Tue, 10 Nov 2015 18:29:08 +1100 (AEDT) Date: Tue, 10 Nov 2015 18:29:08 +1100 (AEDT) From: Damien Miller To: Peter Gutmann cc: denis bider , "ietf-ssh@netbsd.org" , Jeffrey Hutzelman , =?ISO-8859-15?Q?NielsM=F6ller?= , "Mark D. Baushke" , "stephen.farrell@cs.tcd.ie" , "jon@siliconcircus.com" , Max Horn Subject: RE: Experimental server for RSA SHA-2 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B5BD70@uxcn10-5.UoA.auckland.ac.nz> Message-ID: References: <2073638188-720@skroderider.denisbider.com>,<2096718084-720@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B5BD70@uxcn10-5.UoA.auckland.ac.nz> User-Agent: Alpine 2.20 (BSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub X-Scanned-By: MIMEDefang 2.75 on 130.102.79.58 X-UQ-FilterTime: 1447140560 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Tue, 10 Nov 2015, Peter Gutmann wrote: > So I figured this would be the quickest RFC (draft) implementation ever, one > line of code: > > { "rsa-sha2-256", 12, CRYPT_ALGO_RSA, CRYPT_ALGO_RSA, CRYPT_ALGO_SHA2 }, > > However, this doesn't work, for several reasons... the biggest problem > is that the hash algorithm HASH is already specified in the keyex > method, for "diffie- hellman-group-exchange-sha1" it's SHA-1 and for > "diffie-hellman-group- exchange-sha256" it's SHA2-256. So specifying > "rsa-sha2-256" for "diffie- hellman-group-exchange- sha1" doesn't make > sense, and specifying it for "diffie-hellman-group-exchange-sha256" is > redundant. I don't think this is right: the hash used in the signature algorithm has always been independent of the key exchange hash. Moreover, the key exchange hash is only tangentially involved for publickey authentication. > Another problem is shown up by the argument about naming, that since > this is a standard SSH signature, the "ssh-" isn't needed. Looking > at the draft, this isn't anything like any other SSH signature, it > uses RSA-PSS not PKCS #1, which no other SSH signature uses. So it > needs some indicator in the name that it's a nonstandard signature > type, not a standard SSH signature, e.g. "ssh-rsa-pss" to contrast > with the standard "ssh-rsa". It also means that you need to do an > implementation of RSA-PSS just to support this signature type. > > The result is that the draft is really "Use of RSA-PSS with > SSH", not "Use of RSA Keys with SHA-2 256 and 512 in Secure > Shell (SSH)", since they're already in use with SHA-2 when > "diffie-hellman-group-exchange-sha256" is used. IMO it's both. I don't really care for bikeshedding names, but if I were picking it, then it would be "rsa-pss-sha256". -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 9 23:31:08 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF921A0405 for ; Mon, 9 Nov 2015 23:31:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 YYJKdp4iVLHo for ; Mon, 9 Nov 2015 23:31:07 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 465071A03C7 for ; Mon, 9 Nov 2015 23:31:07 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 9027314A2C1; Tue, 10 Nov 2015 07:31:06 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id CA28614A2A4 for ; Tue, 10 Nov 2015 07:31:03 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 2svGGOD7GKDY for ; Tue, 10 Nov 2015 07:31:03 +0000 (UTC) Received: from newmailhub.uq.edu.au (mailhub1.soe.uq.edu.au [130.102.132.208]) by mail.netbsd.org (Postfix) with ESMTP id D75CF14A18A for ; Tue, 10 Nov 2015 07:31:02 +0000 (UTC) Received: from smtp2.soe.uq.edu.au (smtp2.soe.uq.edu.au [10.138.113.41]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id tAA7UfOr010226; Tue, 10 Nov 2015 17:30:41 +1000 Received: from mailhub.eait.uq.edu.au (hazel.eait.uq.edu.au [130.102.60.17]) by smtp2.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id tAA7Uff0003528 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Nov 2015 17:30:41 +1000 Received: from natsu.mindrot.org (natsu.mindrot.org [130.102.96.2]) by mailhub.eait.uq.edu.au (8.15.1/8.15.1) with ESMTP id tAA7UebE031386; Tue, 10 Nov 2015 17:30:40 +1000 (AEST) Received: by natsu.mindrot.org (Postfix, from userid 1000) id 97CDFA4F32; Tue, 10 Nov 2015 18:30:40 +1100 (AEDT) Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id 96DBCA4F31; Tue, 10 Nov 2015 18:30:40 +1100 (AEDT) Date: Tue, 10 Nov 2015 18:30:40 +1100 (AEDT) From: Damien Miller To: =?ISO-8859-15?Q?Niels_M=F6ller?= cc: "Mark D. Baushke" , Peter Gutmann , denis bider , Jeffrey Hutzelman , "ietf-ssh@NetBSD.org" , "stephen.farrell@cs.tcd.ie" , "jon@siliconcircus.com" Subject: Re: DH group exchange (Re: SSH key algorithm updates) In-Reply-To: Message-ID: References: <9A043F3CF02CD34C8E74AC1594475C73F4B5993D@uxcn10-5.UoA.auckland.ac.nz> <2096379125-720@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B599ED@uxcn10-5.UoA.auckland.ac.nz> <55190.1447001241@eng-mail01.juniper.net> <9A043F3CF02CD34C8E74AC1594475C73F4B5A9BC@uxcn10-5.UoA.auckland.ac.nz> <65113.1447107876@eng-mail01.juniper.net> User-Agent: Alpine 2.20 (BSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="0-1695002146-1447140640=:8324" X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub X-Scanned-By: MIMEDefang 2.75 on 130.102.60.17 X-UQ-FilterTime: 1447140641 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1695002146-1447140640=:8324 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT On Tue, 10 Nov 2015, Niels Möller wrote: > > It may also be desirable to setup a way that RFC 3526 groups: > > > > diffie-hellman-group14-sha256 (2048-bit MODP group - 112 bits of security) > > diffie-hellman-group15-sha256 (3072-bit MODP group - 128 bits of security) > > > > diffie-hellman-group16-sha384 (4096-bit MODP group - ~150 bits of security) FWIW OpenSSH has been using RFC3526 group 16 as the fallback group for group-exchange when it can't find a local pre-computed group list. -d --0-1695002146-1447140640=:8324-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Nov 10 00:18:48 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B1E1A879C for ; Tue, 10 Nov 2015 00:18:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 n_4UFzLMEMBP for ; Tue, 10 Nov 2015 00:18:47 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 661171A879A for ; Tue, 10 Nov 2015 00:18:47 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id E7D5614A2D6; Tue, 10 Nov 2015 08:18:43 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 6C90714A2CE for ; Tue, 10 Nov 2015 08:18:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id kzOMndSqAai3 for ; Tue, 10 Nov 2015 08:18:38 +0000 (UTC) Received: from newmailhub.uq.edu.au (mailhub1.soe.uq.edu.au [130.102.132.208]) by mail.netbsd.org (Postfix) with ESMTP id 5703E14A2AA for ; Tue, 10 Nov 2015 08:18:38 +0000 (UTC) Received: from smtp1.soe.uq.edu.au (smtp1.soe.uq.edu.au [10.138.113.40]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id tAA8IGZ8043362; Tue, 10 Nov 2015 18:18:16 +1000 Received: from mailhub.eait.uq.edu.au (hazel.eait.uq.edu.au [130.102.60.17]) by smtp1.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id tAA8IFBP044224 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Nov 2015 18:18:15 +1000 Received: from natsu.mindrot.org (natsu.mindrot.org [130.102.96.2]) by mailhub.eait.uq.edu.au (8.15.1/8.15.1) with ESMTP id tAA8IBfM006300; Tue, 10 Nov 2015 18:18:12 +1000 (AEST) Received: by natsu.mindrot.org (Postfix, from userid 1000) id 8C77BA4F2F; Tue, 10 Nov 2015 19:18:11 +1100 (AEDT) Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id 87B59A4F07; Tue, 10 Nov 2015 19:18:11 +1100 (AEDT) Date: Tue, 10 Nov 2015 19:18:11 +1100 (AEDT) From: Damien Miller To: denis bider cc: ietf-ssh@netbsd.org, Jeffrey Hutzelman , =?ISO-8859-15?Q?NielsM=F6ller?= , "Mark D. Baushke" , stephen.farrell@cs.tcd.ie, jon@siliconcircus.com, Peter Gutmann , Max Horn Subject: Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation In-Reply-To: <2070897157-568@skroderider.denisbider.com> Message-ID: References: <2070897157-568@skroderider.denisbider.com> User-Agent: Alpine 2.20 (BSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub X-Scanned-By: MIMEDefang 2.75 on 130.102.60.17 X-UQ-FilterTime: 1447143497 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Sun, 8 Nov 2015, denis bider wrote: > (1) I have uploaded a new version of the RSA SHA-2 draft: > > https://tools.ietf.org/html/draft-rsa-dsa-sha2-256-02 Some feedback on the draft: > 1. Overview and Rationale The DSA bits in here don't seem very relevant. Could I suggest ditching them or putting them in an appendix? > All aspects of the "ssh-rsa" format are kept, including the encoded > string "ssh-rsa", in order to allow users' existing RSA keys to be > used with the new signature formats, without requiring re-encoding, > or affecting already trusted key fingerprints. I can see the argument for keeping "ssh-rsa" as the key name and another name for the revised signature format. I'm not entirely sure about it, I guess because I'm used to there being an identity between key types and signature types in the SSH protocol. > 3. Discovery of signature algorithms supported by servers > > When a public key format can use multiple signature algorithms, it can > be useful for a mechanism to exist which a client can use to discover > signature algorithms accepted by a server for user authentication > without resorting to trial and error in authentication requests. > > Such a mechanism is defined in [SSH-EXT-INFO], which describes general > purpose extension negotiation for SSH, and specifies discovery of > signature algorithms as a usage case. IMO a "publickey2" (or somesuch) method that included a custom failure message to list the supported key types seems like a better way to offer this. > Public Key Algorithm Name Reference Note > rsa-sha2-256 [this document] Section 2 > rsa-sha2-512 [this document] Section 2 As mentioned in my other email, I don't feel super-strongly about naming, but "rsa-pss-sha2-*" seems slightly more descriptive and future-proof. Is it worthwhile to specify a minimum key size for the new signature schemes? -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Nov 10 00:53:02 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4531AD481 for ; Tue, 10 Nov 2015 00:53:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 c8oUAs0E7wi7 for ; Tue, 10 Nov 2015 00:52:55 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 148B61A8903 for ; Tue, 10 Nov 2015 00:52:55 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 08F1614A2E9; Tue, 10 Nov 2015 08:52:54 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id EB47414A2E7 for ; Tue, 10 Nov 2015 08:48:30 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 9ZT58x1xELb3 for ; Tue, 10 Nov 2015 08:48:30 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0769.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:769]) by mail.netbsd.org (Postfix) with ESMTP id 961B714A224 for ; Tue, 10 Nov 2015 08:48:29 +0000 (UTC) Received: from SN1PR05CA0034.namprd05.prod.outlook.com (10.163.68.172) by CY1PR0501MB1387.namprd05.prod.outlook.com (10.160.148.141) with Microsoft SMTP Server (TLS) id 15.1.318.15; Tue, 10 Nov 2015 08:48:26 +0000 Received: from BL2FFO11FD009.protection.gbl (2a01:111:f400:7c09::182) by SN1PR05CA0034.outlook.office365.com (2a01:111:e400:5197::44) with Microsoft SMTP Server (TLS) id 15.1.318.15 via Frontend Transport; Tue, 10 Nov 2015 08:48:25 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=juniper.net; cs.tcd.ie; dkim=none (message not signed) header.d=none;cs.tcd.ie; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.17) by BL2FFO11FD009.mail.protection.outlook.com (10.173.161.15) with Microsoft SMTP Server (TLS) id 15.1.325.5 via Frontend Transport; Tue, 10 Nov 2015 08:48:24 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 10 Nov 2015 00:48:23 -0800 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id tAA8mLD67867; Tue, 10 Nov 2015 00:48:21 -0800 (PST) (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 32A6D1144F; Tue, 10 Nov 2015 00:48:21 -0800 (PST) To: Damien Miller CC: =?us-ascii?Q?=3D=3FISO-8859-15=3FQ=3FNiels=5FM=3DF6ller=3F=3D?= , Peter Gutmann , "denis bider" , Jeffrey Hutzelman , "ietf-ssh@NetBSD.org" , "stephen.farrell@cs.tcd.ie" , "jon@siliconcircus.com" Subject: Re: DH group exchange (Re: SSH key algorithm updates) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73F4B5993D@uxcn10-5.UoA.auckland.ac.nz> <2096379125-720@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B599ED@uxcn10-5.UoA.auckland.ac.nz> <55190.1447001241@eng-mail01.juniper.net> <9A043F3CF02CD34C8E74AC1594475C73F4B5A9BC@uxcn10-5.UoA.auckland.ac.nz> <65113.1447107876@eng-mail01.juniper.net> Comments: In-reply-to: Damien Miller message dated "Tue, 10 Nov 2015 18:30:40 +1100." From: "Mark D. Baushke" MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Nov 2015 00:48:21 -0800 Message-ID: <90378.1447145301@eng-mail01.juniper.net> X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1;BL2FFO11FD009;1:YHKzxHJNS4Wb/EE9eSjPWNsE6fXagIvmqxjc9R1vRN1Hy9QDcA3lUJwBMcQi5oG3pJMESR2xN+we28+QP0psEmg0crHx4dmozwhv1x4fhbXwITSyai5yZvDQEXtV5SfEZu6IfksdoyTwuMpsyQ/3yn0K1oFIiqKz6Prgx8PZKTSiLBkbBl7fMAtRd+qG71O70XJ/ZOaB1t7Yr+WuWD8Y+qvYhXh+iqcCpCpBv1QqGzU/DnOwH6+JdQeD4Lp4tUeS4wnboTnjNt/IlYoAtclRfURwEEEe8CpfygmVOpm39ba2hmqw85kDrZ9GInvN5pTnaBsYIHlAzqvIOCrn4yTZkJ/60QHbj7V+q/Qmt+9KCevNRSm6gaIPupNqluSpxq1riHvv8oePvo45Qucfn5Yhvg== X-Forefront-Antispam-Report: CIP:66.129.239.17;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(2980300002)(189002)(199003)(54094003)(24454002)(106466001)(23676002)(105596002)(97736004)(110136002)(5001960100002)(81156007)(117636001)(87936001)(5007970100001)(19580395003)(19580405001)(69596002)(77096005)(2950100001)(92566002)(93886004)(5003600100002)(189998001)(47776003)(76506005)(53416004)(50466002)(76176999)(54356999)(50986999)(86362001)(11100500001)(6806005)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:CY1PR0501MB1387;H:p-emfe01a-sac.jnpr.net;FPR:;SPF:SoftFail;PTR:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;CY1PR0501MB1387;2:R689+YrhQjtJIgIJjcC6gqAhIoA+nUatqDGQFETaqEqVPlF/G1T0pyimXYR4+DVnW00HHfPQ6hll8gpEmb2Cg8ulrQr/SyqqaKtzIcNsF/LwRuKGh9+NmV026CisrHXB7qUx0plYbVkEfh33FiZE+NL9+RKGn7fFvw6YJfYj9vc=;3:F2q6o77I0yCogaBlE2MngdnVG6663GRbme/6QQoCZxHFyYMq8HJcHAZ4A5UoEDrd88adULNYj8tDOJgiv5YvFQmLM1dFVj4bOrtQtKA0GjsoJzOpOZiI50eNLxSzLYn5jkYxUcpNm/dAkXB3w0VIewboYznqggHx+JaqcQzpRHap8qnwpRvkSTmqkNCmSCgymwgsMZiPZQHm6klpF1/0RkUtfDUton9NIjmQack+Gps=;25:yDvqEuEv+7KQVpqCea8ttLbrUFEHhC4r0htESVuuEnZovkwq3ybT1ZM3cvaRe08Q1H/Tz8HwpnBuxn1TymgtDG5aVjaMabdH63f+glgsh3wba9FlIe0bzNDqSSAkKcl44GLPPVaVpk51UoXJ8C3QHZ/uhHOu3rOsqpg23kzEP09iIlOPBq6jHIy72sL5U9nz6LNlWYBUuvDguvEx3HhpXNB9xvjxBTuYc7C6A0fKJ+fMjpOWW4HoB963/9rnEbzFqQvU4AU4Xbw4geXlG/tzag== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1387; X-Microsoft-Exchange-Diagnostics: 1;CY1PR0501MB1387;20:KSAQvSPWhNaOrfDMNUQyQBcg1wLn3U9T1jh+6TFvyyZLoJNWm8vykkYPYp28GyyAvZKRtkjt8iaTJJGf5idbNWTfFKzHtnyFt8iCwG5QdLfH0lrnfoBnzx8nxfSlBmFk9UcQLlhkGLOPd1ndmoSytcYqpBI4Ig1/76f5KgoR2XE++XvI6LJh3oVRz/sr6T9Mie/XaoPfvOJNk7qpVSthWCaflbh5ijZCjGLEOKBNkSeioF42yAJ6zDRiK/wIzufUIIYYTCWxiIRIeW5USR75yeGIZDxLCKI1VQ84PJwm+KfJ8+7ZXUOl6hRfIcJuSB7ZsYXLpF8m+/WdAi1H8tsQUCtR4h/Vt7WPyGTGNm76cP7xJx09f9acobaUPaTOnz6JXyncYFgdxFX6HuineaSCUmXJZHIeSHzW8iKmvXX19MdKPYhEOoJds1UbmguPR+fX0Te7mLnelvwxHAcE4YCP7+HX3PtEMD7X1CBy+4O27rhmUlNsRHkBtzJCEUv720Fu;4:0x388AWOmo4u8a438hSPnUJiJEMfvOxvyELEuD9yc99xrMpJxCKbm9CuUooviuPEcFd8MNIQ+LGQCF5fsHdluEflq9GS/duG9lJX4o1Oin81RX3syxLmXLYP04VAQdxbLinKrw6WDkSs6QLQKnAZnXoMYQampdaY7sH45YEErOQQB8zearj487tFSlRJLHjElcAMQGbJbI85CVetgnA74OD1+lF34pJrWs95lrNwDUq1klp2gckmcFT7EZSbb19zG1TgLUFTyAhnSHl4Yy/b8ZOxvcr2/JkDx6KhEsP7358zS7ANRL7sH2FM9ZHpKuvkSjM16h6EelL1U6EVheabEybAA4rcj0fUwF1h0ONqzbw3/DBLVHD9P34thlb9TWh1 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001);SRVR:CY1PR0501MB1387;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1387; X-Forefront-PRVS: 07562C22DA X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTFQUjA1MDFNQjEzODc7MjM6WjYxZ1ovai81Mkc1U0JlUCtBMjZYelNI?= =?utf-8?B?K2o3RjZuNkwySDZiWWFkRDk0TGxOMjlLRkdQM0M4dUxKTEpRRjRQbHpVTEJt?= =?utf-8?B?NHJxajc4SThlaGdJNnRmMXZyaGFUYTY5bmNBWHcrcEdFRWFHSVJkd3l2M01I?= =?utf-8?B?T3FncE05YWRBbHNFOGRRY3pCWmlNbytObG9oU0xBd0xCOVNrSGx1b05BaFIr?= =?utf-8?B?VHpKQ2V5ZE5sR2JhYlRNZzJKS2Z2K3c4WDdURVJHU1RXQ1pSbUMxRTVESzY4?= =?utf-8?B?cHJudC9nYVZYeE5GLzlTSnJFT0xjSGxqZzBRRUJCTjF6Sy94S083bDc5TE5y?= =?utf-8?B?K1ZzNDZYQnN1T01Fc3Jib1FlOEZZdGk3TFFZSGpOVFBBMkhLN2dTZEE2ektx?= =?utf-8?B?Rm02NG9acW1rSU1CdEs4NHJ3ZkhUVVB0RmZ5NnZnS3UzUUIvazRqZkZ6ajdE?= =?utf-8?B?Z0cxMWh3elR6dG9PT1h6THk1cFZ3cmVXZFY1cStnckc1Uk9adjlZYXFaZVlE?= =?utf-8?B?enFjVW1wU1pMTEkzS0swNXVmT2tGd0E5T1Y4WjhLbkQxdzZTb0dVQTNmRUdD?= =?utf-8?B?SVNHajkrWVZhczNsNG9Qb3hCYmNsUXBjbkRjMTdlSVdkWjRvUDFzRmhuLzMr?= =?utf-8?B?VUhvYSt4WTRCMTAwdEhkT0dPZlY3eFpKaWJXRVFzUnl2aEJ4bzBMV2V5eGhQ?= =?utf-8?B?eGFSVU1vL2hQNHV5cGNhZU9ONERpV0tDNW1JTlJsb1haR2g0YlJ2RUNLYWNs?= =?utf-8?B?bG9zRmpia2dYOFAzSVk0dmI0WmdFUWc3cUxzNzlaRlVEWXZsVnloMEpxNUxr?= =?utf-8?B?UzVaeU41L1A3NmJoRmIrME5zdlBGRFhKM2YxbWVzd0FoWjZtckFnbk9rOFNW?= =?utf-8?B?bTBwZDVYUUpPeEZtL2UrT1dOSk1EQnlKVERoa2hWbldjeGR6Vk5NSmRVMHI5?= =?utf-8?B?dlVzM04rcUtPNm1iSEx1NUVtSGRJNHQzV0t5TDZMSDBhemszNEdPWFk1SDVx?= =?utf-8?B?Tmlud3M2NXdtbHJzRi90dTNRaHVvWW9Qb3U2Y0FCbjJycmVUZU1xbGdrUEVn?= =?utf-8?B?K0daR1AvUFI5NXRqdURmMkVIa2ZiMkhmcVJqM2JyRHA3NkVoREIzK0Z0OGdP?= =?utf-8?B?NzJZdEkzTU0zTzJZVFJuNEw3QjlGRWNYdzJpd1RKM2UwYWJTVXRNTmdHL0dp?= =?utf-8?B?UzkyWm1ReDV6L2xMM1FVRGYySm9mVzFRMStNUFhRamQyUHptcUFHaHcyVG5h?= =?utf-8?B?Z1N6MkNjbjZPTzZmeEZiVllPOXZGQ1NYNkY3ZzkzU0pZR0tvS3IrU0Z3aDlx?= =?utf-8?Q?i+L6X2kiUIZXiNRg8ZAdrQwEXHcrkyRqnw=3D?= X-Microsoft-Exchange-Diagnostics: 1;CY1PR0501MB1387;5:SxpGFXlTIsxcQvWD7/3cn1p/eYF5cVG44gvUhZres9wdJptsHcjEyGuucgVBFee3Ht5fFn95PFMgMFU0DH1MS1SvSb4GbVBeLxDLy+k9buSMxmhXHZ6Qr5LyyOr9c+sMSidKORyJI6n2smtT7DcjMA==;24:rCJlutYeOmKMLFfJ5Yn22TaeaVeqnBrSZdqdcYTr3h2VI5kPYA7ar2yaz/6C7VrrPHdc5aOcf0Itzd8wh94/9trHN7ELpvVJKLUdb/hq5uo=;20:Oo9cqDd25JvMS4jh6PnwAGPX5230MBWqsHSRvH+WuCvciB1py1cNE8ZTlfuXSgu/L5G05rU9lmUcH4Q+gQeMKQ== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Nov 2015 08:48:24.7953 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.17];Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1387 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hi Damien, Damien Miller writes: > On Tue, 10 Nov 2015, Niels M=C3=B6ller wrote: >=20 > > > It may also be desirable to setup a way that RFC 3526 groups: > > > > > > diffie-hellman-group14-sha256 (2048-bit MODP group - 112 bits of se= curity) > > > diffie-hellman-group15-sha256 (3072-bit MODP group - 128 bits of se= curity) > > > > > > diffie-hellman-group16-sha384 (4096-bit MODP group - ~150 bits of s= ecurity) >=20 > FWIW OpenSSH has been using RFC3526 group 16 as the fallback group for > group-exchange when it can't find a local pre-computed group list. Yes, I am aware that OpenSSH will fall back on group16 with either sha1 or sha2-256 depending on what key exchange method is being used. Given that OpenSSH is using group16 with sha2-256 preserves 128 bits of security, should there be a group16 using either sha2-384 or sha2-512 so that the maximum number of security bits is retained (security bits estimate for RFC 3526 is in this table: +--------+----------+---------------------+---------------------+ | Group | Modulus | Strength Estimate 1 | Strength Estimate 2 | | | +----------+----------+----------+----------+ | | | | exponent | | exponent | | | | in bits | size | in bits | size | +--------+----------+----------+----------+----------+----------+ | 5 | 1536-bit | 90 | 180- | 120 | 240- | | 14 | 2048-bit | 110 | 220- | 160 | 320- | | 15 | 3072-bit | 130 | 260- | 210 | 420- | | 16 | 4096-bit | 150 | 300- | 240 | 480- | | 17 | 6144-bit | 170 | 340- | 270 | 540- | | 18 | 8192-bit | 190 | 380- | 310 | 620- | +--------+----------+---------------------+---------------------+ so, group16 is nominally somewhere between 150-240 bits of security sha2-384 preserves 192 bits of security and sha2-512 preserves 256 bits of security. For that matter, I wonder if we want to take the time to specify "diffie-hellman-group-exchange-sha512" for the larger group sizes while we have RFC4419bis in discussion? Curious, -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Nov 10 00:53:20 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F26B1ACE94 for ; Tue, 10 Nov 2015 00:53:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 9dykNqQkSH7p for ; Tue, 10 Nov 2015 00:53:17 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 872EE1B2850 for ; Tue, 10 Nov 2015 00:53:07 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 2291D14A2E7; Tue, 10 Nov 2015 08:53:07 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 242F814A2DF for ; Tue, 10 Nov 2015 08:52:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id iGx6hhz0lKI7 for ; Tue, 10 Nov 2015 08:52:49 +0000 (UTC) Received: from newmailhub.uq.edu.au (mailhub2.soe.uq.edu.au [130.102.132.209]) by mail.netbsd.org (Postfix) with ESMTP id 00DA814A2D0 for ; Tue, 10 Nov 2015 08:52:46 +0000 (UTC) Received: from smtp2.soe.uq.edu.au (smtp2.soe.uq.edu.au [10.138.113.41]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id tAA8qPqA045888; Tue, 10 Nov 2015 18:52:26 +1000 Received: from mailhub.eait.uq.edu.au (holly.eait.uq.edu.au [130.102.79.58]) by smtp2.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id tAA8qP2A029614 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Nov 2015 18:52:25 +1000 Received: from natsu.mindrot.org (natsu.mindrot.org [130.102.96.2]) by mailhub.eait.uq.edu.au (8.15.1/8.15.1) with ESMTP id tAA8qPb9001235; Tue, 10 Nov 2015 18:52:25 +1000 (AEST) Received: by natsu.mindrot.org (Postfix, from userid 1000) id 54499A4F30; Tue, 10 Nov 2015 19:52:25 +1100 (AEDT) Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id 53B30A4F2F; Tue, 10 Nov 2015 19:52:25 +1100 (AEDT) Date: Tue, 10 Nov 2015 19:52:25 +1100 (AEDT) From: Damien Miller To: Simon Josefsson cc: ietf-ssh@netbsd.org Subject: Re: Curve25519/448 key agreement for SSH In-Reply-To: <87pozjyzxc.fsf@latte.josefsson.org> Message-ID: References: <87pozjyzxc.fsf@latte.josefsson.org> User-Agent: Alpine 2.20 (BSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub X-Scanned-By: MIMEDefang 2.75 on 130.102.79.58 X-UQ-FilterTime: 1447145546 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Mon, 9 Nov 2015, Simon Josefsson wrote: > Aris and me have prepared a document describing key agreement using the > CFRG curves for Secure Shell. As you know, curve25519-sha256@libssh.org > is already implemented by libssh, OpenSSH, Dropbear, and some others. > This is about putting the description of that into IETF format, and to > add the Curve448 hedge variant chosen by CFRG. It might not be detailed > enough for independent implementation, but we hope to get there. Any > review and feedback is welcome. > > https://tools.ietf.org/html/draft-josefsson-ssh-curves Thanks for writing this up. Some feedback: > 2. Key Exchange Methods > > The key exchange procedure is identical to the one described RFC 5656 > chapter 4 of [RFC5656]. Public ephemeral keys are transmitted over > SSH encapsulated into standard SSH strings. RFC5656 describes multiple key exchange procedures (ECDH and ECMQV), so s/the one described RFC 5656/the ECDH method described in RFC 5656/ The procedure isn't completely identical, since different encodings are used for the wire values and the shared secret. IMO it's worth foreshadowing this here. Perhaps something like: The key exchange procedure is similar to the ECDH method described in chapter 4 of [RFC5656], though with a different wire encoding used for public values and the final shared secret. Public ephemeral keys are transmitted over SSH encapsulated into standard SSH strings. I think it is also worth mentioning that the protocol flow, the SSH_MSG_KEX_ECDH_INIT and SSH_MSG_KEX_ECDH_REPLY messages, and the structure of the exchange hash are identical between this and RFC5656 chapter 4. > The whole method is based on the Curve25519 and Curve448 scalar > multiplication, as described in [I-D.irtf-cfrg-curves]. Private and > public keys are generated as described therein, and no special > validation is required beyond what is discussed there. Public keys > are defined as strings of 32 bytes for Curve25519 and 56 bytes for > Curve448. The derived shared secret is is 32 bytes when Curve25519 > is used and 56 bytes when Curve448 is used. I think that it's worth mentioning here that it's [I-D.irtf-cfrg-curves] that specifies encodings for the public values. > The shared secret, k, is defined in SSH specifications to be a big > integer. This number is calculated as follows. X is the 32 bytes > point obtained by the scalar multiplication of the other side's > public key and the local private key scalar. The whole 32 bytes of s/32 bytes/32 or 56 bytes/ here. Maybe mention that X is encoded the same as the public values (AFAIK I-D.irtf-cfrg-curves doesn't explicitly specify an encoding for the shared secret - maybe it should?) > the number X are then converted into a big integer k. This > conversion follows the network byte order. This step differs from > [RFC5656]. Maybe "converted into a big integer k by treating the value X as an unsigned, network-byte order integer". -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Nov 10 00:54:05 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45BC1A8913 for ; Tue, 10 Nov 2015 00:54:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 k9ShhaK9Ro-V for ; Tue, 10 Nov 2015 00:54:04 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 951AC1A8906 for ; Tue, 10 Nov 2015 00:54:04 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 15B1E14A2EF; Tue, 10 Nov 2015 08:54:04 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 7F25D14A2EE for ; Tue, 10 Nov 2015 08:53:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id c1aSb6HzUlDt for ; Tue, 10 Nov 2015 08:53:56 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 4477C14A2DF for ; Tue, 10 Nov 2015 08:53:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1447145636; x=1478681636; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=P8mB+foX1uf2BqHyP9dSEu9Lfna9RauzF8rXEFGkUmU=; b=Pk3Zq8/PA99GpLGjlilZy1iC5GjlBGs8e14WybefmUTZYgHcW93dQ8wB 1YOv+OdQ+n5Epojvv7hAXw/acesiLSnMOCsqSWEk3fN5nun3N9hcTOmtG Y09elWTsTIWGzp5UUrRYXoSAf8KDnmcvnGgRdEjT4/UQ9RF5JyR4g6zjC T+UVVJ5ggjAn2Jj883ZtRo54/LdOczhFxfTtW5dQjlkPxqcubafMAECVm i8HkDNJKXCmVGSnSPAEQQfk43/vODQs0McPx3hoh6zxAQVWzfNxnSFp+c 1mXY6RBVrORgkWJ7911s4SMZ+owuYP8049CuTMnXhlCRbyX3kgVNUfVQk A==; X-IronPort-AV: E=Sophos;i="5.20,269,1444647600"; d="scan'208";a="53528434" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe1.UoA.auckland.ac.nz) ([130.216.4.112]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 10 Nov 2015 21:53:54 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Tue, 10 Nov 2015 21:53:54 +1300 From: Peter Gutmann To: Damien Miller CC: denis bider , "ietf-ssh@netbsd.org" , Jeffrey Hutzelman , =?iso-8859-1?Q?NielsM=F6ller?= , "Mark D. Baushke" , "stephen.farrell@cs.tcd.ie" , "jon@siliconcircus.com" , Max Horn Subject: RE: Experimental server for RSA SHA-2 Thread-Topic: Experimental server for RSA SHA-2 Thread-Index: AQHRGgVgKCANwh+VhEemT+UuTqD4Yp6UzkDX//82vwCAAPFyGw== Date: Tue, 10 Nov 2015 08:53:53 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B5BF20@uxcn10-5.UoA.auckland.ac.nz> References: <2073638188-720@skroderider.denisbider.com>,<2096718084-720@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B5BD70@uxcn10-5.UoA.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Damien Miller writes:=0A= =0A= >I don't think this is right: the hash used in the signature algorithm has= =0A= >always been independent of the key exchange hash. =0A= =0A= Is it? I hope I'm not reading this wrong, but the exchange hash H is what'= s=0A= signed, and that's what's calculated using the hash algorithm HASH, which i= s=0A= specified by e.g. "diffie-hellman-group-exchange-sha256". So=0A= "server_host_key_algorithms" can say RSA or DSA or ECDSA, but not the hash,= =0A= since that's implicit from "kex_algorithms".=0A= =0A= >I don't really care for bikeshedding names, but if I were picking it, then= it=0A= >would be "rsa-pss-sha256".=0A= =0A= It definitely needs to indicate quite clearly that it uses a signature form= =0A= that's not compatible with anything else that SSH has ever used. I'd vote = for=0A= "crunchy-raw-unboned-real-dead-frog-rsa-pss".=0A= =0A= Could I also suggest that the draft include a facility to use standard PKCS= #1=0A= sigs? I really don't want to have to implement a nonstandard (meaning not= =0A= used by any other part of SSH, or any other protocol like PGP, S/MIME, TLS,= =0A= etc) signature format just to be able to use SHA-256 in a sig.=0A= =0A= Peter.=0A= =0A= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Nov 10 01:01:31 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C561B2B62 for ; Tue, 10 Nov 2015 01:01:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 OmH2xGt2iXr1 for ; Tue, 10 Nov 2015 01:01:25 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CEC51B2B3C for ; Tue, 10 Nov 2015 01:01:25 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 5A66314A2F2; Tue, 10 Nov 2015 09:01:23 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 6E1A914A2EE for ; Tue, 10 Nov 2015 09:01:15 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id B2eRGzHMeObf for ; Tue, 10 Nov 2015 09:01:14 +0000 (UTC) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0731.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc09::731]) by mail.netbsd.org (Postfix) with ESMTP id 1C3C114A2E3 for ; Tue, 10 Nov 2015 09:01:13 +0000 (UTC) Received: from BY2PR05CA023.namprd05.prod.outlook.com (10.141.250.13) by BY1PR0501MB1382.namprd05.prod.outlook.com (10.160.107.140) with Microsoft SMTP Server (TLS) id 15.1.318.15; Tue, 10 Nov 2015 09:01:10 +0000 Received: from BY2FFO11FD025.protection.gbl (2a01:111:f400:7c0c::125) by BY2PR05CA023.outlook.office365.com (2a01:111:e400:2c5f::13) with Microsoft SMTP Server (TLS) id 15.1.318.15 via Frontend Transport; Tue, 10 Nov 2015 09:01:10 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=juniper.net; cs.tcd.ie; dkim=none (message not signed) header.d=none;cs.tcd.ie; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.17) by BY2FFO11FD025.mail.protection.outlook.com (10.1.15.214) with Microsoft SMTP Server (TLS) id 15.1.325.5 via Frontend Transport; Tue, 10 Nov 2015 09:01:08 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 10 Nov 2015 01:01:07 -0800 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id tAA916D79663; Tue, 10 Nov 2015 01:01:06 -0800 (PST) (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id B384E11498; Tue, 10 Nov 2015 01:01:05 -0800 (PST) To: Damien Miller CC: denis bider , , "Jeffrey Hutzelman" , =?ISO-8859-15?Q?NielsM=F6ller?= , , , Peter Gutmann , Max Horn Subject: Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation In-Reply-To: References: <2070897157-568@skroderider.denisbider.com> Comments: In-reply-to: Damien Miller message dated "Tue, 10 Nov 2015 19:18:11 +1100." From: "Mark D. Baushke" X-Phone: +1 408 745-2952 (Office) X-Mailer: MH-E 8.5; nmh 1.2; GNU Emacs 24.3.1 X-Face: #8D_6URD2G%vC.hzU MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1;BY2FFO11FD025;1:fAGEfs7gAgMA7MrkSP6OixkeYRGD7NXF4KaOUNPQD7MHEnQZJWI8mN/NLuyeZzXyNz3d7PLgnUTjAWEPgxt+bTXhXUupB8WcKFimf/WXBdHX4BbggodXTZgd9v9l7+E+Hc6STWcNE7vQc3GneJBSbl65XRchS+2LzPy4olYpUREoOr6IRRELCrPPNho6EMpSPopkpqOWYviatve4Fb2q2xjEbRM+hRE5omBAhl/CEFAr6GLtwsljg86g9npCy5hoC4uLUf44F+b08gJZq3SKqtilan+jRUYsXk5neiPTTyWA0tObEbzBgjQFzgHzaWYNujoWZdEokS2YnouO9eAHHKLXNLJ8UFSi5vYoFhVj9Z+VStfR08fC/bapL9rhMpDC4DR+OxeDyWFTWrYd7doTGQ== X-Forefront-Antispam-Report: CIP:66.129.239.17;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(2980300002)(189002)(24454002)(199003)(5001960100002)(97736004)(110136002)(92566002)(5007970100001)(5003940100001)(5003600100002)(117636001)(81156007)(87936001)(2950100001)(189998001)(106466001)(15975445007)(77096005)(105596002)(50466002)(48376002)(76176999)(19580405001)(69596002)(53416004)(47776003)(76506005)(50226001)(6806005)(11100500001)(19580395003)(86362001)(50986999)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:BY1PR0501MB1382;H:p-emfe01a-sac.jnpr.net;FPR:;SPF:SoftFail;PTR:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BY1PR0501MB1382;2:7k9eM1GHlAK16TNKvQno2zxcppdgU21lE/mRU+vVKgWKA7tKcnJltuVuQ9rLmgg3EFkCueSp37unci4Yps/eiGlC8nloRjrLUaUleM6qNrY+0wXYu3vjbVv1cJIxctXeG/kXwuLFuWL6LpyDLUvE6IHc0SKMAP31gTr2g3o7C3U=;3:WocwLcUxJ6DzsyyLgxFaOpBirap5ez7PskRUth8F7ln1ktA6FfDM2PGY7iYlg+Ue1w+fwiJ8WM8P5CQwDAznMcXlLcQfNG+HZi5qAjtUGKwefKyzS8MyCz1YZJepQWC8NsZQvalQ1L3/J6RY7hdbJ7iXeQD9SkaMfFt0ZZbobXdzclt4ZCi5nY0w3LU/lfW1022CtQ8WKX0mNmr4r13+2tHTy4PV7LDuDUdDNHFNiYc=;25:PqGNkarxM9wOMaKlyTcapZsjdqNsFwFh5UD+rpHxNZgPQfjAeO3Dlie4SoiV6k+Rbj3G3IjCZN7YLxVGYB4DaJRo5pnTVnxV3airHxeOqGQZKdU+LMmfSbg9/ZzAY59FYDHJtvACw0I5hY4bbS68M4/04Fe4ipH4xHWO7gCHAJegSrVnQJbFWpDsHLiwskeFXv7MRBZHBW8wLqzjjyomq2oajykc0SOshgbEqb8aFunQLU8uazhdiI62H/+JPQAIMVSFW6CjX9VrqtSplhBbEg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1382; X-Microsoft-Exchange-Diagnostics: 1;BY1PR0501MB1382;20:UrXe3tzWk/ibEDlnfPUUz+LHjLvyR7//FbtjtKotzkKlDc+CQLSCO+nhK3wEogJ3uh7LSKk7DZ8HUBwkgGjJ8Q3SHO/f3qWuYTzDXEOV95S9vR3Dr5fuf7V8FxuPuieHCB4dScxg34dOOpbcM9nvRoZ9RyIT6lVMrf/raKgMPTfQTZsu8/0czdDiQpW+uC6tpoE0yJIj+yJ4mT/JUBschDkeKc0mfLndqeahYuJWsGLP2H67pKrbFgz4RVVFRm60Z9WMvWs/HfWQiLp+o5h87ddzuio8WBcKhhtlqFN7vtOEzcDS5RMEpiBH1H6lwd64XlQW4beQTLdBa+CcrF7TjFwKfIBxKkAldq/yqQe+J72gpLZUbQ2dXQ0mdAl7fYcr8l13qmNrU9MM9RZMPYudFyZdr9hY5L8wTnf7/qTi0kZIAz0NYtxtdgN0+9x0+wyUf4Xv6bwz1mcd9q83lOAa1IjnNyWLBJvm0AR7vQWnhI4PVeAvH//S6sePOZ7Ypi3m;4:KonW8lEZSZ1dVw/zHxX8kNftFprcLAIsu1KNugC4gATBJHgUl1OMPvdg7Tqyxxz1RnyS0fxiGvecH23MBQCDoet+wXcQMfzhxpPMV2yEJxWznKe7h3C2Mfer7uJQv1iPJ43c7E8wBc+nN4QcrcdmXIdW+MBOueE8Zu9aWAWg/g2XSHsyQXj2EsS3oE6ySQtYye09UzppmTNog63YnogEPTA55w3Y/nBewZB60H2UdN6xY2YYSfccOgy7VUhUqnxBSnJU/5X1Z52/iga16PTC58vE38jVPNnTp432KJy8OmE/nzfmKFqr9MXhQzgU3GucZgRrCml5VW7+EoQ4NBsH3ra0YDaL/3ZAN4sE20yQ3zbIDOUCehdCAQbyp/JUFWJ+ X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046);SRVR:BY1PR0501MB1382;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1382; X-Forefront-PRVS: 07562C22DA X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;BY1PR0501MB1382;23:nvKfo1iXI1eHpkvwzF5tu3KZF7yyuPKQsf94IG3?= =?us-ascii?Q?PegO+pH/itAsJS4tt94VFb8ZPNxrr450Y+aDr/S3u2z5fq84C+6vcFf9nLz5?= =?us-ascii?Q?JfI/6BnFJpivE7asA7VZijez3PmzFP70o1a12YANvxFlx61elELJYghfr+nd?= =?us-ascii?Q?ud7jk0ilkQXtw06P+CQ6AEN2Nko9ixrQ01iyoAPXmQpcJ40/R/z4qjE39vk1?= =?us-ascii?Q?/YxI7ay4BRjUVqAxgIwz4F+UTsmhZ/SA4lUs2OV8YWFgkDeae7p19fIwFrS9?= =?us-ascii?Q?ZNOabvxWxIHXTMJhWROClk4t4B1tPmVP2YCO+O2xuVNRhneFZRuveWgardG0?= =?us-ascii?Q?gJ8lnP8IjcacycUNLziOyERRsn06uGpK1kbUMjXrakhA60Xh/8zfhiOcLvnc?= =?us-ascii?Q?iiVHiPoOMqnNp/ex09dJYDL+8O1XhjWVLGjlPH+vqPWJDSdJhc38mVgd5nWe?= =?us-ascii?Q?Zyj8FEtP8wbM//d9A2lroXqKCuLuJ7B2YuglnOfFfNQgngoSyYMUJb3Mu1el?= =?us-ascii?Q?vPkUs9pDMlrzHq903yiCQ0dbYFq5WVkJIiZy0gZ6QgiSD24gpV7XpI8VwOL1?= =?us-ascii?Q?fvvP5zAjAZgDvhLDrSdHOD1UQR9seJw3TO2PjArdP4vQ58xanRHRi3qM3keJ?= =?us-ascii?Q?2+VjM7nl9qZA50Bh5vq7A9aE8oCspaS8CSzRuhxKMJoc/sGyNSgAazsIQemi?= =?us-ascii?Q?1IwmYcAz5JJzKP4Lpo2nBV/B6/NdEyzvnSTCreDm+bOp+4I9nJbXFOshcYKq?= =?us-ascii?Q?YzYIQrdx++PcqweEo+LncfocST/bgAWepUMugdOIHmaES4OlKA7XAD1hPocO?= =?us-ascii?Q?2IszZ0cI/6rJwq7xLS0NB4Kbn7//y7TMkBClkYydowEennAxXZR3rmUdnNSE?= =?us-ascii?Q?vSPU9JT40hgipVTXB+FzD7UYXpVyOnnjOghJZUa+aDaSRN8IU9PYkp+kfxDl?= =?us-ascii?Q?5wnDJKl3t1miRc0rRXdkYWOP2HQ53+Omw77IcusKq7EoBadfE9N9U2YwFjS7?= =?us-ascii?Q?wtqiO8O1lbTtYaCZkj31epRe4?= X-Microsoft-Exchange-Diagnostics: 1;BY1PR0501MB1382;5:hTaLf3aWaQeg/+qvE5o1E7hVS2qAoxKpxONjrNqaGFKfHF8rVrVVCYZ5JQi8Z2kMvEu/k0BVc2mGHKr3HFWH63NOVjxUMOq4uBQgX2wMreYIiGrVHYZMqeM+9kSs383D8vPJutvRJ/74W+heHg03uQ==;24:93gg+lMGQ+2ZFzrQTmu2wZrbeu2J9wwAuxlhkyiEwRonXTedrvJUFDGQEOtoWV2ZKm8oa1N/sMpKlebr0LmXJ/2S3b9FbrvQeSJCkdBzUQc=;20:0Iw6Iv/RzPi1ZFr9wBQfkizsseNmwmt2DMvNPQ7tGqxrB3d6TtKOjpgklrMovfxwrNrzYEM/0YCVdvuUANh+fw== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Nov 2015 09:01:08.1779 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.17];Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1382 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Damien Miller writes: > On Sun, 8 Nov 2015, denis bider wrote: > > > (1) I have uploaded a new version of the RSA SHA-2 draft: > > > > https://tools.ietf.org/html/draft-rsa-dsa-sha2-256-02 > > Some feedback on the draft: ...elided... > Is it worthwhile to specify a minimum key size for the new signature > schemes? Hmmm... I am not sure. I would suggest a minimum of 2048 or 3072 would seem to fit, but that might already be covered from RFC 4251 which has: RFC 4251 Section 4.4 Security Properties says: "All algorithms are used with cryptographically sound key sizes that are believed to provide protection against even the strongest cryptanalytic attacks for decades." Do we believe that 112 bits of security will (i.e., RSA 2048-bit keys) will last for decades? If not, do we want to go for RSA 3072-bit keys with 128 bits of security (like AES-128) and SHA2-256? Or, should we let the developers just choose what they will and hope for the best? -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Nov 10 01:12:37 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE86E1B347E for ; Tue, 10 Nov 2015 01:12:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 TVK6XrIiAaUs for ; Tue, 10 Nov 2015 01:12:35 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A75AF1B347D for ; Tue, 10 Nov 2015 01:12:35 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id ED5E014A2FB; Tue, 10 Nov 2015 09:12:33 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id D97C714A2F3 for ; Tue, 10 Nov 2015 09:12:26 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id mwPq01L0iC06 for ; Tue, 10 Nov 2015 09:12:26 +0000 (UTC) Received: from newmailhub.uq.edu.au (mailhub1.soe.uq.edu.au [130.102.132.208]) by mail.netbsd.org (Postfix) with ESMTP id B0CEB14A2EE for ; Tue, 10 Nov 2015 09:12:25 +0000 (UTC) Received: from smtp2.soe.uq.edu.au (smtp2.soe.uq.edu.au [10.138.113.41]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id tAA9BXB5030104; Tue, 10 Nov 2015 19:11:33 +1000 Received: from mailhub.eait.uq.edu.au (holly.eait.uq.edu.au [130.102.79.58]) by smtp2.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id tAA9BX9d049194 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Nov 2015 19:11:33 +1000 Received: from natsu.mindrot.org (natsu.mindrot.org [130.102.96.2]) by mailhub.eait.uq.edu.au (8.15.1/8.15.1) with ESMTP id tAA9BWuj030169; Tue, 10 Nov 2015 19:11:32 +1000 (AEST) Received: by natsu.mindrot.org (Postfix, from userid 1000) id EEE67A4F2F; Tue, 10 Nov 2015 20:11:31 +1100 (AEDT) Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id EDE55A4F2E; Tue, 10 Nov 2015 20:11:31 +1100 (AEDT) Date: Tue, 10 Nov 2015 20:11:31 +1100 (AEDT) From: Damien Miller To: Peter Gutmann cc: denis bider , "ietf-ssh@netbsd.org" , Jeffrey Hutzelman , =?ISO-8859-15?Q?NielsM=F6ller?= , "Mark D. Baushke" , "stephen.farrell@cs.tcd.ie" , "jon@siliconcircus.com" , Max Horn Subject: RE: Experimental server for RSA SHA-2 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B5BF20@uxcn10-5.UoA.auckland.ac.nz> Message-ID: References: <2073638188-720@skroderider.denisbider.com>,<2096718084-720@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B5BD70@uxcn10-5.UoA.auckland.ac.nz>, <9A043F3CF02CD34C8E74AC1594475C73F4B5BF20@uxcn10-5.UoA.auckland.ac.nz> User-Agent: Alpine 2.20 (BSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub X-Scanned-By: MIMEDefang 2.75 on 130.102.79.58 X-UQ-FilterTime: 1447146695 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Tue, 10 Nov 2015, Peter Gutmann wrote: > Damien Miller writes: > > >I don't think this is right: the hash used in the signature algorithm has > >always been independent of the key exchange hash. > > Is it? I hope I'm not reading this wrong, but the exchange hash H is what's > signed, and that's what's calculated using the hash algorithm HASH, which is > specified by e.g. "diffie-hellman-group-exchange-sha256". So > "server_host_key_algorithms" can say RSA or DSA or ECDSA, but not the hash, > since that's implicit from "kex_algorithms". Yes, the kex method specifies an output hash. The output hash is reused for key derivation too. The signature methods *also* have implicit (or explicit in the ecdsa cases) input hashes. I.e. a current ssh-rsa kex signature is roughly RSA( PKCS1_PAD( SHA1( KEX_HASH( ... ) ) ) ) Over the banner+kexinit+etc blob. The publickey authentication hash isn't as redundant, since it doesn't have the inner kex hash. > >I don't really care for bikeshedding names, but if I were picking it, > >then it would be "rsa-pss-sha256". > > It definitely needs to indicate quite clearly that it uses a signature > form that's not compatible with anything else that SSH has ever used. > I'd vote for "crunchy-raw-unboned-real-dead-frog-rsa-pss". > > Could I also suggest that the draft include a facility to use standard > PKCS #1 sigs? I really don't want to have to implement a nonstandard > (meaning not used by any other part of SSH, or any other protocol like > PGP, S/MIME, TLS, etc) signature format just to be able to use SHA-256 > in a sig. Please no; I was counting the absence of ASN.1 formatting in the proposed signature scheme as a significant improvement. -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Nov 10 02:15:39 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3F41B3610 for ; Tue, 10 Nov 2015 02:15:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 qR_p25F722VN for ; Tue, 10 Nov 2015 02:15:34 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA04F1B360F for ; Tue, 10 Nov 2015 02:15:34 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 0B1F814A18E; Tue, 10 Nov 2015 10:15:32 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 24C7214A304 for ; Tue, 10 Nov 2015 10:15:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id vI1-jaOixlmU for ; Tue, 10 Nov 2015 10:15:26 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id EB7D814A2D8 for ; Tue, 10 Nov 2015 10:15:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1447150526; x=1478686526; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=dYNw3PZq1HbsqtRd4Cv9MpRSQcNBWlWFwQAFEuBK+YQ=; b=DKhGr5iGVi7b/tWy/jExyUXbj6O/m3TsNXif3FJAn2huRxWwN6N4AE77 svXldte/g6CNkS8RwyjJ+orZQOSj7KtiqBv9yv7ssH+o8BDKnURHc4Tgr 4PnwMS4uiPQZFAhAXwVFJ/MING/1luHX45qFAip1OV63gPgebwvD3od/d H2kcXQ3nC077HosEGOQCkBXaPGedaxFBlpqcfaUwBGls+OR3slNcH6mHT P05uQx2MeSfXj5US2ZxCpAQIbbD+nfOjJQn2uQOMDnyKd+YhsF9blxvoR ehBKZ7AMjygGmcnm3eUdJV2Us5ZdCWFXIh2RfBdyl1ln+zWK/wTy6Emsr A==; X-IronPort-AV: E=Sophos;i="5.20,270,1444647600"; d="scan'208";a="53535053" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe4.UoA.auckland.ac.nz) ([130.216.4.171]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 10 Nov 2015 23:14:57 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Tue, 10 Nov 2015 23:14:57 +1300 From: Peter Gutmann To: Damien Miller CC: denis bider , "ietf-ssh@netbsd.org" , Jeffrey Hutzelman , =?iso-8859-1?Q?NielsM=F6ller?= , "Mark D. Baushke" , "stephen.farrell@cs.tcd.ie" , "jon@siliconcircus.com" , Max Horn Subject: RE: Experimental server for RSA SHA-2 Thread-Topic: Experimental server for RSA SHA-2 Thread-Index: AQHRGgVgKCANwh+VhEemT+UuTqD4Yp6UzkDX//82vwCAAPFyG///KymAgADrO2s= Date: Tue, 10 Nov 2015 10:14:56 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B5BFD6@uxcn10-5.UoA.auckland.ac.nz> References: <2073638188-720@skroderider.denisbider.com>,<2096718084-720@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B5BD70@uxcn10-5.UoA.auckland.ac.nz>, <9A043F3CF02CD34C8E74AC1594475C73F4B5BF20@uxcn10-5.UoA.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Damien Miller writes:=0A= =0A= >The signature methods *also* have implicit (or explicit in the ecdsa cases= )=0A= >input hashes.=0A= =0A= Ah, OK, I missed this bit:=0A= =0A= Most signature algorithms include hashing and additional padding (e.g.,= =0A= "ssh-dss" specifies SHA-1 hashing). In that case, the data is first has= hed=0A= with HASH to compute H, and H is then hashed with SHA-1 as part of the= =0A= signing operation.=0A= =0A= So the new IDs just signal a switch of the hash from SHA-1 to SHA-256.=0A= =0A= >Please no; I was counting the absence of ASN.1 formatting in the proposed= =0A= >signature scheme as a significant improvement.=0A= =0A= What the formatting is isn't a big deal since it's already present in the= =0A= code. Every version of SSH over the last 20 years has used PKCS #1. The o= nly=0A= change for SHA-256 support is to add an OID to a table somewhere. If you'r= e=0A= using a general crypto library, chances are it'll already support this out = of=0A= the box.=0A= =0A= OTOH for RSA-PSS sigs you need to implement, debug, and test a completely n= ew=0A= signature scheme that's incompatible with pretty much everything else (PGP,= =0A= TLS, etc) out there.=0A= =0A= Peter.= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Nov 10 02:34:00 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F40CB1B3686 for ; Tue, 10 Nov 2015 02:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 tGaStzx9Ik6A for ; Tue, 10 Nov 2015 02:33:58 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88C281B3685 for ; Tue, 10 Nov 2015 02:33:58 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 4226B14A304; Tue, 10 Nov 2015 10:33:56 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 5331314A302 for ; Tue, 10 Nov 2015 10:33:53 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id VIcJDjofCXVo for ; Tue, 10 Nov 2015 10:33:52 +0000 (UTC) Received: from newmailhub.uq.edu.au (mailhub1.soe.uq.edu.au [130.102.132.208]) by mail.netbsd.org (Postfix) with ESMTP id 2F17B14A2E3 for ; Tue, 10 Nov 2015 10:33:50 +0000 (UTC) Received: from smtp2.soe.uq.edu.au (smtp2.soe.uq.edu.au [10.138.113.41]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id tAAAXUx8035089; Tue, 10 Nov 2015 20:33:30 +1000 Received: from mailhub.eait.uq.edu.au (holly.eait.uq.edu.au [130.102.79.58]) by smtp2.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id tAAAXUD1063531 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Nov 2015 20:33:30 +1000 Received: from natsu.mindrot.org (natsu.mindrot.org [130.102.96.2]) by mailhub.eait.uq.edu.au (8.15.1/8.15.1) with ESMTP id tAAAXUL1029343; Tue, 10 Nov 2015 20:33:30 +1000 (AEST) Received: by natsu.mindrot.org (Postfix, from userid 1000) id 1ED9FA4F2F; Tue, 10 Nov 2015 21:33:30 +1100 (AEDT) Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id 19CC7A4F2E; Tue, 10 Nov 2015 21:33:30 +1100 (AEDT) Date: Tue, 10 Nov 2015 21:33:30 +1100 (AEDT) From: Damien Miller To: Simon Josefsson cc: ietf-ssh@netbsd.org Subject: Re: Curve25519/448 key agreement for SSH In-Reply-To: <87poziw56c.fsf@latte.josefsson.org> Message-ID: References: <87pozjyzxc.fsf@latte.josefsson.org> <87poziw56c.fsf@latte.josefsson.org> User-Agent: Alpine 2.20 (BSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub X-Scanned-By: MIMEDefang 2.75 on 130.102.79.58 X-UQ-FilterTime: 1447151610 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Tue, 10 Nov 2015, Simon Josefsson wrote: > Damien Miller writes: > > >> the number X are then converted into a big integer k. This > >> conversion follows the network byte order. This step differs from > >> [RFC5656]. > > > > Maybe "converted into a big integer k by treating the value X as an > > unsigned, network-byte order integer". > > For Curve448, it appears to lead to 56 byte bigint or sometimes (when > msb is 1) a 57 byte bigint with leading zero. Is this a problem? If > somebody could observe the size difference, it would leak the MSB. If > worth resolving, how to resolve it? AFAIK it might not be possible to resolve without being incompatible with the deployed curve25519-sha256@libssh.org protocol: OpenSSH at least checks for correct zero-padding for mpints with the MSB set. When OpenSSH first added curve25519-sha256@libssh.org, I accidentally messed up this padding and it would cause ~1/128 connections to libssh to fail :/ IMO it's probably not worth fixing this now; the other kex protocols have the same problem, and the shared secret is never sent on the wire. -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Nov 10 02:54:57 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C37931A898C for ; Tue, 10 Nov 2015 02:54:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ItYAKym4nxP9 for ; Tue, 10 Nov 2015 02:54:56 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F8EE1A898B for ; Tue, 10 Nov 2015 02:54:56 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id E023814A310; Tue, 10 Nov 2015 10:54:52 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 09EBD14A30E for ; Tue, 10 Nov 2015 10:54:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 0PVOPdZ3BBqj for ; Tue, 10 Nov 2015 10:54:45 +0000 (UTC) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0753.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::753]) by mail.netbsd.org (Postfix) with ESMTP id 9D4CB14A30D for ; Tue, 10 Nov 2015 10:54:41 +0000 (UTC) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (86.185.87.133) by AMSPR07MB050.eurprd07.prod.outlook.com (10.242.81.24) with Microsoft SMTP Server (TLS) id 15.1.318.15; Tue, 10 Nov 2015 10:54:37 +0000 Message-ID: <02f601d11ba6$0867da80$4001a8c0@gateway.2wire.net> From: t.petch To: Peter Gutmann , Damien Miller CC: denis bider , , Jeffrey Hutzelman References: <2073638188-720@skroderider.denisbider.com>,<2096718084-720@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B5BD70@uxcn10-5.UoA.auckland.ac.nz>, <9A043F3CF02CD34C8E74AC1594475C73F4B5BF20@uxcn10-5.UoA.auckland.ac.nz> Subject: Re: Experimental server for RSA SHA-2 Date: Tue, 10 Nov 2015 10:53:09 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.87.133] X-ClientProxiedBy: DB3PR05CA0040.eurprd05.prod.outlook.com (25.160.41.168) To AMSPR07MB050.eurprd07.prod.outlook.com (10.242.81.24) X-Microsoft-Exchange-Diagnostics: 1;AMSPR07MB050;2:Z+rhuEH7LcWeN2klZ+p3nO+oXHrptpvrSeLS9nevmIoo1kXDN2qyhhIUnPRtf7DERdMGIzvj9cF4J/RSuaXk/OxEjWfqW8bx50vZyogCh5pT4vnnG8XYiFZdr4lHnsmrRtyYLWC1j6vkbp7bcBDOQhSYaZBIszTovzLqSwxJweE=;3:E3AqJ11tdNj4M7CMOAEC8Vjlz/XRHIx86akFi5rYhEp6TAFlLA4uXb9goczQVTm3qdfZ59yNC0CbzvpAQ3MIx5DxDuQnxINDbdrqzg2HvU+0rADAuzrjljBhBCkhdSfR29mQINi1YxTwg/qgBKlPfg==;25:lc69h1LbRJwLxruZ4AHkAZYHB7Y7ixrL0kHqau1pye6WuHsF3OikFZjSSd5h3Cm9x6lU2f6MzMH9SQaPpz4JyQaThZHRWHKxL+d16b2jnqoNL5z0yba4vPsvPHLP8JpByl4Nee7mS4qD2iZtWqMKkt24TY0Eu43LWNszKu3PovCPPlD7t7yilCxXuOjzJAQX8rmzMEmHeH9F5y7qKYB/6y7q7AZXOUO2+mRegS6bCv9dQfr5pjMFz1AnkaIix2Kv;4:TpAJdfWg9gta2CHreoJWga9X21H+6lmuxaJo6aWAFPIi2+2ixluTG974V4Me902XraXXk6vW3l+V/NYANeSlXxYvp5UiWDHZXC0RVmRaW5EmsbH5XpnCD4GpDcYC4XOW1DcbYCh2vBKLWGqIZf8F5zXBOV6aWawTTq+62jSaLW+T7zeCsKSBVuOm0+h+5aoOdjDMkGvNDnCr2vGujhJw7XAOxZ7skd7PlmMpSpjcpbUMLwJUapy19ndz/JJO5qLW070frvvc7EZo7khZ6WRFJHumkY/DjSp+734ZYrzHfJznmk0Ahann3jN6BvK0ShCrCDyGOtsUc+4ZS8I9Sp0UxlEOjDKW211O0cXLa3dDlNicgJYeQ6y0Ur+TJZpGDn I1 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB050; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001)(10201501046);SRVR:AMSPR07MB050;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB050; X-Forefront-PRVS: 07562C22DA X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(6009001)(199003)(13464003)(189002)(377454003)(42186005)(62236002)(47776003)(33646002)(44716002)(44736004)(93886004)(5007970100001)(5001960100002)(76176999)(40100003)(86362001)(230700001)(101416001)(81686999)(92566002)(81816999)(122386002)(50226001)(19580395003)(19580405001)(5004730100002)(97736004)(106356001)(1556002)(5001770100001)(66066001)(1456003)(105586002)(23756003)(61296003)(5001920100001)(116806002)(50466002)(5008740100001)(50986999)(77096005)(81156007)(189998001)(14496001)(87976001)(84392001)(74416001)(7726001);DIR:OUT;SFP:1102;SCL:1;SRVR:AMSPR07MB050;H:pc6;FPR:;SPF:None;PTR:InfoNoRecords;A:0;MX:1;LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1;AMSPR07MB050;23:Bd6TGVZPil1wCLXb//94IPMzIovQw47XbJSHyT8y?= =?iso-8859-1?Q?WeOTx0uPZQ+VLlhh3XGkgGkcIVSl4KGjE0MefbTI43LMmPTAwJCzKpYS5N?= =?iso-8859-1?Q?yvVfIcXee0tBj6mVheE1otG0LfwTgTsgBsURFDb7mxZ/mo9xrQUgPWF9pt?= =?iso-8859-1?Q?28W6ReQ0VPBVS1VD5YBwc9n9ruFK0Sesq5CoP6upqMmAPoJYVMP3cbeGGA?= =?iso-8859-1?Q?9O8y1f+FtwSqLeL4Y7TeWu+i0TIlTtuZiOuyUPiq7t3cKKJr84kOI2W2sr?= =?iso-8859-1?Q?SIvRr2wSsdzTAWDJ5kUY28p2/+dHtZXejzUMOAVLHEj4NmUcj/s0v1C5tS?= =?iso-8859-1?Q?CNBKTT7Ook+/r2Ni+II37R1qaWXZMCl8M1O+GTNuVVQUZJE0uAFeloe2XJ?= =?iso-8859-1?Q?mQSRq4jDN2oeYL/VBBhxoQlaH8M7KUJb0kfxllNEeIGZimT0xYbxgXExph?= =?iso-8859-1?Q?2owjR0NaIpxL5dTEPVsbyWLsy+++nzp8ha1l3mH6ZumNjXiS7QJJPig0F2?= =?iso-8859-1?Q?39YeefaGM+ApquUP2yX1LP0PQZZ6UEZKuO4YNlVN6HP/z9Ri0xvDSjyZQQ?= =?iso-8859-1?Q?tEsMVCe3SJ3HUY4MRm9XXgcN3t0lRgF39Ijz1Pf0PDg2N+RGBxAkiiDYp3?= =?iso-8859-1?Q?kWHKT6vPRn0g+5wf2328Bc/0yfu74b500g8wL2C1dOYGloPtGod7sJokBF?= =?iso-8859-1?Q?jfdcAjlIGTKaBG/4+STt8MYpgT46h/a3Xysin3bbSMPeli4Oz/brNGRxR4?= =?iso-8859-1?Q?u2N686v91W02GchEYc6VqPtvXbt5Sd7Q9jZ3equnvZw9jXvzZ5YX7dFTq3?= =?iso-8859-1?Q?Eh64iSfO8dXANvJxxZuP8bEEeDcacyzqOtuaj5cWVQJnUEMBdiAbPRobqT?= =?iso-8859-1?Q?jVyidaGqPWTJR1olgXiBazm0PrIxJmO2+EsJucUkb8bZvadl3e+dY9DCYq?= =?iso-8859-1?Q?aaknA59T6X91xDrYI8mn2bTA8HJjYCceYiE+e/4k5tXm7bwoeen8Iu5eiH?= =?iso-8859-1?Q?9M5X9Y6nsDL3R8o6sGUNQC2+nRbP+OzE5lARmbdWpXutATO8OUKOgjFqrj?= =?iso-8859-1?Q?BTuiTQGj2sk13EzkW0nGkegpaB+0jYlJioOX3AwXib62zULhm+cbEiPeuL?= =?iso-8859-1?Q?+fVeMBwrBTHdcB9UZ8N6jNv/JimMr6cLP+0JHVqRTqyUbsXYGzYBe6pv/Q?= =?iso-8859-1?Q?PRedvEV8TsFuxivUQoIBvF/g4TqixItAmXIshiz7OeNWAHJwjQsTGW60QD?= =?iso-8859-1?Q?COdsznXPZARNHycv0C5EqbPcIK5G0M94yIXUN4HEzEnxnKGl2hlD4ud+cx?= =?iso-8859-1?Q?HSTDlxDJ2s7OOzbt39j9+R?= X-Microsoft-Exchange-Diagnostics: 1;AMSPR07MB050;5:X3EmuPRqqqEjnaDa0qYbTFwL+6tLnDwzPKY3e83ne+eswH6qD2s7EeeJybJNFqfCerXKJrIZUK7eb5DyhhxSk6s1VlhFjcQZEoIdoa47mI+5Obb6+YuCNsr1ObL20zHE3RdyuHwwAtBCp8NmOzaPMg==;24:KkSI8t0+eqO6PmmIgNZCfcf/iyRZnwobfsEFt9g/rl3cKf+7u1CpXUjZeFQwhW9zQkT6Bo5rwE235wNGwo9jpgZeyLzLbFD+qDWVJlVLylQ=;20:4MWSGCe9qUUzi+hdrC5XK9gExF9a4cYV+PoDRxltSy/iVtE/JKgFmzXy28WfCMr3GAoMUosdEwChzumkUtco4w== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Nov 2015 10:54:37.4170 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB050 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list ---- Original Message ----- From: "Peter Gutmann" Sent: Tuesday, November 10, 2015 8:53 AM Damien Miller writes: >I don't think this is right: the hash used in the signature algorithm has >always been independent of the key exchange hash. Is it? I hope I'm not reading this wrong, but the exchange hash H is what's signed, and that's what's calculated using the hash algorithm HASH, which is specified by e.g. "diffie-hellman-group-exchange-sha256". So "server_host_key_algorithms" can say RSA or DSA or ECDSA, but not the hash, since that's implicit from "kex_algorithms". >I don't really care for bikeshedding names, but if I were picking it, then it >would be "rsa-pss-sha256". It definitely needs to indicate quite clearly that it uses a signature form that's not compatible with anything else that SSH has ever used. I'd vote for "crunchy-raw-unboned-real-dead-frog-rsa-pss". Sounds appropriate:-) My experience is that encoding semantics into identifiers generates long term problems. An identifier should be easy to use, easy to read and write, hard to confuse with other identifiers in the name space. Using it to identify e.g. which version of which model of kitchen sink is used leads to overlong and easy to get wrong identifiers which then engenders mistakes. Since in this case, we are naming a replacement for ssh-rsa it would seem sound to use ssh-rsa-(something short and snappy to show it is an update) e.g. ssh-rsa-sha256 Yes, I know about x509v3-ssh-dss x509v3-ssh-rsa Not sound, IMHO; ssh-dss-x509v3 ssh-rsa-x509v3 would have been better or even ssh-dss-x509 ssh-rsa-x509 Relevant for me, but perhaps heresy to mention here, is the fact the TLS Cipher Suite names make extensive use of SHA256 and SHA384 as an element thereof. Tom Petch Could I also suggest that the draft include a facility to use standard PKCS #1 sigs? I really don't want to have to implement a nonstandard (meaning not used by any other part of SSH, or any other protocol like PGP, S/MIME, TLS, etc) signature format just to be able to use SHA-256 in a sig. Peter. = From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Nov 10 11:50:03 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 268D81B3DED for ; Tue, 10 Nov 2015 11:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_SORBS_WEB=0.77, T_RP_MATCHES_RCVD=-0.01] autolearn=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 OANfNLeED3nQ for ; Tue, 10 Nov 2015 11:50:01 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D62C1B3DE6 for ; Tue, 10 Nov 2015 11:50:01 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 7D1CC14A1E4; Tue, 10 Nov 2015 19:49:58 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id D7A5314A1E0 for ; Tue, 10 Nov 2015 19:49:51 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id cD2NMAjiUh14 for ; Tue, 10 Nov 2015 19:49:51 +0000 (UTC) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id D266E14A1DD for ; Tue, 10 Nov 2015 19:49:48 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 30436BE59; Tue, 10 Nov 2015 19:49:46 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yA8Cazveigyh; Tue, 10 Nov 2015 19:49:44 +0000 (GMT) Received: from [10.87.48.91] (unknown [86.46.22.174]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 33A07BE4C; Tue, 10 Nov 2015 19:49:44 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1447184984; bh=264xsUOM19KzVJX/b4OzBAEM21mDHFRAcNhsISq+w8I=; h=To:Cc:From:Subject:Date:From; b=HzNwD47r3UaA+Wy0PrMCSg/tum85TjeEtI30/SVT5EunOlAKZQ6CobcBIKKHGDR3I MBvbZLAHhuzfm67BMrM5ThxNzRCqL5hmeG8iGghoP1alvyYgq88/bbhvnhPihYg/N/ O0PztIVde1Po3OfDLyttlaCc0gDqcETvG3vlnypE= To: ietf-ssh@NetBSD.org Cc: Kent Watsen From: Stephen Farrell Subject: question about zmap, ssh and fingerprinting Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56424A52.1030201@cs.tcd.ie> Date: Tue, 10 Nov 2015 19:49:38 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hiya, The netconf protocol can use either TLS or SSH. They're working on a "call-home" draft [1] and as part of that I suggested that the WG maybe consider adding a security consideration something like that below. They're thinking about that but asked if the same considerations would apply to SSH. I guess in principle it ought, but I don't think I've seen specific uses of zmap that did that, so I figured I'd ask. (Note: we just need to know if s/TLS/TLS or SSH/ would be good or bad below, but of course any other comments on [1] would be interesting too.) Thanks in advance, S. [1] https://tools.ietf.org/html/draft-ietf-netconf-call-home-11 Suggested text: "Internet facing hosts running TLS will be fingerprinted via public IPv4 scanning tools such as zmap. [zmap] If those hosts are not updated and have known vulnerabilities those will be exploited. This is noted here as, a) TLS provides many ways in which a device can be fingerprinted and b) zmap is still relatively new. Implementers and those deploying need to ensure that they provide mechanisms for software update so that vulnerabilities are fixed in a timely fashion." [zmap] Durumeric, Zakir, Eric Wustrow, and J. Alex Halderman. "ZMap: Fast Internet-wide Scanning and Its Security Applications." Usenix Security. 2013. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Nov 10 14:33:04 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02EB41B4166 for ; Tue, 10 Nov 2015 14:33:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 3LC7VkI2z4f9 for ; Tue, 10 Nov 2015 14:33:02 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11B241B4163 for ; Tue, 10 Nov 2015 14:33:02 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 9881214A1E0; Tue, 10 Nov 2015 22:32:58 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 3BE9B14A1B8; Tue, 10 Nov 2015 22:32:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 740B614A298 for ; Tue, 10 Nov 2015 09:31:01 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id o0TOvAnsvXE8 for ; Tue, 10 Nov 2015 09:31:00 +0000 (UTC) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 31ABC14A1D5 for ; Tue, 10 Nov 2015 09:30:57 +0000 (UTC) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id tAA9UcDs001002 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 10 Nov 2015 10:30:39 +0100 From: Simon Josefsson To: denis bider Cc: ietf-ssh@netbsd.org Subject: Re: Curve25519/448 key agreement for SSH References: <2258609541-1780@skroderider.denisbider.com> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:151110:ietf-ssh@netbsd.org::aQHVXHSVgUCsR1++:1Tij X-Hashcash: 1:22:151110:ietf-ssh3@denisbider.com::P6baJ0rXozD3j+U1:Nyim Date: Tue, 10 Nov 2015 10:30:37 +0100 In-Reply-To: <2258609541-1780@skroderider.denisbider.com> (denis bider's message of "Tue, 10 Nov 2015 06:12:05 +0000") Message-ID: <87y4e6w69u.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable denis bider writes: > Simon, Aris - > > thank you for this work. I plan to be implementing this soon, and I > appreciate that you're moving ahead with standardization. Hi Denis. Excellent! It would be perfect if someone would attempt implementation based on this document (and cfrg-curves) and tell us what is missing, and what could have helped them implement it more quickly. > With respect to conversion of the binary string X into mpint K, is > there a chance that X might have its high bit set? > > If it's possible for the high bit to be set, it seems you ought to > clarify how that's converted into mpint, given that mpint is signed: > > https://www.ietf.org/rfc/rfc4251.txt > Represents multiple precision integers in two's complement format, > stored as a string, 8 bits per byte, MSB first. Negative numbers > have the value 1 as the most significant bit of the first byte of > the data partition. If the most significant bit would be set for > a positive number, the number MUST be preceded by a zero byte. Good point, I believe the document has to discuss the mapping between binary Curve25519/Curve448 binary strings into mpint's. A simple approach would be to say that if the MSB is 1, prepend a zero byte. However, the length difference would leak that information. For Curve25519 the most-significant bit is always zero though, so this will never happen. For Curve448 this seems like a problem. Is it okay to prepend a zero byte in SSH big integers even if one is not necessary? Then a simple approach would be to do nothing for Curve2559 and to always add a zero byte for Curve448. > Besides that, I'm noticing the language could use improvement in > places ("this document re-use" -> "this document reuses", "is is" -> > "is"). Fixed, thank you. /Simon > Overall, thank you for moving forward with this, though. > > > ----- Original Message ----- > From: Simon Josefsson=20 > Sent: Monday, November 9, 2015 09:07 > To: ietf-ssh@netbsd.org=20 > Subject: Curve25519/448 key agreement for SSH > > Aris and me have prepared a document describing key agreement using the > CFRG curves for Secure Shell.=A0 As you know, curve25519-sha256@libssh.org > is already implemented by libssh, OpenSSH, Dropbear, and some others. > This is about putting the description of that into IETF format, and to > add the Curve448 hedge variant chosen by CFRG.=A0 It might not be detailed > enough for independent implementation, but we hope to get there.=A0 Any > review and feedback is welcome. > > https://tools.ietf.org/html/draft-josefsson-ssh-curves > > /Simon > > PS. There is https://tools.ietf.org/html/draft-bjh21-ssh-ed25519 but > that talks about Ed25519 signatures.=A0 The document above is about key > agreement. > --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWQbk9AAoJEIYLf7sy+BGd9m0IAJ6gFWevkMERcyMKzl8SCn69 cgsRQHVKegx4s2HbVEIYxt7Xc1cQmfmHXZgvf7bA1UueBLzZWmasaRzaQydVOJWD R4GvU1DSP7FzjE6Da+B0DRPbryhEKkb7c/jomaYsgBMPen1ykOeOuqQhFbFF8kb5 4VbbXhMoP70wVGam+E15s8c28AdCNR3Qo2DLjMaRAfOEf7ZCjKoQvt0GDsiTb2v9 G2HA53+Pyy82FCRNPsx2pUy3sk5xqlFgehigqwVLGOWWuTVShJhrn8Z361k9ws5Q J8i+4FbXXKROm3idyxiM2bT4A0awt6R6gfiI2iVdP5veHNlxf2qUvHfryS+b4XQ= =aWTi -----END PGP SIGNATURE----- --=-=-=-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Nov 10 14:33:13 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0DD01B416B for ; Tue, 10 Nov 2015 14:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 b79_ZTNJ4lZ1 for ; Tue, 10 Nov 2015 14:33:10 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07CC41B4165 for ; Tue, 10 Nov 2015 14:33:10 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id A73A214A1ED; Tue, 10 Nov 2015 22:33:09 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 44FBF14A1EB; Tue, 10 Nov 2015 22:33:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id BD0C814A2A3 for ; Tue, 10 Nov 2015 09:54:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id Vvthm4tZ6CGd for ; Tue, 10 Nov 2015 09:54:30 +0000 (UTC) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 9E61914A14B for ; Tue, 10 Nov 2015 09:54:30 +0000 (UTC) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id tAA9sKlN003005 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 10 Nov 2015 10:54:21 +0100 From: Simon Josefsson To: Damien Miller Cc: ietf-ssh@netbsd.org Subject: Re: Curve25519/448 key agreement for SSH References: <87pozjyzxc.fsf@latte.josefsson.org> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:151110:ietf-ssh@netbsd.org::ZEte/qIxqB9apdNj:6W6j X-Hashcash: 1:22:151110:djm@mindrot.org::m058xkEJ5SsNryIx:b7nt Date: Tue, 10 Nov 2015 10:54:19 +0100 In-Reply-To: (Damien Miller's message of "Tue, 10 Nov 2015 19:52:25 +1100 (AEDT)") Message-ID: <87poziw56c.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Damien Miller writes: >> 2. Key Exchange Methods >>=20 >> The key exchange procedure is identical to the one described RFC 5656 >> chapter 4 of [RFC5656]. Public ephemeral keys are transmitted over >> SSH encapsulated into standard SSH strings. > > RFC5656 describes multiple key exchange procedures (ECDH and ECMQV), > so s/the one described RFC 5656/the ECDH method described in RFC 5656/ > > The procedure isn't completely identical, since different encodings are > used for the wire values and the shared secret. IMO it's worth > foreshadowing this here. Perhaps something like: > > The key exchange procedure is similar to the ECDH method described in > chapter 4 of [RFC5656], though with a different wire encoding used for > public values and the final shared secret. Public ephemeral keys are > transmitted over SSH encapsulated into standard SSH strings. > > I think it is also worth mentioning that the protocol flow, the > SSH_MSG_KEX_ECDH_INIT and SSH_MSG_KEX_ECDH_REPLY messages, and > the structure of the exchange hash are identical between this and > RFC5656 chapter 4. Agreed, it now has two paragraphs: The key exchange procedure is similar to the ECDH method described in chapter 4 of [RFC5656], though with a different wire encoding used for public values and the final shared secret. Public ephemeral keys are transmitted over SSH encapsulated into standard SSH strings. The protocol flow, the SSH_MSG_KEX_ECDH_INIT and SSH_MSG_KEX_ECDH_REPLY messages, and the structure of the exchange hash are identical with chapter 4 of [RFC5656]. >> The whole method is based on the Curve25519 and Curve448 scalar >> multiplication, as described in [I-D.irtf-cfrg-curves]. Private and >> public keys are generated as described therein, and no special >> validation is required beyond what is discussed there. Public keys >> are defined as strings of 32 bytes for Curve25519 and 56 bytes for >> Curve448. The derived shared secret is is 32 bytes when Curve25519 >> is used and 56 bytes when Curve448 is used. > > I think that it's worth mentioning here that it's [I-D.irtf-cfrg-curves] > that specifies encodings for the public values. I've changed it into: The whole method is based on the Curve25519 and Curve448 scalar multiplication, as described in [I-D.irtf-cfrg-curves]. Private and public keys are generated as described therein, and no special validation is required beyond what is discussed there. Public keys are defined as strings of 32 bytes for Curve25519 and 56 bytes for Curve448. The derived shared secret is 32 bytes when Curve25519 is used and 56 bytes when Curve448 is used. The encodings of all values are defined in [I-D.irtf-cfrg-curves]. >> The shared secret, k, is defined in SSH specifications to be a big >> integer. This number is calculated as follows. X is the 32 bytes >> point obtained by the scalar multiplication of the other side's >> public key and the local private key scalar. The whole 32 bytes of > > s/32 bytes/32 or 56 bytes/ here. Fixed. > Maybe mention that X is encoded the same as the public values (AFAIK > I-D.irtf-cfrg-curves doesn't explicitly specify an encoding for the > shared secret - maybe it should?) The cfrg-curves document should specify encoding for everything, see section 5. It has the encodeUCoordinate function and also says: Finally, encode the resulting value as 32 or 56 bytes in little- endian order. For X25519, the unused, most-significant bit MUST be zero. So I believe this is covered by the previous changed paragraph which refers to cfrg-curves for all encodings. >> the number X are then converted into a big integer k. This >> conversion follows the network byte order. This step differs from >> [RFC5656]. > > Maybe "converted into a big integer k by treating the value X as an > unsigned, network-byte order integer". For Curve448, it appears to lead to 56 byte bigint or sometimes (when msb is 1) a 57 byte bigint with leading zero. Is this a problem? If somebody could observe the size difference, it would leak the MSB. If worth resolving, how to resolve it? /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWQb7LAAoJEIYLf7sy+BGd2wAH/jz6mj74w16ygHLH0Y8/ydYM 6tN+6vseYoHJY6t0c1HZJdEur9lM0A3PtfaaDl7xZM8TTd/R19cdooXjEFfNCE6f ePNSZcszVgUgKb4ZATDf23A4h/RahK9iPZEkMInAeq0A7egH8A80+k2M4AAqJCv8 n/Yx/6fQKxjsA1kNFH0LUfMSF1hQ8PHPCqaqVk55jiZyKHv2+BD9K/tSKbt1ZXMW QOTD6uc5EFuxAqkJUGIvWmH/cmXxEoINV9Bsow0ou0IRMR7ufOFyG9A5mTZB9I4H azzrVsVSuG8Lge2oLzRx1WqmUa5IPTgwiz4pggppsb8J0ea5y+T+jqKkWNPwsw4= =txWr -----END PGP SIGNATURE----- --=-=-=-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Nov 10 14:33:22 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 390381B416C for ; Tue, 10 Nov 2015 14:33:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 gkx79-nONQfI for ; Tue, 10 Nov 2015 14:33:20 -0800 (PST) Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 937891B4165 for ; Tue, 10 Nov 2015 14:33:19 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 2777114A1EE; Tue, 10 Nov 2015 22:33:19 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id BE5F214A1EB; Tue, 10 Nov 2015 22:33:18 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id D294414A318 for ; Tue, 10 Nov 2015 13:08:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id nO6lEotDqTRu for ; Tue, 10 Nov 2015 13:08:43 +0000 (UTC) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id A983514A30A for ; Tue, 10 Nov 2015 13:08:41 +0000 (UTC) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id tAAD8NF6022964 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 10 Nov 2015 14:08:24 +0100 From: Simon Josefsson To: Damien Miller Cc: ietf-ssh@netbsd.org Subject: Re: Curve25519/448 key agreement for SSH References: <87pozjyzxc.fsf@latte.josefsson.org> <87poziw56c.fsf@latte.josefsson.org> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:151110:ietf-ssh@netbsd.org::HbY9RarEDHt7WXU/:2HDm X-Hashcash: 1:22:151110:djm@mindrot.org::UkEFHXNXQabrAORi:F9wK Date: Tue, 10 Nov 2015 14:08:22 +0100 In-Reply-To: (Damien Miller's message of "Tue, 10 Nov 2015 21:33:30 +1100 (AEDT)") Message-ID: <87vb9auhmh.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Damien Miller writes: > On Tue, 10 Nov 2015, Simon Josefsson wrote: > >> Damien Miller writes: >>=20 >> >> the number X are then converted into a big integer k. This >> >> conversion follows the network byte order. This step differs from >> >> [RFC5656]. >> > >> > Maybe "converted into a big integer k by treating the value X as an >> > unsigned, network-byte order integer". >> >> For Curve448, it appears to lead to 56 byte bigint or sometimes (when >> msb is 1) a 57 byte bigint with leading zero. Is this a problem? If >> somebody could observe the size difference, it would leak the MSB. If >> worth resolving, how to resolve it? > > AFAIK it might not be possible to resolve without being incompatible > with the deployed curve25519-sha256@libssh.org protocol: OpenSSH at > least checks for correct zero-padding for mpints with the MSB set. Curve25519 would never have the MSB set, if I understand correctly. So what is the potential for incompatibility? Maybe I'm missing something. I believe this document should document exactly what curve25519-sha256@libssh.org does, otherwise things will be confusing. Unless there is a significant mistake with it, of course, but then people shouldn't be using it at all. Nobody has implemented Curve448 for SSH so there is no compatibility to think about there. There has not been a lot of interest from implementers in Curve448 either, since it is slower (no twisted curve). The only argument I can think of for supporting it is that it hedges you against potential new analytical ECC attacks that would affect Curve25519. But for this work, I believe including Curve448 makes sense since it is what CFRG recommends. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWQexGAAoJEIYLf7sy+BGdhoQIAIs3wD8WQ3nMcQAof2lP+TDM erArp2bqe+drx9wgvgXD8DE7y3poqeGqlOfmrb4xCdBlzvyQ39AI2ZwbhL2hnZxF zFgSYyq5fpM4iNI3L7LWlkNnp+zOfuBAjXjPFrPOmGwMPmFuocpioULMGVRmr0ve jY9ynCKRgx1xlcXNTRxJd8T+/x43nPJzYJwkiKoC9SI/lmjgcRumNFWw/4g1WrzW FdlD6HP9Iov/6S5hPB0AOR8lDUH86H7S8xc3m1tfWp9RCG3ajL2bau7m55FgL8IO ppYTuzIsissnzo4rPiU5pijhjByjkEXE5rqLA7xDkxc8xzSUquXQBwg+655X1H8= =mSxG -----END PGP SIGNATURE----- --=-=-=-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Nov 10 14:33:40 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1A881B4170 for ; Tue, 10 Nov 2015 14:33:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 vBNv6Dx7Jvf6 for ; Tue, 10 Nov 2015 14:33:37 -0800 (PST) Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C00581B416E for ; Tue, 10 Nov 2015 14:33:37 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 67E0714A1F0; Tue, 10 Nov 2015 22:33:37 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 05E3314A1EF; Tue, 10 Nov 2015 22:33:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id ADAA314A311 for ; Tue, 10 Nov 2015 14:24:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 7kJXa1b6aKkX for ; Tue, 10 Nov 2015 14:24:30 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 418FA14A2DF for ; Tue, 10 Nov 2015 14:24:30 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for ietf-ssh@netbsd.org; Tue, 10 Nov 2015 14:24:03 +0000 Date: Tue, 10 Nov 2015 14:24:03 +0000 Subject: Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <2288549674-480@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: ietf-ssh@netbsd.org, Damien Miller Cc: Jeffrey Hutzelman , =?UTF-8?q?NielsM=C3=B6ller?= , "Mark D. Baushke" , stephen.farrell@cs.tcd.ie, jon@siliconcircus.com, Peter Gutmann , Max Horn Content-Type: multipart/alternative; boundary="=-s4KscjfjZ74A6VvpnuBL" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-s4KscjfjZ74A6VvpnuBL Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Damien: > The DSA bits in here don't seem very relevant. > Could I suggest ditching them or putting them > in an appendix? I have done so for the -03 version of the draft. > I can see the argument for keeping "ssh-rsa" as the > key name and another name for the revised signature > format. I'm not entirely sure about it, I guess > because I'm used to there being an identity between > key types and signature types in the SSH protocol. It's the only way to allow existing, good RSA host keys and fingerprints to= continue to be used. If we change the key format, it requires users to re-do their host key and = client key setups in order to use the new signature methods. In my experien= ce, this is the one thing that costs users the most, and which they most wa= nt to avoid. They'll avoid the new format if it comes at the cost of re-key= ing. It would mean adoption would be pushed several years down the road. Furthermore, transition to any other signature format - like from SHA-256 t= o SHA-512, or from SHA-2 to SHA-3 - would then mean paying this whole cost = again, and again when the same keys could be used. If we decouple the key type from signature type: - adoption can happen faster, since the new signatures are compatible with = existing keys - the same keys can also be used if we want to migrate to SHA-2 512 or SHA-= 3 It took me a few days to implement this decoupling for Bitvise SSH Server a= nd Client. Not too hard. > As mentioned in my other email, I don't feel super- > strongly about naming, but "rsa-pss-sha2-*" seems > slightly more descriptive and future-proof. There haven't been any other formats besides PSS and PKCS#1 v1.5 for a coup= le decades. I'm proposing is to migrate to PSS for the reasons explained in my message = dedicated to that. If we settle on PSS, I think anyone who wants to use PKCS#1 v1.5, perhaps b= ecause they're lazy, should carry the shame of naming "pkcs1v15" in their s= ignature format.=20 If we decide on PSS, I think it should be implicitly baked in. The signature format that's more desirable for the community should have th= e nicer / more default looking name, I think. Unless we must disambiguate f= rom something previously existing. We don't have to disambiguate from something that does not exist yet. > Is it worthwhile to specify a minimum key size for > the new signature schemes? RFC 6187 goes so far as to put "2048" in the algorithm name. I have decided against that because it's totally arbitrary and a matter of = policy. We don't currently have "ssh-rsa-1024", even though that was the pr= evious de facto minimum key size. The next version of our SSH Server will have a setting which will allow a s= erver-wide minimum size for RSA keys. This will be set to 2048 bits for new= installations by default. However, I don't see the need to hardcode this in an algorithm name. The Se= curity Considerations section does already strongly suggest 2048-bit keys, = or larger. > IMO a "publickey2" (or somesuch) method that included > a custom failure message to list the supported key > types seems like a better way to offer this. It seems to me that SSH needs a proper extension mechanism to avoid version= -string-based hacks and other kinds of hacks. "publickey2" is not that much simpler to deploy. It requires changes to exi= sting implementations, like EXT_INFO does. But it has none of the benefits: - Does not solve the general problem of SSH protocol extension and feature = discovery. - Has a flat cost of an additional round-trip due to SERVICE_REQUEST and SE= RVICE_ACCEPT. - Does not make signature algorithm information available in time for the c= lient's first user auth request. This costs a round-trip if the client's fi= rst guess is incorrect. I think it makes sense to expand the "server-sig-algs" extension to "auth-i= nfo", and include "methods that can continue" as part of that. This should = avoid the need for clients to send "none", which adds yet an additional rou= nd-trip. I have made this change for the next draft version. ----- Original Message ----- From: Damien Miller=20 Sent: Tuesday, November 10, 2015 02:18 To: denis bider=20 Cc: ietf-ssh@netbsd.org ; Jeffrey Hutzelman ; NielsM=C3=B6ller ; Mark D. Ba= ushke ; stephen.farrell@cs.tcd.ie ; jon@siliconcircus.com ; Peter Gutmann ;= Max Horn=20 Subject: Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation On Sun, 8 Nov 2015, denis bider wrote: > (1) I have uploaded a new version of the RSA SHA-2 draft: >=20 > https://tools.ietf.org/html/draft-rsa-dsa-sha2-256-02 Some feedback on the draft: > 1.=C2=A0 Overview and Rationale The DSA bits in here don't seem very relevant. Could I suggest ditching them or putting them in an appendix? >=C2=A0=C2=A0 All aspects of the "ssh-rsa" format are kept, including the e= ncoded >=C2=A0=C2=A0 string "ssh-rsa", in order to allow users' existing RSA keys = to be >=C2=A0=C2=A0 used with the new signature formats, without requiring re-enc= oding, >=C2=A0=C2=A0 or affecting already trusted key fingerprints. I can see the argument for keeping "ssh-rsa" as the key name and another name for the revised signature format. I'm not entirely sure about it, I guess because I'm used to there being an identity between key types and signature types in the SSH protocol. > 3.=C2=A0 Discovery of signature algorithms supported by servers >=20 >=C2=A0=C2=A0 When a public key format can use multiple signature algorithm= s, it can >=C2=A0=C2=A0 be useful for a mechanism to exist which a client can use to = discover >=C2=A0=C2=A0 signature algorithms accepted by a server for user authentica= tion >=C2=A0=C2=A0 without resorting to trial and error in authentication reques= ts. >=20 >=C2=A0=C2=A0 Such a mechanism is defined in [SSH-EXT-INFO], which describe= s general >=C2=A0=C2=A0 purpose extension negotiation for SSH, and specifies discover= y of >=C2=A0=C2=A0 signature algorithms as a usage case. IMO a "publickey2" (or somesuch) method that included a custom failure message to list the supported key types seems like a better way to offer this. >=C2=A0=C2=A0=C2=A0=C2=A0 Public Key Algorithm Name=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Reference=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Note >=C2=A0=C2=A0=C2=A0=C2=A0 rsa-sha2-256=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [t= his document]=C2=A0=C2=A0=C2=A0 Section 2 >=C2=A0=C2=A0=C2=A0=C2=A0 rsa-sha2-512=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [t= his document]=C2=A0=C2=A0=C2=A0 Section 2 As mentioned in my other email, I don't feel super-strongly about naming, but "rsa-pss-sha2-*" seems slightly more descriptive and future-proof. Is it worthwhile to specify a minimum key size for the new signature schemes? -d = --=-s4KscjfjZ74A6VvpnuBL Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Damien:


> The DSA bits in here don't= seem very relevant.
> Could I suggest ditching them or putting them<= br>> in an appendix?

I have done so for the -03 version of the dr= aft.


> I can see the argument for keeping "ssh-rsa" as the> key name and another name for the revised signature
> format. I= 'm not entirely sure about it, I guess
> because I'm used to there be= ing an identity between
> key types and signature types in the SSH pr= otocol.

It's the only way to allow existing, good RSA host keys and = fingerprints to continue to be used.

If we change the key format, it= requires users to re-do their host key and client key setups in order to u= se the new signature methods. In my experience, this is the one thing that = costs users the most, and which they most want to avoid. They'll avoid the = new format if it comes at the cost of re-keying. It would mean adoption wou= ld be pushed several years down the road.

Furthermore, transition to= any other signature format - like from SHA-256 to SHA-512, or from SHA-2 t= o SHA-3 - would then mean paying this whole cost again, and again when the = same keys could be used.

If we decouple the key type from signature = type:
- adoption can happen faster, since the new signatures are compati= ble with existing keys
- the same keys can also be used if we want to mi= grate to SHA-2 512 or SHA-3

It took me a few days to implement this = decoupling for Bitvise SSH Server and Client. Not too hard.


>= As mentioned in my other email, I don't feel super-
> strongly about= naming, but "rsa-pss-sha2-*" seems
> slightly more descriptive and f= uture-proof.

There haven't been any other formats besides PSS and PK= CS#1 v1.5 for a couple decades.

I'm proposing is to migrate to PSS f= or the reasons explained in my message dedicated to that.

If we sett= le on PSS, I think anyone who wants to use PKCS#1 v1.5, perhaps because the= y're lazy, should carry the shame of naming "pkcs1v15" in their signature f= ormat.

If we decide on PSS, I think it should be implicitly baked i= n.

The signature format that's more desirable for the community shou= ld have the nicer / more default looking name, I think. Unless we must disa= mbiguate from something previously existing.

We don't have to disamb= iguate from something that does not exist yet.


> Is it worthw= hile to specify a minimum key size for
> the new signature schemes?
RFC 6187 goes so far as to put "2048" in the algorithm name.

I= have decided against that because it's totally arbitrary and a matter of p= olicy. We don't currently have "ssh-rsa-1024", even though that was the pre= vious de facto minimum key size.

The next version of our SSH Server = will have a setting which will allow a server-wide minimum size for RSA key= s. This will be set to 2048 bits for new installations by default.

H= owever, I don't see the need to hardcode this in an algorithm name. The Sec= urity Considerations section does already strongly suggest 2048-bit keys, o= r larger.


> IMO a "publickey2" (or somesuch) method that incl= uded
> a custom failure message to list the supported key
> typ= es seems like a better way to offer this.

It seems to me that SSH ne= eds a proper extension mechanism to avoid version-string-based hacks and ot= her kinds of hacks.

"publickey2" is not that much simpler to deploy.= It requires changes to existing implementations, like EXT_INFO does. But i= t has none of the benefits:

- Does not solve the general problem of = SSH protocol extension and feature discovery.
- Has a flat cost of an ad= ditional round-trip due to SERVICE_REQUEST and SERVICE_ACCEPT.
- Does no= t make signature algorithm information available in time for the client's f= irst user auth request. This costs a round-trip if the client's first guess= is incorrect.

I think it makes sense to expand the "server-sig-algs= " extension to "auth-info", and include "methods that can continue" as part= of that. This should avoid the need for clients to send "none", which adds= yet an additional round-trip.

I have made this change for the next = draft version.


----- Original Message -----
From: Damien Mill= er
Sent: Tuesday, November 10, 2015 02:18
To: denis bider
Cc: ie= tf-ssh@netbsd.org ; Jeffrey Hutzelman ; NielsM=C3=B6ller ; Mark D. Baushke = ; stephen.farrell@cs.tcd.ie ; jon@siliconcircus.com ; Peter Gutmann ; Max H= orn
Subject: Re: Updated RSA SHA-2 draft / New draft: SSH Extension Neg= otiation

On Sun, 8 Nov 2015, denis bider wrote:

> (1) I ha= ve uploaded a new version of the RSA SHA-2 draft:
>
> https://= tools.ietf.org/html/draft-rsa-dsa-sha2-256-02

Some feedback on the d= raft:

> 1.  Overview and Rationale

The DSA bits in he= re don't seem very relevant. Could I suggest ditching
them or putting th= em in an appendix?

>   All aspects of the "ssh-rsa" for= mat are kept, including the encoded
>   string "ssh-rsa", i= n order to allow users' existing RSA keys to be
>   used wi= th the new signature formats, without requiring re-encoding,
> &= nbsp; or affecting already trusted key fingerprints.

I can see the a= rgument for keeping "ssh-rsa" as the key name and
another name for the r= evised signature format. I'm not entirely sure
about it, I guess because= I'm used to there being an identity between
key types and signature typ= es in the SSH protocol.

> 3.  Discovery of signature algorit= hms supported by servers
>
>   When a public key for= mat can use multiple signature algorithms, it can
>   be us= eful for a mechanism to exist which a client can use to discover
>&nb= sp;  signature algorithms accepted by a server for user authentication=
>   without resorting to trial and error in authentication= requests.
>
>   Such a mechanism is defined in [SSH= -EXT-INFO], which describes general
>   purpose extension n= egotiation for SSH, and specifies discovery of
>   signatur= e algorithms as a usage case.

IMO a "publickey2" (or somesuch) metho= d that included a custom failure
message to list the supported key types= seems like a better way to offer
this.

>   &nb= sp; Public Key Algorithm Name      Reference =          Note
>  &n= bsp;  rsa-sha2-256        &nbs= p;          [this document]&nb= sp;   Section 2
>     rsa-sha2-512 = ;            &n= bsp;     [this document]    Section 2
As mentioned in my other email, I don't feel super-strongly about
n= aming, but "rsa-pss-sha2-*" seems slightly more descriptive and
future-p= roof.

Is it worthwhile to specify a minimum key size for the new sig= nature
schemes?

-d

= --=-s4KscjfjZ74A6VvpnuBL-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Nov 10 14:34:08 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F091B4177 for ; Tue, 10 Nov 2015 14:34:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 v53gMB0VGVbd for ; Tue, 10 Nov 2015 14:34:03 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE1D51B4176 for ; Tue, 10 Nov 2015 14:34:03 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 58FC814A1F4; Tue, 10 Nov 2015 22:33:58 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id F33C714A1F3; Tue, 10 Nov 2015 22:33:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id A488F14A318 for ; Tue, 10 Nov 2015 13:25:28 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id V22W38uJzxFk for ; Tue, 10 Nov 2015 13:25:27 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id DF43B14A301 for ; Tue, 10 Nov 2015 13:25:27 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for ietf-ssh@netbsd.org; Tue, 10 Nov 2015 13:25:19 +0000 Date: Tue, 10 Nov 2015 13:25:19 +0000 Subject: rsa-sha2-256: Need YOUR opinion on PSS vs PKCS#1 v1.5 X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <2283674768-1052@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: ietf-ssh@netbsd.org Cc: pgut001@cs.auckland.ac.nz, djm@mindrot.org Content-Type: multipart/alternative; boundary="=-ky4J/Pwgpackbi9pmvMT" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-ky4J/Pwgpackbi9pmvMT Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBleHRlbmQgdGhhbmtzIHRvIFBldGVyIEd1dG1hbm4gZm9yIGF0dGVtcHRpbmcgdG8gaW1wbGVt ZW50IHJzYS1zaGEyLTI1Ni4NCg0KSW4gYSByZWNlbnQgdmVyc2lvbiBvZiB0aGUgZHJhZnQsIEkg Y2hhbmdlZCB0aGUgcGFkZGluZyB0byBQU1MgKGZyb20gUEtDUyMxIHYxLjUpIGZvciB0aGUgZm9s bG93aW5nIHJlYXNvbnM6DQoNCigxKSBSRkMgMzQ0Nywgd2hlcmUgYm90aCBmb3JtYXRzIGFyZSBk ZWZpbmVkLCByZWNvbW1lbmRzIFBTUzoNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm YzM0NDcjc2VjdGlvbi04DQogICBBbHRob3VnaCBubyBhdHRhY2tzIGFyZSBrbm93bgogICBhZ2Fp bnN0IFJTQVNTQS1QS0NTMS12MV81LCBpbiB0aGUgaW50ZXJlc3Qgb2YgaW5jcmVhc2VkIHJvYnVz dG5lc3MsCiAgIFJTQVNTQS1QU1MgaXMgcmVjb21tZW5kZWQgZm9yIGV2ZW50dWFsIGFkb3B0aW9u IGluIG5ldyBhcHBsaWNhdGlvbnMuCiAgIFJTQVNTQS1QS0NTMS12MV81IGlzIGluY2x1ZGVkIGZv ciBjb21wYXRpYmlsaXR5IHdpdGggZXhpc3RpbmcKICAgYXBwbGljYXRpb25zLCBhbmQgd2hpbGUg c3RpbGwgYXBwcm9wcmlhdGUgZm9yIG5ldyBhcHBsaWNhdGlvbnMsIGEKICAgZ3JhZHVhbCB0cmFu c2l0aW9uIHRvIFJTQVNTQS1QU1MgaXMgZW5jb3VyYWdlZC5Ob3RlIHRoYXQgdGhpcyB3YXMgcHVi bGlzaGVkIGluIDIwMDMuIFR3ZWx2ZSB5ZWFycyBsYXRlciwgaXQgbWlnaHQgYmUgdGltZSB0byBz dGFydCBtYWtpbmcgdGhpcyB0cmFuc2l0aW9uLg0KDQooMikgSGFubm8gQm9lY2sgaGFzIGFyZ3Vl ZCBwZXJzdWFzaXZlbHkgaW4gZmF2b3Igb2YgUFNTOg0KDQpodHRwczovL3JzYXBzcy5oYm9lY2su ZGUvcnNhcHNzLTEuMC4zLnBkZg0KDQpIZSBtYWtlcyB0aGUgZm9sbG93aW5nIHBvaW50czoNCg0K LSBQU1MgaGFzIHByb3ZhYmxlIHNlY3VyaXR5IGluIHRoZSByYW5kb20gb3JhY2xlIG1vZGVsOyBQ S0NTIzEgdjEuNSBkb2VzIG5vdC4NCi0gVGhlcmUgaGF2ZSBiZWVuIHN1Y2Nlc3NmdWwgYXR0YWNr cyBvbiBQS0NTIzEgdjEuNSBpbXBsZW1lbnRhdGlvbnMuIFRoZXNlIGRvIG5vdCB3b3JrIGFnYWlu c3QgY29ycmVjdCAobm9uLXBhcnNlci1saWtlKSB2ZXJpZmllciBpbXBsZW1lbnRhdGlvbnMuIEhv d2V2ZXIsIGR1ZSB0byBpdHMgc3RydWN0dXJlLCBQS0NTIzEgdjEuNSBpcyBhcHBlYWxpbmcgdG8g aW1wbGVtZW50IGluY29ycmVjdGx5Lg0KLSBGYXVsdC1iYXNlZCBhdHRhY2tzIHRha2UgbW9yZSBj YXJlIHRvIGRlZmVuZCBhZ2FpbnN0IHVzaW5nIFBLQ1MjMSB2MS41IHRoYW4gdXNpbmcgUFNTLg0K DQooMykgQXZhaWxhYmlsaXR5IG9mIFBTUyBpcyBub3cgbXVjaCBiZXR0ZXIgdGhhbiBpdCB1c2Vk IHRvIGJlLiBJbiBteSBjYXNlLCBJIHdvcmsgd2l0aCBDcnlwdG8rKyBhbmQgV2luZG93cyBDTkcs IHdoaWNoIGJvdGggc3VwcG9ydCBpdC4gRnJlZSBzb2Z0d2FyZSB0ZW5kcyB0byB1c2UgT3BlblNT TCwgd2hpY2ggaGFzIGFsc28gc3VwcG9ydGVkIFBTUyBzaW5jZSB2ZXJzaW9uIDEuMC4xLiBUaGlz IGhhcyBiZWVuIGF2YWlsYWJsZSBzaW5jZSAyMDEyLg0KDQpUaGVzZSBhcmUgdGhlIGFyZ3VtZW50 cyBpbiBmYXZvciBvZiBQU1MuDQoNClRoZSBtYWluIGFyZ3VtZW50IGFnYWluc3QgaXMgYXMgcG9p bnRlZCBvdXQgYnkgUGV0ZXIgR3V0bWFubi4gQWx0aG91Z2ggYSBudW1iZXIgb2YgbWFqb3IgY3J5 cHRvIGltcGxlbWVudGF0aW9ucyBoYXZlIGl0LCB0aGVyZSBhcmUgc3RpbGwgaW1wbGVtZW50YXRp b25zIG91dCB0aGVyZSB0aGF0IGRvIG5vdC4NCg0KV2hhdCdzIGV2ZXJ5b25lJ3Mgb3BpbmlvbiBv biB0aGlzPw0KDQpJbiBteSBvcGluaW9uLCB3ZSBvdWdodCB0byBtaWdyYXRlIHRvd2FyZCBhbiBh cHBhcmVudCBpbXByb3ZlbWVudCwgYW5kIG5vdyBpcyB0aGUgb3Bwb3J0dW5pdHkgdG8gZG8gc28u DQoNCklmIHdlIHNwZWNpZnkgUEtDUyMxIHYxLjUgdG9kYXksIHdlJ2xsIGJlIHN0dWNrIHdpdGgg aXQgZm9yIDE1IHllYXJzLg0KDQpXZSBtYXkgaGF2ZSB0byBkZWZpbmUgYW5vdGhlciBzaWduYXR1 cmUgYWxnb3JpdGhtIHRoYXQgdXNlcyBQU1MgaW4gdGhlIGZ1dHVyZSwgaWYgc3RhbmRhcmRzIGJv ZGllcyBzdGFydCB0byBkZW1hbmQgUFNTLg0KDQpUaGUgbWFpbiBhcmd1bWVudCBpbiBmYXZvciBv ZiBQS0NTIzEgdjEuNSBhcHBlYXJzIHRvIGJlIGxhemluZXNzLiBObz8NCg0K --=-ky4J/Pwgpackbi9pmvMT Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable I extend thanks to Peter Gutmann for attempting to= implement rsa-sha2-256.

In a recent version of the draft, I changed= the padding to PSS (from PKCS#1 v1.5) for the following reasons:

(1) RFC 3447, where both formats are defined, recommends PSS:
https://tools.ietf.org/html/rfc3447#section-8
   Although no attacks are known
   against RSASSA-PKCS1-v1_5, in the interest of increased robustness,
   RSASSA-PSS is recommended for eventual adoption in new applications.
   RSASSA-PKCS1-v1_5 is included for compatibility with existing
   applications, and while still appropriate for new applications, a
   gradual transition to RSASSA-PSS is encouraged.
Note that this was = published in 2003. Twelve years later, it might be time to start making thi= s transition.

(2) Hanno Boeck has argued persuasively in favo= r of PSS:

https://rsapss.hboeck.de/rsapss-1.0.3.pdf

He makes = the following points:

- PSS has provable security in the rand= om oracle model; PKCS#1 v1.5 does not.
- There have been successful a= ttacks on PKCS#1 v1.5 implementations. These do not work against correc= t (non-parser-like) verifier implementations. However, due to its structure= , PKCS#1 v1.5 is appealing to implement incorrectly.
- Fault-based at= tacks take more care to defend against using PKCS#1 v1.5 than using PSS= .

(3) Availability of PSS is now much better than it used to = be. In my case, I work with Crypto++ and Windows CNG, which both support it= . Free software tends to use OpenSSL, which has also supported PSS since ve= rsion 1.0.1. This has been available since 2012.

These are the argum= ents in favor of PSS.

The main argument against is as pointed out by= Peter Gutmann. Although a number of major crypto implementations have it, = there are still implementations out there that do not.

What's everyo= ne's opinion on this?

In my opinion, we ought to migrate toward an a= pparent improvement, and now is the opportunity to do so.

If we spec= ify PKCS#1 v1.5 today, we'll be stuck with it for 15 years.

We may h= ave to define another signature algorithm that uses PSS in the future, if s= tandards bodies start to demand PSS.

The main argument in favor of P= KCS#1 v1.5 appears to be laziness. No?

= --=-ky4J/Pwgpackbi9pmvMT-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Nov 10 14:34:22 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96A901B416E for ; Tue, 10 Nov 2015 14:34:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 4lkORmkwe8re for ; Tue, 10 Nov 2015 14:34:18 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 316CB1B417A for ; Tue, 10 Nov 2015 14:34:18 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id D325A14A1F7; Tue, 10 Nov 2015 22:34:17 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 7BF6D14A1F3; Tue, 10 Nov 2015 22:34:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id F3E8814A31A for ; Tue, 10 Nov 2015 14:32:45 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id me4nNq4ZAR_c for ; Tue, 10 Nov 2015 14:32:45 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 02A2D14A311 for ; Tue, 10 Nov 2015 14:32:44 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for ietf-ssh@netbsd.org; Tue, 10 Nov 2015 14:32:17 +0000 Date: Tue, 10 Nov 2015 14:32:17 +0000 Subject: Re: Curve25519/448 key agreement for SSH X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <2289172118-568@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: ietf-ssh@netbsd.org Cc: Simon Josefsson , djm@mindrot.org Content-Type: multipart/alternative; boundary="=-LFBhBGGgWahE/uupDZnb" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-LFBhBGGgWahE/uupDZnb Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2ltb24gLQ0KDQoNCj4gQSBzaW1wbGUgYXBwcm9hY2ggd291bGQgYmUgdG8gc2F5IHRoYXQgaWYg dGhlIE1TQiBpcyAxLA0KPiBwcmVwZW5kIGEgemVybyBieXRlLsKgIEhvd2V2ZXIsIHRoZSBsZW5n dGggZGlmZmVyZW5jZQ0KPiB3b3VsZCBsZWFrIHRoYXQgaW5mb3JtYXRpb24uDQoNClRoZSBsZW5n dGggZGlmZmVyZW5jZSBtaWdodCBub3QgYmUgbXVjaCBvZiBhIHByb2JsZW0sIHNpbmNlIEsgaXMg bmV2ZXIgc2VudC4NCg0KDQo+IEZvciBDdXJ2ZTQ0OCB0aGlzIHNlZW1zIGxpa2UgYSBwcm9ibGVt LsKgIElzIGl0IG9rYXkgdG8NCj4gcHJlcGVuZCBhIHplcm8gYnl0ZSBpbiBTU0ggYmlnIGludGVn ZXJzIGV2ZW4gaWYNCj4gb25lIGlzIG5vdCBuZWNlc3Nhcnk/DQoNCk5vLCB0aGlzIGlzIHByb2hp Yml0ZWQgaW4gUkZDIDQyNTE6DQoNCiAgVW5uZWNlc3NhcnkgbGVhZGluZyBieXRlcyB3aXRoIHRo ZSB2YWx1ZSAwIG9yIDI1NSBNVVNUIE5PVCBiZQogIGluY2x1ZGVkLiAgVGhlIHZhbHVlIHplcm8g TVVTVCBiZSBzdG9yZWQgYXMgYSBzdHJpbmcgd2l0aCB6ZXJvCiAgYnl0ZXMgb2YgZGF0YS4NCmRl bmlzDQoNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogU2ltb24gSm9zZWZz c29uIA0KU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMTAsIDIwMTUgMDM6MzANClRvOiBkZW5pcyBi aWRlciANCkNjOiBpZXRmLXNzaEBuZXRic2Qub3JnIA0KU3ViamVjdDogUmU6IEN1cnZlMjU1MTkv NDQ4IGtleSBhZ3JlZW1lbnQgZm9yIFNTSA0KDQpkZW5pcyBiaWRlciA8aWV0Zi1zc2gzQGRlbmlz YmlkZXIuY29tPiB3cml0ZXM6DQoNCj4gU2ltb24sIEFyaXMgLQ0KPg0KPiB0aGFuayB5b3UgZm9y IHRoaXMgd29yay4gSSBwbGFuIHRvIGJlIGltcGxlbWVudGluZyB0aGlzIHNvb24sIGFuZCBJDQo+ IGFwcHJlY2lhdGUgdGhhdCB5b3UncmUgbW92aW5nIGFoZWFkIHdpdGggc3RhbmRhcmRpemF0aW9u Lg0KDQpIaSBEZW5pcy7CoCBFeGNlbGxlbnQhwqAgSXQgd291bGQgYmUgcGVyZmVjdCBpZiBzb21l b25lIHdvdWxkIGF0dGVtcHQNCmltcGxlbWVudGF0aW9uIGJhc2VkIG9uIHRoaXMgZG9jdW1lbnQg KGFuZCBjZnJnLWN1cnZlcykgYW5kIHRlbGwgdXMgd2hhdA0KaXMgbWlzc2luZywgYW5kIHdoYXQg Y291bGQgaGF2ZSBoZWxwZWQgdGhlbSBpbXBsZW1lbnQgaXQgbW9yZSBxdWlja2x5Lg0KDQo+IFdp dGggcmVzcGVjdCB0byBjb252ZXJzaW9uIG9mIHRoZSBiaW5hcnkgc3RyaW5nIFggaW50byBtcGlu dCBLLCBpcw0KPiB0aGVyZSBhIGNoYW5jZSB0aGF0IFggbWlnaHQgaGF2ZSBpdHMgaGlnaCBiaXQg c2V0Pw0KPg0KPiBJZiBpdCdzIHBvc3NpYmxlIGZvciB0aGUgaGlnaCBiaXQgdG8gYmUgc2V0LCBp dCBzZWVtcyB5b3Ugb3VnaHQgdG8NCj4gY2xhcmlmeSBob3cgdGhhdCdzIGNvbnZlcnRlZCBpbnRv IG1waW50LCBnaXZlbiB0aGF0IG1waW50IGlzIHNpZ25lZDoNCj4NCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvcmZjL3JmYzQyNTEudHh0DQoNCj7CoMKgwqDCoMKgwqAgUmVwcmVzZW50cyBtdWx0aXBs ZSBwcmVjaXNpb24gaW50ZWdlcnMgaW4gdHdvJ3MgY29tcGxlbWVudCBmb3JtYXQsDQo+wqDCoMKg wqDCoMKgIHN0b3JlZCBhcyBhIHN0cmluZywgOCBiaXRzIHBlciBieXRlLCBNU0IgZmlyc3QuwqAg TmVnYXRpdmUgbnVtYmVycw0KPsKgwqDCoMKgwqDCoCBoYXZlIHRoZSB2YWx1ZSAxIGFzIHRoZSBt b3N0IHNpZ25pZmljYW50IGJpdCBvZiB0aGUgZmlyc3QgYnl0ZSBvZg0KPsKgwqDCoMKgwqDCoCB0 aGUgZGF0YSBwYXJ0aXRpb24uwqAgSWYgdGhlIG1vc3Qgc2lnbmlmaWNhbnQgYml0IHdvdWxkIGJl IHNldCBmb3INCj7CoMKgwqDCoMKgwqAgYSBwb3NpdGl2ZSBudW1iZXIsIHRoZSBudW1iZXIgTVVT VCBiZSBwcmVjZWRlZCBieSBhIHplcm8gYnl0ZS4NCg0KR29vZCBwb2ludCwgSSBiZWxpZXZlIHRo ZSBkb2N1bWVudCBoYXMgdG8gZGlzY3VzcyB0aGUgbWFwcGluZyBiZXR3ZWVuDQpiaW5hcnkgQ3Vy dmUyNTUxOS9DdXJ2ZTQ0OCBiaW5hcnkgc3RyaW5ncyBpbnRvIG1waW50J3MuDQoNCkEgc2ltcGxl IGFwcHJvYWNoIHdvdWxkIGJlIHRvIHNheSB0aGF0IGlmIHRoZSBNU0IgaXMgMSwgcHJlcGVuZCBh IHplcm8NCmJ5dGUuwqAgSG93ZXZlciwgdGhlIGxlbmd0aCBkaWZmZXJlbmNlIHdvdWxkIGxlYWsg dGhhdCBpbmZvcm1hdGlvbi4NCg0KRm9yIEN1cnZlMjU1MTkgdGhlIG1vc3Qtc2lnbmlmaWNhbnQg Yml0IGlzIGFsd2F5cyB6ZXJvIHRob3VnaCwgc28gdGhpcw0Kd2lsbCBuZXZlciBoYXBwZW4uwqAg Rm9yIEN1cnZlNDQ4IHRoaXMgc2VlbXMgbGlrZSBhIHByb2JsZW0uwqAgSXMgaXQgb2theQ0KdG8g cHJlcGVuZCBhIHplcm8gYnl0ZSBpbiBTU0ggYmlnIGludGVnZXJzIGV2ZW4gaWYgb25lIGlzIG5v dCBuZWNlc3Nhcnk/DQpUaGVuIGEgc2ltcGxlIGFwcHJvYWNoIHdvdWxkIGJlIHRvIGRvIG5vdGhp bmcgZm9yIEN1cnZlMjU1OSBhbmQgdG8NCmFsd2F5cyBhZGQgYSB6ZXJvIGJ5dGUgZm9yIEN1cnZl NDQ4Lg0KDQo+IEJlc2lkZXMgdGhhdCwgSSdtIG5vdGljaW5nIHRoZSBsYW5ndWFnZSBjb3VsZCB1 c2UgaW1wcm92ZW1lbnQgaW4NCj4gcGxhY2VzICgidGhpcyBkb2N1bWVudCByZS11c2UiIC0+ICJ0 aGlzIGRvY3VtZW50IHJldXNlcyIsICJpcyBpcyIgLT4NCj4gImlzIikuDQoNCkZpeGVkLCB0aGFu ayB5b3UuDQoNCi9TaW1vbg0KDQo+IE92ZXJhbGwsIHRoYW5rIHlvdSBmb3IgbW92aW5nIGZvcndh cmQgd2l0aCB0aGlzLCB0aG91Z2guDQo+DQo+DQo+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0t LS0NCj4gRnJvbTogU2ltb24gSm9zZWZzc29uIA0KPiBTZW50OiBNb25kYXksIE5vdmVtYmVyIDks IDIwMTUgMDk6MDcNCj4gVG86IGlldGYtc3NoQG5ldGJzZC5vcmcgDQo+IFN1YmplY3Q6IEN1cnZl MjU1MTkvNDQ4IGtleSBhZ3JlZW1lbnQgZm9yIFNTSA0KPg0KPiBBcmlzIGFuZCBtZSBoYXZlIHBy ZXBhcmVkIGEgZG9jdW1lbnQgZGVzY3JpYmluZyBrZXkgYWdyZWVtZW50IHVzaW5nIHRoZQ0KPiBD RlJHIGN1cnZlcyBmb3IgU2VjdXJlIFNoZWxsLsKgIEFzIHlvdSBrbm93LCBjdXJ2ZTI1NTE5LXNo YTI1NkBsaWJzc2gub3JnDQo+IGlzIGFscmVhZHkgaW1wbGVtZW50ZWQgYnkgbGlic3NoLCBPcGVu U1NILCBEcm9wYmVhciwgYW5kIHNvbWUgb3RoZXJzLg0KPiBUaGlzIGlzIGFib3V0IHB1dHRpbmcg dGhlIGRlc2NyaXB0aW9uIG9mIHRoYXQgaW50byBJRVRGIGZvcm1hdCwgYW5kIHRvDQo+IGFkZCB0 aGUgQ3VydmU0NDggaGVkZ2UgdmFyaWFudCBjaG9zZW4gYnkgQ0ZSRy7CoCBJdCBtaWdodCBub3Qg YmUgZGV0YWlsZWQNCj4gZW5vdWdoIGZvciBpbmRlcGVuZGVudCBpbXBsZW1lbnRhdGlvbiwgYnV0 IHdlIGhvcGUgdG8gZ2V0IHRoZXJlLsKgIEFueQ0KPiByZXZpZXcgYW5kIGZlZWRiYWNrIGlzIHdl bGNvbWUuDQo+DQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qb3NlZnNzb24t c3NoLWN1cnZlcw0KPg0KPiAvU2ltb24NCj4NCj4gUFMuIFRoZXJlIGlzIGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1iamgyMS1zc2gtZWQyNTUxOSBidXQNCj4gdGhhdCB0YWxrcyBh Ym91dCBFZDI1NTE5IHNpZ25hdHVyZXMuwqAgVGhlIGRvY3VtZW50IGFib3ZlIGlzIGFib3V0IGtl eQ0KPiBhZ3JlZW1lbnQuDQo+DQoNCg== --=-LFBhBGGgWahE/uupDZnb Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Simon -


> A simple approach would be= to say that if the MSB is 1,
> prepend a zero byte.  However, t= he length difference
> would leak that information.

The length= difference might not be much of a problem, since K is never sent.

<= br>> For Curve448 this seems like a problem.  Is it okay to
>= prepend a zero byte in SSH big integers even if
> one is not necessa= ry?

No, this is prohibited in RFC 4251:

  Unnecessary le=
ading bytes with the value 0 or 255 MUST NOT be
  included.  The value zero MUST be stored as a string with zero
  bytes of data.

denis


----- Original Message -----
= From: Simon Josefsson
Sent: Tuesday, November 10, 2015 03:30
To: den= is bider
Cc: ietf-ssh@netbsd.org
Subject: Re: Curve25519/448 key ag= reement for SSH

denis bider <ietf-ssh3@denisbider.com> writes:=

> Simon, Aris -
>
> thank you for this work. I plan = to be implementing this soon, and I
> appreciate that you're moving a= head with standardization.

Hi Denis.  Excellent!  It would= be perfect if someone would attempt
implementation based on this docume= nt (and cfrg-curves) and tell us what
is missing, and what could have he= lped them implement it more quickly.

> With respect to conversion= of the binary string X into mpint K, is
> there a chance that X migh= t have its high bit set?
>
> If it's possible for the high bit = to be set, it seems you ought to
> clarify how that's converted into = mpint, given that mpint is signed:
>
> https://www.ietf.org/rfc= /rfc4251.txt

>       Represents mul= tiple precision integers in two's complement format,
>  &nb= sp;    stored as a string, 8 bits per byte, MSB first. = Negative numbers
>       have the valu= e 1 as the most significant bit of the first byte of
>  &nb= sp;    the data partition.  If the most significant bit= would be set for
>       a positive nu= mber, the number MUST be preceded by a zero byte.

Good point, I beli= eve the document has to discuss the mapping between
binary Curve25519/Cu= rve448 binary strings into mpint's.

A simple approach would be to sa= y that if the MSB is 1, prepend a zero
byte.  However, the length d= ifference would leak that information.

For Curve25519 the most-signi= ficant bit is always zero though, so this
will never happen.  For C= urve448 this seems like a problem.  Is it okay
to prepend a zero by= te in SSH big integers even if one is not necessary?
Then a simple appro= ach would be to do nothing for Curve2559 and to
always add a zero byte f= or Curve448.

> Besides that, I'm noticing the language could use = improvement in
> places ("this document re-use" -> "this document = reuses", "is is" ->
> "is").

Fixed, thank you.

/Simo= n

> Overall, thank you for moving forward with this, though.
&= gt;
>
> ----- Original Message -----
> From: Simon Josefs= son
> Sent: Monday, November 9, 2015 09:07
> To: ietf-ssh@netb= sd.org
> Subject: Curve25519/448 key agreement for SSH
>
&g= t; Aris and me have prepared a document describing key agreement using the<= br>> CFRG curves for Secure Shell.  As you know, curve25519-sha256@= libssh.org
> is already implemented by libssh, OpenSSH, Dropbear, and= some others.
> This is about putting the description of that into IE= TF format, and to
> add the Curve448 hedge variant chosen by CFRG.&nb= sp; It might not be detailed
> enough for independent implementation,= but we hope to get there.  Any
> review and feedback is welcome= .
>
> https://tools.ietf.org/html/draft-josefsson-ssh-curves>
> /Simon
>
> PS. There is https://tools.ietf.org/ht= ml/draft-bjh21-ssh-ed25519 but
> that talks about Ed25519 signatures.=   The document above is about key
> agreement.
>

= --=-LFBhBGGgWahE/uupDZnb-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Nov 10 14:35:32 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57B951B4191 for ; Tue, 10 Nov 2015 14:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 87eJRMHUhPhF for ; Tue, 10 Nov 2015 14:35:31 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F1501B4190 for ; Tue, 10 Nov 2015 14:35:31 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id D0B8E14A0A5; Tue, 10 Nov 2015 22:35:30 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 679D614A0A2; Tue, 10 Nov 2015 22:35:30 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id E00C014A1D2 for ; Tue, 10 Nov 2015 20:08:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id OwZCe62r9CdY for ; Tue, 10 Nov 2015 20:08:39 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 0ECF014A1BA for ; Tue, 10 Nov 2015 20:08:37 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 0B4AA4001F; Tue, 10 Nov 2015 21:08:35 +0100 (CET) Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id 9CAD44001B; Tue, 10 Nov 2015 21:08:32 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Tue, 10 Nov 2015 21:08:32 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: "Mark D. Baushke" Cc: Damien Miller , Peter Gutmann , "denis bider" , Jeffrey Hutzelman , "ietf-ssh\@NetBSD.org" , "stephen.farrell\@cs.tcd.ie" , "jon\@siliconcircus.com" Subject: Re: DH group exchange (Re: SSH key algorithm updates) References: <9A043F3CF02CD34C8E74AC1594475C73F4B5993D@uxcn10-5.UoA.auckland.ac.nz> <2096379125-720@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B599ED@uxcn10-5.UoA.auckland.ac.nz> <55190.1447001241@eng-mail01.juniper.net> <9A043F3CF02CD34C8E74AC1594475C73F4B5A9BC@uxcn10-5.UoA.auckland.ac.nz> <65113.1447107876@eng-mail01.juniper.net> <90378.1447145301@eng-mail01.juniper.net> Date: Tue, 10 Nov 2015 21:08:32 +0100 In-Reply-To: <90378.1447145301@eng-mail01.juniper.net> (Mark D. Baushke's message of "Tue, 10 Nov 2015 00:48:21 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list "Mark D. Baushke" writes: > Given that OpenSSH is using group16 with sha2-256 preserves 128 bits of > security, How do you reason about that halving, from 256 to 128? For the key expansion, I'd expect that you can count very close to 256 bits of entropy in the generated keys (assuming the secret dh values were generated randomly). Now, you will start to get some repeated session keys, i.e., collisions, after about 2^128 sessions. But that has little to do with the hash function: if we had a crypto system which for each session generated a 256-bit session key from a truly random source, we'd also get collisions after about 2^128 sessions. But I think the conventional way to assign a security level to such a system is 2^256 (the difficuly of exhaustive key search), not 2^128. Am I missing something? Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Nov 10 16:02:17 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B51131A1B4E for ; Tue, 10 Nov 2015 16:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 fGbThsw2iC1n for ; Tue, 10 Nov 2015 16:02:16 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D5C01A1B51 for ; Tue, 10 Nov 2015 16:02:16 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 6C8DA14A1DD; Wed, 11 Nov 2015 00:02:14 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 124F314A1D8 for ; Wed, 11 Nov 2015 00:02:03 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id b9hDHNmpACgz for ; Wed, 11 Nov 2015 00:02:02 +0000 (UTC) Received: from newmailhub.uq.edu.au (mailhub2.soe.uq.edu.au [130.102.132.209]) by mail.netbsd.org (Postfix) with ESMTP id 0A6A614A1D5 for ; Wed, 11 Nov 2015 00:01:59 +0000 (UTC) Received: from smtp2.soe.uq.edu.au (smtp2.soe.uq.edu.au [10.138.113.41]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id tAB01fUM010130; Wed, 11 Nov 2015 10:01:41 +1000 Received: from mailhub.eait.uq.edu.au (hazel.eait.uq.edu.au [130.102.60.17]) by smtp2.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id tAB01f3R030495 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 11 Nov 2015 10:01:41 +1000 Received: from natsu.mindrot.org (natsu.mindrot.org [130.102.96.2]) by mailhub.eait.uq.edu.au (8.15.1/8.15.1) with ESMTP id tAB01eUM004929; Wed, 11 Nov 2015 10:01:40 +1000 (AEST) Received: by natsu.mindrot.org (Postfix, from userid 1000) id CE9ABA4F31; Wed, 11 Nov 2015 11:01:40 +1100 (AEDT) Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id CDFC4A4F30; Wed, 11 Nov 2015 11:01:40 +1100 (AEDT) Date: Wed, 11 Nov 2015 11:01:40 +1100 (AEDT) From: Damien Miller To: Simon Josefsson cc: ietf-ssh@netbsd.org Subject: Re: Curve25519/448 key agreement for SSH In-Reply-To: <87vb9auhmh.fsf@latte.josefsson.org> Message-ID: References: <87pozjyzxc.fsf@latte.josefsson.org> <87poziw56c.fsf@latte.josefsson.org> <87vb9auhmh.fsf@latte.josefsson.org> User-Agent: Alpine 2.20 (BSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub X-Scanned-By: MIMEDefang 2.75 on 130.102.60.17 X-UQ-FilterTime: 1447200101 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Tue, 10 Nov 2015, Simon Josefsson wrote: > > AFAIK it might not be possible to resolve without being incompatible > > with the deployed curve25519-sha256@libssh.org protocol: OpenSSH at > > least checks for correct zero-padding for mpints with the MSB set. > > Curve25519 would never have the MSB set, if I understand correctly. So > what is the potential for incompatibility? Maybe I'm missing something. That's true of the public values, but not necessarily of the shared secret, right? I'd expect the shared secret to have the most significant bit set half the time. > I believe this document should document exactly what > curve25519-sha256@libssh.org does, otherwise things will be confusing. > Unless there is a significant mistake with it, of course, but then > people shouldn't be using it at all. > > Nobody has implemented Curve448 for SSH so there is no compatibility to > think about there. There has not been a lot of interest from > implementers in Curve448 either, since it is slower (no twisted curve). > The only argument I can think of for supporting it is that it hedges you > against potential new analytical ECC attacks that would affect > Curve25519. But for this work, I believe including Curve448 makes sense > since it is what CFRG recommends. Changing the encoding means changing the exchange hash's last field from mpint to string. I argued for this when Aris sent the original curve25519-sha256@libssh.org diff to OpenSSH, but didn't think of the possible MSB leakage and lost the argument :/ Anyway, to summarise the arguments: For changing the encoding of K from mpint to string: - Avoids varying length of K encoding in exchange hash, unlikely leak of MSB via timing channel - Easier to implement Against: - Inconsistency between curve25519 and curve448 K encoding - Inconsistency between curve448 and all the other KEX methods I honestly don't know whether it is worth fixing it. If I were writing SSH protocol v.3 then I'd remove mpints from the wire protocol entirely and have each protocol define a canonical string encoding for its values. -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Nov 11 00:15:05 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60C251A037A for ; Wed, 11 Nov 2015 00:15:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 coz1Tfjc4kjI for ; Wed, 11 Nov 2015 00:15:02 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D8FF1A036C for ; Wed, 11 Nov 2015 00:15:02 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id ABBD514A228; Wed, 11 Nov 2015 08:14:58 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 0EFBD14A224 for ; Wed, 11 Nov 2015 08:14:49 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 6CPf-3GgcT94 for ; Wed, 11 Nov 2015 08:14:48 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 44B9D14A1F0 for ; Wed, 11 Nov 2015 08:14:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1447229688; x=1478765688; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=RB35z9L8ESPG9AMhXjz5u794Kf1nyWrcnH5M49GOcps=; b=vve688Zbakx7qmryfYMH1ZpK3+r3kqanQUhitiDtYwDGO8W58B1xCNRH ejaO9NUy3ru9D2oU4yJlCDRCKQuvF52bq3+bzD5kSD+Vo/+Qv4xp5TZ5W OrdPhTr57w6E+83LXf/rG6ns4Jn+g5ni5f1dP/f+oFSzMH66HAoD8XdYV BfoV6HGhSQZAO52GOJuMNDT+YsDZyelNyxJihnCc+ByaSfBApe+vjFj/W rrpNce8rS3uEwAzb/xtfqQIU6NDZ1SjUAzF0UWTnbyRSACv4kC0fyW47g sFZipts8k81Tc5k8ShNRwFAsdFE322AXUIjau5XKSVMaR6SYYOOrgSYgl g==; X-IronPort-AV: E=Sophos;i="5.20,274,1444647600"; d="scan'208";a="53704242" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe2.UoA.auckland.ac.nz) ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 11 Nov 2015 21:14:19 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Wed, 11 Nov 2015 21:14:18 +1300 From: Peter Gutmann To: denis bider , "ietf-ssh@netbsd.org" CC: "djm@mindrot.org" Subject: RE: rsa-sha2-256: Need YOUR opinion on PSS vs PKCS#1 v1.5 Thread-Topic: rsa-sha2-256: Need YOUR opinion on PSS vs PKCS#1 v1.5 Thread-Index: AQHRG7tAJkIC2QLIW0Cbt3W8mke9Op6WelCr Date: Wed, 11 Nov 2015 08:14:18 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B5DEB1@uxcn10-5.UoA.auckland.ac.nz> References: <2283674768-1052@skroderider.denisbider.com> In-Reply-To: <2283674768-1052@skroderider.denisbider.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list denis bider writes:=0A= =0A= >Note that this was published in 2003. Twelve years later, it might be time= to=0A= >start making this transition.=0A= =0A= PSS is just under 20 years old (it dates from 1996, "The Exact Security of= =0A= Digital Signatures How to Sign with RSA and Rabin"). If there's been next = to=0A= zero interest in it in twenty years, why start now? The signature mechanis= m=0A= that'll be used everywhere a decade from now will almost certainly still be= =0A= PKCS #1, not PSS.=0A= =0A= OAEP, the key-transport equivalent of PSS, has the same problem. It dates= =0A= from 1994 ("Optimal Asymmetric Encryption"), but the only major(?)=0A= applications I can think of at the moment are SET and Windows Vista content= =0A= protection. In twenty years its major adopters have been a failed e-commer= ce=0A= protocol and Vista DRM (and that had some pretty weird stuff in it anyway, = it=0A= looked like it was defined by geeks on a crypto algorithm shopping expediti= on,=0A= I had to add a pile of bizarro stuf to my code to implement that that I've= =0A= never had to use since).=0A= =0A= >- PSS has provable security in the random oracle model; PKCS#1 v1.5 does n= ot.=0A= =0A= I haven't looked at PSS too much, but OAEP is a mass of timing side-channel= s.=0A= Its complex structure makes it pretty much impossible to implement without= =0A= exposing side-channels, and there are published attacks on some of them (se= e=0A= e.g. James Manger's "A chosen ciphertext attack on RSA optimal asymmetric= =0A= encryption padding (OAEP)").=0A= =0A= It's not such a big deal with PSS since you're not exposing secret data=0A= through it, but just because something has an abstract mathematical proof (= in=0A= an equally abstract mathematical model) doesn't make it secure in the real= =0A= world. OAEP, like PSS, is also provably secure, except that it probably is= n't=0A= (see Victor Shoup's "OAEP Reconsidered", and the more recent "Trading One-= =0A= Wayness against Chosen-Ciphertext Security in Factoring-Based Encryption",= =0A= which points out that the random-oracle model used for the proofs doesn't= =0A= provide the same level of assurance as the standard model, and vice versa i= n=0A= some cases).=0A= =0A= In any case since the proof doesn't consider side-channel attacks, it's not= =0A= actually secure despite its proof that it is. OAEP in my code is commented= =0A= out because of this, and isn't exposed through an external API.=0A= =0A= (Not wanting to start a long debate about security proofs, see "Another Loo= k=0A= at 'Provable Security'" for a starter on this, just pointing out that a=0A= security proof is just a supporting argument for something, not an actual= =0A= proof that it's secure in practice).=0A= =0A= >- There have been successful attacks on PKCS#1 v1.5 implementations. These= do=0A= >not work against correct (non-parser-like) verifier implementations. Howev= er,=0A= >due to its structure, PKCS#1 v1.5 is appealing to implement incorrectly.= =0A= =0A= All you need there is a note to tell people to encode the sig and do a=0A= memcmp(), it's extremely simple. In addition if there were timing side-=0A= channels, a constant-time memcmp() to deal with them is easy to implement.= =0A= =0A= >(3) Availability of PSS is now much better than it used to be. In my case,= I=0A= >work with Crypto++ and Windows CNG, which both support it. =0A= =0A= Oh, they finally added it in Windows? It wasn't supported for most of the= =0A= lifetime of CryptoAPI (and presumably still won't be in older version of=0A= Windows which don't qualify for upgrades).=0A= =0A= >In my opinion, we ought to migrate toward an apparent improvement, and now= is=0A= >the opportunity to do so.=0A= >=0A= >If we specify PKCS#1 v1.5 today, we'll be stuck with it for 15 years.=0A= =0A= You've described what will happen if we move to PSS, not PKCS #1. We'll be= =0A= stuck supporting an orphaned crypto mechanism for the next 15 years. To=0A= paraphrase a quote by AV researcher Vesselin Bontchev, if PSS (and OAEP) wa= s=0A= going to work, it would have worked by now.=0A= =0A= >We may have to define another signature algorithm that uses PSS in the=0A= >future, if standards bodies start to demand PSS.=0A= =0A= They've had nearly twenty years to do so and haven't yet, why would they st= art=0A= now?=0A= =0A= >The main argument in favor of PKCS#1 v1.5 appears to be laziness. No?=0A= =0A= That certainly contributes, although in my case I underestimated the amount= of=0A= work by 50%, I need to change two lines of code, not one. However, the muc= h=0A= bigger objection is being stuck supporting an oddball orphaned crypto=0A= mechanism that nothing else uses for the rest of eternity.=0A= =0A= Peter.= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Nov 11 01:30:05 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D88001B48C1 for ; Wed, 11 Nov 2015 01:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 YZiaLBem4goj for ; Wed, 11 Nov 2015 01:30:04 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E7D41B48C7 for ; Wed, 11 Nov 2015 01:30:04 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 98FD814A28B; Wed, 11 Nov 2015 09:30:00 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 0003114A28A; Wed, 11 Nov 2015 09:29:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id E611E14A203 for ; Wed, 11 Nov 2015 07:18:53 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id RlT6Hk8Oo0Ab for ; Wed, 11 Nov 2015 07:18:53 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0776.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::776]) by mail.netbsd.org (Postfix) with ESMTP id B06B114A1A5 for ; Wed, 11 Nov 2015 07:18:52 +0000 (UTC) Received: from BY2PR05CA040.namprd05.prod.outlook.com (10.141.250.30) by BLUPR05MB056.namprd05.prod.outlook.com (10.255.210.151) with Microsoft SMTP Server (TLS) id 15.1.312.18; Wed, 11 Nov 2015 07:18:48 +0000 Received: from BN1BFFO11FD011.protection.gbl (2a01:111:f400:7c10::1:179) by BY2PR05CA040.outlook.office365.com (2a01:111:e400:2c5f::30) with Microsoft SMTP Server (TLS) id 15.1.325.17 via Frontend Transport; Wed, 11 Nov 2015 07:18:48 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=juniper.net; cs.tcd.ie; dkim=none (message not signed) header.d=none;cs.tcd.ie; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.17) by BN1BFFO11FD011.mail.protection.outlook.com (10.58.144.74) with Microsoft SMTP Server (TLS) id 15.1.325.5 via Frontend Transport; Wed, 11 Nov 2015 07:18:47 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 10 Nov 2015 23:18:46 -0800 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id tAB7IiD15814; Tue, 10 Nov 2015 23:18:44 -0800 (PST) (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 8CFC711493; Tue, 10 Nov 2015 23:18:43 -0800 (PST) To: Niels =?us-ascii?Q?=3D=3Futf-8=3FQ=3FM=3DC3=3DB6ller=3F=3D?= CC: Damien Miller , Peter Gutmann , denis bider , "Jeffrey Hutzelman" , "ietf-ssh@NetBSD.org" , "stephen.farrell@cs.tcd.ie" , "jon@siliconcircus.com" Subject: Re: DH group exchange (Re: SSH key algorithm updates) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73F4B5993D@uxcn10-5.UoA.auckland.ac.nz> <2096379125-720@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B599ED@uxcn10-5.UoA.auckland.ac.nz> <55190.1447001241@eng-mail01.juniper.net> <9A043F3CF02CD34C8E74AC1594475C73F4B5A9BC@uxcn10-5.UoA.auckland.ac.nz> <65113.1447107876@eng-mail01.juniper.net> <90378.1447145301@eng-mail01.juniper.net> Comments: In-reply-to: Niels =?us-ascii?Q?=3D=3Futf-8=3FQ=3FM=3DC3=3DB6lle?= =?us-ascii?Q?r=3F=3D?= message dated "Tue, 10 Nov 2015 21:08:32 +0100." From: "Mark D. Baushke" MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Nov 2015 23:18:43 -0800 Message-ID: <41119.1447226323@eng-mail01.juniper.net> X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1;BN1BFFO11FD011;1:a3M04x6kYVVAiWgZn44hMyoboHKtXqHQLyhKEAVbgySJ4+k9A+bgYK6v2qEdCMY8xmSDZAKCCgSULEjkcOTYuL+kRIg6ICP93PlA5W+kVAxkk2NBBCl5s4MiVMW/NJNSxJal8bKFICdZqFZjmtA/qt5aSdKE2OoCfimZnG3If16pmMelxA4GWKcey9AemBvVz7y5cgGRAOO1RfUQ5Fc5P9tLQ3jRbmlXZt7BvvSWSH/bVIB/BXnmbpfeeax3G9eYvqnRWnO0HFSMD6FNju7MUgd48qlikEFRCuDIxI/EGF0dVk8of3EsY1fzzw1nRwR9GPoy7bJQeKSBfvZ3bNDwFcj9bbd12wLXK+eq7abIwRxPXYcXUSakrt0nK0S4dF4QbZ3q97gNs+ktdvTIRjp/0Q== X-Forefront-Antispam-Report: CIP:66.129.239.17;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(2980300002)(189002)(243025005)(199003)(11100500001)(92566002)(10710500006)(5007970100001)(105596002)(2950100001)(77096005)(2420400006)(81156007)(53416004)(76506005)(106466001)(69596002)(15975445007)(5003600100002)(110136002)(87936001)(19580395003)(19580405001)(23676002)(7110500001)(117636001)(93886004)(54356999)(189998001)(50466002)(5001960100002)(76176999)(97736004)(47776003)(6806005)(86362001)(50986999)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:BLUPR05MB056;H:p-emfe01a-sac.jnpr.net;FPR:;SPF:SoftFail;PTR:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BLUPR05MB056;2:frn1lx8LOIQtwpSoT3XGnTqISxSdRKRD0cCh6czxSp4e0c5RyN1spNi63hTV8LqK9gViIuiww6Fjc7/RlSJnPNVep86rWqSfk+DbEsT65CSOZU8eq2u3yo9Sy2ye106wx6c39KIMoZPj78tBn6T8/iJ50pdBXURACz/2iWMsNKI=;3:Y39grhjqqYhtpcPnYurN4Zu362XAH2YMeOX4OjopbgeskuMTUmWGhT9jXyw6c9wn8Naud9TXpYH5vkugzIl0gDZDgsvzom+hJHIDp7NbQNRMjBBFc1NzUhVHb9NPruUKwMAtlrvsjcBXFM+Q/5zWgICeiH+AOzocb1vvN2ktL/6LyZK1axUf8YtSWd+b2aJCfvn5QN5uELvqcii5A42iajHiRSf0AccrDuv+2u4hbgk=;25:RsygT2cHu6Ht/vinIQ14zG5ppDepZYX2ffBiGTzJ7nbyhg3iMon20fOi73zf4CbuRHscTi/EF8VoQRx5/f2tPKwEA4lEgsnFDwY0dGAd79n5dnYBjGe3VjcDoIFGBWAz35GCglpFYzZ9EhMd9GTo6oS2vqjDjYJuAey5wOtPBAOPfb3DPz+J7tVuTTL3z+le7ATj1/oM9gmOTv/wx2L4t9464SNMojvMraZnLxOVbpJv2elH1D802+EP92clZCal X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB056; X-Microsoft-Exchange-Diagnostics: 1;BLUPR05MB056;20:/UJ2ETy16DUdltm706L14+Z7STYGzcEm8X6qLNlVXZsgkxDStaqPbsYMep36v5yL3dXW47MyMAdZQSOtEfLn7pRe24CJ5rkDt28C0C3uJa0/zq8bOpu0G7ZXdcTO13hZEtVdLFFuiq4da/6NTr+VPw7az188vZTEQSf2QqVG/SbUQYBFc8CPDGL+z48eXUvIxkVWJflU+Vwrzox7rfBD8D1XOPf2W9ezSCHdtFcUQcOyVtm1ne1DRkb4DbfDSZh+wQBocSi6Yzv6ov3DB9L3iclUSsFM3iaucTzvUY80tx9Og6KE1jLb3UGUpi5928Hl9FEfoFh8y8Uo4gRob7IOh5QBYScQPI1T8+PXD/S4awXxOFcTWaDJ0CaELPo+RFAAqma1eBzsejMw3TpLkHGDW1GlaY6uWn/auW7xv5TcJL20SMOxgFJKfr38XppoiTpEQlyKi/PyQbz73R9jtWkrhHa1xDRyJOUWWrkueTw58qEvUoMpdz94v+ZuOg2DFqCm;4:JAtq3ZYfj2WnRQ3sZiWK923Ot1drMXMPCO93rJaQdH/lZeMVQTgX/SCJwkz0Rp+/eVx2Rvr8aNRA9ee8Jh4+cLuRlNfBLfZVChA02vne57reiHIig06wt68YXmqZlW3h8aWoa7JMCyDSivYNFrE5ADfNJqUMueETsI6kQYYzsNU3UIufr2ypEHVwqFET++T5TLn0COv0J+4gD2oJ/+5HqCDQByvTi+TFvOdjuHnlY/v22m6q7gHDQjeKgzh6ijUZ9Fv1uVVTfePGOwoNfYkF7ngonrM7xGxbl4H7j/h/TM8Q+zICIROAxw05wuDHzezwKz69SAgF6YATHZqqLym6CZxg9Uk/16nsaIWC23+HcTj0ZPPZKyk5knL8ktO3yrgH X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008)(65766998875637); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001);SRVR:BLUPR05MB056;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB056; X-Forefront-PRVS: 0757EEBDCA X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTFVQUjA1TUIwNTY7MjM6UTJ1OUZJOGxmMXlKdm9BM2pOOXZPSWF5WXBY?= =?utf-8?B?VWNNdmtkdk5MaFlIMklNRXNLMTZRTVFHRndZY0cxK05XWWVrRzNmZ3NXRG5G?= =?utf-8?B?akJnQU9laEZSU1RuUnN3SzhNSWVEQVpEQVZCSUR5cWpsVlVKOUVMQVRXL1pP?= =?utf-8?B?dnFxdHRtak1Ka2JMS3VvOWd2aXFmVkZYVG52S2xTWnJCYmEvQ1ppdGd4Vjky?= =?utf-8?B?eEw2ZlcvWEkrVlBDV0ZZc0tKeHo0S3VVRVlrWkJuQk9xY2ZVUnYwakNHSFNY?= =?utf-8?B?NlJSUWU4bThxUktHZlFFS2RDaWhub2JMWXRDd1BoOTcwWDdIOEVlaHM4TGdR?= =?utf-8?B?Q0lQTEhzTkZEUUxuTHFKSEpsUHRVY2VISDBHMVY0dkZ6L0MrOVRlbVVKaTBl?= =?utf-8?B?bXZSeTZkRVEwVnBNdmJ4cmFGbGxLOXlDYnZNZGRXNG5QeVNuOEtxS0Vsd3dx?= =?utf-8?B?ZC9RMDlrY0xCSFpHL21VWHVzT0Z1RTQ2bVJYcWZaWXFDQUszdnptWGJIVndS?= =?utf-8?B?RVJpN0RhQ1dMVVM2K3ZtSStxVWdkcHRXdU1GbXRqY2JpS2tPOFNjWWMrVUR0?= =?utf-8?B?SDZQWWt6OHpBbGU1TGhJZCtuVDI3ck5GS29yVTE1dzByRTdrY09YdmNNWjhv?= =?utf-8?B?bmQvSTlVVkpydkc4TFZ3YWFBQUczUzU3SXQrV3Y3dHdZU2Vhb09CU3p3cUJG?= =?utf-8?B?UFVTMWN6bklkMzZkVWhiN21JNVZPOEozWVJ2cVVLYkVGT2ZDV1BmWUtFakZ6?= =?utf-8?B?aE9DQUlNanJ0Mnl6dkxWZWg3RzdnK2JjaGFhWCttRHpTaTdObzZRN2ZaSmF3?= =?utf-8?B?NTNCV1lBVmp5M2FWMUF4MEd1eUZYaGZ2T0JHQXhSV0Jhc0s4YzQ1ekRMd2sx?= =?utf-8?B?dkczNXFzYm45T095UlYvRDg1VUJPeWxyT0hlL3B1SGRGM1B6SlFpRHpYN1RE?= =?utf-8?B?d3hheWVzZGtUNnNLZUk2SFN4ekFCckZqODFST1lwSVg1My9XSFl0elpzWWZr?= =?utf-8?B?UE8yWkxvZUxvL0FZWXJkaTNxeDRUT0tuMDJkUFQxRU0wZHBFMW1PNU1hNFhT?= =?utf-8?B?WjJrVGpRbWVlN00zRFZPZElHREpWcHlUMnY0SVcvUmR1L0owTDB1OGF3MDJ4?= =?utf-8?B?UHc0NFNkSHBic1JZekU0Mzh3Uk4vK3ZlYVJxMUd1czNGRVdudHhJM2EwWkdi?= =?utf-8?B?aXhJTjlTMEZVa1R5UlRNS3pSSEQ1cWtadFF4MGJmLytnQVRNMm1oNjZ6ejNp?= =?utf-8?B?Z2hIUThKL1E0K2o3RnhkWlR4RHF1cEQrWTVYVTJ3QnJHZm5pSnAzYUlpZFBE?= =?utf-8?B?bVRVbTJJU2NTRTVxV1lCVjBBR0xMRk9VQ3RMZGc4ZDRnNHB0eHdkOFNoSDV3?= =?utf-8?B?VWltb2IzNms5YmpZdlNXQlVaUmRYUnNQOWpCUmhPUW5LY2FMV3Z5QmdVSzMw?= =?utf-8?Q?v86f/b7TJPbUTNziWsUr8qh+NU?= X-Microsoft-Exchange-Diagnostics: 1;BLUPR05MB056;5:Rx0Q55zKrmlmQupswNwqVdpMfAi++eS5me4iFLrPZK8RE1ph0MUzkmK47cTsEBFaeNSxDHzv23K7JamtUJcSxGVqbRsf58Hyzg04hDPhbrq5uiOPZlOF1Nx735aavDEePbpjc91nv+zjCa++XdF+Ug==;24:k9kGBZJy88HF8tqRP+8kVF+n89IZmQz8rtgV7HTY1N0GvSw7S7FlLMO6CNQBXaPywab3dJ8Mk6NMNxxAlHLdryEFxdlheP090mQAdYPt1XI=;20:Mznu5FGrj76X/q8zgSdywQxYZHLYQ4YuzLPR6yIfQdUHvitFlCCnYUIGcwVCLzjgxA1AFASmAFRTkn9BGn+gOQ== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Nov 2015 07:18:47.7896 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.17];Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB056 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hi Niels, Niels M=C3=B6ller writes: > "Mark D. Baushke" writes: >=20 > > Given that OpenSSH is using group16 with sha2-256 preserves 128 bits of > > security, >=20 > How do you reason about that halving, from 256 to 128?=20 sha2-256 has 128 bits of security per NIST SP 800-107-rev1. > For the key expansion, I'd expect that you can count very close to 256 > bits of entropy in the generated keys (assuming the secret dh values > were generated randomly). Attacks on the signature hash will only need to brute force about half of the keyspace on average to recover the key. > Now, you will start to get some repeated session keys, i.e., collisions, > after about 2^128 sessions. But that has little to do with the hash > function: if we had a crypto system which for each session generated a > 256-bit session key from a truly random source, we'd also get collisions > after about 2^128 sessions. But I think the conventional way to assign a > security level to such a system is 2^256 (the difficuly of exhaustive > key search), not 2^128. >=20 > Am I missing something? I have always been told that one should choose a signature mechanism which provides the same number of bits of security as the asymmetric or symmetric encryption keys. See also: http://csrc.nist.gov/publications/nistpubs/800-107-rev1/sp800-107-rev1.pdf Section 4.2 table 1. Or look at the tables in these documents: http://www.keylength.com/en/4/ https://wiki.mozilla.org/Security/Guidelines/Key_Management I suppose I may have been over conservative in my numbers... -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Nov 11 11:48:59 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5722A1B393E for ; Wed, 11 Nov 2015 11:48:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 6mUXVCGKkQBK for ; Wed, 11 Nov 2015 11:48:56 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DAA71B393D for ; Wed, 11 Nov 2015 11:48:56 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 80CE814A1E9; Wed, 11 Nov 2015 19:48:53 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 22AE314A1E7; Wed, 11 Nov 2015 19:48:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 7904914A24A for ; Wed, 11 Nov 2015 10:41:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id npuz9912nnID for ; Wed, 11 Nov 2015 10:41:32 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 10E9A14A245 for ; Wed, 11 Nov 2015 10:41:31 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for pgut001@cs.auckland.ac.nz; Wed, 11 Nov 2015 10:41:22 +0000 Date: Wed, 11 Nov 2015 10:41:22 +0000 Subject: Re: rsa-sha2-256: Need YOUR opinion on PSS vs PKCS#1 v1.5 X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <2359976604-1440@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: Peter Gutmann Cc: djm@mindrot.org, ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-Yv1RDj/Y6GuQng3OvuDe" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-Yv1RDj/Y6GuQng3OvuDe Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Peter: > in my case I underestimated the amount of work by 50%, > I need to change two lines of code, not one. So, it turns out that there isn't an availability problem... :-) > just pointing out that a security proof is just a supporting > argument for something, not an actual proof that it's > secure in practice Oh, absolutely. Fully agreed. I am not aware of these practical flaws in PSS, though. > If there's been next to zero interest in it in twenty years, > why start now? It's not true that there has been zero interest. It is present in major cry= pto implementations, and has been added to them recently (OpenSSL). I do believe it was added with hope that it will be supported widely enough= that protocols like SSH will begin to specify it. The obstacle to widespread PSS adoption is exactly at the point we're now: = standardization in common protocols. In other words, the fact that you make this argument seems to be the main r= eason PSS is not (yet?) widely adopted. This causes a circular cause and ef= fect. > All you need there is a note to tell people to encode > the sig and do a memcmp(), it's extremely simple. With a different algorithm, you have recently supported the opposite side o= f this argument. I argued that DSA is secure if you do X (use deterministic= K); others (whom you've supported) argued that people won't do that, and w= ill just use crypto libraries that generate K randomly. Both arguments are of the form "algorithm X is secure if you do Z". Why doe= s this argument hold water when it comes to PKCS#1 v1.5, but not when it co= mes to DSA? > supporting an oddball orphaned crypto mechanism > that nothing else uses for the rest of eternity. Except that SSH is a major protocol, and RSA is a major algorithm. If we us= e PSS, it's no longer oddball. Maybe we're not TLS, but SSH is not bush lea= gue. The libraries implementing PSS appear to be numerous enough that we should = no longer be stopped by availability. We should consider what's technically= best. That's why we're specifying a new signature algorithm. denis =C2=A0 ----- Original Message ----- From: Peter Gutmann Sent: Wednesday, November 11, 2015 02:14 To: denis bider ; ietf-ssh@netbsd.org Cc: djm@mindrot.org Subject: RE: rsa-sha2-256: Need YOUR opinion on PSS vs PKCS#1 v1.5 =C2=A0 denis bider writes: =C2=A0 >Note that this was published in 2003. Twelve years later, it might be time= to >start making this transition. =C2=A0 PSS is just under 20 years old (it dates from 1996, "The Exact Security of Digital Signatures How to Sign with RSA and Rabin").=C2=A0 If there's been = next to zero interest in it in twenty years, why start now?=C2=A0 The signature mec= hanism that'll be used everywhere a decade from now will almost certainly still be PKCS #1, not PSS. =C2=A0 OAEP, the key-transport equivalent of PSS, has the same problem.=C2=A0 It d= ates from 1994 ("Optimal Asymmetric Encryption"), but the only major(?) applications I can think of at the moment are SET and Windows Vista content protection.=C2=A0 In twenty years its major adopters have been a failed e-c= ommerce protocol and Vista DRM (and that had some pretty weird stuff in it anyway, = it looked like it was defined by geeks on a crypto algorithm shopping expediti= on, I had to add a pile of bizarro stuf to my code to implement that that I've never had to use since). =C2=A0 >- PSS has provable security in the random oracle model; PKCS#1 v1.5 does n= ot. =C2=A0 I haven't looked at PSS too much, but OAEP is a mass of timing side-channel= s. Its complex structure makes it pretty much impossible to implement without exposing side-channels, and there are published attacks on some of them (se= e e.g. James Manger's "A chosen ciphertext attack on RSA optimal asymmetric encryption padding (OAEP)"). =C2=A0 It's not such a big deal with PSS since you're not exposing secret data through it, but just because something has an abstract mathematical proof (= in an equally abstract mathematical model) doesn't make it secure in the real world.=C2=A0 OAEP, like PSS, is also provably secure, except that it probab= ly isn't (see Victor Shoup's "OAEP Reconsidered", and the more recent "Trading One- Wayness against Chosen-Ciphertext Security in Factoring-Based Encryption", which points out that the random-oracle model used for the proofs doesn't provide the same level of assurance as the standard model, and vice versa i= n some cases). =C2=A0 In any case since the proof doesn't consider side-channel attacks, it's not actually secure despite its proof that it is.=C2=A0 OAEP in my code is comm= ented out because of this, and isn't exposed through an external API. =C2=A0 (Not wanting to start a long debate about security proofs, see "Another Loo= k at 'Provable Security'" for a starter on this, just pointing out that a security proof is just a supporting argument for something, not an actual proof that it's secure in practice). =C2=A0 >- There have been successful attacks on PKCS#1 v1.5 implementations. These= do >not work against correct (non-parser-like) verifier implementations. Howev= er, >due to its structure, PKCS#1 v1.5 is appealing to implement incorrectly. =C2=A0 All you need there is a note to tell people to encode the sig and do a memcmp(), it's extremely simple.=C2=A0 In addition if there were timing sid= e- channels, a constant-time memcmp() to deal with them is easy to implement. =C2=A0 >(3) Availability of PSS is now much better than it used to be. In my case,= I >work with Crypto++ and Windows CNG, which both support it. =C2=A0 Oh, they finally added it in Windows?=C2=A0 It wasn't supported for most of= the lifetime of CryptoAPI (and presumably still won't be in older version of Windows which don't qualify for upgrades). =C2=A0 >In my opinion, we ought to migrate toward an apparent improvement, and now= is >the opportunity to do so. > >If we specify PKCS#1 v1.5 today, we'll be stuck with it for 15 years. =C2=A0 You've described what will happen if we move to PSS, not PKCS #1.=C2=A0 We'= ll be stuck supporting an orphaned crypto mechanism for the next 15 years.=C2=A0 = To paraphrase a quote by AV researcher Vesselin Bontchev, if PSS (and OAEP) wa= s going to work, it would have worked by now. =C2=A0 >We may have to define another signature algorithm that uses PSS in the >future, if standards bodies start to demand PSS. =C2=A0 They've had nearly twenty years to do so and haven't yet, why would they st= art now? =C2=A0 >The main argument in favor of PKCS#1 v1.5 appears to be laziness. No? =C2=A0 That certainly contributes, although in my case I underestimated the amount= of work by 50%, I need to change two lines of code, not one.=C2=A0 However, th= e much bigger objection is being stuck supporting an oddball orphaned crypto mechanism that nothing else uses for the rest of eternity. =C2=A0 Peter. = --=-Yv1RDj/Y6GuQng3OvuDe Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Peter:


> in my case I underestimated= the amount of work by 50%,
> I need to change two lines of code, not= one.

So, it turns out that there isn't an availability problem... := -)


> just pointing out that a security proof is just a suppor= ting
> argument for something, not an actual proof that it's
> = secure in practice

Oh, absolutely. Fully agreed.

I am not awa= re of these practical flaws in PSS, though.


> If there's been= next to zero interest in it in twenty years,
> why start now?
It's not true that there has been zero interest. It is present in major cr= ypto implementations, and has been added to them recently (OpenSSL).
I do believe it was added with hope that it will be supported widely enoug= h that protocols like SSH will begin to specify it.

The obstacle to = widespread PSS adoption is exactly at the point we're now: standardization = in common protocols.

In other words, the fact that you make t= his argument seems to be the main reason PSS is not (yet?) widely adopted. = This causes a circular cause and effect.


> All you need there= is a note to tell people to encode
> the sig and do a memcmp(), it's= extremely simple.

With a different algorithm, you have recently sup= ported the opposite side of this argument. I argued that DSA is secure if y= ou do X (use deterministic K); others (whom you've supported) argued that p= eople won't do that, and will just use crypto libraries that generate K ran= domly.

Both arguments are of the form "algorithm X is secure if you = do Z". Why does this argument hold water when it comes to PKCS#1 v1.5, but = not when it comes to DSA?


> supporting an oddball orphaned cr= ypto mechanism
> that nothing else uses for the rest of eternity.
=
Except that SSH is a major protocol, and RSA is a major algorithm. If w= e use PSS, it's no longer oddball. Maybe we're not TLS, but SSH is not bush= league.

The libraries implementing PSS appear to be numerous enough= that we should no longer be stopped by availability. We should consider wh= at's technically best. That's why we're specifying a new signature algorith= m.


denis

 
----- Original Message -----
From: = Peter Gutmann
Sent: Wednesday, November 11, 2015 02:14
To: denis bide= r ; ietf-ssh@netbsd.org
Cc: djm@mindrot.org
Subject: RE: rsa-sha2-256= : Need YOUR opinion on PSS vs PKCS#1 v1.5
 
denis bider <ietf= -ssh3@denisbider.com> writes:
 
>Note that this was publis= hed in 2003. Twelve years later, it might be time to
>start making th= is transition.
 
PSS is just under 20 years old (it dates from 1= 996, "The Exact Security of
Digital Signatures How to Sign with RSA and = Rabin").  If there's been next to
zero interest in it in twenty yea= rs, why start now?  The signature mechanism
that'll be used everywh= ere a decade from now will almost certainly still be
PKCS #1, not PSS. 
OAEP, the key-transport equivalent of PSS, has the same problem= .  It dates
from 1994 ("Optimal Asymmetric Encryption"), but the on= ly major(?)
applications I can think of at the moment are SET and Window= s Vista content
protection.  In twenty years its major adopters hav= e been a failed e-commerce
protocol and Vista DRM (and that had some pre= tty weird stuff in it anyway, it
looked like it was defined by geeks on = a crypto algorithm shopping expedition,
I had to add a pile of bizarro s= tuf to my code to implement that that I've
never had to use since).
&= nbsp;
>- PSS has provable security in the random oracle model; PKCS#1= v1.5 does not.
 
I haven't looked at PSS too much, but OAEP is = a mass of timing side-channels.
Its complex structure makes it pretty mu= ch impossible to implement without
exposing side-channels, and there are= published attacks on some of them (see
e.g. James Manger's "A chosen ci= phertext attack on RSA optimal asymmetric
encryption padding (OAEP)"). 
It's not such a big deal with PSS since you're not exposing sec= ret data
through it, but just because something has an abstract mathemat= ical proof (in
an equally abstract mathematical model) doesn't make it s= ecure in the real
world.  OAEP, like PSS, is also provably secure, = except that it probably isn't
(see Victor Shoup's "OAEP Reconsidered", a= nd the more recent "Trading One-
Wayness against Chosen-Ciphertext Secur= ity in Factoring-Based Encryption",
which points out that the random-ora= cle model used for the proofs doesn't
provide the same level of assuranc= e as the standard model, and vice versa in
some cases).
 
In = any case since the proof doesn't consider side-channel attacks, it's notactually secure despite its proof that it is.  OAEP in my code is com= mented
out because of this, and isn't exposed through an external API. 
(Not wanting to start a long debate about security proofs, see = "Another Look
at 'Provable Security'" for a starter on this, just pointi= ng out that a
security proof is just a supporting argument for something= , not an actual
proof that it's secure in practice).
 
>- = There have been successful attacks on PKCS#1 v1.5 implementations. These do=
>not work against correct (non-parser-like) verifier implementations= . However,
>due to its structure, PKCS#1 v1.5 is appealing to impleme= nt incorrectly.
 
All you need there is a note to tell people to= encode the sig and do a
memcmp(), it's extremely simple.  In addit= ion if there were timing side-
channels, a constant-time memcmp() to dea= l with them is easy to implement.
 
>(3) Availability of PSS = is now much better than it used to be. In my case, I
>work with Crypt= o++ and Windows CNG, which both support it.
 
Oh, they finally a= dded it in Windows?  It wasn't supported for most of the
lifetime o= f CryptoAPI (and presumably still won't be in older version of
Windows w= hich don't qualify for upgrades).
 
>In my opinion, we ought = to migrate toward an apparent improvement, and now is
>the opportunit= y to do so.
>
>If we specify PKCS#1 v1.5 today, we'll be stuck = with it for 15 years.
 
You've described what will happen if we = move to PSS, not PKCS #1.  We'll be
stuck supporting an orphaned cr= ypto mechanism for the next 15 years.  To
paraphrase a quote by AV = researcher Vesselin Bontchev, if PSS (and OAEP) was
going to work, it wo= uld have worked by now.
 
>We may have to define another sign= ature algorithm that uses PSS in the
>future, if standards bodies sta= rt to demand PSS.
 
They've had nearly twenty years to do so and= haven't yet, why would they start
now?
 
>The main argume= nt in favor of PKCS#1 v1.5 appears to be laziness. No?
 
That ce= rtainly contributes, although in my case I underestimated the amount of
= work by 50%, I need to change two lines of code, not one.  However, th= e much
bigger objection is being stuck supporting an oddball orphaned cr= ypto
mechanism that nothing else uses for the rest of eternity.
 = ;
Peter.

= --=-Yv1RDj/Y6GuQng3OvuDe-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Nov 11 18:38:01 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6693D1A1B62 for ; Wed, 11 Nov 2015 18:38:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 1oIVERXWN0GV for ; Wed, 11 Nov 2015 18:37:56 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2DE61A1B83 for ; Wed, 11 Nov 2015 18:37:56 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id BB31A14A247; Thu, 12 Nov 2015 02:37:53 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id F16F014A245 for ; Thu, 12 Nov 2015 02:37:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id p1I_Qrw416j0 for ; Thu, 12 Nov 2015 02:37:38 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id DC72E14A243 for ; Thu, 12 Nov 2015 02:37:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1447295858; x=1478831858; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=GkZBLI5/qoXVaNz7tYxiP2LVBemkjpVXQ+QHSazwjOQ=; b=f2IzvLXz9R0lFx2g7421P/MEkcKVefFFesLKkQJ3oJ+lm3//93EACGRy GiRi+RDp65a/o7jCTzKgUTO49i4UCnsnHyoZKs7IY1JUCOUUeoRpwDPGo BxunVUZtdDGjDbKEbK/BR7GXjWmum60AfEZKPSbtBPFoScDRNvHOCQRPE y6FYLn1mAQwe8ixYw8NGMj9LiQHlkcvsFvNsMIxURsGu3ynEkTLpz3CuF yWclGhBk5Xz7zIH5BwSz1pBPQO0iZv3elHMcg8kOy3xXoFF6rYzgQjD+c V9t91MiAIo+Cpn2vG4HONR+CQMjef51q7ixluDjwcojcN+gyUHHt8x68n g==; X-IronPort-AV: E=Sophos;i="5.20,279,1444647600"; d="scan'208";a="53849704" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 12 Nov 2015 15:37:31 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Thu, 12 Nov 2015 15:37:31 +1300 From: Peter Gutmann To: denis bider CC: "djm@mindrot.org" , "ietf-ssh@netbsd.org" Subject: RE: rsa-sha2-256: Need YOUR opinion on PSS vs PKCS#1 v1.5 Thread-Topic: rsa-sha2-256: Need YOUR opinion on PSS vs PKCS#1 v1.5 Thread-Index: AQHRHG2BJkIC2QLIW0Cbt3W8mke9Op6XrI9r Date: Thu, 12 Nov 2015 02:37:30 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B5EDC4@uxcn10-5.UoA.auckland.ac.nz> References: <2359976604-1440@skroderider.denisbider.com> In-Reply-To: <2359976604-1440@skroderider.denisbider.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list denis bider writes:=0A= =0A= >> in my case I underestimated the amount of work by 50%,=0A= >> I need to change two lines of code, not one.=0A= >=0A= >So, it turns out that there isn't an availability problem... :-)=0A= =0A= Uhh, just in case there's any confusion over this, that's for PKCS #1. For= =0A= PSS I would have had to implement a completely new signature mechanism from= =0A= scratch, thus my earlier email requesting use of PKCS #1.=0A= =0A= >I am not aware of these practical flaws in PSS, though.=0A= =0A= Not yet. However, PSS has seen so little interest from both the crypto=0A= community and implementers that we can't really say much about it. For=0A= example for some years the NIST test vectors for RSA-PSS were completely wr= ong=0A= (every single test except the SHA-224 ones failed), and no-one noticed.=0A= =0A= I'll just let that sink in for a second. The published test vectors from a= =0A= major, effectively global in reach, standards body for RSA-PSS were wrong, = and=0A= no-one noticed. How much attention do you think that indicates PSS has got= in=0A= practice?=0A= =0A= >It is present in major crypto implementations, and has been added to them= =0A= >recently (OpenSSL).=0A= =0A= Well, OpenSSL is kinda of the petri dish that everything gets hacked into, = so=0A= I'm not sure if that's a good indicator. For example it has a convenient= =0A= remote-debug facility that allows attackers to read out your server's memor= y=0A= in 64kB blocks, but I won't be adding that to my code any time soon. It al= so=0A= implements X9.31 RSA, and there was a patch for some of the ISO 9796 RSA=0A= schemes floating around as well. How often have you run into those in=0A= practice?=0A= =0A= In any case with the "close to zero interest" I was referring to=0A= standardisation and support in major crypto-using protocols, PGP, S/MIME,= =0A= X.509, IPsec, TLS, and SSH.=0A= =0A= >In other words, the fact that you make this argument seems to be the main= =0A= >reason PSS is not (yet?) widely adopted. This causes a circular cause and= =0A= >effect.=0A= =0A= It can actually work both ways: We need to make a start somewhere in order = to=0A= get it adopted, or conversely if we adopt it and no-one else does we'll be= =0A= stuck supporting an orphan protocol like the lucky adopters of OAEP are.=0A= Given that there's been close to twenty years of no interest, I'd say it's = far=0A= more likely to be the latter.=0A= =0A= It's actually more than just passive disinterest, it was actively rejected = by=0A= the TLS WG (as OAEP for RSA key transport) in 2001 when an attempt was made= to=0A= piggyback it on top of AES adoption (in other words "if you want AES you ha= ve=0A= to use RSA-OAEP with it", it couldn't even stand on its own merits). I've= =0A= attached one vendor's reasoning for this at the end of this message, it tal= ks=0A= about AES which was the big deal at the time, substitute SHA-2 for AES to= =0A= update it to the current discussion. RSA-KEM, yet another newer padding=0A= scheme, was rejected by the S/MIME WG in 2002, as was OAEP. There's anothe= r=0A= scheme, Simple-RSA, which was proposed when the flaws in the OAEP proof wer= e=0A= discovered, that's also failed to see an adoption, as has SAEP and OAEP+.= =0A= =0A= >With a different algorithm, you have recently supported the opposite side = of=0A= >this argument. I argued that DSA is secure if you do X (use deterministic = K);=0A= >others (whom you've supported) argued that people won't do that, and will = just=0A= >use crypto libraries that generate K randomly.=0A= =0A= Uhh, I never made any comment about deterministic DSA. If I did, I would a= lso=0A= have argued against ECDSA, which has the same problem. My point with DSA w= as=0A= that continuing support for an algorithm that was more or less dead wasn't = a=0A= good idea.=0A= =0A= >Except that SSH is a major protocol, and RSA is a major algorithm. If we u= se=0A= >PSS, it's no longer oddball. Maybe we're not TLS, but SSH is not bush leag= ue.=0A= =0A= It's no longer oddball, but it'll leave SSH stuck with something that no-on= e=0A= else (meaning no other mainstream protocol) uses. Redde Caesari quae sunt= =0A= Caesaris: The stated goal of this draft is to allow use of SHA-2 instead of= =0A= SHA-1, so that's what it should do. If there's interest in introducing a n= ew=0A= signature scheme that's incompatible with the one that every version of SSH= =0A= for the last 20 years has been using then it should stand or fall on its ow= n,=0A= not piggybacked onto an update of hash algorithms.=0A= =0A= I would be perfectly happy with a separate draft for RSA-PSS. My sole=0A= objection to it is having to implement a completely new signature mechanism= =0A= just to be allowed to use SHA-2.=0A= =0A= Peter.=0A= =0A= -- Snip --=0A= =0A= 1. Deploying AES-based ciphersuites is the primary goal=0A= =0A= The AES block cipher provides a step up in security from 3DES including=0A= true 128 bit (and larger) keys, and a larger block size. At the same=0A= time, it provides increased performance across a wide set of platforms.=0A= =0A= The definitions of the AES ciphersuites should introduce only the new=0A= block cipher, not additional protocol or cryptographic mechanisms that=0A= would complicate or delay deployment of AES. If OAEP has benefits for=0A= TLS it should be introduced as a separate ciphersuite using an existing=0A= and established encryption mechanism such as 3DES.=0A= =0A= 2. RSA-OAEP is not required for security=0A= =0A= In message to this list on 31 May, David Hopwood said:=0A= =0A= "Using OAEP with TLS makes effectively no difference to the provable securi= ty=0A= properties of the RSA ciphersuites, assuming that the method described in= =0A= section 7.4.7.1 of RFC 2246 is followed (i.e. the premaster secret is repla= ced=0A= with a random value whenever the PKCS #1 v1.5 block is invalid).=0A= =0A= The effect of that method is to prevent chosen ciphertext attacks in much= =0A= the same way as the "Simple RSA" scheme described in [Shoup01], which has= =0A= a tighter reduction from the RSA problem than OAEP does. To get the same=0A= tightness of reduction when using OAEP in TLS, you would still have to=0A= require that no information is leaked about whether the decryption of the= =0A= premaster secret succeeds or not."=0A= =0A= So it seems that OAEP adds no benefit for TLS, since the suggested=0A= method from RFC 2246 must be used in any case.=0A= =0A= 3. Adding RSA-OAEP adds complexity=0A= =0A= Requiring RSA-OAEP for the AES ciphersuites means that implementations=0A= will need to provide both RSA padding schemes. In some situations the=0A= extra code space and complexity won't be a problem, but some memory or=0A= performance contrained devices would be better off without both=0A= implemenations. It is unlikely that AES-only deployments will be=0A= possible in the near term, so devices will need to implement both old=0A= and new methods for interoperability reasons.=0A= =0A= 4. Adding RSA-OAEP delays implementation=0A= =0A= This requirement will delay the availability of the new ciphersuites for=0A= two reasons. First, the time to implement the OAEP padding will delay=0A= the availability of products with this capability. Second, testing=0A= independantly developed products will take longer since the=0A= interoperability of both OAEP and the AES cipher will need to be tested.=0A= =0A= 5. Adding RSA-OAEP delays adoption of AES in hardware devices=0A= =0A= Many services that use TLS rely on hardware devices to improve the=0A= performance of TLS or to provide additional security. These hardware=0A= devices will need to be updated to provide both the AES cipher, and the=0A= new RSA-OAEP encryption mechanism. Hardware updates are typically less=0A= frequent than updates for software packages, and=0A= =0A= [6 =3D not-relevant TLS-specific issue]= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Nov 11 23:50:16 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D30E1A8835 for ; Wed, 11 Nov 2015 23:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 SyvWBEc6EfQ8 for ; Wed, 11 Nov 2015 23:50:13 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF7841A8829 for ; Wed, 11 Nov 2015 23:50:13 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 9114D14A269; Thu, 12 Nov 2015 07:50:10 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id EB20914A266 for ; Thu, 12 Nov 2015 07:50:05 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id ex5-ClCw3hhp for ; Thu, 12 Nov 2015 07:50:05 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 7341114A262 for ; Thu, 12 Nov 2015 07:50:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1447314604; x=1478850604; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=0N7A7aJsWiW5sXc1QeQalFjphn0iudtd3hjeHCILT7k=; b=AlWboP2Y5DrXVn20ArLqhSvbKe05Em5iIKsT1WNaVXE8Q8ziqQLvdJNj kGhzL83KQU88UoXz6oTfuAzRgo5aZa5SDCXO8qLBi838+08lziIIKdPhO ww5B/mBJBnwqtg+t223OK2WkJUgBTR1Y/InbF2RBUzHOiRms3XRXjU2zr x0aLyXAe+H3oGl+qAFDWzYfilEErPCybUMKHGT0qnY6ES27KQfRnW+4Ro RK1Fg8lqr7+MQDV83pd5I/4wZcUdeXI7QtPxv+p/g1xSHiWXqjxxDrTWr OZ6IqXRibqPpNqwwRnNJ5n8GyaqFtyFXV39UJVh4SCRAkxhCuSy7XWXE2 w==; X-IronPort-AV: E=Sophos;i="5.20,280,1444647600"; d="scan'208";a="53888752" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 12 Nov 2015 20:49:59 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Thu, 12 Nov 2015 20:49:58 +1300 From: Peter Gutmann To: =?iso-8859-1?Q?Niels_M=F6ller?= CC: denis bider , "ietf-ssh@netbsd.org" , Jeffrey Hutzelman , "Mark D. Baushke" , "stephen.farrell@cs.tcd.ie" , "jon@siliconcircus.com" , "djm@mindrot.org" , Max Horn Subject: RE: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation Thread-Topic: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation Thread-Index: AQHRHQrphOUdZ9Oj4Ee4+Vj0CybFfp6YAxNL Date: Thu, 12 Nov 2015 07:49:58 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B5F0E3@uxcn10-5.UoA.auckland.ac.nz> References: <2070897157-568@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B5BDE2@uxcn10-5.UoA.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Niels M=F6ller writes:=0A= =0A= >Send 0, ignore received value, would have made it actually useful.=0A= =0A= Can we get any figures on what effect making it nonzero would have? We kno= w=0A= that there are at least some implementations who would have problems with= =0A= this, but if they're OSS and frequently updated then it may not be such a b= ig=0A= issue, push out a fix fairly soon and by the time the RFC is ready most of = the=0A= problem will have fixed itself.=0A= =0A= Another workaround, although it's a bit of a hack, is if the two major clie= nt=0A= and server implementations, putty and OpenSSH, could retry an initial conne= ct=0A= with a nonzero field that's failed with a zeroed field and if it works, rep= ort=0A= to the user that the implementation needs an update.=0A= =0A= >Also, I'm not sure it has to be restricted to a single channel, I think it= =0A= >would make sense to disable flow control independently for a single channe= l=0A= >or a single unidirectional flow.=0A= =0A= Ah, good point. The number of users of multichannel that I have is pretty= =0A= minimal, so I never see this (it's used almost exclusively as a secure teln= et=0A= or for firmware upgrades, neither of which need multi-channel, to the point= =0A= where it's disabled by default in the source code).=0A= =0A= >Do we have a common understanding of how it's going to work?=0A= =0A= Not yet, I think :-). I'd just seen it as all-or-nothing, is there any rea= son=0A= why you'd have windowing on three channels but not a fourth? That is, is= =0A= there a need for per-channel windowing enable/disable? Can it be enabled m= id-=0A= flow or only on channel open?=0A= =0A= Peter.= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Nov 12 07:51:33 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C08D91AD0C1 for ; Thu, 12 Nov 2015 07:51:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 3RE3LDW8tSHK for ; Thu, 12 Nov 2015 07:51:30 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3DF41AD0BA for ; Thu, 12 Nov 2015 07:51:30 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id CC68C14A213; Thu, 12 Nov 2015 15:51:27 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 79A1C14A201 for ; Thu, 12 Nov 2015 15:51:23 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id esC0vHxYwXGx for ; Thu, 12 Nov 2015 15:51:22 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 3339114A1F6 for ; Thu, 12 Nov 2015 15:51:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1447343482; x=1478879482; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kgWPUnILrYF+iUN+Sxehsh0vDgd9aSp5+9epJDJRt18=; b=DhOB61OfDOeWZ5Y8KB6RC1+dbIQJX5xDF7uRvL4mhoqhxlJmcozjKfQr n8h9W140kC/bhqxF3EQgRHDIb+sft7tiIk/FSf0WwEyEH5+r4ux/b7VXn Lr2hHfqgSktQEEvJlGvIRLq6OJEDOG2qHm35P8mZ7AU9dadqv1PiG2rpc 9wTZuS4YVOq43HyGS2w20URTuexcA//ro5NXpXtl2H9CzagZxLm9S4EPY D2qV6GilAhS5wwOIxpEu8Kc9wXollzmunDrAysSTqR7OnDjXnoOGpdjoS 9hALnRACj8oHZ6y++5IsrVxaO/AylTDawrHNpBAyumsp+mbdRefNGiHVJ w==; X-IronPort-AV: E=Sophos;i="5.20,282,1444647600"; d="scan'208";a="53920527" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe3.UoA.auckland.ac.nz) ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 13 Nov 2015 04:51:16 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Fri, 13 Nov 2015 04:51:16 +1300 From: Peter Gutmann To: denis bider , "ietf-ssh@netbsd.org" CC: "djm@mindrot.org" , "terrafrost@gmail.com" , "thierry.moreau@connotech.com" Subject: RE: New version of rsa-sha2-256 draft: Back to PKCS#1 v1.5 Thread-Topic: New version of rsa-sha2-256 draft: Back to PKCS#1 v1.5 Thread-Index: AQHRHSNesq8SN1Tfz0+kbj2q9UYctp6YiRrL Date: Thu, 12 Nov 2015 15:51:15 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B5F4F1@uxcn10-5.UoA.auckland.ac.nz> References: <9430962-2924@skroderider.denisbider.com> In-Reply-To: <9430962-2924@skroderider.denisbider.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list denis bider writes:=0A= =0A= >I have posted a new version of the draft, which switches back to PKCS#1 v1= .5:=0A= =0A= Phew, thanks, that makes things much easier to deal with.=0A= =0A= >I have also updated the experimental server so it implements the latest dr= aft=0A= >version (with PKCS#1 v1.5):=0A= >=0A= >experiment.bitvise.com:10712=0A= >=0A= >To test host authentication, set the list of host key algorithms in your= =0A= >KEXINIT to "rsa-sha2-256" or "rsa-sha2-512". You will need at least one of= =0A= >these for successful key exchange - the server doesn't offer anything else= .=0A= =0A= It also only provides CTR modes, but none of the modes listed in RFC 4253:= =0A= =0A= Attempt to activate SSH client session failed with error code -20, line 1= 129.=0A= Error message =3D=0A= 'No algorithm compatible with the remote system's selection was found: = =0A= 'aes256-ctr,aes192-ctr,aes128-ctr,3des-ctr''.=0A= =0A= I do the REQUIRED and RECOMMENDED's from the original SSHv2 spec, RFC 4253,= =0A= but not the 4344 ones yet.=0A= =0A= (Yeah, I know, I should probably add them, but given that CTR mode makes it= =0A= possible for an attacker to trivially set the plaintext to any value they= =0A= want, I've never really been convinced that the cure isn't worse than the= =0A= problem).=0A= =0A= Peter.= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Nov 12 14:54:25 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83BDA1B39F4 for ; Thu, 12 Nov 2015 14:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 29jjgR3QgXtH for ; Thu, 12 Nov 2015 14:54:24 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1241C1B39F3 for ; Thu, 12 Nov 2015 14:54:24 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id EF7EE14A2A5; Thu, 12 Nov 2015 22:54:20 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 8084014A2A4; Thu, 12 Nov 2015 22:54:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id CCB0514A24A for ; Thu, 12 Nov 2015 08:46:10 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id KUmKDBa9HAA9 for ; Thu, 12 Nov 2015 08:46:10 +0000 (UTC) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 9832614A247 for ; Thu, 12 Nov 2015 08:46:06 +0000 (UTC) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id tAC8jlJe030103 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 12 Nov 2015 09:45:48 +0100 From: Simon Josefsson To: Damien Miller Cc: ietf-ssh@netbsd.org Subject: Re: Curve25519/448 key agreement for SSH References: <87pozjyzxc.fsf@latte.josefsson.org> <87poziw56c.fsf@latte.josefsson.org> <87vb9auhmh.fsf@latte.josefsson.org> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:151112:ietf-ssh@netbsd.org::iBfwYd2EgeeC0d9k:1t37 X-Hashcash: 1:22:151112:djm@mindrot.org::0sqNczC4S75N/Flb:EYZC Date: Thu, 12 Nov 2015 09:45:46 +0100 In-Reply-To: (Damien Miller's message of "Wed, 11 Nov 2015 11:01:40 +1100 (AEDT)") Message-ID: <87a8qjbo79.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Damien Miller writes: > On Tue, 10 Nov 2015, Simon Josefsson wrote: > >> > AFAIK it might not be possible to resolve without being incompatible >> > with the deployed curve25519-sha256@libssh.org protocol: OpenSSH at >> > least checks for correct zero-padding for mpints with the MSB set. >>=20 >> Curve25519 would never have the MSB set, if I understand correctly. So >> what is the potential for incompatibility? Maybe I'm missing something. > > That's true of the public values, but not necessarily of the shared > secret, right? I'd expect the shared secret to have the most > significant bit set half the time. Ah, right. The shared secret is never encoded on the wire though, but I suppose the same concern applies internally before hashing. >> I believe this document should document exactly what >> curve25519-sha256@libssh.org does, otherwise things will be confusing. >> Unless there is a significant mistake with it, of course, but then >> people shouldn't be using it at all. >>=20 >> Nobody has implemented Curve448 for SSH so there is no compatibility to >> think about there. There has not been a lot of interest from >> implementers in Curve448 either, since it is slower (no twisted curve). >> The only argument I can think of for supporting it is that it hedges you >> against potential new analytical ECC attacks that would affect >> Curve25519. But for this work, I believe including Curve448 makes sense >> since it is what CFRG recommends. > > Changing the encoding means changing the exchange hash's last field > from mpint to string. I argued for this when Aris sent the original > curve25519-sha256@libssh.org diff to OpenSSH, but didn't think of the > possible MSB leakage and lost the argument :/ > > Anyway, to summarise the arguments: > > For changing the encoding of K from mpint to string: > > - Avoids varying length of K encoding in exchange hash, unlikely leak > of MSB via timing channel > - Easier to implement > > Against: > > - Inconsistency between curve25519 and curve448 K encoding > - Inconsistency between curve448 and all the other KEX methods > > I honestly don't know whether it is worth fixing it. If I were writing > SSH protocol v.3 then I'd remove mpints from the wire protocol entirely > and have each protocol define a canonical string encoding for its > values. To change K from mpint to string we would need to update RFC 5656. I now believe we should describe what libssh/OpenSSH implements, and add a security consideration around a potential secret MSB side-channel leak caused by the length difference. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWRFG6AAoJEIYLf7sy+BGdObgH/iMSoSBiaPGz5a74WaOxP8L3 U6XxDwroDiudL9E/f6WjaPmRyq/nz9evBP+99+LfKLfqacRiBHrUa8okWHstGnyT xolivNq+RJ1LSlU1NbvXPIMMX/IPUHSmmO61RZn1RiNyNh243TQSCW0TAAXbVDqS CEXKAFuRzwkRozjp/LgHGCOyReqZs6AYHglkGYT1X4VkK+A0CgIfoYpl+TyjbsVh OFnke5CT9BMwmNxnG+trmM17XTwscFA/No48DFgUrWeZOqFaHUitM2VG6vDlFKj4 6mprlJF3JvVFpZ8ED4T4VcjR95moNtJ21TW2+Zu6IHq1Slg+m6TWqct3Pm4Fkec= =OeN8 -----END PGP SIGNATURE----- --=-=-=-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Nov 12 14:54:34 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB4C1B39F5 for ; Thu, 12 Nov 2015 14:54:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 WOY_85QZwIFi for ; Thu, 12 Nov 2015 14:54:31 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A845F1B39F1 for ; Thu, 12 Nov 2015 14:54:31 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 3272B14A2A6; Thu, 12 Nov 2015 22:54:31 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 9F30014A2A4; Thu, 12 Nov 2015 22:54:30 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 3FEDE14A1C0 for ; Thu, 12 Nov 2015 08:50:41 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 0-yJ4fHPWrxJ for ; Thu, 12 Nov 2015 08:50:40 +0000 (UTC) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 23DA914A1A0 for ; Thu, 12 Nov 2015 08:50:39 +0000 (UTC) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id tAC8oNNj030621 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 12 Nov 2015 09:50:25 +0100 From: Simon Josefsson To: denis bider Cc: ietf-ssh@netbsd.org, djm@mindrot.org Subject: Re: Curve25519/448 key agreement for SSH References: <2289172118-568@skroderider.denisbider.com> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:151112:ietf-ssh@netbsd.org::f6P5rPUTUmtn6Nk8:2KJK X-Hashcash: 1:22:151112:djm@mindrot.org::H2EhccASUBJqO71o:CidX X-Hashcash: 1:22:151112:ietf-ssh3@denisbider.com::Z/60cKibHNnUbNP5:Alju Date: Thu, 12 Nov 2015 09:50:22 +0100 In-Reply-To: <2289172118-568@skroderider.denisbider.com> (denis bider's message of "Tue, 10 Nov 2015 14:32:17 +0000") Message-ID: <876117bnzl.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable denis bider writes: > Simon - > > >> A simple approach would be to say that if the MSB is 1, >> prepend a zero byte.=A0 However, the length difference >> would leak that information. > > The length difference might not be much of a problem, since K is never se= nt. It shouldn't be difficult to fingerprint (statistically, over many connections) if a remote application performs a hash on X bytes or X+1 bytes. Knowing which leaks the MSB of the derived secret. I'm inclined to add a security consideration describing this, and allow for the potential of a nice conference paper describing how to exploit this observation. At this point, to fix this (as Damien described) appear less appealing. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWRFLPAAoJEIYLf7sy+BGdjkkH+wW+ERcS4dUeeYfA1S3ye7vX 5yummOD+pQRrbKjqyU02KEq2qzX7vwEXX1zFXS8ltXNMNCam/pu29DK30fnDDKyz x0VgVvtVIc9mfgKIJeXGROKCBZjKB92+ayMEixtCqOVjgAKP4nIM7sEkQQxbf5p9 nFYOFiOB4CTbiUAJRePPU9xHpJWPzHOGx4Ko2LVj07xkp5gR08MZ7teYNn2aTk2G MaklvFRxYfWFJ8GK/p8PNU5sgh3++7bXJ36nB2gArK6UNTACO0nUwEkm+4AoUGIG 1b/U5EgQ+bfZ8ghHHFaoH8X2KYraEXA02Ns0l/h+ap4wdxPe9rmLG34vkABpGpg= =dD0v -----END PGP SIGNATURE----- --=-=-=-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Nov 12 14:54:42 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEDF61B39F5 for ; Thu, 12 Nov 2015 14:54:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 mYEuRR0tTTYy for ; Thu, 12 Nov 2015 14:54:38 -0800 (PST) Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90D4D1B39F1 for ; Thu, 12 Nov 2015 14:54:38 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 2C35814A2AA; Thu, 12 Nov 2015 22:54:38 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id AF8C914A2A8; Thu, 12 Nov 2015 22:54:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 165BC14A26D for ; Thu, 12 Nov 2015 09:17:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id VigylKpacSAR for ; Thu, 12 Nov 2015 09:17:58 +0000 (UTC) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id DDBFB14A269 for ; Thu, 12 Nov 2015 09:17:57 +0000 (UTC) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id tAC9Hchl001410 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 12 Nov 2015 10:17:39 +0100 From: Simon Josefsson To: denis bider Cc: ietf-ssh@netbsd.org, djm@mindrot.org Subject: Re: Curve25519/448 key agreement for SSH References: <12774469-2924@skroderider.denisbider.com> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:151112:ietf-ssh3@denisbider.com::2ciX34n/Xrnx8JTw:3ozg X-Hashcash: 1:22:151112:djm@mindrot.org::KQ6cHPb1LgVMMbvo:EZ/c X-Hashcash: 1:22:151112:ietf-ssh@netbsd.org::Wpe4Ed7dwUVUlChM:G17p Date: Thu, 12 Nov 2015 10:17:36 +0100 In-Reply-To: <12774469-2924@skroderider.denisbider.com> (denis bider's message of "Thu, 12 Nov 2015 08:57:18 +0000") Message-ID: <876117vaof.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable denis bider writes: > But X and K are different in each key exchange. The only way to make > them same would be for both parties to conspire. It doesn't matter if they are different -- a listening entity may be able to use a side channel (e.g., time) to infer wether the parties hashed X or X+1 bytes, which leaks one bit of the secret. > I have suggested solving this by reinterpreting X as an already > encoded K, which may be negative. Well - that has a different issue: > it violates mpint encoding when the first byte of X is zero... > > All things considered, I don't think it really matters which way this > is resolved. Just please make sure to be clear when you specify it. :) > An imprecise specification may lead to problems that manifest in > e.g. 1/256 of key exchanges. Yep. I don't care strongly about this point, but I do share your strong opinion that it has to be clearly specified. Right now I'm inclined to describe exactly what libssh/OpenSSH implements and describe the vulnerability. If implementers are interested in "fixing" this while we go through this process, we have that opportunity. There is no direct backwards compatibility problem to care about, since we are registering a new name. However, implementations will likely need to support both for quite some time, and having the two implementations differ has code maintenance costs. It seems Aris and Damien represent two significant implementations of this, so if they can agree on this, we have a way forward. /Simon > > Simon Josefsson , 11/12/2015 8:50 AM: > denis bider writes:=20 >=20=20 >> Simon -=20 >>=20 >>=20 >>> A simple approach would be to say that if the MSB is 1,=20 >>> prepend a zero byte.=A0 However, the length difference=20 >>> would leak that information.=20 >>=20 >> The length difference might not be much of a problem, since K is never s= ent.=20 >=20=20 > It shouldn't be difficult to fingerprint (statistically, over many=20 > connections) if a remote application performs a hash on X bytes or X+1=20 > bytes. =A0Knowing which leaks the MSB of the derived secret.=20 >=20=20 > I'm inclined to add a security consideration describing this, and allow=20 > for the potential of a nice conference paper describing how to exploit=20 > this observation. =A0At this point, to fix this (as Damien described)=20 > appear less appealing.=20 >=20=20 > /Simon=20 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWRFkxAAoJEIYLf7sy+BGdMnQH/3uK4ptB47W1yfMu+s6a3jHj A3WtTjenfX/WQx3i8JdV06aPraQvt3Juf39fTpv4bluz5itUlkOd1lw3U5+gu3Ha tyY5BTNdH7Db0E44bHjIc2ndpfbQ2x+7kMjg7+PNZX67mYxhZC9ckS5aNFEL1bh8 /mAJk8RN5VZ7J9yzqfkSPgBuvFAxlARmjKSlCb+c4wzKauFOTbWxLjdcrWFXvjMX WrCe2lOzrODjY4oQRZWgI0O/HNrgEJDbXxj9oVuh8w8MTtYgWWqUyj4tl6Q/Wd7Y igImnRVaaKWT23IuCmf9nXB3artOsN7S82dh0MNVHDwqz6TiNtEyzsP542pzVDg= =+zrE -----END PGP SIGNATURE----- --=-=-=-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Nov 12 14:54:48 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 836A41B39F6 for ; Thu, 12 Nov 2015 14:54:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 DgxnmfCDgBxL for ; Thu, 12 Nov 2015 14:54:45 -0800 (PST) Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 746641B39F1 for ; Thu, 12 Nov 2015 14:54:45 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 21EC814A2A9; Thu, 12 Nov 2015 22:54:45 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id AA59214A2A8; Thu, 12 Nov 2015 22:54:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 708EA14A28E for ; Thu, 12 Nov 2015 09:24:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id U4ZbD5o79agr for ; Thu, 12 Nov 2015 09:24:39 +0000 (UTC) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 72DEC14A287 for ; Thu, 12 Nov 2015 09:24:39 +0000 (UTC) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id tAC9OPhU002272 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 12 Nov 2015 10:24:26 +0100 From: Simon Josefsson To: ietf-ssh@netbsd.org Subject: Re: Curve25519/448 key agreement for SSH References: <87pozjyzxc.fsf@latte.josefsson.org> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:151112:ietf-ssh@netbsd.org::JHnycK7Zr7a5FGmN:IPNJ Date: Thu, 12 Nov 2015 10:24:24 +0100 In-Reply-To: <87pozjyzxc.fsf@latte.josefsson.org> (Simon Josefsson's message of "Mon, 09 Nov 2015 16:07:11 +0100") Message-ID: <87wptntvsn.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-=-= Content-Type: text/plain I have updated the document to be clearer about the encoding issue, and to fix some minor issues. https://tools.ietf.org/html/draft-josefsson-ssh-curves-01 If Aris and Damien are happy with this version, I believe the document is in good shape. Feedback from others is welcome, especially if anyone is considering implementing this. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWRFrIAAoJEIYLf7sy+BGdlBMH/jpPziHh3RQOCck30dydva74 d4j2pZp0mKMpWzZSRpvTacrGb2ScHfd8lCIHc8uTxHGsNh560Bs/lqpXIWXmuZEn pUPgSoS3rmJToxkm3du3hWEnUGfWlCrXlOKHzfMDLqXTS36HwHsHWS+EdVLf9me8 5mOpXP8pTA8swYq07qMZYiCgjnQIftS9Hx4CxND333PS2i1C0WMtF494hNleOgKB 0k+N5Nj9N4AlYjhp7RkqlXw5sqVutvlgj5HDWDxfBfgFGFYhjRYdI8uk5KcPsaqP 5OFlQhvXmP+6NgXM2jHWYgAgGOnTzR4OZvNV+/vxY9/aPfgVinfHd9ZmCw3hJFA= =LNkJ -----END PGP SIGNATURE----- --=-=-=-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Nov 12 14:55:36 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 621141B3A01 for ; Thu, 12 Nov 2015 14:55:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.008 X-Spam-Level: X-Spam-Status: No, score=-2.008 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 tg18AlRa1EXW for ; Thu, 12 Nov 2015 14:55:33 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17A471B39FE for ; Thu, 12 Nov 2015 14:55:33 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 0F97C14A2C0; Thu, 12 Nov 2015 22:55:32 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 769D514A1A4; Thu, 12 Nov 2015 22:55:30 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 5AE4D14A270 for ; Thu, 12 Nov 2015 03:38:24 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id ixN8jlUAeZ1H for ; Thu, 12 Nov 2015 03:38:22 +0000 (UTC) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 6658D14A26C for ; Thu, 12 Nov 2015 03:38:22 +0000 (UTC) Received: by ioc74 with SMTP id 74so53486429ioc.2 for ; Wed, 11 Nov 2015 19:38:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EGMWBB4UnFCIWi8z+InfkryYuLqmZP5Qcbrq3KZKBto=; b=sErLVP2XqXfIzilI0BmrZe/Nh5rb0YBglj1x4YQVx4JFzWS1FdouFuJjaHxBTuv0qG JY8niDiVEu5W+9UYnXBrH4ek370IDSaqrzGpjBu+mmzo5+e9OlbMz2vLXpD15Ve/7VII yJ5zQjWW9NSvGLTiFNkX2LwkUF8szUxBoxbj0WX1kDmYY3GMfIoox6+0G1eTKCFTax8l SPLR6KhPaqSiKsjSbCEmqe+208X0WBYt+K3/Zrq91k1FFl/+MfuQPbA64Z1vy4SNr9g5 23AFoT2fnwCVj4FQp2xaPljwYpYsEQgJiJ8JxOHKbJuzuGaMgg2byXnVhZEngom3wg7M x7lQ== MIME-Version: 1.0 X-Received: by 10.107.138.16 with SMTP id m16mr12777633iod.40.1447299501781; Wed, 11 Nov 2015 19:38:21 -0800 (PST) Received: by 10.107.142.7 with HTTP; Wed, 11 Nov 2015 19:38:21 -0800 (PST) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B5EDC4@uxcn10-5.UoA.auckland.ac.nz> References: <2359976604-1440@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B5EDC4@uxcn10-5.UoA.auckland.ac.nz> Date: Wed, 11 Nov 2015 21:38:21 -0600 Message-ID: Subject: Re: rsa-sha2-256: Need YOUR opinion on PSS vs PKCS#1 v1.5 From: Terra Frost To: Peter Gutmann Cc: denis bider , "djm@mindrot.org" , "ietf-ssh@netbsd.org" Content-Type: multipart/alternative; boundary=001a113f1918aff63a05244fac96 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --001a113f1918aff63a05244fac96 Content-Type: text/plain; charset=UTF-8 Just because an RFC exists that provides for the use of RSA PSS doesn't mean implementations are going to use it. And if new versions of OpenSSL do start implementing it it's still probably years away and even then it's of little consequence without clients implementing it, as well, and prioritizing RSA PSS over other algorithms. Defining it in the RFC is the first of many steps that need to occur for it to become widely utilized and it can become stillborn at each of those steps. If it becomes more widely utilized it'll become more scrutinized and the lessons that that increased scrutiny will bring will lead to even better algorithms, in the future.. Long story short, I'm in support of implementing RSA PSS. On Wed, Nov 11, 2015 at 8:37 PM, Peter Gutmann wrote: > denis bider writes: > > >> in my case I underestimated the amount of work by 50%, > >> I need to change two lines of code, not one. > > > >So, it turns out that there isn't an availability problem... :-) > > Uhh, just in case there's any confusion over this, that's for PKCS #1. For > PSS I would have had to implement a completely new signature mechanism from > scratch, thus my earlier email requesting use of PKCS #1. > > >I am not aware of these practical flaws in PSS, though. > > Not yet. However, PSS has seen so little interest from both the crypto > community and implementers that we can't really say much about it. For > example for some years the NIST test vectors for RSA-PSS were completely > wrong > (every single test except the SHA-224 ones failed), and no-one noticed. > > I'll just let that sink in for a second. The published test vectors from a > major, effectively global in reach, standards body for RSA-PSS were wrong, > and > no-one noticed. How much attention do you think that indicates PSS has > got in > practice? > > >It is present in major crypto implementations, and has been added to them > >recently (OpenSSL). > > Well, OpenSSL is kinda of the petri dish that everything gets hacked into, > so > I'm not sure if that's a good indicator. For example it has a convenient > remote-debug facility that allows attackers to read out your server's > memory > in 64kB blocks, but I won't be adding that to my code any time soon. It > also > implements X9.31 RSA, and there was a patch for some of the ISO 9796 RSA > schemes floating around as well. How often have you run into those in > practice? > > In any case with the "close to zero interest" I was referring to > standardisation and support in major crypto-using protocols, PGP, S/MIME, > X.509, IPsec, TLS, and SSH. > > >In other words, the fact that you make this argument seems to be the main > >reason PSS is not (yet?) widely adopted. This causes a circular cause and > >effect. > > It can actually work both ways: We need to make a start somewhere in order > to > get it adopted, or conversely if we adopt it and no-one else does we'll be > stuck supporting an orphan protocol like the lucky adopters of OAEP are. > Given that there's been close to twenty years of no interest, I'd say it's > far > more likely to be the latter. > > It's actually more than just passive disinterest, it was actively rejected > by > the TLS WG (as OAEP for RSA key transport) in 2001 when an attempt was > made to > piggyback it on top of AES adoption (in other words "if you want AES you > have > to use RSA-OAEP with it", it couldn't even stand on its own merits). I've > attached one vendor's reasoning for this at the end of this message, it > talks > about AES which was the big deal at the time, substitute SHA-2 for AES to > update it to the current discussion. RSA-KEM, yet another newer padding > scheme, was rejected by the S/MIME WG in 2002, as was OAEP. There's > another > scheme, Simple-RSA, which was proposed when the flaws in the OAEP proof > were > discovered, that's also failed to see an adoption, as has SAEP and OAEP+. > > >With a different algorithm, you have recently supported the opposite side > of > >this argument. I argued that DSA is secure if you do X (use deterministic > K); > >others (whom you've supported) argued that people won't do that, and will > just > >use crypto libraries that generate K randomly. > > Uhh, I never made any comment about deterministic DSA. If I did, I would > also > have argued against ECDSA, which has the same problem. My point with DSA > was > that continuing support for an algorithm that was more or less dead wasn't > a > good idea. > > >Except that SSH is a major protocol, and RSA is a major algorithm. If we > use > >PSS, it's no longer oddball. Maybe we're not TLS, but SSH is not bush > league. > > It's no longer oddball, but it'll leave SSH stuck with something that > no-one > else (meaning no other mainstream protocol) uses. Redde Caesari quae sunt > Caesaris: The stated goal of this draft is to allow use of SHA-2 instead of > SHA-1, so that's what it should do. If there's interest in introducing a > new > signature scheme that's incompatible with the one that every version of SSH > for the last 20 years has been using then it should stand or fall on its > own, > not piggybacked onto an update of hash algorithms. > > I would be perfectly happy with a separate draft for RSA-PSS. My sole > objection to it is having to implement a completely new signature mechanism > just to be allowed to use SHA-2. > > Peter. > > -- Snip -- > > 1. Deploying AES-based ciphersuites is the primary goal > > The AES block cipher provides a step up in security from 3DES including > true 128 bit (and larger) keys, and a larger block size. At the same > time, it provides increased performance across a wide set of platforms. > > The definitions of the AES ciphersuites should introduce only the new > block cipher, not additional protocol or cryptographic mechanisms that > would complicate or delay deployment of AES. If OAEP has benefits for > TLS it should be introduced as a separate ciphersuite using an existing > and established encryption mechanism such as 3DES. > > 2. RSA-OAEP is not required for security > > In message to this list on 31 May, David Hopwood said: > > "Using OAEP with TLS makes effectively no difference to the provable > security > properties of the RSA ciphersuites, assuming that the method described in > section 7.4.7.1 of RFC 2246 is followed (i.e. the premaster secret is > replaced > with a random value whenever the PKCS #1 v1.5 block is invalid). > > The effect of that method is to prevent chosen ciphertext attacks in much > the same way as the "Simple RSA" scheme described in [Shoup01], which has > a tighter reduction from the RSA problem than OAEP does. To get the same > tightness of reduction when using OAEP in TLS, you would still have to > require that no information is leaked about whether the decryption of the > premaster secret succeeds or not." > > So it seems that OAEP adds no benefit for TLS, since the suggested > method from RFC 2246 must be used in any case. > > 3. Adding RSA-OAEP adds complexity > > Requiring RSA-OAEP for the AES ciphersuites means that implementations > will need to provide both RSA padding schemes. In some situations the > extra code space and complexity won't be a problem, but some memory or > performance contrained devices would be better off without both > implemenations. It is unlikely that AES-only deployments will be > possible in the near term, so devices will need to implement both old > and new methods for interoperability reasons. > > 4. Adding RSA-OAEP delays implementation > > This requirement will delay the availability of the new ciphersuites for > two reasons. First, the time to implement the OAEP padding will delay > the availability of products with this capability. Second, testing > independantly developed products will take longer since the > interoperability of both OAEP and the AES cipher will need to be tested. > > 5. Adding RSA-OAEP delays adoption of AES in hardware devices > > Many services that use TLS rely on hardware devices to improve the > performance of TLS or to provide additional security. These hardware > devices will need to be updated to provide both the AES cipher, and the > new RSA-OAEP encryption mechanism. Hardware updates are typically less > frequent than updates for software packages, and > > [6 = not-relevant TLS-specific issue] --001a113f1918aff63a05244fac96 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just because an RFC exists that provides for the= use of RSA PSS doesn't mean implementations are going to use it. And i= f new versions of OpenSSL do start implementing it it's still probably = years away and even then it's of little consequence without clients imp= lementing it, as well, and prioritizing RSA PSS over other algorithms.
<= br>
Defining it in the RFC is the first of many steps that need to occ= ur for it to become widely utilized and it can become stillborn at each of = those steps.

If it becomes more widely utilized it'll= become more scrutinized and the lessons that that increased scrutiny will = bring will lead to even better algorithms, in the future..

Long story short, I'm in support of implementing RSA PSS.

On Wed, Nov 1= 1, 2015 at 8:37 PM, Peter Gutmann <pgut001@cs.auckland.ac.nz&g= t; wrote:
denis b= ider <ietf-ssh3@denisbider.c= om> writes:

>> in my case I underestimated the amount of work by 50%,
>> I need to change two lines of code, not one.
>
>So, it turns out that there isn't an availability problem... :-)
Uhh, just in case there's any confusion over this, that's fo= r PKCS #1.=C2=A0 For
PSS I would have had to implement a completely new signature mechanism from=
scratch, thus my earlier email requesting use of PKCS #1.

>I am not aware of these practical flaws in PSS, though.

Not yet.=C2=A0 However, PSS has seen so little interest from both th= e crypto
community and implementers that we can't really say much about it.=C2= =A0 For
example for some years the NIST test vectors for RSA-PSS were completely wr= ong
(every single test except the SHA-224 ones failed), and no-one noticed.

I'll just let that sink in for a second.=C2=A0 The published test vecto= rs from a
major, effectively global in reach, standards body for RSA-PSS were wrong, = and
no-one noticed.=C2=A0 How much attention do you think that indicates PSS ha= s got in
practice?

>It is present in major crypto implementations, and has been added to th= em
>recently (OpenSSL).

Well, OpenSSL is kinda of the petri dish that everything gets hacked= into, so
I'm not sure if that's a good indicator.=C2=A0 For example it has a= convenient
remote-debug facility that allows attackers to read out your server's m= emory
in 64kB blocks, but I won't be adding that to my code any time soon.=C2= =A0 It also
implements X9.31 RSA, and there was a patch for some of the ISO 9796 RSA schemes floating around as well.=C2=A0 How often have you run into those in=
practice?

In any case with the "close to zero interest" I was referring to<= br> standardisation and support in major crypto-using protocols, PGP, S/MIME, X.509, IPsec, TLS, and SSH.

>In other words, the fact that you make this argument seems to be the ma= in
>reason PSS is not (yet?) widely adopted. This causes a circular cause a= nd
>effect.

It can actually work both ways: We need to make a start somewhere in= order to
get it adopted, or conversely if we adopt it and no-one else does we'll= be
stuck supporting an orphan protocol like the lucky adopters of OAEP are. Given that there's been close to twenty years of no interest, I'd s= ay it's far
more likely to be the latter.

It's actually more than just passive disinterest, it was actively rejec= ted by
the TLS WG (as OAEP for RSA key transport) in 2001 when an attempt was made= to
piggyback it on top of AES adoption (in other words "if you want AES y= ou have
to use RSA-OAEP with it", it couldn't even stand on its own merits= ).=C2=A0 I've
attached one vendor's reasoning for this at the end of this message, it= talks
about AES which was the big deal at the time, substitute SHA-2 for AES to update it to the current discussion.=C2=A0 RSA-KEM, yet another newer paddi= ng
scheme, was rejected by the S/MIME WG in 2002, as was OAEP.=C2=A0 There'= ;s another
scheme, Simple-RSA, which was proposed when the flaws in the OAEP proof wer= e
discovered, that's also failed to see an adoption, as has SAEP and OAEP= +.

>With a different algorithm, you have recently supported the opposite si= de of
>this argument. I argued that DSA is secure if you do X (use determinist= ic K);
>others (whom you've supported) argued that people won't do that= , and will just
>use crypto libraries that generate K randomly.

Uhh, I never made any comment about deterministic DSA.=C2=A0 If I di= d, I would also
have argued against ECDSA, which has the same problem.=C2=A0 My point with = DSA was
that continuing support for an algorithm that was more or less dead wasn= 9;t a
good idea.

>Except that SSH is a major protocol, and RSA is a major algorithm. If w= e use
>PSS, it's no longer oddball. Maybe we're not TLS, but SSH is no= t bush league.

It's no longer oddball, but it'll leave SSH stuck with somet= hing that no-one
else (meaning no other mainstream protocol) uses.=C2=A0 Redde Caesari quae = sunt
Caesaris: The stated goal of this draft is to allow use of SHA-2 instead of=
SHA-1, so that's what it should do.=C2=A0 If there's interest in in= troducing a new
signature scheme that's incompatible with the one that every version of= SSH
for the last 20 years has been using then it should stand or fall on its ow= n,
not piggybacked onto an update of hash algorithms.

I would be perfectly happy with a separate draft for RSA-PSS.=C2=A0 My sole=
objection to it is having to implement a completely new signature mechanism=
just to be allowed to use SHA-2.

Peter.

-- Snip --

1. Deploying AES-based ciphersuites is the primary goal

The AES block cipher provides a step up in security=C2=A0 from 3DES includi= ng
true 128 bit (and larger) keys, and a larger block size.=C2=A0 At the same<= br> time, it provides increased performance across a wide set of platforms.

The definitions of the AES ciphersuites should introduce only the new
block cipher, not additional protocol or cryptographic mechanisms that
would complicate or delay deployment of AES.=C2=A0 If OAEP has benefits for=
TLS it should be introduced as a separate ciphersuite using an existing
and established encryption mechanism such as 3DES.

2. RSA-OAEP is not required for security

In message to this list on 31 May, David Hopwood said:

"Using OAEP with TLS makes effectively no difference to the provable s= ecurity
properties of the RSA ciphersuites, assuming that the method described in section 7.4.7.1 of RFC 2246 is followed (i.e. the premaster secret is repla= ced
with a random value whenever the PKCS #1 v1.5 block is invalid).

The effect of that method is to prevent chosen ciphertext attacks in much the same way as the "Simple RSA" scheme described in [Shoup01], w= hich has
a tighter reduction from the RSA problem than OAEP does. To get the same tightness of reduction when using OAEP in TLS, you would still have to
require that no information is leaked about whether the decryption of the premaster secret succeeds or not."

So it seems that OAEP adds no benefit for TLS, since the suggested
method from RFC 2246 must be used in any case.

3. Adding RSA-OAEP adds complexity

Requiring RSA-OAEP for the AES ciphersuites means that implementations
will need to provide both RSA padding schemes.=C2=A0 In some situations the=
extra code space and complexity won't be a problem, but some memory or<= br> performance contrained devices would be better off without both
implemenations.=C2=A0 It is unlikely that AES-only deployments will be
possible in the near term, so devices will need to implement both old
and new methods for interoperability reasons.

4. Adding RSA-OAEP delays implementation

This requirement will delay the availability of the new ciphersuites for two reasons. First, the time to implement the OAEP padding will delay
the availability of products with this capability.=C2=A0 Second, testing independantly developed products will take longer since the
interoperability of both OAEP and the AES cipher will need to be tested.
5. Adding RSA-OAEP delays adoption of AES in hardware devices

Many services that use TLS rely on hardware devices to improve the
performance of TLS or to provide additional security.=C2=A0 These hardware<= br> devices will need to be updated to provide both the AES cipher, and the
new RSA-OAEP encryption mechanism.=C2=A0 Hardware updates are typically les= s
frequent than updates for software packages, and

[6 =3D not-relevant TLS-specific issue]

--001a113f1918aff63a05244fac96-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Nov 12 14:56:16 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 271251B3A07 for ; Thu, 12 Nov 2015 14:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 a_XP9hGqtgIk for ; Thu, 12 Nov 2015 14:56:12 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A2051B3A06 for ; Thu, 12 Nov 2015 14:56:12 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 21D2314A2AB; Thu, 12 Nov 2015 22:56:07 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id AF4F014A2A9; Thu, 12 Nov 2015 22:56:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 1378814A255 for ; Thu, 12 Nov 2015 08:23:11 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id KbdLKI23Sthz for ; Thu, 12 Nov 2015 08:23:09 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 5173714A254 for ; Thu, 12 Nov 2015 08:23:09 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for ietf-ssh@netbsd.org; Thu, 12 Nov 2015 08:23:06 +0000 Date: Thu, 12 Nov 2015 08:23:06 +0000 Subject: New version of rsa-sha2-256 draft: Back to PKCS#1 v1.5 X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <9430962-2924@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: ietf-ssh@netbsd.org Cc: Peter Gutmann , djm@mindrot.org, terrafrost@gmail.com, thierry.moreau@connotech.com Content-Type: multipart/alternative; boundary="=-/aXs1U8hv0n3/Ve5vU1J" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-/aXs1U8hv0n3/Ve5vU1J Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Alright - points taken. :-) The feedback I've received appears to be as follows: - 1 count of support with caveats (Terra) - 1 count of neutral feedback (received from Thierry; my summary: determini= stic intuitively better than probabilistic; but then again, this is probabl= y not a problem with PSS) - 1 count of strong opposition (Peter) In addition, it appears I have misunderstood Peter, and PSS is not availabl= e in his environment after all. All things considered, opposition + availability argument appear to be back= ed more strongly. I have posted a new version of the draft, which switches back to PKCS#1 v1.= 5: https://tools.ietf.org/html/draft-rsa-dsa-sha2-256-03 I have also updated the experimental server so it implements the latest dra= ft version (with PKCS#1 v1.5): experiment.bitvise.com:10712 To test host authentication, set the list of host key algorithms in your KE= XINIT to "rsa-sha2-256" or "rsa-sha2-512". You will need at least one of th= ese for successful key exchange - the server doesn't offer anything else. Once you're past host authentication, the server will send a user authentic= ation banner with info to help test user authentication, as well. ----- Original Message ----- From: Peter Gutmann=20 Sent: Wednesday, November 11, 2015 20:37 To: denis bider=20 Cc: djm@mindrot.org ; ietf-ssh@netbsd.org=20 Subject: RE: rsa-sha2-256: Need YOUR opinion on PSS vs PKCS#1 v1.5 denis bider writes: >> in my case I underestimated the amount of work by 50%, >> I need to change two lines of code, not one. > >So, it turns out that there isn't an availability problem... :-) Uhh, just in case there's any confusion over this, that's for PKCS #1.=C2= =A0 For PSS I would have had to implement a completely new signature mechanism from scratch, thus my earlier email requesting use of PKCS #1. >I am not aware of these practical flaws in PSS, though. Not yet.=C2=A0 However, PSS has seen so little interest from both the crypt= o community and implementers that we can't really say much about it.=C2=A0 Fo= r example for some years the NIST test vectors for RSA-PSS were completely wr= ong (every single test except the SHA-224 ones failed), and no-one noticed. I'll just let that sink in for a second.=C2=A0 The published test vectors f= rom a major, effectively global in reach, standards body for RSA-PSS were wrong, = and no-one noticed.=C2=A0 How much attention do you think that indicates PSS ha= s got in practice? >It is present in major crypto implementations, and has been added to them >recently (OpenSSL). Well, OpenSSL is kinda of the petri dish that everything gets hacked into, = so I'm not sure if that's a good indicator.=C2=A0 For example it has a conveni= ent remote-debug facility that allows attackers to read out your server's memor= y in 64kB blocks, but I won't be adding that to my code any time soon.=C2=A0 = It also implements X9.31 RSA, and there was a patch for some of the ISO 9796 RSA schemes floating around as well.=C2=A0 How often have you run into those in practice? In any case with the "close to zero interest" I was referring to standardisation and support in major crypto-using protocols, PGP, S/MIME, X.509, IPsec, TLS, and SSH. >In other words, the fact that you make this argument seems to be the main >reason PSS is not (yet?) widely adopted. This causes a circular cause and >effect. It can actually work both ways: We need to make a start somewhere in order = to get it adopted, or conversely if we adopt it and no-one else does we'll be stuck supporting an orphan protocol like the lucky adopters of OAEP are. Given that there's been close to twenty years of no interest, I'd say it's = far more likely to be the latter. It's actually more than just passive disinterest, it was actively rejected = by the TLS WG (as OAEP for RSA key transport) in 2001 when an attempt was made= to piggyback it on top of AES adoption (in other words "if you want AES you ha= ve to use RSA-OAEP with it", it couldn't even stand on its own merits).=C2=A0 = I've attached one vendor's reasoning for this at the end of this message, it tal= ks about AES which was the big deal at the time, substitute SHA-2 for AES to update it to the current discussion.=C2=A0 RSA-KEM, yet another newer paddi= ng scheme, was rejected by the S/MIME WG in 2002, as was OAEP.=C2=A0 There's a= nother scheme, Simple-RSA, which was proposed when the flaws in the OAEP proof wer= e discovered, that's also failed to see an adoption, as has SAEP and OAEP+. >With a different algorithm, you have recently supported the opposite side = of >this argument. I argued that DSA is secure if you do X (use deterministic = K); >others (whom you've supported) argued that people won't do that, and will = just >use crypto libraries that generate K randomly. Uhh, I never made any comment about deterministic DSA.=C2=A0 If I did, I wo= uld also have argued against ECDSA, which has the same problem.=C2=A0 My point with = DSA was that continuing support for an algorithm that was more or less dead wasn't = a good idea. >Except that SSH is a major protocol, and RSA is a major algorithm. If we u= se >PSS, it's no longer oddball. Maybe we're not TLS, but SSH is not bush leag= ue. It's no longer oddball, but it'll leave SSH stuck with something that no-on= e else (meaning no other mainstream protocol) uses.=C2=A0 Redde Caesari quae = sunt Caesaris: The stated goal of this draft is to allow use of SHA-2 instead of SHA-1, so that's what it should do.=C2=A0 If there's interest in introducin= g a new signature scheme that's incompatible with the one that every version of SSH for the last 20 years has been using then it should stand or fall on its ow= n, not piggybacked onto an update of hash algorithms. I would be perfectly happy with a separate draft for RSA-PSS.=C2=A0 My sole objection to it is having to implement a completely new signature mechanism just to be allowed to use SHA-2. Peter. -- Snip -- 1. Deploying AES-based ciphersuites is the primary goal The AES block cipher provides a step up in security=C2=A0 from 3DES includi= ng true 128 bit (and larger) keys, and a larger block size.=C2=A0 At the same time, it provides increased performance across a wide set of platforms. The definitions of the AES ciphersuites should introduce only the new block cipher, not additional protocol or cryptographic mechanisms that would complicate or delay deployment of AES.=C2=A0 If OAEP has benefits for TLS it should be introduced as a separate ciphersuite using an existing and established encryption mechanism such as 3DES. 2. RSA-OAEP is not required for security In message to this list on 31 May, David Hopwood said: "Using OAEP with TLS makes effectively no difference to the provable securi= ty properties of the RSA ciphersuites, assuming that the method described in section 7.4.7.1 of RFC 2246 is followed (i.e. the premaster secret is repla= ced with a random value whenever the PKCS #1 v1.5 block is invalid). The effect of that method is to prevent chosen ciphertext attacks in much the same way as the "Simple RSA" scheme described in [Shoup01], which has a tighter reduction from the RSA problem than OAEP does. To get the same tightness of reduction when using OAEP in TLS, you would still have to require that no information is leaked about whether the decryption of the premaster secret succeeds or not." So it seems that OAEP adds no benefit for TLS, since the suggested method from RFC 2246 must be used in any case. 3. Adding RSA-OAEP adds complexity Requiring RSA-OAEP for the AES ciphersuites means that implementations will need to provide both RSA padding schemes.=C2=A0 In some situations the extra code space and complexity won't be a problem, but some memory or performance contrained devices would be better off without both implemenations.=C2=A0 It is unlikely that AES-only deployments will be possible in the near term, so devices will need to implement both old and new methods for interoperability reasons. 4. Adding RSA-OAEP delays implementation This requirement will delay the availability of the new ciphersuites for two reasons. First, the time to implement the OAEP padding will delay the availability of products with this capability.=C2=A0 Second, testing independantly developed products will take longer since the interoperability of both OAEP and the AES cipher will need to be tested. 5. Adding RSA-OAEP delays adoption of AES in hardware devices Many services that use TLS rely on hardware devices to improve the performance of TLS or to provide additional security.=C2=A0 These hardware devices will need to be updated to provide both the AES cipher, and the new RSA-OAEP encryption mechanism.=C2=A0 Hardware updates are typically les= s frequent than updates for software packages, and [6 =3D not-relevant TLS-specific issue]= --=-/aXs1U8hv0n3/Ve5vU1J Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Alright - points taken. :-)

The feedback I'= ve received appears to be as follows:

- 1 count of support with cave= ats (Terra)
- 1 count of neutral feedback (received from Thierry; my sum= mary: deterministic intuitively better than probabilistic; but then again, = this is probably not a problem with PSS)
- 1 count of strong opposition = (Peter)

In addition, it appears I have misunderstood Peter, and PSS = is not available in his environment after all.

All things considered= , opposition + availability argument appear to be backed more strongly.
=
I have posted a new version of the draft, which switches back to= PKCS#1 v1.5:

https://tools.ietf.org/html/draft-rsa-dsa-sha2-256-03<= br>
I have also updated the experimental server so it implements the lat= est draft version (with PKCS#1 v1.5):

experiment.bitvise.com:10712
To test host authentication, set the list of host key algorithms in y= our KEXINIT to "rsa-sha2-256" or "rsa-sha2-512". You will need at least one= of these for successful key exchange - the server doesn't offer anything e= lse.

Once you're past host authentication, the server will send a us= er authentication banner with info to help test user authentication, as wel= l.


----- Original Message -----
From: Peter Gutmann
Sent:= Wednesday, November 11, 2015 20:37
To: denis bider
Cc: djm@mindrot.= org ; ietf-ssh@netbsd.org
Subject: RE: rsa-sha2-256: Need YOUR opinion = on PSS vs PKCS#1 v1.5

denis bider <ietf-ssh3@denisbider.com> w= rites:

>> in my case I underestimated the amount of work by 50= %,
>> I need to change two lines of code, not one.
>
>= So, it turns out that there isn't an availability problem... :-)

Uhh= , just in case there's any confusion over this, that's for PKCS #1.  F= or
PSS I would have had to implement a completely new signature mechanis= m from
scratch, thus my earlier email requesting use of PKCS #1.

= >I am not aware of these practical flaws in PSS, though.

Not yet.=   However, PSS has seen so little interest from both the crypto
com= munity and implementers that we can't really say much about it.  Forexample for some years the NIST test vectors for RSA-PSS were completely = wrong
(every single test except the SHA-224 ones failed), and no-one not= iced.

I'll just let that sink in for a second.  The published t= est vectors from a
major, effectively global in reach, standards body fo= r RSA-PSS were wrong, and
no-one noticed.  How much attention do yo= u think that indicates PSS has got in
practice?

>It is present= in major crypto implementations, and has been added to them
>recentl= y (OpenSSL).

Well, OpenSSL is kinda of the petri dish that everythin= g gets hacked into, so
I'm not sure if that's a good indicator.  Fo= r example it has a convenient
remote-debug facility that allows attacker= s to read out your server's memory
in 64kB blocks, but I won't be adding= that to my code any time soon.  It also
implements X9.31 RSA, and = there was a patch for some of the ISO 9796 RSA
schemes floating around a= s well.  How often have you run into those in
practice?

In a= ny case with the "close to zero interest" I was referring to
standardisa= tion and support in major crypto-using protocols, PGP, S/MIME,
X.509, IP= sec, TLS, and SSH.

>In other words, the fact that you make this a= rgument seems to be the main
>reason PSS is not (yet?) widely adopted= . This causes a circular cause and
>effect.

It can actually wo= rk both ways: We need to make a start somewhere in order to
get it adopt= ed, or conversely if we adopt it and no-one else does we'll be
stuck sup= porting an orphan protocol like the lucky adopters of OAEP are.
Given th= at there's been close to twenty years of no interest, I'd say it's far
m= ore likely to be the latter.

It's actually more than just passive di= sinterest, it was actively rejected by
the TLS WG (as OAEP for RSA key t= ransport) in 2001 when an attempt was made to
piggyback it on top of AES= adoption (in other words "if you want AES you have
to use RSA-OAEP with= it", it couldn't even stand on its own merits).  I've
attached one= vendor's reasoning for this at the end of this message, it talks
about = AES which was the big deal at the time, substitute SHA-2 for AES to
upda= te it to the current discussion.  RSA-KEM, yet another newer paddingscheme, was rejected by the S/MIME WG in 2002, as was OAEP.  There's= another
scheme, Simple-RSA, which was proposed when the flaws in the OA= EP proof were
discovered, that's also failed to see an adoption, as has = SAEP and OAEP+.

>With a different algorithm, you have recently su= pported the opposite side of
>this argument. I argued that DSA is sec= ure if you do X (use deterministic K);
>others (whom you've supported= ) argued that people won't do that, and will just
>use crypto librari= es that generate K randomly.

Uhh, I never made any comment about det= erministic DSA.  If I did, I would also
have argued against ECDSA, = which has the same problem.  My point with DSA was
that continuing = support for an algorithm that was more or less dead wasn't a
good idea.<= br>
>Except that SSH is a major protocol, and RSA is a major algorith= m. If we use
>PSS, it's no longer oddball. Maybe we're not TLS, but S= SH is not bush league.

It's no longer oddball, but it'll leave SSH s= tuck with something that no-one
else (meaning no other mainstream protoc= ol) uses.  Redde Caesari quae sunt
Caesaris: The stated goal of thi= s draft is to allow use of SHA-2 instead of
SHA-1, so that's what it sho= uld do.  If there's interest in introducing a new
signature scheme = that's incompatible with the one that every version of SSH
for the last = 20 years has been using then it should stand or fall on its own,
not pig= gybacked onto an update of hash algorithms.

I would be perfectly hap= py with a separate draft for RSA-PSS.  My sole
objection to it is h= aving to implement a completely new signature mechanism
just to be allow= ed to use SHA-2.

Peter.

-- Snip --

1. Deploying AES-ba= sed ciphersuites is the primary goal

The AES block cipher provides a= step up in security  from 3DES including
true 128 bit (and larger)= keys, and a larger block size.  At the same
time, it provides incr= eased performance across a wide set of platforms.

The definitions of= the AES ciphersuites should introduce only the new
block cipher, not ad= ditional protocol or cryptographic mechanisms that
would complicate or d= elay deployment of AES.  If OAEP has benefits for
TLS it should be = introduced as a separate ciphersuite using an existing
and established e= ncryption mechanism such as 3DES.

2. RSA-OAEP is not required for se= curity

In message to this list on 31 May, David Hopwood said:
"Using OAEP with TLS makes effectively no difference to the provable secur= ity
properties of the RSA ciphersuites, assuming that the method describ= ed in
section 7.4.7.1 of RFC 2246 is followed (i.e. the premaster secret= is replaced
with a random value whenever the PKCS #1 v1.5 block is inva= lid).

The effect of that method is to prevent chosen ciphertext atta= cks in much
the same way as the "Simple RSA" scheme described in [Shoup0= 1], which has
a tighter reduction from the RSA problem than OAEP does. T= o get the same
tightness of reduction when using OAEP in TLS, you would = still have to
require that no information is leaked about whether the de= cryption of the
premaster secret succeeds or not."

So it seems th= at OAEP adds no benefit for TLS, since the suggested
method from RFC 224= 6 must be used in any case.

3. Adding RSA-OAEP adds complexity
Requiring RSA-OAEP for the AES ciphersuites means that implementationswill need to provide both RSA padding schemes.  In some situations th= e
extra code space and complexity won't be a problem, but some memory or=
performance contrained devices would be better off without both
impl= emenations.  It is unlikely that AES-only deployments will be
possi= ble in the near term, so devices will need to implement both old
and new= methods for interoperability reasons.

4. Adding RSA-OAEP delays imp= lementation

This requirement will delay the availability of the new = ciphersuites for
two reasons. First, the time to implement the OAEP padd= ing will delay
the availability of products with this capability.  = Second, testing
independantly developed products will take longer since = the
interoperability of both OAEP and the AES cipher will need to be tes= ted.

5. Adding RSA-OAEP delays adoption of AES in hardware devices
Many services that use TLS rely on hardware devices to improve theperformance of TLS or to provide additional security.  These hardware=
devices will need to be updated to provide both the AES cipher, and the=
new RSA-OAEP encryption mechanism.  Hardware updates are typically= less
frequent than updates for software packages, and

[6 =3D not= -relevant TLS-specific issue]= --=-/aXs1U8hv0n3/Ve5vU1J-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Nov 12 14:56:32 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1221B3A07 for ; Thu, 12 Nov 2015 14:56:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 IvTCSjq8o-cv for ; Thu, 12 Nov 2015 14:56:19 -0800 (PST) Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F24E1B3A06 for ; Thu, 12 Nov 2015 14:56:19 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id A37FD14A2B3; Thu, 12 Nov 2015 22:56:18 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 3BD9F14A2B2; Thu, 12 Nov 2015 22:56:18 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id F050014A254 for ; Thu, 12 Nov 2015 08:57:45 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id hHZjGjub2UXu for ; Thu, 12 Nov 2015 08:57:45 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 57AD714A245 for ; Thu, 12 Nov 2015 08:57:45 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for simon@josefsson.org; Thu, 12 Nov 2015 08:57:18 +0000 Date: Thu, 12 Nov 2015 08:57:18 +0000 Subject: Re: Curve25519/448 key agreement for SSH X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <12774469-2924@skroderider.denisbider.com> X-Priority: 3 Importance: Normal In-Reply-To: <876117bnzl.fsf@latte.josefsson.org> MIME-Version: 1.0 From: denis bider To: Simon Josefsson Cc: ietf-ssh@netbsd.org, djm@mindrot.org Content-Type: multipart/alternative; boundary="=-IW5lGO29Bnan64cldlda" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-IW5lGO29Bnan64cldlda Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable But X and K are different in each key exchange. The only way to make them s= ame would be for both parties to conspire. I have suggested solving this by reinterpreting X as an already encoded K, = which may be negative. Well - that has a different issue: it violates mpint= encoding when the first byte of X is zero... All things considered, I don't think it really matters which way this is re= solved. Just please make sure to be clear when you specify it. :) An imprec= ise specification may lead to problems that manifest in e.g. 1/256 of key e= xchanges. Simon Josefsson , 11/12/2015 8:50 AM: denis bider writes:=20 =20 > Simon -=20 >=20 >=20 >> A simple approach would be to say that if the MSB is 1,=20 >> prepend a zero byte.=C2=A0 However, the length difference=20 >> would leak that information.=20 >=20 > The length difference might not be much of a problem, since K is never se= nt.=20 =20 It shouldn't be difficult to fingerprint (statistically, over many=20 connections) if a remote application performs a hash on X bytes or X+1=20 bytes. =C2=A0Knowing which leaks the MSB of the derived secret.=20 =20 I'm inclined to add a security consideration describing this, and allow=20 for the potential of a nice conference paper describing how to exploit=20 this observation. =C2=A0At this point, to fix this (as Damien described)=20 appear less appealing.=20 =20 /Simon=20 = --=-IW5lGO29Bnan64cldlda Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable But X and K are different in each key exchange. Th= e only way to make them same would be for both parties to conspire.<= br>
I have suggested solving this by reinterpreting X as an already enco= ded K, which may be negative. Well - that has a different issue: it violate= s mpint encoding when the first byte of X is zero...

All things cons= idered, I don't think it really matters which way this is resolved. Just pl= ease make sure to be clear when you specify it. :) An imprecise specificati= on may lead to problems that manifest in e.g. 1/256 of key exchanges.

Simon Josefsson <simon@josefsson.org>= , 11/12/2015 8:50 AM:
denis bide= r <ietf-ssh3@denisbider.com> writes:

> Simon -
>
>
>> A simple approach would be to say that if the MSB is 1,
>> prepend a zero byte.  However, the length difference
>> would leak that information.
>
> The length difference might not be much of a problem, since K is n= ever sent.

It shouldn't be difficult to fingerprint (statistically, over many
connections) if a remote application performs a hash on X bytes or X+1
bytes.  Knowing which leaks the MSB of the derived secret.

I'm inclined to add a security consideration describing this, and allow
for the potential of a nice conference paper describing how to exploit
this observation.  At this point, to fix this (as Damien described= )
appear less appealing.

/Simon
= --=-IW5lGO29Bnan64cldlda-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Nov 12 14:56:33 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09ECC1B3A06 for ; Thu, 12 Nov 2015 14:56:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 MqdJsPS-QVXo for ; Thu, 12 Nov 2015 14:56:30 -0800 (PST) Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4240F1B3A08 for ; Thu, 12 Nov 2015 14:56:29 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id E5BE514A2BA; Thu, 12 Nov 2015 22:56:28 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 7B10714A2B8; Thu, 12 Nov 2015 22:56:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 9E8A114A254 for ; Thu, 12 Nov 2015 12:07:37 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id zKWXIVRMohlY for ; Thu, 12 Nov 2015 12:07:36 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 9F1AE14A253 for ; Thu, 12 Nov 2015 12:07:36 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for simon@josefsson.org; Thu, 12 Nov 2015 12:07:08 +0000 Date: Thu, 12 Nov 2015 12:07:08 +0000 Subject: Re: Curve25519/448 key agreement for SSH X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <23975746-2988@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: Simon Josefsson Cc: ietf-ssh@netbsd.org, djm@mindrot.org Content-Type: multipart/alternative; boundary="=-lA8HUM+3hmPVgDxcXSZe" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-lA8HUM+3hmPVgDxcXSZe Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > If implementers are interested in "fixing" this while we go > through this process, we have that opportunity. There is > no direct backwards compatibility problem to care about, > since we are registering a new name.=C2=A0=20 I agree, but it does seem like it would really require re-specifying K to b= e a "string", and just for these particular algorithms. With regard to compatibility - if there's a standardized name, then for use= in Bitvise SSH Server and Client, I am almost certainly going to implement= only the standardized name. Folks who care highly about these algorithms a= re probably not going to have second thoughts about using the latest versio= ns of their software. Folks who use older versions are typically people who don't care about CBC = until it comes up in a security scan... At which point they grudgingly cons= ider upgrading their 10 year old version. :) ----- Original Message ----- From: Simon Josefsson=20 Sent: Thursday, November 12, 2015 03:17 To: denis bider=20 Cc: ietf-ssh@netbsd.org ; djm@mindrot.org=20 Subject: Re: Curve25519/448 key agreement for SSH denis bider writes: > But X and K are different in each key exchange. The only way to make > them same would be for both parties to conspire. It doesn't matter if they are different -- a listening entity may be able to use a side channel (e.g., time) to infer wether the parties hashed X or X+1 bytes, which leaks one bit of the secret. > I have suggested solving this by reinterpreting X as an already > encoded K, which may be negative. Well - that has a different issue: > it violates mpint encoding when the first byte of X is zero... > > All things considered, I don't think it really matters which way this > is resolved. Just please make sure to be clear when you specify it. :) > An imprecise specification may lead to problems that manifest in > e.g. 1/256 of key exchanges. Yep.=C2=A0 I don't care strongly about this point, but I do share your stro= ng opinion that it has to be clearly specified.=C2=A0 Right now I'm inclined t= o describe exactly what libssh/OpenSSH implements and describe the vulnerability. If implementers are interested in "fixing" this while we go through this process, we have that opportunity.=C2=A0 There is no direct backwards compatibility problem to care about, since we are registering a new name.=C2=A0 However, implementations will likely need to support both for quite some time, and having the two implementations differ has code maintenance costs.=C2=A0 It seems Aris and Damien represent two significant implementations of this, so if they can agree on this, we have a way forward. /Simon > > Simon Josefsson , 11/12/2015 8:50 AM: > denis bider writes:=20 > =C2=A0 >> Simon -=20 >>=20 >>=20 >>> A simple approach would be to say that if the MSB is 1,=20 >>> prepend a zero byte.=C2=A0 However, the length difference=20 >>> would leak that information.=20 >>=20 >> The length difference might not be much of a problem, since K is never s= ent.=20 > =C2=A0 > It shouldn't be difficult to fingerprint (statistically, over many=20 > connections) if a remote application performs a hash on X bytes or X+1=20 > bytes. =C2=A0Knowing which leaks the MSB of the derived secret.=20 > =C2=A0 > I'm inclined to add a security consideration describing this, and allow=20 > for the potential of a nice conference paper describing how to exploit=20 > this observation. =C2=A0At this point, to fix this (as Damien described)=20 > appear less appealing.=20 > =C2=A0 > /Simon=20 = --=-lA8HUM+3hmPVgDxcXSZe Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable > If implementers are interested in "fixing" th= is while we go
> through this process, we have that opportunity. Ther= e is
> no direct backwards compatibility problem to care about,
&g= t; since we are registering a new name. 

I agree, but it does = seem like it would really require re-specifying K to be a "string", and jus= t for these particular algorithms.

With regard to compatibility - if= there's a standardized name, then for use in Bitvise SSH Server and Client= , I am almost certainly going to implement only the standardized name. Folk= s who care highly about these algorithms are probably not going to have sec= ond thoughts about using the latest versions of their software.

Folk= s who use older versions are typically people who don't care about CBC unti= l it comes up in a security scan... At which point they grudgingly consider= upgrading their 10 year old version. :)


----- Original Message = -----
From: Simon Josefsson
Sent: Thursday, November 12, 2015 03:17<= br>To: denis bider
Cc: ietf-ssh@netbsd.org ; djm@mindrot.org
Subjec= t: Re: Curve25519/448 key agreement for SSH

denis bider <ietf-ssh= 3@denisbider.com> writes:

> But X and K are different in each = key exchange. The only way to make
> them same would be for both part= ies to conspire.

It doesn't matter if they are different -- a listen= ing entity may be
able to use a side channel (e.g., time) to infer wethe= r the parties
hashed X or X+1 bytes, which leaks one bit of the secret.<= br>
> I have suggested solving this by reinterpreting X as an already=
> encoded K, which may be negative. Well - that has a different issu= e:
> it violates mpint encoding when the first byte of X is zero...>
> All things considered, I don't think it really matters which= way this
> is resolved. Just please make sure to be clear when you s= pecify it. :)
> An imprecise specification may lead to problems that = manifest in
> e.g. 1/256 of key exchanges.

Yep.  I don't = care strongly about this point, but I do share your strong
opinion that = it has to be clearly specified.  Right now I'm inclined to
describe= exactly what libssh/OpenSSH implements and describe the
vulnerability.<= br>
If implementers are interested in "fixing" this while we go through = this
process, we have that opportunity.  There is no direct backwar= ds
compatibility problem to care about, since we are registering a newname.  However, implementations will likely need to support both for=
quite some time, and having the two implementations differ has code
= maintenance costs.  It seems Aris and Damien represent two significant=
implementations of this, so if they can agree on this, we have a wayforward.

/Simon

>
> Simon Josefsson <simon@josef= sson.org> , 11/12/2015 8:50 AM:
> denis bider <ietf-ssh3@denisb= ider.com> writes:
>  
>> Simon -
>>
&= gt;>
>>> A simple approach would be to say that if the MSB = is 1,
>>> prepend a zero byte.  However, the length diffe= rence
>>> would leak that information.
>>
>&g= t; The length difference might not be much of a problem, since K is never s= ent.
>  
> It shouldn't be difficult to fingerprint (stat= istically, over many
> connections) if a remote application performs= a hash on X bytes or X+1
> bytes.  Knowing which leaks the MSB= of the derived secret.
>  
> I'm inclined to add a secur= ity consideration describing this, and allow
> for the potential of = a nice conference paper describing how to exploit
> this observation= .  At this point, to fix this (as Damien described)
> appear le= ss appealing.
>  
> /Simon

= --=-lA8HUM+3hmPVgDxcXSZe-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Nov 12 14:56:39 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 804091B3A07 for ; Thu, 12 Nov 2015 14:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.609 X-Spam-Level: X-Spam-Status: No, score=-1.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 fWz9Mc6jiRrC for ; Thu, 12 Nov 2015 14:56:37 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDABE1B3A06 for ; Thu, 12 Nov 2015 14:56:37 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 5710414A2BE; Thu, 12 Nov 2015 22:56:37 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id DEA1F14A2B8; Thu, 12 Nov 2015 22:56:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 3F90214A254 for ; Thu, 12 Nov 2015 08:43:28 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id YOLQZEUxEgG0 for ; Thu, 12 Nov 2015 08:43:27 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 4542E14A247 for ; Thu, 12 Nov 2015 08:43:27 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for pgut001@cs.auckland.ac.nz; Thu, 12 Nov 2015 08:43:21 +0000 Date: Thu, 12 Nov 2015 08:43:21 +0000 Subject: Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <12081450-2616@skroderider.denisbider.com> X-Priority: 3 Importance: Normal In-Reply-To: <11020971-2016@skroderider.denisbider.com> MIME-Version: 1.0 From: denis bider To: Peter Gutmann , =?UTF-8?q?Niels_M=C3=B6ller?= Cc: "ietf-ssh@netbsd.org" , Jeffrey Hutzelman , "Mark D. Baushke" , "stephen.farrell@cs.tcd.ie" , "jon@siliconcircus.com" , "djm@mindrot.org" , Max Horn Content-Type: multipart/alternative; boundary="=-x0OEwpiYZdCNrsfq0hF/" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-x0OEwpiYZdCNrsfq0hF/ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To be clear: when you stop reading from the SSH socket because the infinite= -window channel is blocked, this affects: - key re-exchange - can't be started while infinite-window channel is block= ed - keep-alive - can't be used while infinite-window channel is blocked This definitely affects the transport layer, and requires the awareness of = the transport layer if the feature has been enabled for any channel. That's why I think it makes sense to negotiate it on the transport layer. T= he transport layer must be aware of this. denis bider , 11/12/2015 8:24 AM: It seems to me the only known applications that might want to use "no-handb= rake" are those that don't want to use multiplexing. I don't know of a diff= erent usage case. To support a different usage case that we do not know of, we would have to = specify a mechanism for enabling this on a per-channel basis. This could be= a channel request sent by the client. If supported and confirmed by the se= rver, the channel request would switch the channel to infinite-window mode. The way I see it, though, supporting infinite windows with multiple channel= s just doesn't seem to make sense. The problem is not sending data. Yeah, in that case, you send in a round-ro= bin fashion, no problem. The problem is receiving. What happens when you can't write to the infinite= -window channel, but the data keeps coming? In this situation, you must stop reading from the SSH socket, which affects= all channels. You must stop reading because you have no way of knowing whe= ther the next packet you receive is going to be data for the infinite-windo= w channel. The way I see it, the only clean usage scenario for this feature is where t= here's a single channel. Anything else introduces dirty dilemmas that aren'= t even necessary, because the only actual usage case is single-channel. Peter Gutmann , 11/12/2015 7:50 AM: Niels M=C3=B6ller writes: >Send 0, ignore received value, would have made it actually useful. Can we get any figures on what effect making it nonzero would have? =C2=A0W= e know that there are at least some implementations who would have problems with this, but if they're OSS and frequently updated then it may not be such a b= ig issue, push out a fix fairly soon and by the time the RFC is ready most of = the problem will have fixed itself. Another workaround, although it's a bit of a hack, is if the two major clie= nt and server implementations, putty and OpenSSH, could retry an initial conne= ct with a nonzero field that's failed with a zeroed field and if it works, rep= ort to the user that the implementation needs an update. >Also, I'm not sure it has to be restricted to a single channel, I think it >would make sense to disable flow control independently for a single channe= l >or a single unidirectional flow. Ah, good point. =C2=A0The number of users of multichannel that I have is pr= etty minimal, so I never see this (it's used almost exclusively as a secure teln= et or for firmware upgrades, neither of which need multi-channel, to the point where it's disabled by default in the source code). >Do we have a common understanding of how it's going to work? Not yet, I think :-). =C2=A0I'd just seen it as all-or-nothing, is there an= y reason why you'd have windowing on three channels but not a fourth? =C2=A0That is,= is there a need for per-channel windowing enable/disable? =C2=A0Can it be enab= led mid- flow or only on channel open? Peter.= --=-x0OEwpiYZdCNrsfq0hF/ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable To be clear: when you stop reading from the SSH so= cket because the infinite-window channel is blocked, this affects:

-= key re-exchange - can't be started while infinite-window channel is blocke= d

- keep-alive - can't be used while infinite-window channel is bloc= ked

This definitely affects the transport layer, and requires the aw= areness of the transport layer if the feature has been enabled for any channel.

That's why I think it makes sense to negotiate it on the= transport layer. The transport layer must be aware of this.


denis bi= der <nospam@denisbider.com> , 11/12/2015 8:24 AM:
It seems to me th= e only known applications that might want to use "no-handbrake" are those t= hat don't want to use multiplexing. I don't know of a different usage case.=

To support a different usage case that we do not know of, we would = have to specify a mechanism for enabling this on a per-channel basis. This = could be a channel request sent by the client. If supported and confirmed b= y the server, the channel request would switch the channel to infinite-wind= ow mode.

The way I see it, though, supporting infinite windows with = multiple channels just doesn't seem to make sense.

The problem is no= t sending data. Yeah, in that case, you send in a round-robin fashion, no p= roblem.

The problem is receiving. What happens when you can't write = to the infinite-window channel, but the data keeps coming?

In this s= ituation, you must stop reading from the SSH socket, which affects a= ll channels. You must stop reading because you have no way of knowing wheth= er the next packet you receive is going to be data for the infinite-window = channel.

The way I see it, the only clean usage scenario for this fe= ature is where there's a single channel. Anything else introduces dirty dil= emmas that aren't even necessary, because the only actual usage case= is single-channel.


Peter Gutmann <pgut001@cs.auckland.ac.nz> , 11/12/2015 7:50 AM:
Niels M= =C3=B6ller <nisse@lysator.liu.se> = writes:

>Send 0, ignore received value, would have made it actual= ly useful.

Can we get any figures on what effect making it nonzero w= ould have?  We know
that there are at least some implementations wh= o would have problems with
this, but if they're OSS and frequently updat= ed then it may not be such a big
issue, push out a fix fairly soon and b= y the time the RFC is ready most of the
problem will have fixed itself.<= br>
Another workaround, although it's a bit of a hack, is if the two maj= or client
and server implementations, putty and OpenSSH, could retry an = initial connect
with a nonzero field that's failed with a zeroed field a= nd if it works, report
to the user that the implementation needs an upda= te.

>Also, I'm not sure it has to be restricted to a single chann= el, I think it
>would make sense to disable flow control independentl= y for a single channel
>or a single unidirectional flow.

Ah, g= ood point.  The number of users of multichannel that I have is pretty<= br>minimal, so I never see this (it's used almost exclusively as a secure t= elnet
or for firmware upgrades, neither of which need multi-channel, to = the point
where it's disabled by default in the source code).

>= ;Do we have a common understanding of how it's going to work?

Not ye= t, I think :-).  I'd just seen it as all-or-nothing, is there any reas= on
why you'd have windowing on three channels but not a fourth?  Th= at is, is
there a need for per-channel windowing enable/disable?  C= an it be enabled mid-
flow or only on channel open?

Peter.