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

Simo Sorce <simo@redhat.com> Mon, 01 July 2019 17:20 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 DC338120802; Mon, 1 Jul 2019 10:20:59 -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 IGRbGIKY7oZn; Mon, 1 Jul 2019 10:20:58 -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 A5ABA1207FE; Mon, 1 Jul 2019 10:20:58 -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 234987FDFB; Mon, 1 Jul 2019 17:20:42 +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 3B41B60C43; Mon, 1 Jul 2019 17:20:35 +0000 (UTC)
Message-ID: <541117c239df0a1624ef1ca7d25b36188b91c867.camel@redhat.com>
From: Simo Sorce <simo@redhat.com>
To: Suresh Krishnan <suresh@kaloom.com>, The IESG <iesg@ietf.org>
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:20:34 -0400
In-Reply-To: <156139104143.17449.9632346081496014534.idtracker@ietfa.amsl.com>
References: <156139104143.17449.9632346081496014534.idtracker@ietfa.amsl.com>
Organization: Red Hat, Inc.
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
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.27]); Mon, 01 Jul 2019 17:20:58 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/8hnyTAJfCfE6nLyxPklZlRQMMXM>
Subject: Re: [Curdle] Suresh Krishnan'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:21:00 -0000

On Mon, 2019-06-24 at 08:44 -0700, Suresh Krishnan via Datatracker
wrote:
> Suresh Krishnan has entered the following ballot position for
> draft-ietf-curdle-gss-keyex-sha2-09: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-curdle-gss-keyex-sha2/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> * Section 8.3
> 
> I think a pointer to DNSSEC might be relevant here in the context of spoofed DNS responses.
> 
Hi Suresh,
I intentionally kept away from providing solutions in the security
considerations around Delegation. Note that insecure DNS resolution is
not the only issue, using insecure NIS maps for hosts brings the same
issues, so I would rather you consider "DNS" here more as an example.
Given that focusing too much on specific solutions might give the
impression that DNS spoofing is the only issue and that DNSSEC the only
solution, I decided to let the reader decide by themselves how to deal
with these threats.
I consider the document's job done just by warning that there is
something to be aware of around name resolution.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc