Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-ext-info-02.txt

From: Румен Петров <[email-masked]>
Date: Sat, 18 Mar 2017 10:26:55 +0200

[email-masked] wrote:
> 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           : Extension Negotiation in Secure Shell (SSH)
>          Author          : Denis Bider
> 	Filename        : draft-ietf-curdle-ssh-ext-info-02.txt
> 	Pages           : 8
> 	Date            : 2017-02-27
It seems to me published version is 3 - 
https://tools.ietf.org/html/draft-ietf-curdle-rsa-sha2-03 .

> Abstract:
>    This memo defines a mechanism for SSH clients and servers to exchange
>    information about supported protocol extensions confidentially after
>    completed key exchange.

Following notation s/old/new/ is used to describe proposed text 
substitution.

About chapter:
(*) 2 . "Public Key Algorithms":
This chapter is mainly for algorithms not signatures:
... The following new s/signature/public key/ algorithms are defined: ...
... These s/signature //algorithms are suitable for use both in the SSH 
transport ....

(*) 2.1. Use for server authentication
What about
... server sends an s/"ssh-rsa" public key/RSA public key in "ssh-rsa" 
format/ as part of the negotiated key exchange method ... ?

(*) 2.2.  Use for client authentication
...The "public key blob" field encodes the RSA public key using the 
"ssh-rsa" s/algorithm name/format/...

Regards,
Roumen Petrov

---

From: Румен Петров <[email-masked]>
Date: Sat, 18 Mar 2017 15:18:50 +0200

Hello

Sorry for confusion in my previous feedback, quote below I chose wrong 
subject.

About

About (*)
3.1. "server-sig-algs" from draft-ietf-curdle-ssh-ext-info-02.txt
I'm not sure why whole chapter use signature(?) algorithm .

Draft draft-ietf-curdle-rsa-sha2-03 describes new public key algorithm.
In rfc4252 and rfc4253 is used public key algorithm.

I think that correct option must use "public key" instead "signature" in 
its name and chapter to

mention only algorithms.

About  name-list s/signature/publickey/-algorithms-accepted

Its not clear how to list "publickey" algorithms. name-list is
- list of strings, each string is name of public key algorithm
- space separated list of public key algorithm names
- comma separated list of public key algorithm names

(*) 3.2.  "no-flow-control", "accept-channels", "elevation"
It seems to me those elements  are subject of future extension.
If necessary they could be described in new draft.

Regards,
Roumen Petrov

P.S. previous feedback:

Румен Петров wrote:
> [SNIP]
> ... These s/signature //algorithms are suitable for use both in the 
> SSH transport ....
>
>

---

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

Reply to Roumen Petrov’s comments on draft-ietf-curdle-rsa-sha2:

>  > draft-ietf-curdle-ssh-ext-info-02.txt
>
> https://tools.ietf.org/html/draft-ietf-curdle-rsa-sha2-03

These are related, but separate drafts. The EXT_INFO draft is right now at version 2. The rsa-sha2 draft is at version 3.

> ... The following new s/signature/public key/ algorithms ...

The main idea of this draft is to specify use of existing RSA keys deployed in SSH with SHA-2 signatures, without having to replace the RSA keys with new ones just to get better signatures.

If we specified a new "public key algorithm” as this term is currently defined, this would imply a new key format, which would change encoded key fingerprints, which would break trust between existing deployed clients and servers. This would guarantee that take-up of SHA-2 signatures takes a decade.

This draft therefore does not define a new "public key algorithm", but instead defines a new "signature algorithm" as a separate concept. This is so an existing RSA key can stay an "ssh-rsa" key, but we now have signature algorithms "ssh-rsa", "rsa-sha2-256", and "rsa-sha2-512".

Before this draft, SSH uses the following terminology:

- "public key algorithm" means the algorithm used to generate the key; as well as the format used to encode the key; as well as the algorithm used to perform the signature.

The draft as-is decouples this term as follows:

- "public key algorithm" means the algorithm used to generate the key; as well as the format used to encode the key.

- "signature algorithm" means the algorithm used to perform the signature.

