Subject: [Curdle] Multiple WGLC

From: Daniel Migault <[email-masked]>
Date: Tue, 14 Mar 2017 09:00:17 +0000

Hi,

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.

In order to ease tracking comments/reviews/issue raised, please make sure these are handled in a specific thread. Make sure the draft name is mentioned in the mail subject.

Yours,
Daniel

[1] https://datatracker.ietf.org/doc/draft-ietf-curdle-rsa-sha2/
[2] https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/
[3] https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-kex-sha2/
[4] https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-modp-dh-sha2/

[Ericsson]<http://www.ericsson.com/>

DANIEL MIGAULT
Researcher
Research

Ericsson
8500 Boulevard Decarie
H4P 2N2 Montreal, Canada
Phone +1 514 345 7900 46628
Mobile +1 514 452 2160
[email-masked]
www.ericsson.com

[http://www.ericsson.com/current_campaign]<http://www.ericsson.com/current_campaign>

Legal entity: Ericsson Canada Inc., registered office in Montreal. This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 18 Mar 2017 09:01:05 +0000

>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.

---

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Sat, 18 Mar 2017 07:30:48 -0600

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

Peter.

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

---

From: "Mark D. Baushke" <[email-masked]>
Date: Sat, 18 Mar 2017 11:24:36 -0700

> be there?  It seems rather out of place, orphaned between Figure 2 and the

Good point. I have removed this text in my copy of the draft.

It turns out I will not be able to upload a new draft until after this
IETF 98 is finished as the submission mechanism is currently suspended.

A similar issue applies to draft-ietf-curdle-ssh-kex-sha2-05.
This propposed update to the Key Exchange Algorithms list
should also probably be pointing to draft-ssorce-gss-keyex-sha2-00
"GSS-API Key Exchange with SHA2" for updates to gss-api-* key exchange
algorithms. There is also a need to republish draft-ietf-curdle-ssh-curves
so that draft-ietf-curdle-ssh-kex-sha2-06 will point to the unexpired
version.

	Thank you,
	-- Mark

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 18 Mar 2017 18:48:41 -0500

Replying to just a process point:

> 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 t…

You are probably thinking about getting a document published as a
full IETF Internet Standard, which does require at least two
interoperable implementations.  Less stringent RFC types, such as
Proposed Standard, Informational, and Experimental, do not have such
a requirement (though it's always good to have, of course).

-Ben

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 19 Mar 2017 09:06:30 +0000

denis bider (Bitvise) <[email-masked]> writes:

>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.

I don't really see what the problem is though, it's like putting up a "Beware
of the dog" sign on a property with no dog.  The text appears to be warning me
about doing something that I'm not doing anyway, and that I have no idea how
to do.  Since the EXT_INFO has to follow the NEWKEYS, it blocks all other
messages so I couldn't delay it even if I wanted to without stalling the whole
handshake process.
 
>Does the draft need to be modified to make this explicit?

It does need some explanatory text, I think. 
 
>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.

In that case it probably needs some security considerations text if it's sent
before the successful completion of the crypto handshake has been confirmed.
My guess is that putting the EXT_INFO inside the encrypted layer rather than
in the client/server hello like SSL does is to protect it cryptographically,
however sending EXT_INFO before you've got the other side's NEWKEYS means you
could be sending it over a link where the crypto protection hasn't been
successfully activated.
  
>Does the draft need to be modified to clarify this?

Yes, definitely, because I'd implemented it after both sending and receiving
NEWKEYS, for the reason given above.
 
>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.)

I think the draft should include some text like this as an explanatory note.
Getting EXT_INFO as a response to USERAUTH isn't a crash-and-burn thing, but
it just seems logically wrong to insert additional stuff in front of the
answer to the question you've asked.  So some explanatory text would be
useful.

>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.

The issue isn't that it's wrong, but a question of consistency, the rest of
the draft uses MAY and SHOULD, having an alternative synonym used in one
location makes it more difficult to read.
 
>- make it an independent submission.

I would put it back.  Having to do an entire RFC to document a single boolean
flag seems like incredible overkill.
 
Peter.

---

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Thu, 23 Mar 2017 06:01:19 -0600

> It does need some explanatory text, I think.

OK. Draft submissions are currently off, but I have clarified this in my 
local version with the following text:

This message is sent immediately after SSH_MSG_NEWKEYS,
without delay. This allows a client to pipeline an
authentication request after its SSH_MSG_SERVICE_REQUEST,
even when this needs extension information.

> In that case it probably needs some security considerations
> text if it's sent before the successful completion of the
> crypto handshake has been confirmed. My guess is that putting
> the EXT_INFO inside the encrypted layer rather than in the
> client/server hello like SSL does is to protect it
> cryptographically, however sending EXT_INFO before you've
> got the other side's NEWKEYS means you could be sending it
> over a link where the crypto protection hasn't been successfully
> activated.

I'm not sure that I see the threat here, or how the described behavior would 
resolve it.

NEWKEYS is the last message in each direction that is still sent with the 
old keys (or in plaintext). Therefore, receiving NEWKEYS does not provide 
any sense of certainty that encryption is properly in place. Instead, the 
sense of certainy is provided by the key exchange. Either the key exchange 
is secure, and data encrypted using it is secure, regardless of whether the 
other side sends anything; or it isn't.

As-is, a client might obtain crypto parameters from a completed key 
exchange, and then:

1. Send NEWKEYS with the old crypto parameters (or in plaintext if this is 
the first key exchange).

2. Send SERVICE_REQUEST, immediately followed by a USERAUTH message.

This can all be sent potentially in the same transmission as the client's 
NEWKEYS. If the client receives the server's NEWKEYS or not, it does not 
make a difference, because that's sent with the old crypto parameters (e.g. 
in plaintext).

