From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Aug 2 21:33:44 2016 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 349D512D8D9 for ; Tue, 2 Aug 2016 21:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.086 X-Spam-Level: X-Spam-Status: No, score=-4.086 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FyXaNIBwoWVH for ; Tue, 2 Aug 2016 21:33:42 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 6D83512D88F for ; Tue, 2 Aug 2016 21:33:42 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 38AB385ED0; Wed, 3 Aug 2016 04:33:41 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id E18A985E1A; Wed, 3 Aug 2016 04:33:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 0221F85E84 for ; Tue, 2 Aug 2016 19:55:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id 1zQm9XSwXIMb for ; Tue, 2 Aug 2016 19:55: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 424EA84CE5 for ; Tue, 2 Aug 2016 19:55:30 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Tue, 2 Aug 2016 20:55:15 +0100 Message-ID: <7C3A4D37CD484763BA5496F0B08DEE26@Khan> From: "denis bider \(Bitvise\)" To: "Peter Gutmann" , References: <1390BBE9B1DA4692BEB23518D00B09FC@Khan> <9A043F3CF02CD34C8E74AC1594475C73F4CDD31B@uxcn10-5.UoA.auckland.ac.nz>,<80252E4D72004059B23AE81B2256FC9F@Khan> <9A043F3CF02CD34C8E74AC1594475C73F4CDE02F@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4CDE02F@uxcn10-5.UoA.auckland.ac.nz> Subject: Re: rsa-sha2-256/512: handling of incorrect signature encoding Date: Tue, 2 Aug 2016 13:54:45 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0036_01D1ECC5.6D37F030" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0036_01D1ECC5.6D37F030 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Yeah, so my code does use "rsa-sha2-256" after all for the auth and = sig type, OK, that sounds right. :-) > What we actually need is interop test servers, I did set up a test server for the new rsa-sha2-XXX signature types; I = posted connection information here, and included instructions to test = both server and client authentication. I was under the impression that = you might have used it, but I=E2=80=99m not sure if you did. At this point, the implementation is available in our published latest = release, which can be downloaded and tested free of charge (though it = does require a Windows VM or computer). > Make it one again, it did use the correct string,=20 > it was only the mix of SHA-256 + SHA-1 at the=20 > same time that would have caused problems. That=E2=80=99s a relief. Sounds great. :-) From: Peter Gutmann=20 Sent: Tuesday, August 2, 2016 03:07 To: denis bider (Bitvise) ; ietf-ssh@netbsd.org=20 Subject: RE: rsa-sha2-256/512: handling of incorrect signature encoding denis bider (Bitvise) writes: >This is actually exactly contrary to what the current draft says, and = what it >has said for 9 months in its latest version. > >If you are sending an rsa-sha2-XXX signature, you cannot set all 3 = fields in >the authentication request to "ssh-rsa", because then this makes for a = SHA-1 >signature as it was done traditionally, not a SHA-2 signature. To send = a >SHA-2 signature, at least one field has to contain "rsa-sha2-XXX". I've looked through my code and saw why it works currently, I assume = that if you've negotiated SHA-256 in the client/server hello (keyex) then the = auth will also use SHA-256 (it would seem a bit strange to use a strong hash everywhere else in the exchange and then fall back to a weak one for the auth). So in my case unless you use SHA-256 everywhere but then decide = to use SHA-1 in the auth, things will work. >The draft specifically says the signature format names are = "rsa-sha2-XXX", >but the public key format name stays "ssh-rsa", which it must stay in = order >to preserve existing RSA key fingerprints. Yeah, so my code does use "rsa-sha2-256" after all for the auth and sig = type, it just wasn't obvious at first glance because the hash is implied. = I've made the one-line change to allow use of SHA-256 everywhere but then SHA-1 = for the auth. >My strong preference would have been for implementations - especially = the >early implementations - to verify this strictly, and to not accept = signatures >that depart from this spec.=20 What we actually need is interop test servers, with everyone doing this = more or less in isolation (there was nothing to test against when I did this, = and for the ECC stuff it wasn't much better, was it you that set up an = SSH-ECC server for testing when the draft was published?) you end up with implementations that do all sorts of things. >Unfortunately, we now appear to be in a situation where not only one, = but >potentially two implementations depart from the above spec.=20 Make it one again, it did use the correct string, it was only the mix of SHA-256 + SHA-1 at the same time that would have caused problems. Peter. ------=_NextPart_000_0036_01D1ECC5.6D37F030 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Yeah, so = my code does=20 use "rsa-sha2-256" after all for the auth and sig = type,
 
OK, that sounds right. = :-)
 
 
> What we actually need is interop = test=20 servers,
 
I did set up a test server for the = new=20 rsa-sha2-XXX signature types; I posted connection information here, and = included=20 instructions to test both server and client authentication. I was under = the=20 impression that you might have used it, but I=E2=80=99m not sure if you=20 did.
 
At this point, the implementation is = available in=20 our published latest release, which can be downloaded and tested free of = charge=20 (though it does require a Windows VM or computer).
 
 
> Make it one again, it did use the correct = string,=20
> it was = only the mix=20 of SHA-256 + SHA-1 at the
> same time = that would=20 have caused problems.
 
That=E2=80=99s a relief. Sounds = great. :-)


 
Sent: Tuesday, August 2, 2016 03:07
To: denis bider (Bitvise) ; ietf-ssh@netbsd.org
Subject: RE: rsa-sha2-256/512: handling of incorrect = signature=20 encoding
 
denis=20 bider (Bitvise) <ietf-ssh3@denisbider.com> writes:

>This = is=20 actually exactly contrary to what the current draft says, and what = it
>has=20 said for 9 months in its latest version.
>
>If you are = sending an=20 rsa-sha2-XXX signature, you cannot set all 3 fields in
>the = authentication=20 request to "ssh-rsa", because then this makes for a = SHA-1
>signature as it=20 was done traditionally, not a SHA-2 signature. To send a
>SHA-2 = signature,=20 at least one field has to contain "rsa-sha2-XXX".

I've looked = through my=20 code and saw why it works currently, I assume that if
you've = negotiated=20 SHA-256 in the client/server hello (keyex) then the auth
will also = use=20 SHA-256 (it would seem a bit strange to use a strong hash
everywhere = else in=20 the exchange and then fall back to a weak one for the
auth).  So = in my=20 case unless you use SHA-256 everywhere but then decide to use
SHA-1 = in the=20 auth, things will work.

>The draft specifically says the = signature=20 format names are "rsa-sha2-XXX",
>but the public key format name = stays=20 "ssh-rsa", which it must stay in order
>to preserve existing RSA = key=20 fingerprints.

Yeah, so my code does use "rsa-sha2-256" after all = for the=20 auth and sig type,
it just wasn't obvious at first glance because the = hash is=20 implied.  I've made
the one-line change to allow use of SHA-256=20 everywhere but then SHA-1 for the
auth.

>My strong = preference would=20 have been for implementations - especially the
>early = implementations - to=20 verify this strictly, and to not accept signatures
>that depart = from this=20 spec.

What we actually need is interop test servers, with = everyone doing=20 this more
or less in isolation (there was nothing to test against = when I did=20 this, and
for the ECC stuff it wasn't much better, was it you that = set up an=20 SSH-ECC
server for testing when the draft was published?) you end up=20 with
implementations that do all sorts of = things.

>Unfortunately,=20 we now appear to be in a situation where not only one, = but
>potentially=20 two implementations depart from the above spec.

Make it one = again, it=20 did use the correct string, it was only the mix of
SHA-256 + SHA-1 at = the=20 same time that would have caused=20 problems.

Peter.
------=_NextPart_000_0036_01D1ECC5.6D37F030-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Aug 2 21:34:58 2016 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C872312D8FB for ; Tue, 2 Aug 2016 21:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.486 X-Spam-Level: X-Spam-Status: No, score=-5.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIYdKaGNWw73 for ; Tue, 2 Aug 2016 21:34:56 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (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 9392112D88F for ; Tue, 2 Aug 2016 21:34:56 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 0277E85EDD; Wed, 3 Aug 2016 04:34:56 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id AF70A85ED3; Wed, 3 Aug 2016 04:34:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 5243985EF6 for ; Mon, 1 Aug 2016 21:27:51 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id tHMxpFf6ipla for ; Mon, 1 Aug 2016 21:27: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 7034B84CE5 for ; Mon, 1 Aug 2016 21:27:50 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Mon, 1 Aug 2016 22:27:36 +0100 Message-ID: <80252E4D72004059B23AE81B2256FC9F@Khan> From: "denis bider \(Bitvise\)" To: "Peter Gutmann" , References: <1390BBE9B1DA4692BEB23518D00B09FC@Khan> <9A043F3CF02CD34C8E74AC1594475C73F4CDD31B@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4CDD31B@uxcn10-5.UoA.auckland.ac.nz> Subject: Re: rsa-sha2-256/512: handling of incorrect signature encoding Date: Mon, 1 Aug 2016 15:27:14 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0090_01D1EC09.2E7BC860" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0090_01D1EC09.2E7BC860 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > I would change the rsa-sha2 draft to say > that the same ID string should be used > throughout, i.e. "ssh-rsa" for RSA sigs and keys. This is actually exactly contrary to what the current draft says, and = what it has said for 9 months in its latest version. If you are sending an rsa-sha2-XXX signature, you cannot set all 3 = fields in the authentication request to "ssh-rsa", because then this = makes for a SHA-1 signature as it was done traditionally, not a SHA-2 = signature. To send a SHA-2 signature, at least one field has to contain = "rsa-sha2-XXX". The draft specifically says the signature format names are = "rsa-sha2-XXX", but the public key format name stays "ssh-rsa", which it = must stay in order to preserve existing RSA key fingerprints. The signature format is defined thus: string "rsa-sha2-256" / "rsa-sha2-512" string rsa_signature_blob These specifications seem to me very clear and unambiguous. In a user = authentication request, when sending a SHA-2 signature, the only correct = encoding of algorithm names is as follows: byte SSH_MSG_USERAUTH_REQUEST string user name string service name string "publickey" boolean TRUE string "rsa-sha2-256" / "rsa-sha2-512" string public key blob: string "ssh-rsa" mpint e mpint n string signature: string "rsa-sha2-256" / "rsa-sha2-512" string rsa_signature_blob =20 If your implementation does not encode the algorithm names this way, it = is incorrect. The latest OpenSSH versions encode the algorithm names = this way, though a previous version used "ssh-rsa" in the third field by = mistake. Bitvise SSH Client encodes the fields this way also, and the current = version of Bitvise SSH Server expects the algorithm names this way, and = only this way. My strong preference would have been for implementations - especially = the early implementations - to verify this strictly, and to not accept = signatures that depart from this spec. Once a deployed based of strict = and correct implementations is in place, it would have been difficult = for later implementations to do anything incorrectly. Unfortunately, we now appear to be in a situation where not only one, = but potentially two implementations depart from the above spec. = Therefore, it definitely seems to me that we need a section about this = in the draft, and current and future implementations might need to err = on the side of being permissive. :( :-/ ----- Original Message ----- From: Peter Gutmann=20 Sent: Monday, August 1, 2016 06:30 To: denis bider (Bitvise) ; ietf-ssh@netbsd.org=20 Subject: RE: rsa-sha2-256/512: handling of incorrect signature encoding denis bider (Bitvise) writes: >The invariants our implementation currently expects are: >- name 1, in the USERAUTH request, can be any of the RSA signature = algorithm names >- name 2, in the public key blob, must be "ssh-rsa" >- name 3, in the signature blob, must match name 1 My code writes "ssh-rsa" for all three, and accepts whatever it finds = (along with a sarcastic comment about why you need to specify the same thing = three times in a row in case the server has gone deaf or something :-). For = the first one: /* Skip the first of the three copies of the algorithm name (see the = comment in ssh2_cli.c for more on this). We don't do anything with it = because we're about to get two more copies of the same thing, and the key and signature information take precedence over anything that we find here = */ Then for the second one it looks for ssh-rsa (or ssh-dss, or whatever, = since it's needed to decode the key), and finally it again ignores the last = one because it already knows what it should be. Why is there a need for "rsa-sha2-256" and other complications when = "ssh-rsa" is perfectly OK for everything else? >My questions are: >[...] I would use (C) ignore everything except the key blob name. This = situation is confusing enough that you're going to get implementations screwing = things up in all sorts of ways, meaning you'll find who knows what in those ID = strings. Apart from having to know what format the key is in the rest is = irrelevant, you know the key is RSA, you've been hashing with SHA-1 or SHA-256 or whatever, it doesn't matter what the ID strings say. >Regardless of what we think is best - should we put a paragraph about = this in >the rsa-sha2 draft? I would change the rsa-sha2 draft to say that the same ID string should = be used throughout, i.e. "ssh-rsa" for RSA sigs and keys. Peter. ------=_NextPart_000_0090_01D1EC09.2E7BC860 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
> I would change the rsa-sha2 draft to say
> that the same ID string should be used
> throughout, i.e. "ssh-rsa" for RSA sigs and keys.
 
This is actually exactly contrary to what the current draft says, = and what=20 it has said for 9 months in its latest version.
 
If you are sending an rsa-sha2-XXX signature, you cannot set all 3 = fields=20 in the authentication request to "ssh-rsa", because then this makes for = a SHA-1=20 signature as it was done traditionally, not a SHA-2 signature. To send a = SHA-2=20 signature, at least one field has to contain "rsa-sha2-XXX".
 
The draft specifically says the signature format names are = "rsa-sha2-XXX",=20 but the public key format name stays "ssh-rsa", which it must stay in = order to=20 preserve existing RSA key fingerprints.
 
The signature format is defined thus:
 
  string    = "rsa-sha2-256" /=20 "rsa-sha2-512"
  string   =20 rsa_signature_blob
 
These specifications seem to me very clear and unambiguous. In a = user=20 authentication request, when sending a SHA-2 signature, the only correct = encoding of algorithm names is as follows:
 
byte     =20 SSH_MSG_USERAUTH_REQUEST
string    user = name
string    service = name
string    = "publickey"
boolean   TRUE
string    = "rsa-sha2-256" /=20 "rsa-sha2-512"
string    public key=20 blob:
  string   =20 "ssh-rsa"
  mpint    =20 e
  mpint    =20 n
string    = signature:
  string   =20 "rsa-sha2-256" / "rsa-sha2-512"
  string   =20 rsa_signature_blob
If your implementation does not encode the algorithm names this = way, it is=20 incorrect. The latest OpenSSH versions encode the algorithm names this = way,=20 though a previous version used "ssh-rsa" in the third field by = mistake.
 
Bitvise SSH Client encodes the fields this way also, and the = current=20 version of Bitvise SSH Server expects the algorithm names this way, and = only=20 this way.
 
My strong preference would have been for implementations - = especially the=20 early implementations - to verify this strictly, and to not accept = signatures=20 that depart from this spec. Once a deployed based of strict and correct=20 implementations is in place, it would have been difficult for later=20 implementations to do anything incorrectly.
 
Unfortunately, we now appear to be in a situation where not only = one, but=20 potentially two implementations depart from the above spec. Therefore, = it=20 definitely seems to me that we need a section about this in the draft, = and=20 current and future implementations might need to err on the side of = being=20 permissive. :( :-/
 
 
----- Original Message -----
From: Peter Gutmann
Sent: Monday, August 1, 2016 06:30
To: denis bider (Bitvise) ; ietf-ssh@netbsd.org
Subject: RE: rsa-sha2-256/512: handling of incorrect signature=20 encoding
 
denis bider (Bitvise) <ietf-ssh3@denisbider.com> = writes:
 
>The invariants our implementation currently expects are:
>- name 1, in the USERAUTH request, can be any of the RSA = signature=20 algorithm names
>- name 2, in the public key blob, must be "ssh-rsa"
>- name 3, in the signature blob, must match name 1
 
My code writes "ssh-rsa" for all three, and accepts whatever it = finds=20 (along
with a sarcastic comment about why you need to specify the same = thing=20 three
times in a row in case the server has gone deaf or something = :-).  For=20 the
first one:
 
/* Skip the first of the three copies of the algorithm name (see = the=20 comment
   in ssh2_cli.c for more on this).  We don't do = anything=20 with it because
   we're about to get two more copies of the same thing, = and the=20 key and
   signature information take precedence over anything = that we=20 find here */
 
Then for the second one it looks for ssh-rsa (or ssh-dss, or = whatever,=20 since
it's needed to decode the key), and finally it again ignores the = last=20 one
because it already knows what it should be.
 
Why is there a need for "rsa-sha2-256" and other complications when = "ssh-rsa"
is perfectly OK for everything else?
 
>My questions are:
>[...]
 
I would use (C) ignore everything except the key blob name.  = This=20 situation is
confusing enough that you're going to get implementations screwing = things=20 up
in all sorts of ways, meaning you'll find who knows what in those = ID=20 strings.
Apart from having to know what format the key is in the rest is=20 irrelevant,
you know the key is RSA, you've been hashing with SHA-1 or SHA-256 = or
whatever, it doesn't matter what the ID strings say.
 
>Regardless of what we think is best - should we put a paragraph = about=20 this in
>the rsa-sha2 draft?
 
I would change the rsa-sha2 draft to say that the same ID string = should=20 be
used throughout, i.e. "ssh-rsa" for RSA sigs and keys.
 
Peter.
------=_NextPart_000_0090_01D1EC09.2E7BC860-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Aug 2 21:35:14 2016 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEBD612D88F for ; Tue, 2 Aug 2016 21:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.486 X-Spam-Level: X-Spam-Status: No, score=-5.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3lTI7T5Wxcf for ; Tue, 2 Aug 2016 21:35:07 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 BD4CF12D8EC for ; Tue, 2 Aug 2016 21:35:07 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 7FC9B85F02; Wed, 3 Aug 2016 04:35:07 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 339F185F01; Wed, 3 Aug 2016 04:35:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 111C284CF0 for ; Tue, 2 Aug 2016 00:03: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 jygC7TpNXUoJ for ; Tue, 2 Aug 2016 00:03:47 +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 0055E85E11 for ; Tue, 2 Aug 2016 00:03:46 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Tue, 2 Aug 2016 01:03:39 +0100 Message-ID: <62D23120DAF147D99D337AE57BB18373@Khan> From: "denis bider \(Bitvise\)" To: "Curdle" Cc: , "Simon Tatham" , , "Peter Gutmann" References: <20160801230725.3015.91086.idtracker@ietfa.amsl.com> In-Reply-To: <20160801230725.3015.91086.idtracker@ietfa.amsl.com> Subject: SSH: New version of RSA SHA-2 draft; prune extensions from EXT_INFO draft? Date: Mon, 1 Aug 2016 18:03:08 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0066_01D1EC1E.F589AE30" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0066_01D1EC1E.F589AE30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello everyone - the two related drafts to support RSA signatures with SHA-2 in SSH: Use of RSA Keys with SHA-2 256 and 512 in Secure Shell (SSH) https://tools.ietf.org/html/draft-ietf-curdle-rsa-sha2-01 Extension Negotiation in Secure Shell (SSH) https://tools.ietf.org/html/draft-ietf-curdle-ssh-ext-info-00 ... are currently deployed in at least two widely available = implementations that I'm aware of: OpenSSH 7.2 Bitvise SSH Server and Client 7.xx I am aware also of implementations by Peter Gutmann (Cryptlib) and at = least one another smaller one. For these other implementations, I'm not = sure of their status, but it could be that some of them are also = deployed. Issues: 1. New version of RSA SHA-2 draft: After some deployment experience, I am finding that the draft has been = too easy to misread with respect to the correct encoding of an = SSH_MSG_USERAUTH_REQUEST containing an RSA SHA-2 signature. I have = updated the draft to lay out a full example of an authentication = request, in the way it's supposed to be encoded.=20 Besides this additional example, the new version does not change the = protocol in any way. 2. Pruning superfluous extensions from EXT_INFO draft? The EXT_INFO document currently describes the following extensions: server-sig-algs no-flow-control accept-channels elevation delay-compression Currently, I am aware of "server-sig-algs" being widely implemented. = This extension goes hand-in-hand with support for RSA signatures with = SHA-2, so it is implemented in the same products as enumerated above: = OpenSSH, Bitvise SSH Client and Server, and I am aware of at least one = other. I am currently not aware of current implementations of the other = proposed extensions. The respective reasons I proposed them were as = follows: no-flow-control: Peter Gutmann once expressed a passionate argument in favor of something = like this, which did not fit into SSH at that time. I therefore proposed = it because, with a mechanism like EXT_INFO, an extension like this is = possible. However, I am not actually passionate about implementing this = - for our needs, SSH flow control is fine - so the viability of this = extension depends on other people's interest. It should be kept if there = are implementations working on this. It should be cut if there are not. accept-channels: This would be a way to advertise product features that may otherwise = remain unknown to other implementors. Without an extension like this, = feature discovery involves looking at the counterparty's source code (if = available) or analyzing disassembly. If software implements an extension = like this, you can see at a glance what might be a good idea to = implement that your product is missing. elevation: This allows the user to decide whether they want elevation when logging = into a Windows server. Signaling via an extension is pretty much the = only good way to implement this feature - after user authentication, it = is already too late. Bitvise has this feature on a to-do list as a = "would like to have", but it's not high priority. We can also do it with = a proprietary, @bitvise.com extension. This can be cut if no one else is = interested. delay-compression: In my opinion, this is THE solution to delayed compression that should = have been implemented to begin with. The original OpenSSH implementation = of delayed compression is prone to a somewhat bad race condition, and = the PuTTY workaround to this race condition (also adopted by Bitvise) is = to enable compression after user authentication via a second early key = exchange. This workaround costs an additional, mostly unnecessary = handshake, which cost could be removed while also resolving the race = condition using this extension. I think this is a superior solution to an ongoing problem. However, our = software does not have a dependency on the zlib library (we use = Crypto++), so I am currently under a (I hope not mistaken!) impression = that reducing the attack surface through delayed compression is a = "like-to-have" more than a "must-have". For this reason, I would like = this extension to be adopted by authors who are the biggest fans of = delayed compression, e.g. OpenSSH and/or PuTTY - in which case, we would = definitely implement it as well. Overall, my feelings about the current extensions are: server-sig-algs - widely implemented, definitely keep --- delay-compression - promising; would like people to implement; keep? --- elevation - somewhat optional, can keep or cut accept-channels - would be nice, but can keep or cut --- no-flow-control - are there implementations? if not, cut? Best regards, denis bider ---- Original Message ---- From: internet-drafts@ietf.org=20 Sent: Monday, August 1, 2016 17:07 To: i-d-announce@ietf.org=20 Cc: curdle@ietf.org=20 Subject: [Curdle] I-D Action: draft-ietf-curdle-rsa-sha2-01.txt A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the CURves, Deprecating and a Little more = Encryption of the IETF. Title : Use of RSA Keys with SHA-2 256 and 512 in = Secure Shell (SSH) Author : Denis Bider Filename : draft-ietf-curdle-rsa-sha2-01.txt Pages : 6 Date : 2016-08-01 Abstract: This memo defines an algorithm name, public key format, and signature format for use of RSA keys with SHA-2 512 for server and client authentication in SSH connections. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-rsa-sha2/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-curdle-rsa-sha2-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-rsa-sha2-01 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle ------=_NextPart_000_0066_01D1EC1E.F589AE30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello everyone -
 
the two related drafts to support RSA signatures with SHA-2 in=20 SSH:
Use of RSA Keys with SHA-2 256 and 512 in Secure Shell (SSH)
https:= //tools.ietf.org/html/draft-ietf-curdle-rsa-sha2-01
 
Extension Negotiation in Secure Shell (SSH)
ht= tps://tools.ietf.org/html/draft-ietf-curdle-ssh-ext-info-00
 
... are currently deployed in at least two widely available = implementations=20 that I'm aware of:
 
OpenSSH 7.2
Bitvise SSH Server and Client 7.xx
 
I am aware also of implementations by Peter Gutmann (Cryptlib) and = at least=20 one another smaller one. For these other implementations, I'm not sure = of their=20 status, but it could be that some of them are also deployed.
 
Issues:
 
 
1. New version of RSA SHA-2 draft:
 
After some deployment experience, I am finding that the draft has = been too=20 easy to misread with respect to the correct encoding of an=20 SSH_MSG_USERAUTH_REQUEST containing an RSA SHA-2 signature. I have = updated the=20 draft to lay out a full example of an authentication request, in the way = it's=20 supposed to be encoded.
 
Besides this additional example, the new version does not change = the=20 protocol in any way.
 
 
2. Pruning superfluous extensions from EXT_INFO=20 draft?
 
The EXT_INFO document currently describes the following = extensions:
 
  server-sig-algs
  no-flow-control
  accept-channels
  elevation
  delay-compression
 
Currently, I am aware of "server-sig-algs" being widely = implemented. This=20 extension goes hand-in-hand with support for RSA signatures with SHA-2, = so it is=20 implemented in the same products as enumerated above: OpenSSH, Bitvise = SSH=20 Client and Server, and I am aware of at least one other.
 
I am currently not aware of current implementations of the other = proposed=20 extensions. The respective reasons I proposed them were as = follows:
 
no-flow-control:
 
Peter Gutmann once expressed a passionate argument in favor of = something=20 like this, which did not fit into SSH at that time. I therefore proposed = it=20 because, with a mechanism like EXT_INFO, an extension like this is = possible.=20 However, I am not actually passionate about implementing this - for our = needs,=20 SSH flow control is fine - so the viability of this extension depends on = other=20 people's interest. It should be kept if there are implementations = working on=20 this. It should be cut if there are not.
 
accept-channels:
 
This would be a way to advertise product features that may = otherwise remain=20 unknown to other implementors. Without an extension like this, feature = discovery=20 involves looking at the counterparty's source code (if available) or = analyzing=20 disassembly. If software implements an extension like this, you can see = at a=20 glance what might be a good idea to implement that your product is=20 missing.
 
elevation:
 
This allows the user to decide whether they want elevation when = logging=20 into a Windows server. Signaling via an extension is pretty much the = only good=20 way to implement this feature - after user authentication, it is already = too=20 late. Bitvise has this feature on a to-do list as a "would like to = have", but=20 it's not high priority. We can also do it with a proprietary, = @bitvise.com=20 extension. This can be cut if no one else is interested.
 
delay-compression:
 
In my opinion, this is THE solution to delayed compression that = should have=20 been implemented to begin with. The original OpenSSH implementation of = delayed=20 compression is prone to a somewhat bad race condition, and the PuTTY = workaround=20 to this race condition (also adopted by Bitvise) is to enable = compression after=20 user authentication via a second early key exchange. This workaround = costs an=20 additional, mostly unnecessary handshake, which cost could be removed = while also=20 resolving the race condition using this extension.
 
I think this is a superior solution to an ongoing problem. However, = our=20 software does not have a dependency on the zlib library (we use = Crypto++), so I=20 am currently under a (I hope not mistaken!) impression that reducing the = attack=20 surface through delayed compression is a "like-to-have" more than a = "must-have".=20 For this reason, I would like this extension to be adopted by authors = who are=20 the biggest fans of delayed compression, e.g. OpenSSH and/or PuTTY - in = which=20 case, we would definitely implement it as well.
 
Overall, my feelings about the current extensions are:
 
 
server-sig-algs   - widely = implemented,=20 definitely keep
---
delay-compression - promising; would = like people=20 to implement; keep?
---
elevation         -=20 somewhat optional, can keep or cut
accept-channels   - would be = nice, but=20 can keep or cut
---
no-flow-control   - are there=20 implementations? if not, cut?
 
 
Best regards,
 
denis bider
 
 
---- Original Message ----
From: internet-drafts@ietf.org
Sent: Monday, August 1, 2016 17:07
To: i-d-announce@ietf.org
Cc: curdle@ietf.org
Subject: [Curdle] I-D Action: = draft-ietf-curdle-rsa-sha2-01.txt
 
 
A New Internet-Draft is available from the on-line Internet-Drafts=20 directories.
This draft is a work item of the CURves, Deprecating and a Little = more=20 Encryption of the IETF.
 
       =20 Title           : Use = of RSA=20 Keys with SHA-2 256 and 512 in Secure Shell (SSH)
       =20 Author          : Denis = Bider
Filename        :=20 draft-ietf-curdle-rsa-sha2-01.txt
Pages           : = 6
Date          &nbs= p; :=20 2016-08-01
 
Abstract:
  This memo defines an algorithm name, public key format, and=20 signature
  format for use of RSA keys with SHA-2 512 for server and=20 client
  authentication in SSH connections.
 
 
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-curdle-rsa-sha2/
 
There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-curdle-rsa-sha2-01
 
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-rsa-sha2-01
 
 
Please note that it may take a couple of minutes from the time of=20 submission
until the htmlized version and diff are available at = tools.ietf.org.
 
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
 
_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle
------=_NextPart_000_0066_01D1EC1E.F589AE30-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Aug 2 21:35:47 2016 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72EC712D8EC for ; Tue, 2 Aug 2016 21:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 VC-aar4-yTTL for ; Tue, 2 Aug 2016 21:35:42 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (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 A7CA112D88F for ; Tue, 2 Aug 2016 21:35:42 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 652D985F09; Wed, 3 Aug 2016 04:35:42 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 1507C85F01; Wed, 3 Aug 2016 04:35:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 936D885EC6 for ; Mon, 1 Aug 2016 14:04:19 +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 HwihEow7y1p5 for ; Mon, 1 Aug 2016 14:04:18 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (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 BD14985DFE for ; Mon, 1 Aug 2016 14:04:17 +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=1470060257; x=1501596257; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=XxDgBAqmUltlyKA8728HvmZoubdOw1Vj/SefYonv2ic=; b=yfWE3FJ4z8RlIKvPsp+2NPwyQKMH9GqOwXlh9HHkM3eJbeksYpepEXZs doybWN8jpja0SrX9ZphKegTU98bittq11sP8wT0Z1rcWwkceU+VX2CcgJ qOB21Mu4QsHEgPH8ctS2i+JTTGT3gAwYWdUSw9+v5qKEHmwGEFaXYMTq8 96poaWpCYsK78A4fD0sawsqJ0hqfQnbi6gm/qfpLOB/b6JFW1WHdAoYwH 3ITToZ7+K/EwTO2iON90CkgqJrMN9oxAUVLz/NXy03jWeYcoSKVX0Muul bvFqKjj5BUA6NKlTScmaY+RhuDJHbwfzHMt7cg1jb/MyJTTYiZFokrDKm g==; X-IronPort-AV: E=Sophos;i="5.28,455,1464609600"; d="scan'208";a="100102260" 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; 02 Aug 2016 00:30:58 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0266.001; Tue, 2 Aug 2016 00:30:59 +1200 From: Peter Gutmann To: "denis bider (Bitvise)" , "ietf-ssh@netbsd.org" Subject: RE: rsa-sha2-256/512: handling of incorrect signature encoding Thread-Topic: rsa-sha2-256/512: handling of incorrect signature encoding Thread-Index: AQHR6zsapUTxOkJdokK/AK194oicM6A0Cleb Date: Mon, 1 Aug 2016 12:30:58 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4CDD31B@uxcn10-5.UoA.auckland.ac.nz> References: <1390BBE9B1DA4692BEB23518D00B09FC@Khan> In-Reply-To: <1390BBE9B1DA4692BEB23518D00B09FC@Khan> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.2.5] 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 (Bitvise) writes:=0A= =0A= >The invariants our implementation currently expects are:=0A= >- name 1, in the USERAUTH request, can be any of the RSA signature algorit= hm names=0A= >- name 2, in the public key blob, must be "ssh-rsa"=0A= >- name 3, in the signature blob, must match name 1=0A= =0A= My code writes "ssh-rsa" for all three, and accepts whatever it finds (alon= g=0A= with a sarcastic comment about why you need to specify the same thing three= =0A= times in a row in case the server has gone deaf or something :-). For the= =0A= first one:=0A= =0A= /* Skip the first of the three copies of the algorithm name (see the commen= t=0A= in ssh2_cli.c for more on this). We don't do anything with it because= =0A= we're about to get two more copies of the same thing, and the key and=0A= signature information take precedence over anything that we find here */= =0A= =0A= Then for the second one it looks for ssh-rsa (or ssh-dss, or whatever, sinc= e=0A= it's needed to decode the key), and finally it again ignores the last one= =0A= because it already knows what it should be.=0A= =0A= Why is there a need for "rsa-sha2-256" and other complications when "ssh-rs= a"=0A= is perfectly OK for everything else?=0A= =0A= >My questions are:=0A= >[...]=0A= =0A= I would use (C) ignore everything except the key blob name. This situation= is=0A= confusing enough that you're going to get implementations screwing things u= p=0A= in all sorts of ways, meaning you'll find who knows what in those ID string= s.=0A= Apart from having to know what format the key is in the rest is irrelevant,= =0A= you know the key is RSA, you've been hashing with SHA-1 or SHA-256 or=0A= whatever, it doesn't matter what the ID strings say.=0A= =0A= >Regardless of what we think is best - should we put a paragraph about this= in=0A= >the rsa-sha2 draft?=0A= =0A= I would change the rsa-sha2 draft to say that the same ID string should be= =0A= used throughout, i.e. "ssh-rsa" for RSA sigs and keys.=0A= =0A= Peter.= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Aug 2 21:35:58 2016 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C4612D8EC for ; Tue, 2 Aug 2016 21:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 HQtH3fmfLhSX for ; Tue, 2 Aug 2016 21:35:54 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 5234C12D88F for ; Tue, 2 Aug 2016 21:35:54 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 0813485F1F; Wed, 3 Aug 2016 04:35:54 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id AA4FE85F11; Wed, 3 Aug 2016 04:35:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 045FE85E86 for ; Tue, 2 Aug 2016 09:07:37 +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 ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id Mn065q969iwb for ; Tue, 2 Aug 2016 09:07:36 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (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 6769D84CF0 for ; Tue, 2 Aug 2016 09:07:28 +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=1470128855; x=1501664855; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=vwK4SfJ9gUgJ0wtIKW/TghMHoSNyelJPGVOwDR+UTsE=; b=anjrWPDomZNaoTjw+4qoQSGGF6Ss803dbpY3K0oMp1qgD2/NDyxIz5vT rS7y1r1Dk+gtJGF9lMYmxWXuMLRGplMuzCgjt+YOxWwwyGkPiVNaI17ZH Hiom9X50r6yd5ZZJDsH58pw1JB33UzBxSe0Jum6W65vC4C0s0RLyI7ODN wgsR+jJ0H2jLUku0FbjwveuIWvPFK8+RAc+V1KY8Lt9YQRfvwT7i/vQCZ hHbtdRpYHKdimoeAQB/kfizANWD1mzoJVNg59TCHYuBgzEgoaHXjA9jMu BlsGjp7Uu0eAB5mnHxKSoQV2EfMbZiTGkQsbCDUJ7DbpEtUAkumKPMMVq Q==; X-IronPort-AV: E=Sophos;i="5.28,459,1464609600"; d="scan'208";a="100307252" 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; 02 Aug 2016 21:07:24 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0266.001; Tue, 2 Aug 2016 21:07:24 +1200 From: Peter Gutmann To: "denis bider (Bitvise)" , "ietf-ssh@netbsd.org" Subject: RE: rsa-sha2-256/512: handling of incorrect signature encoding Thread-Topic: rsa-sha2-256/512: handling of incorrect signature encoding Thread-Index: AQHR6zsapUTxOkJdokK/AK194oicM6A0Cleb///M+QCAAYx93g== Date: Tue, 2 Aug 2016 09:07:23 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4CDE02F@uxcn10-5.UoA.auckland.ac.nz> References: <1390BBE9B1DA4692BEB23518D00B09FC@Khan> <9A043F3CF02CD34C8E74AC1594475C73F4CDD31B@uxcn10-5.UoA.auckland.ac.nz>,<80252E4D72004059B23AE81B2256FC9F@Khan> In-Reply-To: <80252E4D72004059B23AE81B2256FC9F@Khan> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.3] 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 (Bitvise) writes:=0A= =0A= >This is actually exactly contrary to what the current draft says, and what= it=0A= >has said for 9 months in its latest version.=0A= >=0A= >If you are sending an rsa-sha2-XXX signature, you cannot set all 3 fields = in=0A= >the authentication request to "ssh-rsa", because then this makes for a SHA= -1=0A= >signature as it was done traditionally, not a SHA-2 signature. To send a= =0A= >SHA-2 signature, at least one field has to contain "rsa-sha2-XXX".=0A= =0A= I've looked through my code and saw why it works currently, I assume that i= f=0A= you've negotiated SHA-256 in the client/server hello (keyex) then the auth= =0A= will also use SHA-256 (it would seem a bit strange to use a strong hash=0A= everywhere else in the exchange and then fall back to a weak one for the=0A= auth). So in my case unless you use SHA-256 everywhere but then decide to = use=0A= SHA-1 in the auth, things will work.=0A= =0A= >The draft specifically says the signature format names are "rsa-sha2-XXX",= =0A= >but the public key format name stays "ssh-rsa", which it must stay in orde= r=0A= >to preserve existing RSA key fingerprints.=0A= =0A= Yeah, so my code does use "rsa-sha2-256" after all for the auth and sig typ= e,=0A= it just wasn't obvious at first glance because the hash is implied. I've m= ade=0A= the one-line change to allow use of SHA-256 everywhere but then SHA-1 for t= he=0A= auth.=0A= =0A= >My strong preference would have been for implementations - especially the= =0A= >early implementations - to verify this strictly, and to not accept signatu= res=0A= >that depart from this spec. =0A= =0A= What we actually need is interop test servers, with everyone doing this mor= e=0A= or less in isolation (there was nothing to test against when I did this, an= d=0A= for the ECC stuff it wasn't much better, was it you that set up an SSH-ECC= =0A= server for testing when the draft was published?) you end up with=0A= implementations that do all sorts of things.=0A= =0A= >Unfortunately, we now appear to be in a situation where not only one, but= =0A= >potentially two implementations depart from the above spec. =0A= =0A= Make it one again, it did use the correct string, it was only the mix of=0A= SHA-256 + SHA-1 at the same time that would have caused problems.=0A= =0A= Peter.= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Aug 3 11:29:51 2016 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF00A12D0FF for ; Wed, 3 Aug 2016 11:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 K7fiRZaa1lAZ for ; Wed, 3 Aug 2016 11:29:49 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 35F1712D0B4 for ; Wed, 3 Aug 2016 11:29:49 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 96AA585E91; Wed, 3 Aug 2016 18:29:41 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 4282384CF0; Wed, 3 Aug 2016 18:29:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 64C4685E3F for ; Wed, 3 Aug 2016 10:49:29 +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 ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id Q7Pcqivk4vjt for ; Wed, 3 Aug 2016 10:49:28 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (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 2559985E1A for ; Wed, 3 Aug 2016 10:49:21 +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=1470221368; x=1501757368; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Y1is5j+DtrNn/b/U0wK4MMUIlZpXRYS5n2LvgeS7AuM=; b=n9U5rxRVVe1YSFcZqN6xx+TE4bAGyvB0o3oiYZuF/I+VveCz7PatcEHp Hrmr1y2dl1wT5SIY/f9FbjmQtM+DcOBMnVey1x+mjacPdDMj8DqproV/Q z+MllFPfUDKKp7GOz/37sonB1G0qR9CbmOuVzrMEicqdAsyqXOW9kSpHm MkwpMVp2ypSjYdkJBuNEoq2eR4qKIyy3DzpXa+jq+3blKUN7D7zFnnkcF kuYevCltKeNTKyBHChAUTUiSzLP5LuFNKQKYC2ocQvfOSRWSVukq2QqLE i0szX0oxfHvCeWW+DfqXUQlr4V3fPL4L3gRzikDz1289vci3x/NgR8k13 w==; X-IronPort-AV: E=Sophos;i="5.28,465,1464609600"; d="scan'208";a="100536206" 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; 03 Aug 2016 22:49:19 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0266.001; Wed, 3 Aug 2016 22:49:18 +1200 From: Peter Gutmann To: "denis bider (Bitvise)" , "ietf-ssh@netbsd.org" Subject: RE: rsa-sha2-256/512: handling of incorrect signature encoding Thread-Topic: rsa-sha2-256/512: handling of incorrect signature encoding Thread-Index: AQHR6zsapUTxOkJdokK/AK194oicM6A0Cleb///M+QCAAYx93v//7AGAgAHDAGc= Date: Wed, 3 Aug 2016 10:49:17 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4CDEE4D@uxcn10-5.UoA.auckland.ac.nz> References: <1390BBE9B1DA4692BEB23518D00B09FC@Khan> <9A043F3CF02CD34C8E74AC1594475C73F4CDD31B@uxcn10-5.UoA.auckland.ac.nz>,<80252E4D72004059B23AE81B2256FC9F@Khan> <9A043F3CF02CD34C8E74AC1594475C73F4CDE02F@uxcn10-5.UoA.auckland.ac.nz>,<7C3A4D37CD484763BA5496F0B08DEE26@Khan> In-Reply-To: <7C3A4D37CD484763BA5496F0B08DEE26@Khan> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.2.2] Content-Type: text/plain; charset="Windows-1252" 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 (Bitvise) writes:=0A= =0A= >I did set up a test server for the new rsa-sha2-XXX signature types; I pos= ted=0A= >connection information here, and included instructions to test both server= and=0A= >client authentication. I was under the impression that you might have used= it,=0A= >but I=92m not sure if you did.=0A= =0A= I did, but not for pubkey auth, for lack of a key to auth with.=0A= =0A= Is it worth stating, in the draft, that if you use sha256 everywhere else t= hen=0A= you should also use it for pubkey auth? I can't see any reason why you'd w= ant=0A= to use SHA-1 for that when you're using SHA-2 for everything else. Then yo= u=0A= could also use the server's advertising SHA-2 to indicate that it'll take a= =0A= SHA-2 sig for auth.=0A= =0A= Peter.= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Aug 3 22:19:23 2016 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA92212B060 for ; Wed, 3 Aug 2016 22:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.486 X-Spam-Level: X-Spam-Status: No, score=-5.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmPgxHD2UHP4 for ; Wed, 3 Aug 2016 22:19:21 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 BCCFB12B012 for ; Wed, 3 Aug 2016 22:19:21 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 1B53F85F8F; Thu, 4 Aug 2016 05:19:04 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id C6BF685E8B; Thu, 4 Aug 2016 05:19:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 89AA284C8B for ; Wed, 3 Aug 2016 20:10:51 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id bUXuquGMZ5ib for ; Wed, 3 Aug 2016 20:10: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 E8BD584C6C for ; Wed, 3 Aug 2016 20:10:50 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Wed, 3 Aug 2016 21:10:33 +0100 Message-ID: <068FF1E49944414296AEDD6992BC1776@Khan> From: "denis bider \(Bitvise\)" To: "Peter Gutmann" , References: <1390BBE9B1DA4692BEB23518D00B09FC@Khan> <9A043F3CF02CD34C8E74AC1594475C73F4CDD31B@uxcn10-5.UoA.auckland.ac.nz>,<80252E4D72004059B23AE81B2256FC9F@Khan> <9A043F3CF02CD34C8E74AC1594475C73F4CDE02F@uxcn10-5.UoA.auckland.ac.nz>,<7C3A4D37CD484763BA5496F0B08DEE26@Khan> <9A043F3CF02CD34C8E74AC1594475C73F4CDEE4D@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4CDEE4D@uxcn10-5.UoA.auckland.ac.nz> Subject: Re: rsa-sha2-256/512: handling of incorrect signature encoding Date: Wed, 3 Aug 2016 14:10:10 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0142_01D1ED90.BEB9DBA0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0142_01D1ED90.BEB9DBA0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable What type of =93advertising SHA-2=94 do you mean? If the server = advertises rsa-sha2-256 or -512 for server authentication, then it also = needs to have an RSA host key. But the server might not have an RSA host = key, it might only have an ECDSA or Curve25519 host key. However, the = server still wants to permit a client to configure an RSA key for user = authentication, and to use SHA-2 signatures for this. In this situation, the server cannot advertise an rsa-sha2-XXX algorithm = for host authentication. The mechanism for the server to announce = support for SHA-2 signatures in client authentication is using the = EXT_INFO message, specifically the =93server-sig-algs=94 extension = described here: https://tools.ietf.org/html/draft-ietf-curdle-ssh-ext-info-00 If the server sends an EXT_INFO message with the =93server-sig-algs=94 = extension indicating support for rsa-sha2-256 or rsa-sha2-512, then the = client can assume the server will accept an RSA SHA-2 signature during = user authentication. However, such a signature still has to be correctly = encoded (with the algorithm names as discussed in this thread). From: Peter Gutmann=20 Sent: Wednesday, August 3, 2016 04:49 To: denis bider (Bitvise) ; ietf-ssh@netbsd.org=20 Subject: RE: rsa-sha2-256/512: handling of incorrect signature encoding denis bider (Bitvise) writes: >I did set up a test server for the new rsa-sha2-XXX signature types; I = posted >connection information here, and included instructions to test both = server and >client authentication. I was under the impression that you might have = used it, >but I=92m not sure if you did. I did, but not for pubkey auth, for lack of a key to auth with. Is it worth stating, in the draft, that if you use sha256 everywhere = else then you should also use it for pubkey auth? I can't see any reason why = you'd want to use SHA-1 for that when you're using SHA-2 for everything else. Then = you could also use the server's advertising SHA-2 to indicate that it'll = take a SHA-2 sig for auth. Peter. ------=_NextPart_000_0142_01D1ED90.BEB9DBA0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
What type of =93advertising SHA-2=94 do you mean? If the server = advertises=20 rsa-sha2-256 or -512 for server authentication, then it also needs to = have an=20 RSA host key. But the server might not have an RSA host key, it might = only have=20 an ECDSA or Curve25519 host key. However, the server still wants to = permit a=20 client to configure an RSA key for user authentication, and to use SHA-2 = signatures for this.
 
In this situation, the server cannot advertise an rsa-sha2-XXX = algorithm=20 for host authentication. The mechanism for the server to announce = support for=20 SHA-2 signatures in client authentication is using the EXT_INFO message, = specifically the =93server-sig-algs=94 extension described here:
 
 
If the server sends an EXT_INFO message with the = =93server-sig-algs=94=20 extension indicating support for rsa-sha2-256 or rsa-sha2-512, then the = client=20 can assume the server will accept an RSA SHA-2 signature during user=20 authentication. However, such a signature still has to be correctly = encoded=20 (with the algorithm names as discussed in this thread).
 
 
Sent: Wednesday, August 3, 2016 04:49
To: denis bider (Bitvise) ; ietf-ssh@netbsd.org
Subject: RE: rsa-sha2-256/512: handling of incorrect = signature=20 encoding
 
denis=20 bider (Bitvise) <ietf-ssh3@denisbider.com> writes:

>I = did set up=20 a test server for the new rsa-sha2-XXX signature types; I=20 posted
>connection information here, and included instructions to = test=20 both server and
>client authentication. I was under the impression = that=20 you might have used it,
>but I=92m not sure if you did.

I = did, but=20 not for pubkey auth, for lack of a key to auth with.

Is it worth = stating,=20 in the draft, that if you use sha256 everywhere else then
you should = also use=20 it for pubkey auth?  I can't see any reason why you'd want
to = use SHA-1=20 for that when you're using SHA-2 for everything else.  Then = you
could=20 also use the server's advertising SHA-2 to indicate that it'll take = a
SHA-2=20 sig for auth.

Peter.
------=_NextPart_000_0142_01D1ED90.BEB9DBA0-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Aug 3 22:19:51 2016 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1BC12B060 for ; Wed, 3 Aug 2016 22:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 8khVJsJsXZW0 for ; Wed, 3 Aug 2016 22:19:47 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 9D71612B012 for ; Wed, 3 Aug 2016 22:19:47 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 3480F85F97; Thu, 4 Aug 2016 05:19:46 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id D609F85F94; Thu, 4 Aug 2016 05:19:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 4C1F385E27 for ; Thu, 4 Aug 2016 04:04:26 +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 ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id AN93KT_JtSSd for ; Thu, 4 Aug 2016 04:04:25 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (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 DB39E84CE5 for ; Thu, 4 Aug 2016 04:04:20 +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=1470283465; x=1501819465; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=LxpyijBRzzw2HzMhyxLU/sS3hYVzWhx01/9n7Et5jfo=; b=GC8q3iql791NaF7OCpIJyrclMOtZrjT04/FsfVtnJC1sZlQ7/3LbmmuG kwBkbbqnaMm73NRmgja47eXQu9wl3KCbcachSlk43cv3JVVYxTNJ9BdlM ILwunz6oaQ+Z/DkNlmht82uK5ps4AdMHdskUr49MEIgx9DwtZG0Qne6bI QntaHCg2DIp77ZHtz1qeoGMR6sA8kiw212mqXEsUK8Q3vEit9CbUT56Ky ZSO9bw02fMdFf9IE1TJYpskSUGFNqPMHJV0RBEe0P5SFk+LhLo41GXmpx cKKaPTkYpca3Y66wSIRb8T32+OmoVr0lRkyG73C9fXmrzJu3rDaOcPrmJ g==; X-IronPort-AV: E=Sophos;i="5.28,469,1464609600"; d="scan'208";a="100695825" 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/DHE-RSA-AES256-SHA; 04 Aug 2016 16:04:16 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0266.001; Thu, 4 Aug 2016 16:04:16 +1200 From: Peter Gutmann To: "denis bider (Bitvise)" , "ietf-ssh@netbsd.org" Subject: RE: rsa-sha2-256/512: handling of incorrect signature encoding Thread-Topic: rsa-sha2-256/512: handling of incorrect signature encoding Thread-Index: AQHR6zsapUTxOkJdokK/AK194oicM6A0Cleb///M+QCAAYx93v//7AGAgAHDAGf//9OjAAApsMyH Date: Thu, 4 Aug 2016 04:04:16 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4CDF9D6@uxcn10-5.UoA.auckland.ac.nz> References: <1390BBE9B1DA4692BEB23518D00B09FC@Khan> <9A043F3CF02CD34C8E74AC1594475C73F4CDD31B@uxcn10-5.UoA.auckland.ac.nz>,<80252E4D72004059B23AE81B2256FC9F@Khan> <9A043F3CF02CD34C8E74AC1594475C73F4CDE02F@uxcn10-5.UoA.auckland.ac.nz>,<7C3A4D37CD484763BA5496F0B08DEE26@Khan> <9A043F3CF02CD34C8E74AC1594475C73F4CDEE4D@uxcn10-5.UoA.auckland.ac.nz>,<068FF1E49944414296AEDD6992BC1776@Khan> In-Reply-To: <068FF1E49944414296AEDD6992BC1776@Khan> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.2.4] Content-Type: text/plain; charset="Windows-1252" 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 (Bitvise) writes:=0A= =0A= >What type of =93advertising SHA-2=94 do you mean? If the server advertises= rsa-=0A= >sha2-256 or -512 for server authentication, then it also needs to have an = RSA=0A= >host key. But the server might not have an RSA host key, it might only hav= e=0A= >an ECDSA or Curve25519 host key. =0A= =0A= I was thinking of it in an opportunistic-upgrade sense, for example for PGP= =0A= and S/MIME the mandatory algorithm is SHA-1 but if you receive a message=0A= signed with SHA-2 you can switch to that because the client will be able to= =0A= process it. So if you see ecdsa-sha2... or rsa-sha2... in the keyex then y= ou=0A= know the other side can do SHA2, and should do the auth with SHA2 as well.= =0A= =0A= >In this situation, the server cannot advertise an rsa-sha2-XXX algorithm f= or=0A= >host authentication. =0A= =0A= It's not so much can it do RSA-SHA2, but can it do SHA2 in general rather t= han=0A= SHA1.=0A= =0A= Peter.=0A= =0A= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Aug 4 05:26:53 2016 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0708812DA2F for ; Thu, 4 Aug 2016 05:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.587 X-Spam-Level: X-Spam-Status: No, score=-5.587 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ucc.asn.au header.b=nqn/kScH; dkim=pass (1024-bit key) header.d=ucc.asn.au header.b=aqgQ+jme 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 0IKWpPl063od for ; Thu, 4 Aug 2016 05:26:51 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (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 CF9CA12DA29 for ; Thu, 4 Aug 2016 05:23:25 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id EB0BA84CED; Thu, 4 Aug 2016 12:23: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 4B96784CE9 for ; Thu, 4 Aug 2016 12:23:23 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (1024-bit key) header.d=ucc.asn.au header.b=nqn/kScH; dkim=pass (1024-bit key) header.d=ucc.asn.au header.b=aqgQ+jme 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 pmR5HX4Pvs5z for ; Thu, 4 Aug 2016 12:23:22 +0000 (UTC) Received: from mail-ext-sout1.uwa.edu.au (mail-ext-sout1.uwa.edu.au [130.95.128.72]) (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 A14E984C8B for ; Thu, 4 Aug 2016 12:23:20 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2CoBAA2HaNX/8+AX4JdDoUJux2GHQKCD?= =?us-ascii?q?REBAQEBAQEBXSeEXwEFOgYBATcBDwsOCgklDwUYMYhErieFKgEBBYssAQEBAQE?= =?us-ascii?q?FAQEBAQEaCIQfhliKG48QiimOdnFujWuMMIN3NCCDP0hhiCUBAQE?= X-IPAS-Result: =?us-ascii?q?A2CoBAA2HaNX/8+AX4JdDoUJux2GHQKCDREBAQEBAQEBXSe?= =?us-ascii?q?EXwEFOgYBATcBDwsOCgklDwUYMYhErieFKgEBBYssAQEBAQEFAQEBAQEaCIQfh?= =?us-ascii?q?liKG48QiimOdnFujWuMMIN3NCCDP0hhiCUBAQE?= X-IronPort-AV: E=Sophos;i="5.28,470,1464624000"; d="scan'208";a="231224375" Received: from f5-new.net.uwa.edu.au (HELO mooneye.ucc.gu.uwa.edu.au) ([130.95.128.207]) by mail-ext-out1.uwa.edu.au with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Aug 2016 18:51:05 +0800 Received: by mooneye.ucc.gu.uwa.edu.au (Postfix, from userid 801) id 5F8EA3D189; Thu, 4 Aug 2016 18:50:50 +0800 (AWST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ucc.asn.au; s=ucc-2016-3; t=1470307850; bh=fheBf0zjfnplz4hzyDhJwSpitneyF8bzPArg3n4+mQE=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=nqn/kScH01ioV78iCiDdWX16vMNXy8iowO2StEmDKSMAlp57BOco7woW3sGxQrKw0 4DHthmkpFjpOMDT/2RhUXUTKRQkIJvvSwqw/bhTwK3FIc2AlyAW5lrN+qioJfuLj20 fKKR3KLHpOD4qLt44YxXGnRq5BFEToNMpVDy1jDY= 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 EAE723D170; Thu, 4 Aug 2016 18:50:49 +0800 (AWST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ucc.asn.au; s=ucc-2016-3; t=1470307849; bh=fheBf0zjfnplz4hzyDhJwSpitneyF8bzPArg3n4+mQE=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=aqgQ+jmetOHySewDtJI9SISUW72iBz8BSBJCvcjEelwaeAOmEmPPGJdJcieuQJIRj XJJaSfHvWP8pfo5EWkcMHH3H4T0eCx+Hkh0pYDCfX7hzGjQymw6JkQV+7DWpl2cH1S aQQWnuA9m9fMZaa4oeoaiXBlzzT7QR8ruvHSTECs= Received: by motsugo.ucc.gu.uwa.edu.au (Postfix, from userid 11154) id 6F1282003D; Thu, 4 Aug 2016 18:51:04 +0800 (AWST) Date: Thu, 4 Aug 2016 18:51:04 +0800 From: Matt Johnston To: Peter Gutmann Cc: "denis bider (Bitvise)" , "ietf-ssh@netbsd.org" Subject: Re: rsa-sha2-256/512: handling of incorrect signature encoding Message-ID: <20160804105104.GK23300@ucc.gu.uwa.edu.au> Mail-Followup-To: Peter Gutmann , "denis bider (Bitvise)" , "ietf-ssh@netbsd.org" References: <1390BBE9B1DA4692BEB23518D00B09FC@Khan> <9A043F3CF02CD34C8E74AC1594475C73F4CDD31B@uxcn10-5.UoA.auckland.ac.nz> <80252E4D72004059B23AE81B2256FC9F@Khan> <9A043F3CF02CD34C8E74AC1594475C73F4CDE02F@uxcn10-5.UoA.auckland.ac.nz> <7C3A4D37CD484763BA5496F0B08DEE26@Khan> <9A043F3CF02CD34C8E74AC1594475C73F4CDEE4D@uxcn10-5.UoA.auckland.ac.nz> <068FF1E49944414296AEDD6992BC1776@Khan> <9A043F3CF02CD34C8E74AC1594475C73F4CDF9D6@uxcn10-5.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4CDF9D6@uxcn10-5.UoA.auckland.ac.nz> X-snowman: =?utf-8?Q?=E2=98=83_9noFOT86bj41jGYaOfj6VR?= =?utf-8?Q?1Xw7KsJesXWH7CaPB83yYQKhlY4VNIOkLd?= User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Thu, Aug 04, 2016 at 04:04:16AM +0000, Peter Gutmann wrote: > I was thinking of it in an opportunistic-upgrade sense, for example for PGP > and S/MIME the mandatory algorithm is SHA-1 but if you receive a message > signed with SHA-2 you can switch to that because the client will be able to > process it. So if you see ecdsa-sha2... or rsa-sha2... in the keyex then you The pubkey signature could have come from a ssh-agent (only supporting rsa-sha1) that's elsewhere to the SSH client. Cheers, Matt From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Aug 16 03:36:56 2016 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24C3512D685 for ; Tue, 16 Aug 2016 03:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 xv5aKMC60M4L for ; Tue, 16 Aug 2016 03:36:51 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 6346E12D73D for ; Tue, 16 Aug 2016 03:36:51 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 63A2F85FF8; Tue, 16 Aug 2016 10:36: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 C8EEF85FF4 for ; Tue, 16 Aug 2016 10:36:46 +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 TEOgHsHKHneh for ; Tue, 16 Aug 2016 10:36:46 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (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 670ED84CED for ; Tue, 16 Aug 2016 10:36:41 +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=1471343805; x=1502879805; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=h3V5fqjy/lYA4Ez/w34s805Ik5R7fTThwMT7mDp9ny8=; b=hUWUCtTg/f6S3rusrZuuTmVnzTXaFgUM+2wGClCZPz1lq9N+qxFuSM2t h0UeGpxHWnIYVHr5n3Fztc4AxQ9fKC6LQkXJlNM96SIUaqpAP3x77lZ1u wlCin+/N5rsKKLB0xT9XLBp55u4igBCKqU1y1BumSbhlcqFRliwS/b0Rr HCiksCAHdi/f32gdXcaggpqjSPARm1KR/XGhMYQ+I2hUtx10AvTMG9PRC /oTWajbfeKDWTfyc75MuWOgefFsV0GaseFTWi+yrmN1OGFE5r4GB5LANv JVbqLFCkBJxNObSymiMjLLamKHHkBjVnhLnq11BJhAGyjphLknKYwXaWU g==; X-IronPort-AV: E=Sophos;i="5.28,529,1464609600"; d="scan'208";a="102382911" 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; 16 Aug 2016 22:36:38 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0266.001; Tue, 16 Aug 2016 22:36:38 +1200 From: Peter Gutmann To: "ietf-ssh3@denisbider.com" , "ietf-ssh@netbsd.org" Subject: Questions about draft-ietf-curdle-ssh-ext-info-00.txt Thread-Topic: Questions about draft-ietf-curdle-ssh-ext-info-00.txt Thread-Index: AdH3qhFFiVBC/v1jTQaWzVdr77rf4w== Date: Tue, 16 Aug 2016 10:36:37 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4CF007D@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.2] 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 I've been looking at this draft and have a few questions...=0A= =0A= Section 2.3, "can send the the following message":=0A= =0A= MAY? MUST? SHOULD?=0A= =0A= Section 2.3, "This message is sent without delay, and immediately after=0A= SSH_MSG_NEWKEYS":=0A= =0A= Uhh, shouldn't it wait for the NEWKEYS to succeed? Otherwise if something = goes=0A= wrong the sender has leaked the info that it's withheld until now because i= t's=0A= apparently sensitive.=0A= =0A= Section 2.4, "the server MAY send, but is not obligated to send, an=0A= SSH_MSG_EXT_INFO message immediately before SSH_MSG_USERAUTH_SUCCESS":=0A= =0A= Before, not after? That's going to lead to a pretty strange message flow, = the=0A= client sends a SSH_MSG_USERAUTH_REQUEST and instead of the expected=0A= SSH_MSG_USERAUTH_SUCCESS/SSH_MSG_USERAUTH_FAILURE it gets some random messa= ge=0A= about extensions. Why not require that the extensions be sent after=0A= failure/success has been indicated?=0A= =0A= Section 2.4, "If a server sends a subsequent SSH_MSG_EXT_INFO, this replace= s=0A= any initial one, and both the client and the server re-evaluate extensions = in=0A= effect":=0A= =0A= This is just asking for trouble, you're requiring both sides to be able to= =0A= sort out and disambiguate conflicting extensions in a compatible manner.=0A= =0A= Section 3.4, "elevation":=0A= =0A= What does this extension do? I was expecting an option of which floor you= =0A= want to get off on, with a negative value for the parking garage.=0A= =0A= Peter.= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Aug 17 04:41:00 2016 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC91A12D727 for ; Wed, 17 Aug 2016 04:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 jR91QoAwfPmp for ; Wed, 17 Aug 2016 04:40:58 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (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 E2F0312D980 for ; Wed, 17 Aug 2016 04:26:44 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 0564485FB5; Wed, 17 Aug 2016 11:26:42 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id A818B85E8D for ; Wed, 17 Aug 2016 11:26: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 ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id uI8II0rB_XBX for ; Wed, 17 Aug 2016 11:26:39 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (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 40E8785E22 for ; Wed, 17 Aug 2016 11:26: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=1471433198; x=1502969198; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3T56dL9Ot5Q51lMsS6jfOarnPDPuBPS7nAX+ma/J8m8=; b=QCeH3GsCbqXURg1pt0MDh27G1mBL0iYlwpjh5V3LkRPQnO5sGOZYsJLa sOzRYspYYbevnzBB+XElsF6bWIEa6Kf8kYup38VgYTb2rd9LnOysuzGs6 2MptM5SCdzPY+e/Kr6rdRnsuQ6o0ogsbUkvy/blIAEeNG8duT8Euu8kR/ rMRN04V9CH10pZnfOys9Ct95948GoKgH8RrEuI9OeV/5vsa8E0Xyp73vl XOpoq6HD6GOknmNvpw+kss8K1DyDypO/gT1NoawHfvDPZPaXSlFAz4wfk dfgN8sgVIq+avS9grdW6bJTttIfK9yNlJteqrm54UnIop0rAM0LlfyKpX Q==; X-IronPort-AV: E=Sophos;i="5.28,529,1464609600"; d="scan'208";a="102529826" 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; 17 Aug 2016 23:26:29 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0266.001; Wed, 17 Aug 2016 23:26:29 +1200 From: Peter Gutmann To: "denis bider (Bitvise)" , Curdle CC: "djm@mindrot.org" , "ietf-ssh@netbsd.org" , "Mark D. Baushke" Subject: RE: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 Thread-Topic: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 Thread-Index: AQHR+APyc5WGhg2eHE6rWz5EA7SZMqBNBCC2 Date: Wed, 17 Aug 2016 11:26:28 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4CF1A96@uxcn10-5.UoA.auckland.ac.nz> References: <71963A21726946C3B16A0B77F0CFF3F6@Khan> In-Reply-To: <71963A21726946C3B16A0B77F0CFF3F6@Khan> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.2.5] 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 (Bitvise) writes:=0A= =0A= >this comment is with respect to the following draft specifying new Diffie-= =0A= >Hellman groups for SSH key exchange:=0A= =0A= A further comment on the draft:=0A= =0A= The United States Information Assurance Directorate (IAD) at the=0A= National Security Agency (NSA) has published a FAQ=0A= [MFQ-U-OO-815099-15] suggesting that the use of Elliptic Curve=0A= Diffie-Hellman (ECDH) using the nistp256 curve and SHA-2 based hashes=0A= less than SHA2-384 are no longer sufficient for transport of Top=0A= Secret information. It is for this reason that this draft moves=0A= ecdh-sha2-nistp256 from a REQUIRED to OPTIONAL as a key exchange=0A= method. =0A= =0A= So you've got an arbitrary ruling by some random US govt. agency that's=0A= dictating how the entire world's SSH implementations have to function (sigh= ).=0A= We know from global TLS scans that pretty much the entire planet uses SHA-2= 56,=0A= with SHA-384 and SHA-512 essentially lost in the noise. However, this spec= is=0A= making the universal worldwide standard a MAY and the least-used form of th= e=0A= entire SHA-2 family a MUST. If the NSA's IAD wants to use whatever weird= =0A= config they decide on they can create their own spec (Suite B, anyone?), bu= t a=0A= global standard should go with whatever the world as a whole has decided on= ,=0A= and that's overwhelmingly SHA-256.=0A= =0A= Peter.= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Aug 17 09:34:40 2016 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 073DD12D85D for ; Wed, 17 Aug 2016 09:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.547 X-Spam-Level: X-Spam-Status: No, score=-5.547 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbVQDTBmvTiQ for ; Wed, 17 Aug 2016 09:34:39 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 037FA12D858 for ; Wed, 17 Aug 2016 09:34:39 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id C153C8606F; Wed, 17 Aug 2016 16:34:37 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 6A4888604E; Wed, 17 Aug 2016 16:34:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 7D05585EA6 for ; Wed, 17 Aug 2016 12:55:02 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id F2FBs-rXrSDW for ; Wed, 17 Aug 2016 12:55:02 +0000 (UTC) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by mail.netbsd.org (Postfix) with ESMTP id DD0F085E27 for ; Wed, 17 Aug 2016 12:55:01 +0000 (UTC) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B83A04EF32; Wed, 17 Aug 2016 11:45:15 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 9B8194D23A; Wed, 17 Aug 2016 11:45:15 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1471434315; bh=IxWCKgItFrzp302hnvledKK0WD2Nj6GdKdJR+UPOkdA=; l=212; h=From:To:CC:Date:References:In-Reply-To:From; b=ocEFh5k+w49jq/E65yTxewPHRWcHoGk/h2Q4SJ+Xh8EE/6jL6hGodnqOn4vR/MuEl yQvgR/yQ7M4rP/Bg1Jz7gkJfu0ifpG+7uv0ZhYqYNoYzlBIEGErbloTw/ugNP7grSD 8UuWfCo2XLGQwg7IojOGJmfx4CtKP1WZj3fJIUcw= Received: from email.msg.corp.akamai.com (usma1ex-casadmn.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 90F241FC88; Wed, 17 Aug 2016 11:45:15 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 17 Aug 2016 07:45:15 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Wed, 17 Aug 2016 07:45:15 -0400 From: "Salz, Rich" To: Peter Gutmann , "denis bider (Bitvise)" , Curdle CC: "djm@mindrot.org" , "ietf-ssh@netbsd.org" , "Mark D. Baushke" Subject: RE: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 Thread-Topic: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 Thread-Index: AQHR+APwaEfWkeGPWkyjpB63havJEqBNR2oA///BzAA= Date: Wed, 17 Aug 2016 11:45:14 +0000 Message-ID: References: <71963A21726946C3B16A0B77F0CFF3F6@Khan> <9A043F3CF02CD34C8E74AC1594475C73F4CF1A96@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4CF1A96@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.58] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Speaking as an individual, I strongly agree with Peter; SHA256 should be MU= ST and any other variant should be a MAY. -- =20 Senior Architect, Akamai Technologies IM: richsalz@jabber.at Twitter: RichSalz From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Aug 17 09:35:43 2016 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF6312DAF1 for ; Wed, 17 Aug 2016 09:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.336 X-Spam-Level: X-Spam-Status: No, score=-5.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" header.d=denisbider.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1yN8Ykiotdi for ; Wed, 17 Aug 2016 09:35:41 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (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 BAFF512DA89 for ; Wed, 17 Aug 2016 09:35:41 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 4FAAA8606E; Wed, 17 Aug 2016 16:35:41 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 012718604E; Wed, 17 Aug 2016 16:35:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 5278985E54 for ; Tue, 16 Aug 2016 20:18: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=denisbider.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 nUO_av7qdv8j for ; Tue, 16 Aug 2016 20:18:54 +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 2975185E27 for ; Tue, 16 Aug 2016 20:18:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=denisbider.com; s=mail; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to: references; bh=i8mDDcBoLzoRwJDM1RskTvV0hKnjdL+3udSmhPyfgd8=; b=MZTiGIqIuw1KvmuCS3F+Tr7K0PAk6do7YrDMYk4eJPcpdwXyMhHfGDmWDrhrCt/iKbQPIu7zzz+wF 3oo0MLLYtfX8ZdtppJ5CoH9AwQIE3MHT8tv61oKW6YnzGK+HQK5/kYoGqmt7Pj1/shfTsh1mOGiO6z PKWgasy3gyj6mDnD3CWWO3M4NKeXHxPUAvEbN6l4xpYNQHcUsMT+pp2RxO2SYJv/A+0Iw0Y7OodR53 jVOPQtECggsu/EhmAjS1ewaOTSSIdV5fm9/oRpbPS8RSKnzFm0G/WEGK4yeJEPvLHVUyrOps+XApLY FdempdxrsMTzPDbJ/1onimMY2JHxEKQ== X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Tue, 16 Aug 2016 21:18:38 +0100 Message-ID: <11B894DDA9DC48DDB9ABA4B509946B4D@Khan> From: "denis bider \(Bitvise\)" To: "Peter Gutmann" , Cc: "Curdle" References: <9A043F3CF02CD34C8E74AC1594475C73F4CF007D@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4CF007D@uxcn10-5.UoA.auckland.ac.nz> Subject: Re: Questions about draft-ietf-curdle-ssh-ext-info-00.txt Date: Tue, 16 Aug 2016 14:18:09 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0215_01D1F7C9.03F1F210" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0215_01D1F7C9.03F1F210 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Peter, > Section 2.3, "can send the the following message": > MAY? MUST? SHOULD? thanks. I changed this in the working version of the draft to MAY. > Section 2.3, "This message is sent without delay,=20 > and immediately after SSH_MSG_NEWKEYS": > > Uhh, shouldn't it wait for the NEWKEYS to succeed? > Otherwise if something goes wrong the sender has > leaked the info that it's withheld until now because > it's apparently sensitive. In the direction from client to server, the client's sending of NEWKEYS = indicates the server's authenticity has already been verified, so there = is no issue. In the direction from server to client, any information that's actually = sensitive would be postponed until the second EXT_INFO message sent when = user authentication is successful. There seems to be little value in = mounting an attack to discover the contents of EXT_INFO sent before user = authentication, when you can just connect to the SSH server without = intent to authenticate, and get the information that way after a normal = completed key exchange. > Section 2.4, "the server MAY send, but is not obligated > to send, an SSH_MSG_EXT_INFO message immediately before > SSH_MSG_USERAUTH_SUCCESS": > > Before, not after? Yes, before. Otherwise you get a race condition because the client may = want to take different actions after authentication success depending on = whether it receives certain information in this second EXT_INFO, or not. If the message could be sent after USERAUTH_SUCCESS, but might not be = sent by the server, then the client has no idea whether it should wait = for the server to send this message or not, or how long to wait. Given that the message is optional - which I think is a good choice, and = cannot be changed now anyway because the protocol extension is already = deployed to a significant extent - any second EXT_INFO sent by the = server must be sent *before* SSH_MSG_USERAUTH_SUCCESS. > That's going to lead to a pretty strange message flow, the > client sends a SSH_MSG_USERAUTH_REQUEST and instead of the > expected SSH_MSG_USERAUTH_SUCCESS/SSH_MSG_USERAUTH_FAILURE > it gets some random message about extensions. The EXT_INFO message is not random when received in this context. The = client has signaled it is willing to receive it, which includes the = requirement and ability to receive it in this context, also. Note that the specification requires the server to send no more than one = or two EXT_INFO messages at the times specified, but the client = implementation for handling the second EXT_INFO does not have to enforce = that it is followed by USERAUTH_SUCCESS. If it is simpler for the client = to simply accept and normally handle any additional EXT_INFO messages = received before USERAUTH_SUCCESS, the client can do so without = necessarily needing to enforce the number of these additional messages, = or that a USERAUTH_SUCCESS message immediately follows. This can be done = easily at the same layer that handles the initial EXT_INFO message. = Since the server is already authenticated by the client, I don't see = risks from allowing this leeway. > Section 2.4, "If a server sends a subsequent > SSH_MSG_EXT_INFO, this replaces any initial one, and both > the client and the server re-evaluate extensions in effect": > > This is just asking for trouble, you're requiring both sides > to be able to sort out and disambiguate conflicting > extensions in a compatible manner. If a server implements one or more extensions that require the sending = of a second EXT_INFO, it may check the EXT_INFO received from the client = to see if the client indicates support for any of those extensions. If = it does not, the server does not need to send the second EXT_INFO, and = there are no conflicts. But if the client indicates support for such = extensions, implementations of such extensions will be able to agree on = proper behavior at that time. The current widely used extension, server-sig-algs, does not have much = continued relevance after user authentication is successful, and so does = not suffer from extensions being re-evaluated due to a second EXT_INFO. If you have a suggestion for wording to be inserted that would reduce = the chances of compatibility issues due to the second EXT_INFO, please = let me know. From my perspective, the current spec seems clear ("a = subsequent SSH_MSG_EXT_INFO [...] replaces any initial one", "the client = and the server re-evaluate extensions in effect"). But if there's a way = we can further clarify this, I'm open to suggestions. > Section 3.4, "elevation": > > What does this extension do? I was expecting an option of > which floor you want to get off on, with a negative value > for the parking garage. Point taken. I have modified the working version of the draft to insert = the words "(as used by Windows)" in the description of this extension. denis From: Peter Gutmann=20 Sent: Tuesday, August 16, 2016 04:36 To: ietf-ssh3@denisbider.com ; ietf-ssh@netbsd.org=20 Subject: Questions about draft-ietf-curdle-ssh-ext-info-00.txt I've been looking at this draft and have a few questions... Section 2.3, "can send the the following message": MAY? MUST? SHOULD? Section 2.3, "This message is sent without delay, and immediately after SSH_MSG_NEWKEYS": Uhh, shouldn't it wait for the NEWKEYS to succeed? Otherwise if = something goes wrong the sender has leaked the info that it's withheld until now = because it's apparently sensitive. Section 2.4, "the server MAY send, but is not obligated to send, an SSH_MSG_EXT_INFO message immediately before SSH_MSG_USERAUTH_SUCCESS": Before, not after? That's going to lead to a pretty strange message = flow, the client sends a SSH_MSG_USERAUTH_REQUEST and instead of the expected SSH_MSG_USERAUTH_SUCCESS/SSH_MSG_USERAUTH_FAILURE it gets some random = message about extensions. Why not require that the extensions be sent after failure/success has been indicated? Section 2.4, "If a server sends a subsequent SSH_MSG_EXT_INFO, this = replaces any initial one, and both the client and the server re-evaluate = extensions in effect": This is just asking for trouble, you're requiring both sides to be able = to sort out and disambiguate conflicting extensions in a compatible manner. Section 3.4, "elevation": What does this extension do? I was expecting an option of which floor = you want to get off on, with a negative value for the parking garage. Peter. ------=_NextPart_000_0215_01D1F7C9.03F1F210 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello Peter,
 
> Section 2.3, "can send the the following message":
> MAY?  MUST?  SHOULD?
 
thanks. I changed this in the working version of the draft to = MAY.
 
 
> Section 2.3, "This message is sent without delay,
> and immediately after SSH_MSG_NEWKEYS":
>
> Uhh, shouldn't it wait for the NEWKEYS to succeed?
> Otherwise if something goes wrong the sender has
> leaked the info that it's withheld until now because
> it's apparently sensitive.
 
In the direction from client to server, the client's sending of = NEWKEYS=20 indicates the server's authenticity has already been verified, so there = is no=20 issue.
 
In the direction from server to client, any information that's = actually=20 sensitive would be postponed until the second EXT_INFO message sent when = user=20 authentication is successful. There seems to be little value in mounting = an=20 attack to discover the contents of EXT_INFO sent before user = authentication,=20 when you can just connect to the SSH server without intent to = authenticate, and=20 get the information that way after a normal completed key = exchange.
 
 
> Section 2.4, "the server MAY send, but is not obligated
> to send, an SSH_MSG_EXT_INFO message immediately before
> SSH_MSG_USERAUTH_SUCCESS":
>
> Before, not after?
 
Yes, before. Otherwise you get a race condition because the client = may want=20 to take different actions after authentication success depending on = whether it=20 receives certain information in this second EXT_INFO, or not.
 
If the message could be sent after USERAUTH_SUCCESS, but might not = be sent=20 by the server, then the client has no idea whether it should wait for = the server=20 to send this message or not, or how long to wait.
 
Given that the message is optional - which I think is a good = choice, and=20 cannot be changed now anyway because the protocol extension is already = deployed=20 to a significant extent - any second EXT_INFO sent by the server must be = sent=20 *before* SSH_MSG_USERAUTH_SUCCESS.
 
 
> That's going to lead to a pretty strange message flow, = the
> client sends a SSH_MSG_USERAUTH_REQUEST and instead of = the
> expected = SSH_MSG_USERAUTH_SUCCESS/SSH_MSG_USERAUTH_FAILURE
> it gets some random message about extensions.
 
The EXT_INFO message is not random when received in this context. = The=20 client has signaled it is willing to receive it, which includes the = requirement=20 and ability to receive it in this context, also.
 
Note that the specification requires the server to send no more = than one or=20 two EXT_INFO messages at the times specified, but the client = implementation for=20 handling the second EXT_INFO does not have to enforce that it is = followed by=20 USERAUTH_SUCCESS. If it is simpler for the client to simply accept and = normally=20 handle any additional EXT_INFO messages received before = USERAUTH_SUCCESS, the=20 client can do so without necessarily needing to enforce the number of = these=20 additional messages, or that a USERAUTH_SUCCESS message immediately = follows.=20 This can be done easily at the same layer that handles the initial = EXT_INFO=20 message. Since the server is already authenticated by the client, I = don't see=20 risks from allowing this leeway.
 
 
> Section 2.4, "If a server sends a subsequent
> SSH_MSG_EXT_INFO, this replaces any initial one, and = both
> the client and the server re-evaluate extensions in = effect":
>
> This is just asking for trouble, you're requiring both = sides
> to be able to sort out and disambiguate conflicting
> extensions in a compatible manner.
 
If a server implements one or more extensions that require the = sending of a=20 second EXT_INFO, it may check the EXT_INFO received from the client to = see if=20 the client indicates support for any of those extensions. If it does = not, the=20 server does not need to send the second EXT_INFO, and there are no = conflicts.=20 But if the client indicates support for such extensions, implementations = of such=20 extensions will be able to agree on proper behavior at that time.
 
The current widely used extension, server-sig-algs, does not have = much=20 continued relevance after user authentication is successful, and so does = not=20 suffer from extensions being re-evaluated due to a second = EXT_INFO.
 
If you have a suggestion for wording to be inserted that would = reduce the=20 chances of compatibility issues due to the second EXT_INFO, please let = me know.=20 >From my perspective, the current spec seems clear ("a subsequent=20 SSH_MSG_EXT_INFO [...] replaces any initial one", "the client and the = server=20 re-evaluate extensions in effect"). But if there's a way we can further = clarify=20 this, I'm open to suggestions.
 
 
> Section 3.4, "elevation":
>
> What does this extension do?  I was expecting an option = of
> which floor you want to get off on, with a negative = value
> for the parking garage.
 
Point taken. I have modified the working version of the draft to = insert the=20 words "(as used by Windows)" in the description of this extension.
 
denis
 
 
Sent: Tuesday, August 16, 2016 04:36
To: ietf-ssh3@denisbider.com ; = ietf-ssh@netbsd.org
Subject: Questions about=20 draft-ietf-curdle-ssh-ext-info-00.txt
 
I've=20 been looking at this draft and have a few questions...

Section = 2.3, "can=20 send the the following message":

MAY?  MUST? =20 SHOULD?

Section 2.3, "This message is sent without delay, and = immediately=20 after
SSH_MSG_NEWKEYS":

Uhh, shouldn't it wait for the NEWKEYS = to=20 succeed?  Otherwise if something goes
wrong the sender has = leaked the=20 info that it's withheld until now because it's
apparently=20 sensitive.

Section 2.4, "the server MAY send, but is not = obligated to=20 send, an
SSH_MSG_EXT_INFO message immediately before=20 SSH_MSG_USERAUTH_SUCCESS":

Before, not after?  That's going = to lead=20 to a pretty strange message flow, the
client sends a = SSH_MSG_USERAUTH_REQUEST=20 and instead of the = expected
SSH_MSG_USERAUTH_SUCCESS/SSH_MSG_USERAUTH_FAILURE=20 it gets some random message
about extensions.  Why not require = that the=20 extensions be sent after
failure/success has been = indicated?

Section=20 2.4, "If a server sends a subsequent SSH_MSG_EXT_INFO, this = replaces
any=20 initial one, and both the client and the server re-evaluate extensions=20 in
effect":

This is just asking for trouble, you're requiring = both=20 sides to be able to
sort out and disambiguate conflicting extensions = in a=20 compatible manner.

Section 3.4, "elevation":

What does = this=20 extension do?  I was expecting an option of which floor you
want = to get=20 off on, with a negative value for the parking=20 garage.

Peter.
------=_NextPart_000_0215_01D1F7C9.03F1F210-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Aug 17 09:35:59 2016 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D3212DAFC for ; Wed, 17 Aug 2016 09:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.546 X-Spam-Level: X-Spam-Status: No, score=-5.546 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5B_lT-HMT0T8 for ; Wed, 17 Aug 2016 09:35:51 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (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 C66AD12DAF2 for ; Wed, 17 Aug 2016 09:35:51 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 8916486073; Wed, 17 Aug 2016 16:35:51 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 3AE7086072; Wed, 17 Aug 2016 16:35:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id E8E5F85E8D for ; Tue, 16 Aug 2016 21:19:54 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.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 8aqKQj2gbBzn for ; Tue, 16 Aug 2016 21:19:54 +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 1C33185E3F for ; Tue, 16 Aug 2016 21:19:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=denisbider.com; s=mail; h=from:subject:date:message-id:to:cc:mime-version:content-type; bh=PG1UIUr0E1Uowr31xQobsOnWeIpMmudx8lfEO+Rdlq4=; b=fq5MlRStCFAlcu4L82ZvzpqMhT9QIoCIlmZ6YEiT1KOTNT/E1z193xDkXBWZO+LM5riL4UUvKLu7y +UZbhzR70OozRgE0X8EuOXd/CUMjTZ/dK3YZLlQBlr0c/XjiNmaTH7D3UoxkVL7s30DHrNQTAh4Iak 5K1yTVwYgugBFHcj1UMzl7wloZMdwwkZmY15WzXczV67osqyu1tb41mmYu5UwNIElAXnTxxW2Cfufu i7cMxVPkQrds+zM5ssbqbInW0ly0zb2GrPnCJyaLlGvl1cUvXcRzyuoJoyMgMd36Gd+bGfPhsAboC9 xo1SHr/3/gCnYU7xTXVtLmIPov6rY8A== X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Tue, 16 Aug 2016 22:19:40 +0100 Message-ID: <71963A21726946C3B16A0B77F0CFF3F6@Khan> From: "denis bider \(Bitvise\)" To: "Curdle" Cc: , "Mark D. Baushke" , Subject: Group 15 needed in draft-baushke-ssh-dh-group-sha2 Date: Tue, 16 Aug 2016 15:19:14 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_027B_01D1F7D1.8C95D430" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_027B_01D1F7D1.8C95D430 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello everyone, this comment is with respect to the following draft specifying new = Diffie-Hellman groups for SSH key exchange: https://tools.ietf.org/html/draft-ietf-curdle-ssh-kex-sha2-03 The current version of the draft specifies the following: diffie-hellman-group14-sha256 MAY/OPTIONAL diffie-hellman-group16-sha512 SHOULD/RECOMMENDED diffie-hellman-group18-sha512 MAY/OPTIONAL =20 A previous version of this draft specified the following methods: https://tools.ietf.org/html/draft-baushke-ssh-dh-group-sha2-03 diffie-hellman-group14-sha256 MAY/OPTIONAL diffie-hellman-group15-sha512 MUST/REQUIRED/SHALL diffie-hellman-group16-sha512 SHOULD/RECOMMENDED diffie-hellman-group17-sha512 MAY/OPTIONAL diffie-hellman-group18-sha512 MAY/OPTIONAL =20 Note the presence of additional groups 15 and 17 which were removed in = version 4 of the original Baushke draft. Groups 15 and 17 were removed based on feedback from one implementer. = Basically, this feedback was one line: > +1 to dropping the odd-numbered groups and onlist listing = group14/16/18 I would like to counter this, and move to restore the previous table = including groups 15 and 17 - or failing that, at least group 15 - with = the same parameters as above, in version 3 of the original Baushke = draft. My reasons for proposing this are as follows: - According to NSA recommendations, the 3072-bit strength would be the = current sweet spot between performance and acceptable security. Group 15 = is 3072-bit, whereas groups 14 and 16 are 2048- and 4096-bit. - The additional security of group 16 in comparison to group 15 is = estimated to be small. Symmetric security estimates I've seen are 80 = bits for group 1 (1024-bit), 112 bits for group 14 (2048-bit), and 128 = bits for group 15 (3072-bit). Based on this, I expect the security of = group 16 (4096-bit) to be between 136 - 144 symmetric bits. - Based on practical measurements, it appears that group 16 is about a = factor of 2 slower than group 15. With group 15, I'm getting about 20 = full DH key exchanges per second; with group 16, I am getting around 10. = I think this difference is significant, and can affect real world usage = scenarios on heavily loaded servers. At this time, I do not have a particular need for group 17 (or 18), but = I find it peculiar that this draft would not specify a group that = matches the exact recommended DH group size suggested by the NSA. It is = weird that we have to choose either between group 14, which does not = meet the requirements; or group 16, which is significantly slower. For our next Bitvise SSH Server and Client versions, I have implemented = support for groups 15 as well as 16, where group 15 is implemented with = SHA-512, as specified above. When using DH key exchange, our SSH Server = will favor group 15, whereas group 16 will be disabled by default for = performance (but it will be enabled and preferred in the SSH Client). denis ------=_NextPart_000_027B_01D1F7D1.8C95D430 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello everyone,
 
this comment is with respect to the following draft specifying new=20 Diffie-Hellman groups for SSH key exchange:
 
ht= tps://tools.ietf.org/html/draft-ietf-curdle-ssh-kex-sha2-03
 
The current version of the draft specifies the following:
 
  diffie-hellman-group14-sha256    =20 MAY/OPTIONAL
  diffie-hellman-group16-sha512    =20 SHOULD/RECOMMENDED
  diffie-hellman-group18-sha512    =20 MAY/OPTIONAL
A previous version of this draft specified the following = methods:
 
h= ttps://tools.ietf.org/html/draft-baushke-ssh-dh-group-sha2-03
 
  diffie-hellman-group14-sha256    =20 MAY/OPTIONAL
  diffie-hellman-group15-sha512    =20 MUST/REQUIRED/SHALL
  diffie-hellman-group16-sha512    =20 SHOULD/RECOMMENDED
  diffie-hellman-group17-sha512    =20 MAY/OPTIONAL
  diffie-hellman-group18-sha512    =20 MAY/OPTIONAL
Note the presence of additional groups 15 and 17 which were removed = in=20 version 4 of the original Baushke draft.
 
Groups 15 and 17 were removed based on feedback from one = implementer.=20 Basically, this feedback was one line:
 
> +1 to dropping the odd-numbered groups and onlist listing=20 group14/16/18
 
I would like to counter this, and move to restore the previous = table=20 including groups 15 and 17 - or failing that, at least group 15 - with = the same=20 parameters as above, in version 3 of the original Baushke draft.
 
My reasons for proposing this are as follows:
 
- According to NSA recommendations, the 3072-bit strength would be = the=20 current sweet spot between performance and acceptable security. Group 15 = is=20 3072-bit, whereas groups 14 and 16 are 2048- and 4096-bit.
 
- The additional security of group 16 in comparison to group 15 is=20 estimated to be small. Symmetric security estimates I've seen are 80 = bits for=20 group 1 (1024-bit), 112 bits for group 14 (2048-bit), and 128 bits for = group 15=20 (3072-bit). Based on this, I expect the security of group 16 (4096-bit) = to be=20 between 136 - 144 symmetric bits.
 
- Based on practical measurements, it appears that group 16 is = about a=20 factor of 2 slower than group 15. With group 15, I'm getting about 20 = full DH=20 key exchanges per second; with group 16, I am getting around 10. I think = this=20 difference is significant, and can affect real world usage scenarios on = heavily=20 loaded servers.
 
At this time, I do not have a particular need for group 17 (or 18), = but I=20 find it peculiar that this draft would not specify a group that matches = the=20 exact recommended DH group size suggested by the NSA. It is weird that = we have=20 to choose either between group 14, which does not meet the requirements; = or=20 group 16, which is significantly slower.
 
For our next Bitvise SSH Server and Client versions, I have = implemented=20 support for groups 15 as well as 16, where group 15 is implemented with = SHA-512,=20 as specified above. When using DH key exchange, our SSH Server will = favor group=20 15, whereas group 16 will be disabled by default for performance (but it = will be=20 enabled and preferred in the SSH Client).
 
denis
 
------=_NextPart_000_027B_01D1F7D1.8C95D430-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Aug 17 09:36:21 2016 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDEA12DAFD for ; Wed, 17 Aug 2016 09:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.545 X-Spam-Level: X-Spam-Status: No, score=-5.545 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k--PyXtkbigl for ; Wed, 17 Aug 2016 09:36:19 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 2EB9312DBA7 for ; Wed, 17 Aug 2016 09:36:16 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id DA63D86072; Wed, 17 Aug 2016 16:36:15 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 85D8E86071; Wed, 17 Aug 2016 16:36:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id C33EE85E8D for ; Wed, 17 Aug 2016 14:28: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=gmail.com Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id T72mzWRqX3ec for ; Wed, 17 Aug 2016 14:28:57 +0000 (UTC) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (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 AA04D85E22 for ; Wed, 17 Aug 2016 14:28:57 +0000 (UTC) Received: by mail-ua0-x231.google.com with SMTP id 74so174319691uau.0 for ; Wed, 17 Aug 2016 07:28:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=T9kKa6BqPFLcVAuE7JY3GN4ib8aGOGMULj4ESzxfFBc=; b=m1FdgWoL5DBhQQlOI5TaX1TQPbuUvwYt8VDXwgqFP5WH7DTId5llQlhcErsEFXFtC5 Xup0pjmrwG6rX9jDO1hGPb4TtYX6b4m72cFsZfvmGYXnUucBlcPIXMzwwnCBSOjwZRaO 1Ax/JVtlqWm4Lap5W+XuP+KOX21z7cebAitkvRAkblDegbyX0VklqPCGAtVoHzoUcjHS J1uq5NmjZiZ/DmfySXgnGsTMz7zN6x+lkOWMhpvZ6zvWuI2AWNksN5TqTfo0fbfTIvy7 92S2QYPcsMQ1/KneI3/G2Zbffju13q50tvhNMLqYtBFCRM5NokiWKayO3wRHzCYrEVwz 2/7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=T9kKa6BqPFLcVAuE7JY3GN4ib8aGOGMULj4ESzxfFBc=; b=FwT9YyG2Ej3We/Nj4kXoFJ19yhQb8AGkOsmDHN+Ua10/ylfBHRPZcikB9+Q+WhPUBt FVnyPSRRwUJ1xOXCCkuNSWFird2i0NX6r+gf0zJebfEXVMO3etQKmm74hCAFo1qvRNi9 ow7ZS35JbNXfBqxqD28OkOnljHwCOxTa/9obu6PHiUFwiSiraBfr0uxR9JBnira23RBR zs5VGcooDH8n7sIznu7u0W2PQIKiaJ2GwhBPY3G+ijXsueNyysTiwuNP+FlHmaCVtsLJ XXHeRxliluBoU6CX3XY7CNZQesxr2yE7JS5aO46RUIJPOUlZVxvq6yMrBl38clegAYEj MiqQ== X-Gm-Message-State: AEkoouvASau+itvkv6POJm1deht/BhthAu+Fb1OLDKIfJpH1YV9TVXG2kz4JLkzOpf+GwEMDDP3Ye/BMIYxcwQ== X-Received: by 10.176.4.85 with SMTP id 79mr5924193uav.56.1471444136650; Wed, 17 Aug 2016 07:28:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.209 with HTTP; Wed, 17 Aug 2016 07:28:56 -0700 (PDT) In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C117F5BECA@eusaamb107.ericsson.se> References: <71963A21726946C3B16A0B77F0CFF3F6@Khan> <2DD56D786E600F45AC6BDE7DA4E8A8C117F5BECA@eusaamb107.ericsson.se> From: Watson Ladd Date: Wed, 17 Aug 2016 07:28:56 -0700 Message-ID: Subject: Re: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 To: Daniel Migault Cc: "denis bider (Bitvise)" , Curdle , "djm@mindrot.org" , "ietf-ssh@netbsd.org" , "Mark D. Baushke" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Wed, Aug 17, 2016 at 7:15 AM, Daniel Migault wrote: > Hi, > > > > > > Going briefly through the draft, it seems redundant to have MAY/OPTIONAL, > SHOULD/RECOMMENDED, MAY/OPTIONAL. I am not sure this does not result in = a > combination of recommendation for the users as well as a recommendation o= n > algorithms to implement. I would recommend we only focus on requirements = for > algorithm implementation. We should also specify that all non specified > algorithms in this document are =E2=80=9CMAY=E2=80=9D. There must be a single algorithm that everyone is required to implement. Make it P256 SHA2. Do not make it P384. There are no efficient constant time implementations. (I have written a constant time P384 this summer at Mozilla: it is not that fast). By contrast OpenSSL has a constant time P256 implementation (possibly not used by default: the rumors are unclear. Can you guys go ahead and ensure that it is used by default?) That's on top of everyone uses P256+SHA256. > > > > I have not found any recommendations for these algorithms at the IANA web > page [1], nor in another document. If that is the case, maybe this docume= nt > should clarify this so a status can be assigned for each kex. The IANA pa= ge > also does not mention all algorithm and I have not found documentation fo= r > all suites found in the manual. > > > > Updating the different algorithm should consider two aspects: security an= d > interoperability, which means a SHOULD NOT status is expected to be done = for > a cipher suite with a SHOULD status. In other words going from MUST to > SHOULD NOT should be avoided unless there are strong reasons to do so. So > maybe we should do a little bit more cleanup. > > > > I do not know the current status for SSH but it would be good to end up i= n > group1 and SHA1 set to MUST NOT =E2=80=93 eventually SHOULD NOT later bei= ng updated > to MUST NOT. > > > > SHA256 set to MUST, SHA386 to MAY and SHA512 set to SHOULD to have it rea= dy > when SHA256 will be replaced. > > > > Maybe we should also consider the current use of the various group, and > those not widely used may be set to MAY. > > > > BR, > > Daniel > > > > [1] > http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-p= arameters-16 > > > > > > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of denis bider > (Bitvise) > Sent: Tuesday, August 16, 2016 5:19 PM > To: Curdle > Cc: djm@mindrot.org; ietf-ssh@netbsd.org; Mark D. Baushke > Subject: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 > > > > Hello everyone, > > > > this comment is with respect to the following draft specifying new > Diffie-Hellman groups for SSH key exchange: > > > > https://tools.ietf.org/html/draft-ietf-curdle-ssh-kex-sha2-03 > > > > The current version of the draft specifies the following: > > > > diffie-hellman-group14-sha256 MAY/OPTIONAL > > diffie-hellman-group16-sha512 SHOULD/RECOMMENDED > > diffie-hellman-group18-sha512 MAY/OPTIONAL > > A previous version of this draft specified the following methods: > > > > https://tools.ietf.org/html/draft-baushke-ssh-dh-group-sha2-03 > > > > diffie-hellman-group14-sha256 MAY/OPTIONAL > > diffie-hellman-group15-sha512 MUST/REQUIRED/SHALL > > diffie-hellman-group16-sha512 SHOULD/RECOMMENDED > > diffie-hellman-group17-sha512 MAY/OPTIONAL > > diffie-hellman-group18-sha512 MAY/OPTIONAL > > Note the presence of additional groups 15 and 17 which were removed in > version 4 of the original Baushke draft. > > > > Groups 15 and 17 were removed based on feedback from one implementer. > Basically, this feedback was one line: > > > >> +1 to dropping the odd-numbered groups and onlist listing group14/16/18 > > > > I would like to counter this, and move to restore the previous table > including groups 15 and 17 - or failing that, at least group 15 - with th= e > same parameters as above, in version 3 of the original Baushke draft. > > > > My reasons for proposing this are as follows: > > > > - According to NSA recommendations, the 3072-bit strength would be the > current sweet spot between performance and acceptable security. Group 15 = is > 3072-bit, whereas groups 14 and 16 are 2048- and 4096-bit. > > > > - The additional security of group 16 in comparison to group 15 is estima= ted > to be small. Symmetric security estimates I've seen are 80 bits for group= 1 > (1024-bit), 112 bits for group 14 (2048-bit), and 128 bits for group 15 > (3072-bit). Based on this, I expect the security of group 16 (4096-bit) t= o > be between 136 - 144 symmetric bits. > > > > - Based on practical measurements, it appears that group 16 is about a > factor of 2 slower than group 15. With group 15, I'm getting about 20 ful= l > DH key exchanges per second; with group 16, I am getting around 10. I thi= nk > this difference is significant, and can affect real world usage scenarios= on > heavily loaded servers. > > > > At this time, I do not have a particular need for group 17 (or 18), but I > find it peculiar that this draft would not specify a group that matches t= he > exact recommended DH group size suggested by the NSA. It is weird that we > have to choose either between group 14, which does not meet the > requirements; or group 16, which is significantly slower. > > > > For our next Bitvise SSH Server and Client versions, I have implemented > support for groups 15 as well as 16, where group 15 is implemented with > SHA-512, as specified above. When using DH key exchange, our SSH Server w= ill > favor group 15, whereas group 16 will be disabled by default for performa= nce > (but it will be enabled and preferred in the SSH Client). > > > > denis > > > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Aug 17 09:36:46 2016 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 249CD12DAF2 for ; Wed, 17 Aug 2016 09:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umKBhEsKxHqt for ; Wed, 17 Aug 2016 09:36:44 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (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 5CF5B12DAFD for ; Wed, 17 Aug 2016 09:36:44 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 1B1CD86074; Wed, 17 Aug 2016 16:36:39 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id BD85086071; Wed, 17 Aug 2016 16:36:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 1DDC785FA5 for ; Wed, 17 Aug 2016 15:25: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 3e3v0d-r3s4w for ; Wed, 17 Aug 2016 15:25:49 +0000 (UTC) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (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 0AF9685E27 for ; Wed, 17 Aug 2016 15:25:48 +0000 (UTC) X-AuditID: c618062d-980fb98000000a08-be-57b478567b4c Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by (Symantec Mail Security) with SMTP id 98.B2.02568.65874B75; Wed, 17 Aug 2016 16:44:38 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0301.000; Wed, 17 Aug 2016 10:35:41 -0400 From: Daniel Migault To: Watson Ladd CC: "denis bider (Bitvise)" , Curdle , "djm@mindrot.org" , "ietf-ssh@netbsd.org" , "Mark D. Baushke" Subject: RE: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 Thread-Topic: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 Thread-Index: AQHR+APwxyfnHXpgoEakB10teLEFZ6BNHKVggABdwAD//75NEA== Date: Wed, 17 Aug 2016 14:35:40 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C117F5BEFD@eusaamb107.ericsson.se> References: <71963A21726946C3B16A0B77F0CFF3F6@Khan> <2DD56D786E600F45AC6BDE7DA4E8A8C117F5BECA@eusaamb107.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyuXRPrG5YxZZwg1NP9Sy2LpzFbHHl2zMm i3svpzBafLj3mM2i6851NouezpNsDmwe96fPY/fYOesuu8eSJT+ZPK43XWX3+Papnc1j4cMe xgC2KC6blNSczLLUIn27BK6Mszd7GQs+uFe0PLzE3sDY4tbFyMkhIWAiMedABzOILSSwgVHi 1pMKCHs5o8T826UgNpuAkUTboX52EFtEQF1iwvJNLF2MXBzMAqcZJfb1b2IESQgLeEgcnPmR CaLIU+Li9ttADRxAtpPEtzVRIGEWAVWJtpMbWEFsXgFfiVPv7rGDzBES2McocfPOcbBeToFA iRlvv4IVMQqISXw/tQYsziwgDnTbfCaIowUkluw5zwxhi0q8fPyPFcJWkpi09BwryF5mAU2J 9bv0IVoVJaZ0P2SH2CsocXLmE5YJjKKzkEydhdAxC0nHLCQdCxhZVjFylBYX5OSmGxlsYgRG 1jEJNt0djPenex5iFOBgVOLhXRCyOVyINbGsuDL3EKMEB7OSCO/awi3hQrwpiZVVqUX58UWl OanFhxilOViUxHnFHimGCwmkJ5akZqemFqQWwWSZODilGhitdPdaJl946lvHV/moLu7JnZ8h +8W/3uRn/FCudVz+0c6M11kf2bKLyvbxiBfJV9fPdf2/9/GSCoXyJ4+NGCaWV/zmicpZFXzB UGFa82quB4ey29jWh4tEuqY3r30YtHyDbl7BjOffv8QdZVpS0F14tiLkwbRAiUnPsz4tPlR9 34i31S7+h7ASS3FGoqEWc1FxIgAY6z/+qAIAAA== Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list SWYgdGhhdCBpcyB0aGUgZGVmYXVsdCwgaXQgd291bGQgZWFzZSB0byBkZXByZWNhdGUgd2hhdCB3 ZSB3YW50IHRvIGRlcHJlY2F0ZS4gQW5kIEkgYWdyZWUgaXRzIHN0YXR1cyBzaG91bGQgYmUgaW5k aWNhdGVkIGluIHRoZSBkcmFmdC4NCg0KQlIsIA0KRGFuaWVsDQoNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IFdhdHNvbiBMYWRkIFttYWlsdG86d2F0c29uYmxhZGRAZ21haWwu Y29tXSANClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDE3LCAyMDE2IDEwOjI5IEFNDQpUbzogRGFu aWVsIE1pZ2F1bHQgPGRhbmllbC5taWdhdWx0QGVyaWNzc29uLmNvbT4NCkNjOiBkZW5pcyBiaWRl ciAoQml0dmlzZSkgPGlldGYtc3NoM0BkZW5pc2JpZGVyLmNvbT47IEN1cmRsZSA8Y3VyZGxlQGll dGYub3JnPjsgZGptQG1pbmRyb3Qub3JnOyBpZXRmLXNzaEBuZXRic2Qub3JnOyBNYXJrIEQuIEJh dXNoa2UgPG1kYkBqdW5pcGVyLm5ldD4NClN1YmplY3Q6IFJlOiBbQ3VyZGxlXSBHcm91cCAxNSBu ZWVkZWQgaW4gZHJhZnQtYmF1c2hrZS1zc2gtZGgtZ3JvdXAtc2hhMg0KDQpPbiBXZWQsIEF1ZyAx NywgMjAxNiBhdCA3OjE1IEFNLCBEYW5pZWwgTWlnYXVsdCA8ZGFuaWVsLm1pZ2F1bHRAZXJpY3Nz b24uY29tPiB3cm90ZToNCj4gSGksDQo+DQo+DQo+DQo+DQo+DQo+IEdvaW5nIGJyaWVmbHkgdGhy b3VnaCB0aGUgZHJhZnQsIGl0IHNlZW1zIHJlZHVuZGFudCB0byBoYXZlIA0KPiBNQVkvT1BUSU9O QUwsIFNIT1VMRC9SRUNPTU1FTkRFRCwgTUFZL09QVElPTkFMLiAgSSBhbSBub3Qgc3VyZSB0aGlz IA0KPiBkb2VzIG5vdCByZXN1bHQgaW4gYSBjb21iaW5hdGlvbiBvZiByZWNvbW1lbmRhdGlvbiBm b3IgdGhlIHVzZXJzIGFzIA0KPiB3ZWxsIGFzIGEgcmVjb21tZW5kYXRpb24gb24gYWxnb3JpdGht cyB0byBpbXBsZW1lbnQuIEkgd291bGQgcmVjb21tZW5kIA0KPiB3ZSBvbmx5IGZvY3VzIG9uIHJl cXVpcmVtZW50cyBmb3IgYWxnb3JpdGhtIGltcGxlbWVudGF0aW9uLiBXZSBzaG91bGQgDQo+IGFs c28gc3BlY2lmeSB0aGF0IGFsbCBub24gc3BlY2lmaWVkIGFsZ29yaXRobXMgaW4gdGhpcyBkb2N1 bWVudCBhcmUg4oCcTUFZ4oCdLg0KDQpUaGVyZSBtdXN0IGJlIGEgc2luZ2xlIGFsZ29yaXRobSB0 aGF0IGV2ZXJ5b25lIGlzIHJlcXVpcmVkIHRvIGltcGxlbWVudC4gTWFrZSBpdCBQMjU2IFNIQTIu IERvIG5vdCBtYWtlIGl0IFAzODQuIFRoZXJlIGFyZSBubyBlZmZpY2llbnQgY29uc3RhbnQgdGlt ZSBpbXBsZW1lbnRhdGlvbnMuIChJIGhhdmUgd3JpdHRlbiBhIGNvbnN0YW50IHRpbWUgUDM4NCB0 aGlzIHN1bW1lciBhdCBNb3ppbGxhOiBpdCBpcyBub3QgdGhhdCBmYXN0KS4gQnkgY29udHJhc3Qg T3BlblNTTCBoYXMgYSBjb25zdGFudCB0aW1lIFAyNTYgaW1wbGVtZW50YXRpb24gKHBvc3NpYmx5 IG5vdCB1c2VkIGJ5DQpkZWZhdWx0OiB0aGUgcnVtb3JzIGFyZSB1bmNsZWFyLiBDYW4geW91IGd1 eXMgZ28gYWhlYWQgYW5kIGVuc3VyZSB0aGF0IGl0IGlzIHVzZWQgYnkgZGVmYXVsdD8pDQoNClRo YXQncyBvbiB0b3Agb2YgZXZlcnlvbmUgdXNlcyBQMjU2K1NIQTI1Ni4NCg0KPg0KPg0KPg0KPiBJ IGhhdmUgbm90IGZvdW5kIGFueSByZWNvbW1lbmRhdGlvbnMgZm9yIHRoZXNlIGFsZ29yaXRobXMg YXQgdGhlIElBTkEgDQo+IHdlYiBwYWdlIFsxXSwgbm9yIGluIGFub3RoZXIgZG9jdW1lbnQuIElm IHRoYXQgaXMgdGhlIGNhc2UsIG1heWJlIHRoaXMgDQo+IGRvY3VtZW50IHNob3VsZCBjbGFyaWZ5 IHRoaXMgc28gYSBzdGF0dXMgY2FuIGJlIGFzc2lnbmVkIGZvciBlYWNoIGtleC4gDQo+IFRoZSBJ QU5BIHBhZ2UgYWxzbyBkb2VzIG5vdCBtZW50aW9uIGFsbCBhbGdvcml0aG0gYW5kIEkgaGF2ZSBu b3QgZm91bmQgDQo+IGRvY3VtZW50YXRpb24gZm9yIGFsbCBzdWl0ZXMgZm91bmQgaW4gdGhlIG1h bnVhbC4NCj4NCj4NCj4NCj4gVXBkYXRpbmcgdGhlIGRpZmZlcmVudCBhbGdvcml0aG0gc2hvdWxk IGNvbnNpZGVyIHR3byBhc3BlY3RzOiBzZWN1cml0eSANCj4gYW5kIGludGVyb3BlcmFiaWxpdHks IHdoaWNoIG1lYW5zIGEgU0hPVUxEIE5PVCBzdGF0dXMgaXMgZXhwZWN0ZWQgdG8gDQo+IGJlIGRv bmUgZm9yIGEgY2lwaGVyIHN1aXRlIHdpdGggYSBTSE9VTEQgc3RhdHVzLiBJbiBvdGhlciB3b3Jk cyBnb2luZyANCj4gZnJvbSBNVVNUIHRvIFNIT1VMRCBOT1Qgc2hvdWxkIGJlIGF2b2lkZWQgdW5s ZXNzIHRoZXJlIGFyZSBzdHJvbmcgDQo+IHJlYXNvbnMgdG8gZG8gc28uIFNvIG1heWJlIHdlIHNo b3VsZCBkbyBhIGxpdHRsZSBiaXQgbW9yZSBjbGVhbnVwLg0KPg0KPg0KPg0KPiBJIGRvIG5vdCBr bm93IHRoZSBjdXJyZW50IHN0YXR1cyBmb3IgU1NIIGJ1dCBpdCB3b3VsZCBiZSBnb29kIHRvIGVu ZCANCj4gdXAgaW4NCj4gZ3JvdXAxIGFuZCBTSEExIHNldCB0byBNVVNUIE5PVCDigJMgZXZlbnR1 YWxseSBTSE9VTEQgTk9UIGxhdGVyIGJlaW5nIA0KPiB1cGRhdGVkIHRvIE1VU1QgTk9ULg0KPg0K Pg0KPg0KPiBTSEEyNTYgc2V0IHRvIE1VU1QsIFNIQTM4NiB0byBNQVkgYW5kIFNIQTUxMiBzZXQg dG8gU0hPVUxEIHRvIGhhdmUgaXQgDQo+IHJlYWR5IHdoZW4gU0hBMjU2IHdpbGwgYmUgcmVwbGFj ZWQuDQo+DQo+DQo+DQo+IE1heWJlIHdlIHNob3VsZCBhbHNvIGNvbnNpZGVyIHRoZSBjdXJyZW50 IHVzZSBvZiB0aGUgdmFyaW91cyBncm91cCwgDQo+IGFuZCB0aG9zZSBub3Qgd2lkZWx5IHVzZWQg bWF5IGJlIHNldCB0byBNQVkuDQo+DQo+DQo+DQo+IEJSLA0KPg0KPiBEYW5pZWwNCj4NCj4NCj4N Cj4gWzFdDQo+IGh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvc3NoLXBhcmFtZXRlcnMv c3NoLXBhcmFtZXRlcnMueGh0bWwjc3MNCj4gaC1wYXJhbWV0ZXJzLTE2DQo+DQo+DQo+DQo+DQo+ DQo+IEZyb206IEN1cmRsZSBbbWFpbHRvOmN1cmRsZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgZGVuaXMgYmlkZXINCj4gKEJpdHZpc2UpDQo+IFNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAx NiwgMjAxNiA1OjE5IFBNDQo+IFRvOiBDdXJkbGUgPGN1cmRsZUBpZXRmLm9yZz4NCj4gQ2M6IGRq bUBtaW5kcm90Lm9yZzsgaWV0Zi1zc2hAbmV0YnNkLm9yZzsgTWFyayBELiBCYXVzaGtlIA0KPiA8 bWRiQGp1bmlwZXIubmV0Pg0KPiBTdWJqZWN0OiBbQ3VyZGxlXSBHcm91cCAxNSBuZWVkZWQgaW4g ZHJhZnQtYmF1c2hrZS1zc2gtZGgtZ3JvdXAtc2hhMg0KPg0KPg0KPg0KPiBIZWxsbyBldmVyeW9u ZSwNCj4NCj4NCj4NCj4gdGhpcyBjb21tZW50IGlzIHdpdGggcmVzcGVjdCB0byB0aGUgZm9sbG93 aW5nIGRyYWZ0IHNwZWNpZnlpbmcgbmV3IA0KPiBEaWZmaWUtSGVsbG1hbiBncm91cHMgZm9yIFNT SCBrZXkgZXhjaGFuZ2U6DQo+DQo+DQo+DQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWN1cmRsZS1zc2gta2V4LXNoYTItMDMNCj4NCj4NCj4NCj4gVGhlIGN1cnJlbnQg dmVyc2lvbiBvZiB0aGUgZHJhZnQgc3BlY2lmaWVzIHRoZSBmb2xsb3dpbmc6DQo+DQo+DQo+DQo+ ICAgZGlmZmllLWhlbGxtYW4tZ3JvdXAxNC1zaGEyNTYgICAgIE1BWS9PUFRJT05BTA0KPg0KPiAg IGRpZmZpZS1oZWxsbWFuLWdyb3VwMTYtc2hhNTEyICAgICBTSE9VTEQvUkVDT01NRU5ERUQNCj4N Cj4gICBkaWZmaWUtaGVsbG1hbi1ncm91cDE4LXNoYTUxMiAgICAgTUFZL09QVElPTkFMDQo+DQo+ IEEgcHJldmlvdXMgdmVyc2lvbiBvZiB0aGlzIGRyYWZ0IHNwZWNpZmllZCB0aGUgZm9sbG93aW5n IG1ldGhvZHM6DQo+DQo+DQo+DQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1i YXVzaGtlLXNzaC1kaC1ncm91cC1zaGEyLTAzDQo+DQo+DQo+DQo+ICAgZGlmZmllLWhlbGxtYW4t Z3JvdXAxNC1zaGEyNTYgICAgIE1BWS9PUFRJT05BTA0KPg0KPiAgIGRpZmZpZS1oZWxsbWFuLWdy b3VwMTUtc2hhNTEyICAgICBNVVNUL1JFUVVJUkVEL1NIQUxMDQo+DQo+ICAgZGlmZmllLWhlbGxt YW4tZ3JvdXAxNi1zaGE1MTIgICAgIFNIT1VMRC9SRUNPTU1FTkRFRA0KPg0KPiAgIGRpZmZpZS1o ZWxsbWFuLWdyb3VwMTctc2hhNTEyICAgICBNQVkvT1BUSU9OQUwNCj4NCj4gICBkaWZmaWUtaGVs bG1hbi1ncm91cDE4LXNoYTUxMiAgICAgTUFZL09QVElPTkFMDQo+DQo+IE5vdGUgdGhlIHByZXNl bmNlIG9mIGFkZGl0aW9uYWwgZ3JvdXBzIDE1IGFuZCAxNyB3aGljaCB3ZXJlIHJlbW92ZWQgaW4g DQo+IHZlcnNpb24gNCBvZiB0aGUgb3JpZ2luYWwgQmF1c2hrZSBkcmFmdC4NCj4NCj4NCj4NCj4g R3JvdXBzIDE1IGFuZCAxNyB3ZXJlIHJlbW92ZWQgYmFzZWQgb24gZmVlZGJhY2sgZnJvbSBvbmUg aW1wbGVtZW50ZXIuDQo+IEJhc2ljYWxseSwgdGhpcyBmZWVkYmFjayB3YXMgb25lIGxpbmU6DQo+ DQo+DQo+DQo+PiArMSB0byBkcm9wcGluZyB0aGUgb2RkLW51bWJlcmVkIGdyb3VwcyBhbmQgb25s aXN0IGxpc3RpbmcgDQo+PiArZ3JvdXAxNC8xNi8xOA0KPg0KPg0KPg0KPiBJIHdvdWxkIGxpa2Ug dG8gY291bnRlciB0aGlzLCBhbmQgbW92ZSB0byByZXN0b3JlIHRoZSBwcmV2aW91cyB0YWJsZSAN Cj4gaW5jbHVkaW5nIGdyb3VwcyAxNSBhbmQgMTcgLSBvciBmYWlsaW5nIHRoYXQsIGF0IGxlYXN0 IGdyb3VwIDE1IC0gd2l0aCANCj4gdGhlIHNhbWUgcGFyYW1ldGVycyBhcyBhYm92ZSwgaW4gdmVy c2lvbiAzIG9mIHRoZSBvcmlnaW5hbCBCYXVzaGtlIGRyYWZ0Lg0KPg0KPg0KPg0KPiBNeSByZWFz b25zIGZvciBwcm9wb3NpbmcgdGhpcyBhcmUgYXMgZm9sbG93czoNCj4NCj4NCj4NCj4gLSBBY2Nv cmRpbmcgdG8gTlNBIHJlY29tbWVuZGF0aW9ucywgdGhlIDMwNzItYml0IHN0cmVuZ3RoIHdvdWxk IGJlIHRoZSANCj4gY3VycmVudCBzd2VldCBzcG90IGJldHdlZW4gcGVyZm9ybWFuY2UgYW5kIGFj Y2VwdGFibGUgc2VjdXJpdHkuIEdyb3VwIA0KPiAxNSBpcyAzMDcyLWJpdCwgd2hlcmVhcyBncm91 cHMgMTQgYW5kIDE2IGFyZSAyMDQ4LSBhbmQgNDA5Ni1iaXQuDQo+DQo+DQo+DQo+IC0gVGhlIGFk ZGl0aW9uYWwgc2VjdXJpdHkgb2YgZ3JvdXAgMTYgaW4gY29tcGFyaXNvbiB0byBncm91cCAxNSBp cyANCj4gZXN0aW1hdGVkIHRvIGJlIHNtYWxsLiBTeW1tZXRyaWMgc2VjdXJpdHkgZXN0aW1hdGVz IEkndmUgc2VlbiBhcmUgODAgDQo+IGJpdHMgZm9yIGdyb3VwIDEgKDEwMjQtYml0KSwgMTEyIGJp dHMgZm9yIGdyb3VwIDE0ICgyMDQ4LWJpdCksIGFuZCAxMjggDQo+IGJpdHMgZm9yIGdyb3VwIDE1 ICgzMDcyLWJpdCkuIEJhc2VkIG9uIHRoaXMsIEkgZXhwZWN0IHRoZSBzZWN1cml0eSBvZiANCj4g Z3JvdXAgMTYgKDQwOTYtYml0KSB0byBiZSBiZXR3ZWVuIDEzNiAtIDE0NCBzeW1tZXRyaWMgYml0 cy4NCj4NCj4NCj4NCj4gLSBCYXNlZCBvbiBwcmFjdGljYWwgbWVhc3VyZW1lbnRzLCBpdCBhcHBl YXJzIHRoYXQgZ3JvdXAgMTYgaXMgYWJvdXQgYSANCj4gZmFjdG9yIG9mIDIgc2xvd2VyIHRoYW4g Z3JvdXAgMTUuIFdpdGggZ3JvdXAgMTUsIEknbSBnZXR0aW5nIGFib3V0IDIwIA0KPiBmdWxsIERI IGtleSBleGNoYW5nZXMgcGVyIHNlY29uZDsgd2l0aCBncm91cCAxNiwgSSBhbSBnZXR0aW5nIGFy b3VuZCANCj4gMTAuIEkgdGhpbmsgdGhpcyBkaWZmZXJlbmNlIGlzIHNpZ25pZmljYW50LCBhbmQg Y2FuIGFmZmVjdCByZWFsIHdvcmxkIA0KPiB1c2FnZSBzY2VuYXJpb3Mgb24gaGVhdmlseSBsb2Fk ZWQgc2VydmVycy4NCj4NCj4NCj4NCj4gQXQgdGhpcyB0aW1lLCBJIGRvIG5vdCBoYXZlIGEgcGFy dGljdWxhciBuZWVkIGZvciBncm91cCAxNyAob3IgMTgpLCANCj4gYnV0IEkgZmluZCBpdCBwZWN1 bGlhciB0aGF0IHRoaXMgZHJhZnQgd291bGQgbm90IHNwZWNpZnkgYSBncm91cCB0aGF0IA0KPiBt YXRjaGVzIHRoZSBleGFjdCByZWNvbW1lbmRlZCBESCBncm91cCBzaXplIHN1Z2dlc3RlZCBieSB0 aGUgTlNBLiBJdCANCj4gaXMgd2VpcmQgdGhhdCB3ZSBoYXZlIHRvIGNob29zZSBlaXRoZXIgYmV0 d2VlbiBncm91cCAxNCwgd2hpY2ggZG9lcyANCj4gbm90IG1lZXQgdGhlIHJlcXVpcmVtZW50czsg b3IgZ3JvdXAgMTYsIHdoaWNoIGlzIHNpZ25pZmljYW50bHkgc2xvd2VyLg0KPg0KPg0KPg0KPiBG b3Igb3VyIG5leHQgQml0dmlzZSBTU0ggU2VydmVyIGFuZCBDbGllbnQgdmVyc2lvbnMsIEkgaGF2 ZSANCj4gaW1wbGVtZW50ZWQgc3VwcG9ydCBmb3IgZ3JvdXBzIDE1IGFzIHdlbGwgYXMgMTYsIHdo ZXJlIGdyb3VwIDE1IGlzIA0KPiBpbXBsZW1lbnRlZCB3aXRoIFNIQS01MTIsIGFzIHNwZWNpZmll ZCBhYm92ZS4gV2hlbiB1c2luZyBESCBrZXkgDQo+IGV4Y2hhbmdlLCBvdXIgU1NIIFNlcnZlciB3 aWxsIGZhdm9yIGdyb3VwIDE1LCB3aGVyZWFzIGdyb3VwIDE2IHdpbGwgYmUgDQo+IGRpc2FibGVk IGJ5IGRlZmF1bHQgZm9yIHBlcmZvcm1hbmNlIChidXQgaXQgd2lsbCBiZSBlbmFibGVkIGFuZCBw cmVmZXJyZWQgaW4gdGhlIFNTSCBDbGllbnQpLg0KPg0KPg0KPg0KPiBkZW5pcw0KPg0KPg0KPg0K Pg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBD dXJkbGUgbWFpbGluZyBsaXN0DQo+IEN1cmRsZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2N1cmRsZQ0KPg0KDQoNCg0KLS0NCiJNYW4gaXMgYm9ybiBm cmVlLCBidXQgZXZlcnl3aGVyZSBoZSBpcyBpbiBjaGFpbnMiLg0KLS1Sb3Vzc2VhdS4NCg== From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Aug 17 09:36:51 2016 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 179D712D694 for ; Wed, 17 Aug 2016 09:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.446 X-Spam-Level: X-Spam-Status: No, score=-5.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uK3shsvWi58S for ; Wed, 17 Aug 2016 09:36:48 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 A944512DAFC for ; Wed, 17 Aug 2016 09:36:48 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 5EBB486071; Wed, 17 Aug 2016 16:36:48 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 0950F8604E; Wed, 17 Aug 2016 16:36:48 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id BD8DA8605D for ; Wed, 17 Aug 2016 16:05:44 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id 1pSN8BivPJM6 for ; Wed, 17 Aug 2016 16:05:43 +0000 (UTC) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (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 A471285E38 for ; Wed, 17 Aug 2016 16:05:43 +0000 (UTC) X-AuditID: c618062d-980fb98000000a08-8d-57b4739fb51e Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by (Symantec Mail Security) with SMTP id 39.3F.02568.F9374B75; Wed, 17 Aug 2016 16:24:31 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0301.000; Wed, 17 Aug 2016 10:15:28 -0400 From: Daniel Migault To: "denis bider (Bitvise)" , Curdle CC: "djm@mindrot.org" , "ietf-ssh@netbsd.org" , "Mark D. Baushke" Subject: RE: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 Thread-Topic: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 Thread-Index: AQHR+APwxyfnHXpgoEakB10teLEFZ6BNHKVg Date: Wed, 17 Aug 2016 14:15:27 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C117F5BECA@eusaamb107.ericsson.se> References: <71963A21726946C3B16A0B77F0CFF3F6@Khan> In-Reply-To: <71963A21726946C3B16A0B77F0CFF3F6@Khan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_2DD56D786E600F45AC6BDE7DA4E8A8C117F5BECAeusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsUyuXRPiO784i3hBhM3qVpsXTiL2eLKt2dM FvdeTmG0+HDvMZtF153rbA6sHvenz2P3WLLkJ5PH9aar7B7fPrWzeSx82MMYwBrFZZOSmpNZ llqkb5fAlfFnhXlB8wbGil/n1jA3MHbPZuxi5OCQEDCRuLkit4uRi0NIYAOjxL7bJ9khnOWM Evf2vWTrYuTkYBMwkmg71M8OYosIBEms+toHZjMLVEs8X/8arEZYwEPi4MyPTBA1nhIXt9+G qjeS+HvpDSuIzSKgKvH+ziVmEJtXwFfi8K3FYPVCAsYSRw7fZgM5iBPooPWdliBhRgExie+n 1jBBrBKXuPVkPpgtISAgsWTPeWYIW1Ti5eN/rBC2ksSkpedYIerzJVoudEGtEpQ4OfMJywRG kVlIRs1CUjYLSRlEXEdiwe5PbBC2tsSyha+ZYewzBx4zIYsvYGRfxchRWlyQk5tuZLCJERh5 xyTYdHcw3p/ueYhRgINRiYd3QcjmcCHWxLLiytxDjBIczEoivGsLt4QL8aYkVlalFuXHF5Xm pBYfYpTmYFES5xV7pBguJJCeWJKanZpakFoEk2Xi4JRqYGw68EEx3Ddr3smzJ55M81664JnQ htbjijekbfYwageofDr44KjSjetntF93qlfVW+j1SIRUJ8312LLrR9iRE49TGrevWLX31+/d fwvburSWzF0z9d+JNR6in+MWTfQ/4Nq7oCfwdP4hizIPIetLjml8z7tC9ib/NpvoUFs99+SH lNbUiZq6x1mUWIozEg21mIuKEwEPnR2RuAIAAA== Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --_000_2DD56D786E600F45AC6BDE7DA4E8A8C117F5BECAeusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Going briefly through the draft, it seems redundant to have MAY/OPTIONAL, S= HOULD/RECOMMENDED, MAY/OPTIONAL. I am not sure this does not result in a c= ombination of recommendation for the users as well as a recommendation on a= lgorithms to implement. I would recommend we only focus on requirements for= algorithm implementation. We should also specify that all non specified al= gorithms in this document are "MAY". I have not found any recommendations for these algorithms at the IANA web p= age [1], nor in another document. If that is the case, maybe this document = should clarify this so a status can be assigned for each kex. The IANA page= also does not mention all algorithm and I have not found documentation for= all suites found in the manual. Updating the different algorithm should consider two aspects: security and = interoperability, which means a SHOULD NOT status is expected to be done fo= r a cipher suite with a SHOULD status. In other words going from MUST to SH= OULD NOT should be avoided unless there are strong reasons to do so. So may= be we should do a little bit more cleanup. I do not know the current status for SSH but it would be good to end up in = group1 and SHA1 set to MUST NOT - eventually SHOULD NOT later being updated= to MUST NOT. SHA256 set to MUST, SHA386 to MAY and SHA512 set to SHOULD to have it ready= when SHA256 will be replaced. Maybe we should also consider the current use of the various group, and tho= se not widely used may be set to MAY. BR, Daniel [1] http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh= -parameters-16 From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of denis bider (Bit= vise) Sent: Tuesday, August 16, 2016 5:19 PM To: Curdle Cc: djm@mindrot.org; ietf-ssh@netbsd.org; Mark D. Baushke Subject: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 Hello everyone, this comment is with respect to the following draft specifying new Diffie-H= ellman groups for SSH key exchange: https://tools.ietf.org/html/draft-ietf-curdle-ssh-kex-sha2-03 The current version of the draft specifies the following: diffie-hellman-group14-sha256 MAY/OPTIONAL diffie-hellman-group16-sha512 SHOULD/RECOMMENDED diffie-hellman-group18-sha512 MAY/OPTIONAL A previous version of this draft specified the following methods: https://tools.ietf.org/html/draft-baushke-ssh-dh-group-sha2-03 diffie-hellman-group14-sha256 MAY/OPTIONAL diffie-hellman-group15-sha512 MUST/REQUIRED/SHALL diffie-hellman-group16-sha512 SHOULD/RECOMMENDED diffie-hellman-group17-sha512 MAY/OPTIONAL diffie-hellman-group18-sha512 MAY/OPTIONAL Note the presence of additional groups 15 and 17 which were removed in vers= ion 4 of the original Baushke draft. Groups 15 and 17 were removed based on feedback from one implementer. Basic= ally, this feedback was one line: > +1 to dropping the odd-numbered groups and onlist listing group14/16/18 I would like to counter this, and move to restore the previous table includ= ing groups 15 and 17 - or failing that, at least group 15 - with the same p= arameters as above, in version 3 of the original Baushke draft. My reasons for proposing this are as follows: - According to NSA recommendations, the 3072-bit strength would be the curr= ent sweet spot between performance and acceptable security. Group 15 is 307= 2-bit, whereas groups 14 and 16 are 2048- and 4096-bit. - The additional security of group 16 in comparison to group 15 is estimate= d to be small. Symmetric security estimates I've seen are 80 bits for group= 1 (1024-bit), 112 bits for group 14 (2048-bit), and 128 bits for group 15 = (3072-bit). Based on this, I expect the security of group 16 (4096-bit) to = be between 136 - 144 symmetric bits. - Based on practical measurements, it appears that group 16 is about a fact= or of 2 slower than group 15. With group 15, I'm getting about 20 full DH k= ey exchanges per second; with group 16, I am getting around 10. I think thi= s difference is significant, and can affect real world usage scenarios on h= eavily loaded servers. At this time, I do not have a particular need for group 17 (or 18), but I f= ind it peculiar that this draft would not specify a group that matches the = exact recommended DH group size suggested by the NSA. It is weird that we h= ave to choose either between group 14, which does not meet the requirements= ; or group 16, which is significantly slower. For our next Bitvise SSH Server and Client versions, I have implemented sup= port for groups 15 as well as 16, where group 15 is implemented with SHA-51= 2, as specified above. When using DH key exchange, our SSH Server will favo= r group 15, whereas group 16 will be disabled by default for performance (b= ut it will be enabled and preferred in the SSH Client). denis --_000_2DD56D786E600F45AC6BDE7DA4E8A8C117F5BECAeusaamb107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

 

Going briefly through the draft, it seems redundant= to have MAY/OPTIONAL, SHOULD/RECOMMENDED, MAY/OPTIONAL.  I am not sur= e this does not result in a combination of recommendation for the users as well as a recommendation on algorithms to implement. I wo= uld recommend we only focus on requirements for algorithm implementation. W= e should also specify that all non specified algorithms in this document ar= e “MAY”.

 

I have not found any recommendations for these algo= rithms at the IANA web page [1], nor in another document. If that is the ca= se, maybe this document should clarify this so a status can be assigned for each kex. The IANA page also does not mention= all algorithm and I have not found documentation for all suites found in t= he manual.

 

Updating the different algorithm should consider tw= o aspects: security and interoperability, which means a SHOULD NOT status i= s expected to be done for a cipher suite with a SHOULD status. In other words going from MUST to SHOULD NOT should be av= oided unless there are strong reasons to do so. So maybe we should do a lit= tle bit more cleanup.

 

I do not know the current status for SSH but it wou= ld be good to end up in group1 and SHA1 set to MUST NOT – eventually = SHOULD NOT later being updated to MUST NOT.

 

SHA256 set to MUST, SHA386 to MAY and SHA512 set to= SHOULD to have it ready when SHA256 will be replaced.

 

Maybe we should also consider the current use of th= e various group, and those not widely used may be set to MAY.

 

BR,

Daniel

 

[1] http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-par= ameters-16

 

 

From: Curdle [mailto:curdle-bounces@= ietf.org] On Behalf Of denis bider (Bitvise)
Sent: Tuesday, August 16, 2016 5:19 PM
To: Curdle <curdle@ietf.org>
Cc: djm@mindrot.org; ietf-ssh@netbsd.org; Mark D. Baushke <mdb@ju= niper.net>
Subject: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2=

 

Hello everyone,

 

this comment is with respect to the follo= wing draft specifying new Diffie-Hellman groups for SSH key exchange:<= /o:p>

 

 

The current version of the draft specifie= s the following:

 

  diffie-hellman-group14-sha256 = ;    MAY/OPTIONAL

  diffie-hellman-group16-sha512 = ;    SHOULD/RECOMMENDED

  diffie-hellman-group18-sha512 = ;    MAY/OPTIONAL

A previous version of this draft specifie= d the following methods:

 

 

  diffie-hellman-group14-sha256 = ;    MAY/OPTIONAL

  diffie-hellman-group15-sha512 = ;    MUST/REQUIRED/SHALL

  diffie-hellman-group16-sha512 = ;    SHOULD/RECOMMENDED

  diffie-hellman-group17-sha512 = ;    MAY/OPTIONAL

  diffie-hellman-group18-sha512 = ;    MAY/OPTIONAL

Note the presence of additional groups 15= and 17 which were removed in version 4 of the original Baushke draft.=

 

Groups 15 and 17 were removed based on fe= edback from one implementer. Basically, this feedback was one line:

 

> +1 to dropping the odd-numbered = groups and onlist listing group14/16/18

 

I would like to counter this, and move to= restore the previous table including groups 15 and 17 - or failing that, a= t least group 15 - with the same parameters as above, in version 3 of the original Baushke draft.

 

My reasons for proposing this are as foll= ows:

 

- According to NSA recommendations, the 3= 072-bit strength would be the current sweet spot between performance and ac= ceptable security. Group 15 is 3072-bit, whereas groups 14 and 16 are 2048- and 4096-bit.

 

- The additional security of group 16 in = comparison to group 15 is estimated to be small. Symmetric security estimat= es I've seen are 80 bits for group 1 (1024-bit), 112 bits for group 14 (2048-bit), and 128 bits for group 15 (3072-bit). Ba= sed on this, I expect the security of group 16 (4096-bit) to be between 136= - 144 symmetric bits.

 

- Based on practical measurements, it app= ears that group 16 is about a factor of 2 slower than group 15. With group = 15, I'm getting about 20 full DH key exchanges per second; with group 16, I am getting around 10. I think this difference= is significant, and can affect real world usage scenarios on heavily loade= d servers.

 

At this time, I do not have a particular = need for group 17 (or 18), but I find it peculiar that this draft would not= specify a group that matches the exact recommended DH group size suggested by the NSA. It is weird that we have to choose eit= her between group 14, which does not meet the requirements; or group 16, wh= ich is significantly slower.

 

For our next Bitvise SSH Server and Clien= t versions, I have implemented support for groups 15 as well as 16, where g= roup 15 is implemented with SHA-512, as specified above. When using DH key exchange, our SSH Server will favor group 15, whe= reas group 16 will be disabled by default for performance (but it will be e= nabled and preferred in the SSH Client).

 

denis

 

--_000_2DD56D786E600F45AC6BDE7DA4E8A8C117F5BECAeusaamb107erics_--