[Curdle] review of draft-ietf-curdle-des-des-des-die-die-die

Daniel Migault <daniel.migault@ericsson.com> Thu, 18 May 2017 02:37 UTC

Return-Path: <daniel.migault@ericsson.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 6D290129B69; Wed, 17 May 2017 19:37:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 1o-rpVdJXmZo; Wed, 17 May 2017 19:37:31 -0700 (PDT)
Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (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 007FE129B3F; Wed, 17 May 2017 19:35:29 -0700 (PDT)
X-AuditID: c618062d-527ff7000000248b-79-591d1bed7f52
Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 4C.86.09355.DEB1D195; Thu, 18 May 2017 05:58:40 +0200 (CEST)
Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0319.002; Wed, 17 May 2017 22:35:25 -0400
From: Daniel Migault <daniel.migault@ericsson.com>
To: "draft-ietf-curdle-des-des-des-die-die-die@ietf.org" <draft-ietf-curdle-des-des-des-die-die-die@ietf.org>
CC: "curdle-chairs@ietf.org" <curdle-chairs@ietf.org>, 'curdle' <curdle@ietf.org>
Thread-Topic: review of draft-ietf-curdle-des-des-des-die-die-die
Thread-Index: AdLPf1TvBfzJEx88T9es3kEzPCJa1A==
Date: Thu, 18 May 2017 02:35:24 +0000
Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118BDB433@eusaamb107.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.11]
Content-Type: multipart/alternative; boundary="_000_2DD56D786E600F45AC6BDE7DA4E8A8C118BDB433eusaamb107erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyuXRPiO4HadlIgx/f9Sxm9mxgtti6cBaz xdOuI0wOzB5LlvxkCmCM4rJJSc3JLEst0rdL4MroW7KeqWDbLsaKhYtWMjYw7ljK2MXIySEh YCJxpqeZvYuRi0NI4CijxOFtjUwQznJGiTMTXrGBVLEJGEm0HeoHquLgEBHIl2g86g4SZhYI ljg36wFYWFjARuJ+jy1EhaPEl7tRIBUiAnoSx85eYQWxWQRUJdbeP8cCYvMK+Eosm/oZLM4o ICbx/dQaJoiJ4hK3nsxngjhNQGLJnvPMELaoxMvH/1ghbCWJj7/ns0PU50s8757NDDFTUOLk zCcsExiFZiEZNQtJ2SwkZRBxHYkFuz+xQdjaEssWvmaGsc8ceMyELL6AkX0VI0dpcUFObrqR wSZGYDQck2DT3cF4f7rnIUYBDkYlHt5DorKRQqyJZcWVuYcYJTiYlUR4P3yUiRTiTUmsrEot yo8vKs1JLT7EKM3BoiTOO+H8hQghgfTEktTs1NSC1CKYLBMHp1QDY4TEyb+mE4Lu6P37x7BD emLO/syuH0FuXrqJntIKzx0svNdXf0iqS98ieO8ze/4Ehk/ruyZHHGcx+7wmnd9unr/tnu5W 6Q8Tuct0zjD6FHtFtc3+sOGxhIu69afDd5OmF75IC3kk/Vz5YkZPuKP5gQcbbTxOyqzOkltz VGbNe30pi+99s+3qlViKMxINtZiLihMBHgHqZoICAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/pXPtYHJyqRLCxwCXK4LIHOL3apU>
Subject: [Curdle] review of draft-ietf-curdle-des-des-des-die-die-die
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, 18 May 2017 02:37:34 -0000

Hi,

The draft seems to me quite ready. Please find some small comments.


  1.  Updates / obsoletes should be mentioned in the header, abstract and intro.


  1.  Status: wouldn't standard track be more appropriated ?

Nits:

Section 5.2



to the has function

section 5.4:


TGT needs to be defined.





"""

It is now believed that all machines that might be broken by disabling RC4 are unsupported, and concerns about breaking them will be reduced.

"""



I see this sentence as reflecting a support team point of view. If an application runs on W2003 and save lifes, I prefer not breaking it.



I believe the issue is that an important aspect of support is addressing vulnerabilities. As patches are not provided for these versions, these systems becomes too vulnerable and authentication with Kerberos may provide limited protection. In such situation, could Kerberos be disabled, and alternate authentication may be used. Kerberos might be the preferred way to perform authentication but what would be the other ways. The typical use case I see is a that new client will not be able to connect the service. I hardly see KDC, Services being updated while client are not updated. I am fine clearly saying that upgrading to newer version is recommended.



OK, reading the name of the draft I expected RC4/3DES to be MUST NOT. If the status is SHOULD NOT, it gives time for the transition. In that case comment above may not require so detailed explanations. Then, do we have recommendation for the deprecation, such as specific message, logs...?


Section 7.

If SHOULD NOT is specified, maybe we should mention that the status is expected to move to MUST NOT.

Nits from the datatracker:

idnits 2.14.01

/tmp/draft-ietf-curdle-des-des-des-die-die-die-00.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  http://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to http://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  -- The draft header indicates that this document obsoletes RFC4757, but the
     abstract doesn't seem to mention this, which it should.

  -- The draft header indicates that this document updates RFC3961, but the
     abstract doesn't seem to mention this, which it should.


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

     (Using the creation date from RFC3961, updated by this document, for
     RFC5378 checks: 2004-02-11)

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
     (See the Legal Provisions document at
     http://trustee.ietf.org/license-info for more information.)

  -- The document date (May 1, 2017) is 16 days in the past.  Is this
     intentional?


  Checking references for intended status: Informational
  ----------------------------------------------------------------------------

     No issues found here.

     Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 4 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.
--------------------------------------------------------------------------------


[Ericsson]<http://www.ericsson.com/>

DANIEL MIGAULT
Researcher
Research

Ericsson
8500 Boulevard Decarie
H4P 2N2 Montreal, Canada
Phone +1 514 345 7900 46628
Mobile +1 514 452 2160
daniel.migault@ericsson.com
www.ericsson.com


[http://www.ericsson.com/current_campaign]<http://www.ericsson.com/current_campaign>

Legal entity: Ericsson Canada Inc., registered office in Montreal. This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>