This is not problematic for the client, because the client has already 
verified the identity of the server as part of the key exchange. If the key 
exchange is secure, anything the client sends will either be decrypted by 
the legitimate server, or it won't be decrypted.

Sending EXT_INFO is not problematic from the server's perspective either, 
because the server has not authenticated the client, and anything the server 
sends at this stage is world-readable. (Aside from IP blocking and similar, 
anyone can connect to the server, do their own key exchange, and get the 
info.)

> Yes, definitely, because I'd implemented it after
> both sending and receiving NEWKEYS, for the reason
> given above.

But I don't see what this would achieve, since NEWKEYS is still unencrypted. 
As-is, the server doesn't send an encrypted piece of information until it's 
replying to SERVICE_ACCEPT.

> The issue isn't that it's wrong, but a question of
> consistency, the rest of the draft uses MAY and SHOULD,
> having an alternative synonym used in one location makes
> it more difficult to read.

OK, I have changed SHALL to MUST.

> I would put it back.  Having to do an entire RFC to
> document a single boolean flag seems like incredible overkill.

OK, I have added back definitions for "no-flow-control" and "elevation".

I have recently implemented "delay-compression" in our SSH Server and 
Client.

Our FlowSsh library implements "elevation", and it's pending implementation 
in our SSH Server and Client.

I have left out "accept-channels" completely. I have changed my mind about 
it having a compelling reason, and I haven't noticed interest in it.

When re-adding "no-flow-control", I realized that the original definition is 
deficient, and allows no room for implementations that support this 
extension, but still prefer not to use it.

Ours would be an implementation like that. If this needs two implementations 
to be added, I will implement it to make life easier for implementers of 
simpler SSH software, but I would prefer not to use it.

I have therefore changed the definition as follows:

  string  "no-flow-control"
  string  choice of: "p" for preferred | "s" for supported

To take effect, this extension MUST be:

- Sent by both parties.
- At least one party MUST have sent the value "p" (preferred).

Since I cannot submit a new version right now, I attach a copy of my current 
local version.

denis

----- Original Message -----
From: Peter Gutmann
Sent: Sunday, March 19, 2017 03:06
To: denis bider (Bitvise) ; Daniel Migault ; curdle
Subject: Re: [Curdle] Comments on draft-ietf-curdle-ssh-ext-info

>nip the problem in the bud.

I don't really see what the problem is though, it's like putting up a 
"Beware
of the dog" sign on a property with no dog.  The text appears to be warning 
me
about doing something that I'm not doing anyway, and that I have no idea how
to do.  Since the EXT_INFO has to follow the NEWKEYS, it blocks all other
messages so I couldn't delay it even if I wanted to without stalling the 
whole
handshake process.

>sent its own NEWKEYS. Doing otherwise would contradict the “without delay”

In that case it probably needs some security considerations text if it's 
sent
before the successful completion of the crypto handshake has been confirmed.
My guess is that putting the EXT_INFO inside the encrypted layer rather than
in the client/server hello like SSL does is to protect it cryptographically,
however sending EXT_INFO before you've got the other side's NEWKEYS means 
you
could be sending it over a link where the crypto protection hasn't been
successfully activated.

>- make it an independent submission.

I would put it back.  Having to do an entire RFC to document a single 
boolean
flag seems like incredible overkill.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 25 Mar 2017 10:02:27 +0000

>I'm not sure that I see the threat here, or how the described behavior would

I was thinking of it in terms of SSL's Change Cipherspec, the same as SSH's
Newkeys, where there's all sorts of subtle problems if you send data before
getting the other side's CCS to confirm that both sides are using the same
crypto parameters.  I'd always assumed that SSH's use of the redudant
SSH_MSG_SERVICE_REQUEST followed by a SSH_MSG_USERAUTH_REQUEST was that you
checked that the SSH_MSG_SERVICE_REQUEST succeeded, in other words that both
sides had scuccessfully agreed on the same crypto parameters, before sending
sensitive data in the SSH_MSG_USERAUTH_REQUEST.  So the point of the
SSH_MSG_SERVICE_REQUEST wasn't so much getting back the "yeah, sure, whatever"
response from the server, it was being able to verify that you could decrypt
and MAC the response you got.

>NEWKEYS. 

Ugh.  So there are implementations that will send a NEWKEYS + SERVICE_REQUEST
+ USERAUTH all in one block without having any idea wheteher the crypto
handshake process has succeeded?

>replying to SERVICE_ACCEPT.

See above, I was using the SERVICE_REQUEST + SERVICE_ACCEPT to verify that
client and server are on the same page cryptographically.

>- At least one party MUST have sent the value "p" (preferred).

That seems a bit wierd... the fact that a client or server is sending no-flow-
control already says "supported".  So you really just need at least one side
to set a boolean flag saying "yes, I really want this".  In other words no-
flow-control + boolean = false says the option is available, and boolean =
true says you must enable the option.

Peter.

---

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Sat, 25 Mar 2017 13:52:43 -0600

Peter:

> I was thinking of it in terms of SSL's Change Cipherspec,
> the same as SSH's Newkeys, where there's all sorts of
> subtle problems if you send data before getting the other
> side's CCS to confirm that both sides are using the same
> crypto parameters.

Can you point out some of these subtle problems that could occur in this 
regard in SSH?

> So the point of the SSH_MSG_SERVICE_REQUEST wasn't so much
> getting back the "yeah, sure, whatever" response from the
> server, it was being able to verify that you could decrypt

If that was a primary purpose, rather than a side effect, I imagine there 
would be an SSH_MSG_NEWKEYS_VERIFY, which would be encrypted with the new 
crypto parameters. This could be sent immediately after SSH_MSG_NEWKEYS, 
which is the last message that uses old parameters.

But yes, it's possible this is a desired side effect. In this case, if the 
server sends EXT_INFO immediately after NEWKEYS, and client wants to wait 
for a successful encrypted packet before queueing up an authentication 
request; this lets the client queue up the authentication request faster, 
because it doesn't have to wait for SERVICE_ACCEPT. Instead, the server's 
EXT_INFO already serves this role.

The server's EXT_INFO doesn't contain confidential information (client is 
not authenticated), so there is no problem there.

This leaves the situation that the client may be sending its own EXT_INFO 
after NEWKEYS. Perhaps an extension will be defined where the client would 
send info here it doesn't want to make public. (Currently, I don't know of 
one.)

Under the assumption that such an extension were defined, can you point out 
at least one way that sending this info right after NEWKEYS can help an 
attacker?

> > 2. Send SERVICE_REQUEST, immediately followed by a USERAUTH
> > message. This can all be sent potentially in the same
> > transmission as the client's NEWKEYS.
>
> Ugh. So there are implementations that will send a NEWKEYS +
> SERVICE_REQUEST + USERAUTH all in one block without having
> any idea wheteher the crypto handshake process has succeeded?

It is possible. However, I'm not aware that an implementation actually does 
this. Ours waits for SERVICE_ACCEPT. I checked three others; they wait too.

> So you really just need at least one side to set a boolean
> flag saying "yes, I really want this".  In other words
> no-flow-control + boolean = false says the option is
> available, and boolean = true says you must enable the option.

Yes. But the extension value field is generically a string (it must be same 
type for all extensions, so unsupported extensions can be decoded and 
ignored). "p" and "s" are therefore fitting ways to express this boolean.

This week, I implemented "no-flow-control" in our software (in the manner 
recently defined - using "p" to indicate preferred, and "s" for supported). 
It works, but I point out that testing indicates zero performance benefit 
between our SSH Client and Server. In other words, regular SSH flow control 
has no handbrake effect if it's done right.

The main advantages I see with this extension are:

- In 10 years: it could become widely supported, and new simpler SSH 
software that only needs one channel can avoid complexity, and never 
implement SSH flow control.

- Right now: authors who are having trouble with their window adjusting can 
sidestep that by implementing "no-flow-control" in addition.

Properly implemented flow control is superior. However, this extension is a 
nod to that not everyone will be using an SSH library that does this right, 
and "no-flow-control" is a better option if your needs are simple, and you 
don't have a few years to get this right.

denis

----- Original Message -----
From: Peter Gutmann
Sent: Saturday, March 25, 2017 04:02
To: denis bider (Bitvise) ; Daniel Migault ; curdle
Subject: Re: [Curdle] Comments on draft-ietf-curdle-ssh-ext-info

SSH_MSG_SERVICE_REQUEST wasn't so much getting back the "yeah, sure, 
whatever"

>This can all be sent potentially in the same transmission as the client's

Ugh.  So there are implementations that will send a NEWKEYS + 
SERVICE_REQUEST
+ USERAUTH all in one block without having any idea wheteher the crypto
handshake process has succeeded?

>- At least one party MUST have sent the value "p" (preferred).

That seems a bit wierd... the fact that a client or server is sending 
no-flow-

Peter.