Subject: [Curdle] I-D Action: draft-ietf-curdle-rsa-sha2-01.txt

From: [email-masked]
Date: Mon, 01 Aug 2016 16:07:25 -0700

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/

---

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Mon, 1 Aug 2016 18:03:08 -0600

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. 

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: [email-masked] 
Sent: Monday, August 1, 2016 17:07
To: [email-masked] 
Cc: [email-masked] 
Subject: [Curdle] I-D Action: draft-ietf-curdle-rsa-sha2-01.txt

Abstract:

_______________________________________________
Curdle mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/curdle