Compared to before the draft, the draft reduces the term "public key algorithm" to 2/3 of its current meaning, and carves out a new term "signature algorithm" for the remaining 1/3 of the meaning. The existing IANA table “Public Key Algorithm Names” is kept the same, and a new table is added.

It appears to me what you are proposing is the following:

- "public key format" to mean the algorithm used to generate the key; as well as the format used to encode the key.

- "public key algorithm" to mean the algorithm used to perform the signature.

Compared to before the draft, this suggestion would reduce the term "public key algorithm" to 1/3 of its current meaning, and assign a new term "public key format" for the remaining 2/3 of the meaning. The existing IANA table “Public Key Algorithm Names” would have to be renamed to “Public Key Format Names”, and a new table named “Public Key Algorithm Names” would have to be added.

I think this would be slightly more confusing than what the draft currently does.

denis

From: Румен Петров 
Sent: Saturday, March 18, 2017 02:26
To: [email-masked] 
Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-ext-info-02.txt

About chapter:

Regards,
Roumen Petrov

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

---

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Sat, 18 Mar 2017 08:29:47 -0600

Roumen:

> I think that correct option must use "public key" instead "signature"
> in its name and chapter to mention only algorithms.

I believe the opposite, as explained in my previous reply.

> - comma separated list of public key algorithm names

The term "name-list" is defined in RFC 4251:

https://tools.ietf.org/html/rfc4251

Although this RFC is not listed as a direct normative reference for this draft, the term "name-list" is used in both RFC 4252, and RFC 4253, which are listed as normative references.

> If necessary they could be described in new draft.

Yes. Previous versions of this draft contained definitions for those extensions. These were published for over a year before they were removed. Since drafts are public, and existence of implementations cannot be excluded, it would be irresponsible to not mention that these names, in particular, already have meanings - even if this draft has dropped pursuing those extensions at this time.

denis

From: Румен Петров 
Sent: Saturday, March 18, 2017 07:18
To: [email-masked] 
Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-ext-info-02.txt

Hello

About

About (*)

mention only algorithms.

Regards,
Roumen Petrov

P.S. previous feedback:

---

From: Румен Петров <[email-masked]>
Date: Sat, 18 Mar 2017 16:39:44 +0200

HI Denis,

denis bider (Bitvise) wrote:
[SNIP]
> - "public key algorithm" means the algorithm used to generate the key; as well as the format used to encode the key; as well as the algorithm used to perform the signature.
No. Before this draft, RFC 6187 defines new public key algorithms with 
new format to encode the key and existing signature format, i.e. 
new/new/old.
You proposition is new/old/new. I'm fine with your arguments to reuse 
public key blog, but I disagree that draft-ietf-curdle-rsa-sha2 does not 
define new algorithm.

Quote from rfc4252:

  byte      SSH_MSG_USERAUTH_REQUEST
       string    user name
       string    service name
       string    "publickey"
       boolean   TRUE
       string    public key algorithm name <<<<-----
       string    public key to be used for authentication
       string    signature

and from draft :

  byte      SSH_MSG_USERAUTH_REQUEST
     string    user name
     string    service name
     string    "publickey"
     boolean   TRUE
     string    "rsa-sha2-512" <<<<----- public
     string    public key blob:
         string    "ssh-rsa"
         mpint     e
         mpint     n
     string    signature:
         string    "rsa-sha2-512"
         string    rsa_signature_blob

If in draft your replace "rsa-sha2-512" with ssh-rsa I will agree that 
draft is only with signature algorithm, i.e. old/old/new.

Draft sample shows new public key algorithm.
I could guess that you start with only with new signatures but now I see 
more enhanced encoding of authentication request.

[SNIP]
Roumen

---

From: Румен Петров <[email-masked]>
Date: Sat, 18 Mar 2017 16:48:44 +0200

denis bider (Bitvise) wrote:
> [SNIP]These were published for over a year before they were removed. 
> Since drafts are public, and existence of implementations cannot be 
> excluded, [SNIP]

I don't know well process of RFC creation and may be there is written 
rule(requirement) like above.
 From my point of view draft or RFC should not describe experimental or 
not accepted information.

Roumen

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 18 Mar 2017 15:22:22 +0000

>  From my point of view draft or RFC should not describe experimental or not
> accepted information.

There are different "tracks" in RFC's, including experimental.  This link may help: https://www.ietf.org/iesg/informational-vs-experimental.html

---

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Thu, 23 Mar 2017 05:54:02 -0600

Hello Roumen:

> [...]

Thank you for pointing this out. This is an important point. The document 
needs a more formal discussion to properly introduce the concept for 
"signature algorithm".

Draft submissions are currently off, but I have clarified this in my local 
version with an additional section that discusses the terms "public key 
algorithm" and "signature algorithm" in detail. It also points out two 
places in RFC4252 and RFC4253 which subtly change meaning, and now encode a 
signature algorithm name.

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

> From my point of view draft or RFC should not describe
> experimental or not accepted information.

This may conflict with Peter's request, which is to include the definition 
of the "no-flow-control" extension. My understanding is that he intends to 
implement it, but wishes to see the language finalized before doing so.

For the time being, I have re-added "no-flow-control" in my local version.

Besides "no-flow-control", all other extensions ("server-sig-algs", 
"delay-compression", "elevation") are currently implemented.

denis

----- Original Message -----
From: Румен Петров
Sent: Saturday, March 18, 2017 08:39
To: [email-masked]
Subject: Re: [Curdle] Comments on draft-ietf-curdle-rsa-sha2

HI Denis,

> - "public key algorithm" means the algorithm used to generate the key; as 
> well as the format used to encode the key; as well as the algorithm used 
> to perform the signature.

Quote from rfc4252:

and from draft :

[SNIP]
Roumen

---

From: Румен Петров <[email-masked]>
Date: Sun, 26 Mar 2017 14:21:58 +0300

Hi Denis and members of curdle group,

denis bider (Bitvise) wrote:
>> stringÃÂ ÃÂ ÃÂ  public key algorithm name <<<<-----
>
> Thank you for pointing this out. This is an important point. The 
> document needs a more formal discussion to properly introduce the 
> concept for "signature algorithm".
>
> Draft submissions are currently off, but I have clarified this in my 
> local version with an additional section that discusses the terms 
> "public key algorithm" and "signature algorithm" in detail. It also 
> points out two places in RFC4252 and RFC4253 which subtly change 
> meaning, and now encode a signature algorithm name.
>
> Since I cannot submit it right now, I attach a copy of my current 
> local version.
I have objection to change meaning of public key algorithm identifier . 
It is well defined in chapter 6.6. "Public Key Algorithms" of RFC 4253.

I cannot understand the goal of such change ("*Signature Algorithm as 
Distinct Aspect of* Public Key *Algorithm*").
You define new "public key algorithm identifier" and signature 
identifier is same although it not necessary as is by default "Public 
key/certificate formats that do not explicitly specify a signature 
format identifier MUST use the public key/certificate format identifier 
as the signature identifier."

It seems to me you would like to swap(replace) "public key" with 
"signature" in all RFC documents with this document(draft).

Why to redefineconcept?
Is not more easy to define new public-key algorithms? Such definition 
does not require relation with server extension. If server extension is 
not accepted then "rsa-sha2" should be canceled (suspended).

[SNIP]

Regards,
Roumen Petrov

P.S. attachment "rsa-sha2-03_vs_04.html" is deference in html format 
between v3 and v4.

---

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Sun, 26 Mar 2017 12:03:22 -0600

Objection noted. I disagree. I have explained, I have addressed, and will not argue this further.

From: Румен Петров 
Sent: Sunday, March 26, 2017 05:21
To: [email-masked] 
Subject: Re: [Curdle] Comments on draft-ietf-curdle-rsa-sha2

denis bider (Bitvise) wrote:
>> stringÃ‚Â Ã‚Â Ã‚Â  public key algorithm name <<<<-----
>

Why to redefineconcept?

[SNIP]

Regards,
Roumen Petrov

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