IETF Logo Mail Archive

Re: [Curdle] Alexey Melnikov's Discuss on draft-ietf-curdle-ssh-ext-info-12: (with DISCUSS and COMMENT)

Adam Roach <adam@nostrum.com> Thu, 14 September 2017 17:46 UTC

Return-Path: <adam@nostrum.com>
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 9A0AA132710; Thu, 14 Sep 2017 10:46:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Level:
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham 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 a8nTSCTkHbjP; Thu, 14 Sep 2017 10:46:58 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DB3B1326FE; Thu, 14 Sep 2017 10:46:57 -0700 (PDT)
Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8EHkpqX087913 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 14 Sep 2017 12:46:52 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local
To: denis bider <denisbider.ietf@gmail.com>
Cc: Eric Rescorla <ekr@rtfm.com>, Daniel Migault <daniel.migault@ericsson.com>, Alexey Melnikov <aamelnikov@fastmail.fm>, curdle-chairs <curdle-chairs@ietf.org>, curdle <curdle@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-curdle-ssh-ext-info@ietf.org
References: <150530402783.30467.17664468923363358742.idtracker@ietfa.amsl.com> <CADPMZDAENLRJEhbhYv86L=Q9v9nARtsrkicyPg86yGqrjUP0mg@mail.gmail.com> <1505308325.2062993.1104706296.3E3DDD7F@webmail.messagingengine.com> <CADPMZDAqb8QND30c+zADZRz4yo=XL_5=DYOkRPA=OCp55tq+yg@mail.gmail.com> <CABcZeBN7kYhV_1kzP21B6gAdOOnf60bkC5dcqbLDvAxdgtqGLA@mail.gmail.com> <CADPMZDBMLNamDq+32S9t=e5-dp4w3-tiu92cVjuvVgej0_Epzg@mail.gmail.com> <344c3cf4-029e-8a8c-ab83-42e18002da23@nostrum.com> <CADPMZDBTrKFp=zVHe3igXg6e_P05K+gzVrNfm4ybcfzS0_rsbQ@mail.gmail.com> <5e1427b5-671f-4bda-5f63-544172849252@nostrum.com> <CADPMZDB-1t=MPks35AbXv2oLEg97u6Mqs-oO0WCzPCJzw_n3Vg@mail.gmail.com>
From: Adam Roach <adam@nostrum.com>
Message-ID: <5f0be446-7566-4c9c-4041-23c25f879374@nostrum.com>
Date: Thu, 14 Sep 2017 12:46:46 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <CADPMZDB-1t=MPks35AbXv2oLEg97u6Mqs-oO0WCzPCJzw_n3Vg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------BD6E2BFEAE5C2028BC458151"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/65JR8k9-wWYOyaant8d3m4m2Hig>
Subject: Re: [Curdle] Alexey Melnikov's Discuss on draft-ietf-curdle-ssh-ext-info-12: (with DISCUSS and COMMENT)
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: Thu, 14 Sep 2017 17:47:00 -0000

Thanks! The changes look good.

/a

On 9/14/17 12:31, denis bider wrote:
> Just to be sure, I've uploaded a new version that does contain the 
> extra explanation as well. Let me know if it's clearer.
>
> On Thu, Sep 14, 2017 at 11:24 AM, Adam Roach <adam@nostrum.com 
> <mailto:adam@nostrum.com>> wrote:
>
>     Ah, okay. I thought I'd asked earlier for an example of nested
>     strings, and was interpreting your lack of response as a lack of
>     such thing. If this kind of nesting is commonplace for the base
>     protocol, then I'm okay with the current formulation. My concern
>     was that this looked like something novel, but with only a loosely
>     implied encoding.
>
>     I'll clear my discuss. Thanks for the explanation.
>
>     /a
>
>
>     On 9/14/17 12:16, denis bider wrote:
>>     But seriously, the spec defines the encoding. There needs to be
>>     no guessing. The definition is right there. The example further
>>     fool-proofs so there's no excuse for anyone to misunderstand.
>>
>>     Nested strings in SSH are not weird. They are used ubiquitously.
>>     For example, in public key authentication, the public key is
>>     encoded as a string. This string itself contains other strings
>>     which are part of the public key format. This is not unusual.
>>     Anyone who works with SSH would be familiar with this.
>>
>>     On Thu, Sep 14, 2017 at 8:15 AM, Adam Roach <adam@nostrum.com
>>     <mailto:adam@nostrum.com>> wrote:
>>
>>         On 9/14/17 08:08, denis bider wrote:
>>
>>             Submitted. :-)
>>
>>
>>         Thanks. This newest version includes an example, but no
>>         further explanation of the encoding. Normative examples that
>>         implementors have to reverse engineer are generally bad for
>>         interoperability, since implementors have to guess at the
>>         handling for corner cases. Could you please add text that
>>         describes the encoding itself? It doesn't need to be overly
>>         complex, but it does need to be explained.
>>
>>         /a
>>
>>
>
>

v2.23.0 | Report a Bug | By Email