Re: [Curdle] WG status

Румен Петров <pkixssh@roumenpetrov.info> Mon, 17 April 2017 09:19 UTC

Return-Path: <pkixssh@roumenpetrov.info>
X-Original-To: curdle@ietfa.amsl.com
Delivered-To: curdle@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03E5B129418 for <curdle@ietfa.amsl.com>; Mon, 17 Apr 2017 02:19:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.579
X-Spam-Level:
X-Spam-Status: No, score=-1.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJsciWfdFLi4 for <curdle@ietfa.amsl.com>; Mon, 17 Apr 2017 02:19:40 -0700 (PDT)
Received: from rila.superhosting.bg (rila.superhosting.bg [91.196.125.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E64CB129BB5 for <curdle@ietf.org>; Mon, 17 Apr 2017 02:19:38 -0700 (PDT)
Received: from [78.128.48.21] (port=57560 helo=[192.168.0.10]) by rila.superhosting.bg with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from <pkixssh@roumenpetrov.info>) id 1d02op-000Huf-Jm for curdle@ietf.org; Mon, 17 Apr 2017 12:19:35 +0300
Message-ID: <58F488A8.8020800@roumenpetrov.info>
Date: Mon, 17 Apr 2017 12:19:36 +0300
From: =?UTF-8?B?0KDRg9C80LXQvSDQn9C10YLRgNC+0LI=?= <pkixssh@roumenpetrov.info>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30
MIME-Version: 1.0
CC: curdle <curdle@ietf.org>
References: <CADZyTkkd-JpsE89z=P10Y0esc1NCZydD5NqMTs8E5xUz-DMT_g@mail.gmail.com> <58F475B5.4090504@roumenpetrov.info> <CADPMZDBjgpzMKp1UJqWMC_xRZpfce=wOOsE51HwY2dEO73kKeA@mail.gmail.com>
In-Reply-To: <CADPMZDBjgpzMKp1UJqWMC_xRZpfce=wOOsE51HwY2dEO73kKeA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - rila.superhosting.bg
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - roumenpetrov.info
X-Get-Message-Sender-Via: rila.superhosting.bg: authenticated_id: master78@roumenpetrov.info
X-Authenticated-Sender: rila.superhosting.bg: master78@roumenpetrov.info
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/qGZ45_VQ-jpFvlG2GdGzLt9h3bc>
Subject: Re: [Curdle] WG status
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "List for discussion of potential new security area wg." <curdle.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/curdle>, <mailto:curdle-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/curdle/>
List-Post: <mailto:curdle@ietf.org>
List-Help: <mailto:curdle-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/curdle>, <mailto:curdle-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Apr 2017 09:19:42 -0000

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.


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


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