Re: [Curdle] Roman Danyliw's No Objection on draft-ietf-curdle-gss-keyex-sha2-09: (with COMMENT)

Simo Sorce <simo@redhat.com> Mon, 01 July 2019 17:03 UTC

Return-Path: <simo@redhat.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 5CBCE120745; Mon, 1 Jul 2019 10:03:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] 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 jj6NDTWJ3Q2z; Mon, 1 Jul 2019 10:03:07 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6DA712072A; Mon, 1 Jul 2019 10:03:06 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 993D4356C4; Mon, 1 Jul 2019 17:03:02 +0000 (UTC)
Received: from ovpn-116-72.phx2.redhat.com (ovpn-116-72.phx2.redhat.com [10.3.116.72]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9843660C43; Mon, 1 Jul 2019 17:02:58 +0000 (UTC)
Message-ID: <a0748b5a1b654501325099d10e58f62011a0bce0.camel@redhat.com>
From: Simo Sorce <simo@redhat.com>
To: Roman Danyliw <rdd@cert.org>, The IESG <iesg@ietf.org>, Adam Roach <adam@nostrum.com>
Cc: draft-ietf-curdle-gss-keyex-sha2@ietf.org, daniel.migault@ericsson.com, curdle-chairs@ietf.org, curdle@ietf.org
Date: Mon, 01 Jul 2019 13:02:57 -0400
In-Reply-To: <156138713666.17510.11504200727464931225.idtracker@ietfa.amsl.com>
References: <156138713666.17510.11504200727464931225.idtracker@ietfa.amsl.com>
Organization: Red Hat, Inc.
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Mon, 01 Jul 2019 17:03:06 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/cY_W-QGAn7xWcMJuMvVW5apr6tQ>
Subject: Re: [Curdle] Roman Danyliw's No Objection on draft-ietf-curdle-gss-keyex-sha2-09: (with COMMENT)
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.29
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, 01 Jul 2019 17:03:22 -0000

On Mon, 2019-06-24 at 07:38 -0700, Roman Danyliw via Datatracker wrote:
> ** Section 5.1.  The various variable (e.g., V_C, V_S) are introduced early in
> the algorithm to construct H and the messages in page 6, but they aren’t
> described until the end of page 7.  I wasn’t following the narrative until I
> hit that section.

On Mon, 2019-06-24 at 20:41 -0700, Adam Roach via Datatracker wrote:
> §5.1: 
> >  To verify the integrity of the handshake, peers use the Hash Function
> >  defined by the selected Key Exchange method to calculate H:
> > 
> >  H = hash(V_C || V_S || I_C || I_S || K_S || Q_C || Q_S || K).
> 
> Please indicate that these variables and the "||" operator will be described
> later in this section.


You both indicate these are described in later section, and although we
do, we have a reference right at the start of 5.1:
   "This section reuses much of the scheme defined in section 2.1 of
   RFC4462"
that reference contains explicit definitions of the symbols used and
the preamble to that referenced section also points to "Section 8 of
[SSH-TRANSPORT]" which also `have definitions.

That reference is required pre-requisite to understand 5.1 fully so I
think we have enough in place, however if you think I should move the
later section 7 text up in to this already overlong paragraph I will.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc