Re: [Curdle] Comments on draft-ietf-curdle-ssh-ext-info

["denis bider \(Bitvise\)" <[e-mail]>]

Reply to Peter’s comments on the SSH EXT_INFO draft:


> Section 2.3, "This message is sent without delay", I'm not really
> sure what to do with this requirement, why would there be a delay,
> necessitating a need to say that it's sent without delay?

There is no reason for a delay, but people do things for which there aren’t good reasons, and then others in the future have to compensate. This is to nip the problem in the bud.

There are three extensions defined at this time. Two in this draft, one in another (an independent submission).

One extension, server-sig-algs, is in widespread use. This is the extension that motivated this mechanism. It is needed to efficiently implement the rsa-sha2-256 and rsa-sha2-512 signature methods for user authentication. The client has a need to know the server-sig-algs information before it sends its first user authentication request.

If the EXT_INFO from the server is delayed – which it can be due to network fragmentation, even if the server follows the spec and sends it immediately after its NEWKEYS – this negatively impacts the client’s ability to pipeline user authentication. It’s not a breaking issue, but it creates a delay that affects user experience.

For example, the client knows that it’s going to authenticate using an RSA key, but it doesn’t know whether it’s going to use “ssh-rsa” or “rsa-sha2-256” or “rsa-sha2-512”. The client can’t guess, because there are servers that apply an authentication penalty for the wrong algorithm. To improve user experience (shorten delays), the client wants to pipeline the authentication request so it’s sent in the same socket write as its SSH_MSG_SERVICE_REQUEST (because there’s no reason to wait for SERVICE_ACCEPT).

If the EXT_INFO comes from the server in the same message as NEWKEYS, the client can pipeline the user authentication immediately. Otherwise, if the EXT_INFO is delayed, the client has to wait either until either EXT_INFO arrives, or SERVICE_ACCEPT is received (implying there won’t be an EXT_INFO at this stage, at least until successful authentication).

Does the draft need to be modified to make this explicit?


> and immediately after SSH_MSG_NEWKEYS", whose NEWKEYs?
> Logic would seem to indicate that it's after both sending and
> receiving NEWKEYs to confirm that the connection is secured,
> but the text is ambiguous.

The two sending directions are independent. EXT_INFO does not have the nature of a response, so it’s not conditional on anything happening in the other direction.

EXT_INFO is sent by the party that sends it, immediately after that party has sent its own NEWKEYS. Doing otherwise would contradict the “without delay” requirement.

Does the draft need to be modified to clarify this?


> Section 2.4: "If the client sent "ext-info-c", the server MAY send,
> but is not obligated to send, an SSH_MSG_EXT_INFO message
> immediately before SSH_MSG_USERAUTH_SUCCESS, as defined
> in [RFC4252]", I've already commented on this before, this just
> seems weird, the client sends its SSH_MSG_USERAUTH_REQUEST
> and instead of getting back SSH_MSG_USERAUTH_SUCCESS
> or SSH_MSG_USERAUTH_FAILURE it gets this odd out-of-place
> extension message packed in front of the success/failure
> indication that it's actually interested in.

We are discussing an SSH client that implements this specification, and therefore expects this message. Therefore, this message is not unexpected, and is exactly in its defined place.

Placement of this message immediately before SSH_MSG_USERAUTH_SUCCESS is the best time to send a second EXT_INFO, in case the SSH server wants to advertise extensions to authenticated clients that it does not want to advertise to unauthenticated ones.

One extension that needs this exact placement is “delay-compression”. For that to work, the client has a need to know whether compression should be started at the exact point it receives SSH_MSG_USERAUTH_SUCCESS. But the server may be reluctant to advertise its support for compression beforehand. Sending the second EXT_INFO at this time is therefore ideal for both parties. (If it was sent after SSH_MSG_USERAUTH_SUCCESS, there would be the exact race condition that “delay-compression” is trying to solve.)

In practice, handling this message at this time has been no trouble to implement. In our implementation, there has been literally zero extra code to support this.


> Section 3.1, "a client SHALL NOT", given that the rest of the
> document uses MUST or SHOULD it'd be better to use that
> form as well here to save people having to look up whether
> MUST or SHOULD is intended.

The word “shall” has a well-known meaning in English, and its use in this context is defined in RFC 2119. If this word was not meant to be used, I think RFC 2119 would not define it.

Someone who implements this draft will also likely have implemented RFC 4253 (The Secure Shell (SSH) Transport Layer Protocol), which uses SHALL in section 4.2.

I personally like this word. If a new version of the draft is needed for another reason, I can make this change, though.


> These proposals are removed due to current lack of implementation",
> isn't that an oxymoron?

I have seen implementation happen when a developer recognizes the need, and the RFC comes a few years later, if at all.

(For example, SFTP is in widespread use, but due to past implementer disagreement about whether there should be a version after 3, we have no RFC for SFTP. The SFTP drafts serve as the de facto spec.)

My understanding, also, is that IETF expects implementations to exist in order to bless an RFC – at least two independent implementations ideally, or at least one minimum. Perhaps I’m mistaken on this?


> I'm certainly ready to go with "no-flow-control", but haven't
> enabled it because I don't know what'll change, or break,
> before the spec is finalised.

That’s why I asked before if there’s actual interest in this extension. :-) I didn’t receive feedback, so after waiting a few months, I thought it would reduce the burden on the working group if I removed it.

At this point, I can:

- put it back in, just like it was; or

- make it an independent submission.

Given the cryptographic orientation of this group, and the flow-control oriented nature of this extension, perhaps an independent draft would be better? I’m doing something similar for “ext-auth-info” here:

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

The only problem with an independent submission, if I make it, is that I have no idea how to shepherd it to RFC. That doesn’t stop me from writing drafts, though, because experience with SFTP shows a draft is still better than nothing. :)

denis



From: Peter Gutmann 
Sent: Saturday, March 18, 2017 03:01
To: Daniel Migault ; curdle 
Subject: Re: [Curdle] Multiple WGLC

Daniel Migault <[e-mail]> writes:

>This emails starts a WGLC on the following drafts:
>
>    - draft-ietf-curdle-rsa-sha2-03 [1]
>    - draft-ietf-curdle-ssh-ext-info-02 [2]
>    - draft-ietf-curdle-ssh-kex-sha2-05 [3]
>    - draft-ietf-curdle-ssh-modp-dh-sha2-02 [4]
>
>Please provide your comments by March 28 on the mailing list. 

draft-ietf-curdle-ssh-modp-dh-sha2-02:

Section 5, "Many users seem to be interested in the perceived safety of using
larger MODP groups and hashing with SHA2-based algorithms", should that text
be there?  It seems rather out of place, orphaned between Figure 2 and the
References section.

draft-ietf-curdle-ssh-ext-info-02.txt:

Section 2.3, "This message is sent without delay", I'm not really sure what to
do with this requirement, why would there be a delay, necessitating a need to
say that it's sent without delay?

Section 2.3: "and immediately after SSH_MSG_NEWKEYS", whose NEWKEYs?  Logic
would seem to indicate that it's after both sending and receiving NEWKEYs to
confirm that the connection is secured, but the text is ambiguous.

Section 2.4: "If the client sent "ext-info-c", the server MAY send, but is not
obligated to send, an SSH_MSG_EXT_INFO message immediately before
SSH_MSG_USERAUTH_SUCCESS, as defined in [RFC4252]", I've already commented on
this before, this just seems weird, the client sends its
SSH_MSG_USERAUTH_REQUEST and instead of getting back SSH_MSG_USERAUTH_SUCCESS
or SSH_MSG_USERAUTH_FAILURE it gets this odd out-of-place extension message
packed in front of the success/failure indication that it's actually
interested in.

Section 3.1, "a client SHALL NOT", given that the rest of the document uses
MUST or SHOULD it'd be better to use that form as well here to save people
having to look up whether MUST or SHOULD is intended.

Section 3.2, "Former versions of this document defined extensions with names
enumerated in this heading. These proposals are removed due to current lack of
implementation", isn't that an oxymoron?  If it's not in a published RFC,
people will be reluctant to implement it, or enable it if it's implemented.
I'm certainly ready to go with "no-flow-control", but haven't enabled it
because I don't know what'll change, or break, before the spec is finalised.

Peter.

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