Re: [secdir] SECDIR review of draft-ietf-netconf-tls-07.txt

Badra <badra@isima.fr> Thu, 12 March 2009 09:14 UTC

Return-Path: <mbadra@gmail.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87A583A6ACD; Thu, 12 Mar 2009 02:14:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.976
X-Spam-Level:
X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuG7yaGxlecB; Thu, 12 Mar 2009 02:14:23 -0700 (PDT)
Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id E7E103A67CC; Thu, 12 Mar 2009 02:14:22 -0700 (PDT)
Received: by fxm24 with SMTP id 24so296943fxm.37 for <multiple recipients>; Thu, 12 Mar 2009 02:14:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=F4pTcGYAODDd/5k5+4878MdIvBKYZA4KzQEwpyausGE=; b=T95eQaKRIL9zWjTyaDr3oeYjtkoPHAXuSZ9Y7XuNbN56c5e8zez2h8YiBsv0KYWj5o 1jZAVRkGkBSYQw9u+BzPTB0Nb0iv3bz5pfazmBLHVE3S4XaMmiK5YkvCRbI871aKvvXO B8wJzO+ZYw/p7Mp57etKPglqKes5iKu3nvTqs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=SjRCY7Etmx3z7jb1cgduvoyZmdrPGIlzvRKTMXdOMpA+ClM9cyu3bL5+cE5jo+Hlzs AzGaXwwBpmv4vc2/6yc+CN9Ikd9mGwLyXhSYrtBWvWKRfkZPqxvZ7bgZDMx5+PP/Td9j JBe0TeX9i1c5dvP4yQPGFvm9H6ki6Fs7Eyjok=
MIME-Version: 1.0
Sender: mbadra@gmail.com
Received: by 10.86.72.15 with SMTP id u15mr6621330fga.33.1236849299537; Thu, 12 Mar 2009 02:14:59 -0700 (PDT)
In-Reply-To: <49B87CAC.6000105@ieca.com>
References: <49B87CAC.6000105@ieca.com>
Date: Thu, 12 Mar 2009 10:14:59 +0100
X-Google-Sender-Auth: 12d7e8a47b7d9f8c
Message-ID: <c24c21d80903120214i24220789kf4d4bc400ed822a5@mail.gmail.com>
From: Badra <badra@isima.fr>
To: Sean Turner <turners@ieca.com>
Content-Type: multipart/alternative; boundary="000e0cd2a18023c0450464e86b4f"
X-Mailman-Approved-At: Thu, 12 Mar 2009 08:23:15 -0700
Cc: secdir <secdir@ietf.org>, Tim Polk <tim.polk@nist.gov>, Pasi Eronen <Pasi.Eronen@nokia.com>, draft-ietf-netconf-tls@tools.ietf.org, iesg@ietf.org, netconf-chairs@tools.ietf.org
Subject: Re: [secdir] SECDIR review of draft-ietf-netconf-tls-07.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Mar 2009 09:14:25 -0000

Dear Sean Turner,
Thank you for your review.



> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> These comments were written primarily for the benefit of the security
> area directors. Document editors and WG chairs should treat these
> comments just like any other last call comments.
>
> I apologize for doing this so late.
>
> This document defines how to use TLS to secure NETCONF exchanges.
>
> I don't have any security issues but I do I have a question about the last
> paragraph in 2.1.  It says that TLS 1.2 MUST be supported and that future
> versions of TLS will also be supported and those mandatory to implement
> algorithms MUST also be supported.  is that also saying that an
> implementation must support all future version of TLS too?
>
>
   This document is assumed to apply to
   future versions of TLS, in which case the mandatory to implement
   cipher suite for the implemented version MUST be supported.

If a future TLS version is implemented, so the mandatory cipher suite of
that version must also be supported. But this doesn't mean it is mandatory
to support any future TLS versions.

Best regards
Badra