Subject: [Curdle] WG status

From: Daniel Migault <[email-masked]>
Date: Sun, 16 Apr 2017 20:30:32 -0400

Hi,

My understanding is that the WG has reached consensus over the following
drafts, and these drafts are ready to be sent to the IESG. If you have any
comments, feel free to provide them as soon as possible.

draft-ietf-curdle-ssh-ext-info-04
<https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/>
draft-ietf-curdle-ssh-modp-dh-sha2-04
<https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-modp-dh-sha2/>
draft-ietf-curdle-rsa-sha2-05
<https://datatracker.ietf.org/doc/draft-ietf-curdle-rsa-sha2/>

The following draft is the one the WG should be focused on. Please provide
review ;-)
draft-ietf-curdle-ssh-kex-sha2-08
<https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-kex-sha2/>

The following drafts are on call for adoption until April 26.
https://www.ietf.org/id/draft-ssorce-gss-keyex-sha2-00.txt
https://tools.ietf.org/html/draft-kaduk-kitten-des-des-des-die-die-die-01

Yours,
Daniel

---

From: Румен Петров <[email-masked]>
Date: Mon, 17 Apr 2017 10:58:45 +0300

Daniel Migault wrote:
> Hi,
>
> My understanding is that the WG has reached consensus over the 
> following drafts, and these drafts are ready to be sent to the IESG. 
> If you have any comments, feel free to provide them as soon as possible.
Consensus?
> <https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/>
Hmm,
"server-sig-algs" is misleading . It is designed against the current 
rules (RFC) that design "Public Key Algorithms"!

> [SNIP] 
Same here. In fact design is for new public key algorithm, but 
paragraphs state something different.

> [SNIP]
Regards,
Roumen Petrov

---

From: denis bider <[email-masked]>
Date: Mon, 17 Apr 2017 02:41:52 -0600

I disagree:

- The terminology is not misleading. It has been made further clearer and
more explicit after your feedback.

- The "server-sig-algs" extension has been in use, under this name, by
multiple implementations, for over a year. If the terminology were changed
now, the name of the extension would have to remain. The name of the
extension would conflict with the terminology you suggest.

- There appears to be no benefit to your suggestion. It would confuse
things by changing terminology that has already been adopted, with
terminology that you personally find preferable, without changing any of
the mechanics.

I consider this a bikeshedding issue, and hold you personally in disregard.

On Mon, Apr 17, 2017 at 1:58 AM, Румен Петров <[email-masked]>
wrote:

>> draft-ietf-curdle-ssh-ext-info-04 <https://datatracker.ietf.org/
>> doc/draft-ietf-curdle-ssh-ext-info/>
>>
> Hmm,
> "server-sig-algs" is misleading . It is designed against the current rules
> (RFC) that design "Public Key Algorithms"!
>
>
> [SNIP] <https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-modp
>> -dh-sha2/>
>> draft-ietf-curdle-rsa-sha2-05 <https://datatracker.ietf.org/
>> doc/draft-ietf-curdle-rsa-sha2/>
>>
> Same here. In fact design is for new public key algorithm, but paragraphs
> state something different.
>
> [SNIP]
>>
>> Yours,
>> Daniel
>>
> Regards,
> Roumen Petrov
>
> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle
>

---

From: denis bider <[email-masked]>
Date: Mon, 17 Apr 2017 03:02:00 -0600

OK, that was a bit harsh.

>From my perspective, this objection is exceptionally annoying because it's
a single person requesting a rework of the entire document in order to
change terminology in a way that in my view does not improve clarity, and
does not impact mechanics.

But maybe I'm not seeing some problem that Roumen is seeing. If there's
someone else seeing the same problem Roumen is seeing, I can rework the
document to change this terminology. But I would really not like to do this
unless it's agreed it is necessary by multiple people (and is not objected
by others whose objections are stronger).

---

From: Румен Петров <[email-masked]>
Date: Mon, 17 Apr 2017 12:19:36 +0300

denis bider wrote:
> I disagree:
>
> - The terminology is not misleading. It has been made further clearer 
> and more explicit after your feedback.
Public key algorithm is unique and 2 algorithms could share same 
signature (format) - see RFC 4253 , 5656 and 6187.
No with updated version you go in wrong direction.  The whole chapter 
"2. Signature Algorithm as Distinct Aspect of Public Key Algorithm" is 
against principles of above RFC.

> multiple implementations, for over a year. If the terminology were 
> changed now, the name of the extension would have to remain. The name 
> of the extension would conflict with the terminology you suggest.
It make no sense to point to that exist implementation of 
"server-sig-algs". Yes, I know, but it is implemented by secure shells 
with limited support of public key algorithms. More over in one "widely" 
distributed it was broken until recent release. Practically this mean 
that is even not distributed in real word.

> terminology that you personally find preferable, without changing any 
> of the mechanics.
You are the author that try to change existing terminology in secure 
shell design.

If server sends signature "ecdsa-sha2-nistp256" there is no way client 
cannot distinguish which public key algorithms to use 
x509v3-ecdsa-sha2-nistp256 or ecdsa-sha2-nistp256?

[SNIP]
Roumen

---

From: Румен Петров <[email-masked]>
Date: Mon, 17 Apr 2017 13:02:23 +0300

denis bider wrote:
> From my perspective, this objection is exceptionally annoying because 
> it's a single person requesting a rework of the entire document in 
> order to change terminology in a way that in my view does not improve 
> clarity, and does not impact mechanics.
It is because few secsh implementation support extension. I know only 
four. Next point is that existence of one implementation is not argument 
for acceptance. In current case is not used locally defined name with 
"at-sign" and etc.
It is not first time that someone say but foo is already implemented and 
we cannot change this. Why? First precedent is why something is 
implemented as public name foo instead as locally defined foo@bar?

