|
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)
... 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.
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@localhost
Sent: Monday, August 1, 2016 17:07
To: i-d-announce%ietf.org@localhost
Cc: curdle%ietf.org@localhost
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=draft-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@localhost
https://www.ietf.org/mailman/listinfo/curdle |