I wonder what you would like IANA to register .
Lest check following  rfc/chapters:

- 4250 / 4.11.3.  Public Key Algorithm Names
Public Key Algorithm Name                 Reference
          -------------------------                 ---------
          ssh-dss                            [SSH-TRANS, Section 6.6]
          ssh-rsa                            [SSH-TRANS, Section 6.6]
          pgp-sign-rsa                       [SSH-TRANS, Section 6.6]
          pgp-sign-dss                       [SSH-TRANS, Section 6.6]

- 5656/ 11.  IANA Considerations
    Consistent with Section 8 of [RFC4251] and Section 4.6 of [RFC4250],
    this document makes the following registrations:
    In the Public Key Algorithm Names registry: The family of SSH public
    key algorithm names beginning with "ecdsa-sha2-" and not containing
    the at-sign ('@'), to name the public key algorithms defined in
    Section 3.

- 6187 / 6.  IANA Considerations
    Consistent with Section 8 of [RFC4251] and Section 4.6 of [RFC4250],
    this document makes the following registrations:
    In the Public Key Algorithm Names registry:
    o  The SSH public key algorithm "x509v3-ssh-dss".
    o  The SSH public key algorithm "x509v3-ssh-rsa".
    o  The SSH public key algorithm "x509v3-rsa2048-sha256".
    o  The family of SSH public key algorithm names beginning with
       "x509v3-ecdsa-sha2-" and not containing the at-sign ('@').

There is no request for signature algorithm.

Please note and "not containing the at-sign ('@')"! Good practice to 
implement new feature and the to ask for acceptance.

Plus the fact that five "Public Key Algorithm" x509v3-ssh-* and 
x509v3-ecdsa-* reuse signature algorithm ...

[SNIP]

Regards,
Roumen Petrov

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 17 Apr 2017 12:45:56 +0000

Thanks for your second note.

Does anyone else agree with Roumen?  Please post by within a couple of days, otherwise we will consider the issue closed.

--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: [email-masked] Twitter: RichSalz

---

From: Daniel Migault <[email-masked]>
Date: Mon, 24 Apr 2017 16:54:24 -0400

Hi everyone,

We need some feed back to make sure we take the correct decision. Please
continue the discussion.

Yours,
Daniel

On Mon, Apr 17, 2017 at 8:45 AM, Salz, Rich <[email-masked]> wrote:

> Does anyone else agree with Roumen?  Please post by within a couple of
> days, otherwise we will consider the issue closed.
>
>
>
> --
>

---

From: Daniel Migault <[email-masked]>
Date: Sun, 30 Apr 2017 14:08:37 -0400

Hi,

So far we have not received many inputs and I would like to make sure we
understand Romen's concern. My understanding of the concerned raised by
Romen is that specifying signature algorithms may complexity the ways
Public Key Algorithm registries are designated.  However it looks to me one
reason is that we are moving from implicit signature scheme to explicit
ones.

Romen please re-state your issues with the draft, clearly expose the issues
as well as the alternate you would fine acceptable.

Yours,
Daniel

On Mon, Apr 24, 2017 at 4:54 PM, Daniel Migault <[email-masked]

---

From: Jim Schaad <[email-masked]>
Date: Sun, 30 Apr 2017 21:55:15 +0200

Given that we are talking about ssh – I do not have any opinion at this time.  I have never implemented nor really used ssh w/o an intermediary

Jim

From: Curdle [mailto:[email-masked]] On Behalf Of Daniel Migault
Sent: Sunday, April 30, 2017 8:09 PM
To: Salz, Rich <[email-masked]>
Cc: curdle <[email-masked]>; denis bider <[email-masked]>; Румен Петров <[email-masked]>
Subject: Re: [Curdle] WG status

Hi, 

So far we have not received many inputs and I would like to make sure we understand Romen's concern. My understanding of the concerned raised by Romen is that specifying signature algorithms may complexity the ways Public Key Algorithm registries are designated.  However it looks to me one reason is that we are moving from implicit signature scheme to explicit ones. 

Romen please re-state your issues with the draft, clearly expose the issues as well as the alternate you would fine acceptable.

Yours, 

Daniel 

On Mon, Apr 24, 2017 at 4:54 PM, Daniel Migault <[email-masked] <mailto:[email-masked]> > wrote:

Hi everyone, 

We need some feed back to make sure we take the correct decision. Please continue the discussion.  

Yours, 

Daniel

On Mon, Apr 17, 2017 at 8:45 AM, Salz, Rich <[email-masked] <mailto:[email-masked]> > wrote:

--  

Member, OpenSSL Dev Team

IM: [email-masked] <mailto:[email-masked]>  Twitter: RichSalz

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

---

From: Damien Miller <[email-masked]>
Date: Mon, 1 May 2017 13:59:44 +1000 (AEST)

On Sun, 30 Apr 2017, Daniel Migault wrote:

> Romen is that specifying signature algorithms may complexity the ways Public
> Key Algorithm registries are designated.  However it looks to me one reason
> is that we are moving from implicit signature scheme to explicit ones.
> 

Speaking as a maintainer of one of the implementations (OpenSSH) that
has support for the draft, I don't think the draft needs changing.
In particular, altering the "server-sig-algs" message on the wire
has zero implications for registries and will only break working
implementations.

-d