[TICTOC] AD Evaluation: draft-ietf-tictoc-security-requirements

Brian Haberman <brian@innovationslab.net> Fri, 27 June 2014 14:56 UTC

Return-Path: <brian@innovationslab.net>
X-Original-To: tictoc@ietfa.amsl.com
Delivered-To: tictoc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0B271B2B5F for <tictoc@ietfa.amsl.com>; Fri, 27 Jun 2014 07:56:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 NuqAsMNPGRT5 for <tictoc@ietfa.amsl.com>; Fri, 27 Jun 2014 07:56:22 -0700 (PDT)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B7C41B2D74 for <tictoc@ietf.org>; Fri, 27 Jun 2014 07:56:15 -0700 (PDT)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 11670880E1; Fri, 27 Jun 2014 07:56:15 -0700 (PDT)
Received: from 102523345.rudm2.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id BF9D871C0002; Fri, 27 Jun 2014 07:56:14 -0700 (PDT)
Message-ID: <53AD8604.2030001@innovationslab.net>
Date: Fri, 27 Jun 2014 10:56:04 -0400
From: Brian Haberman <brian@innovationslab.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: tictoc@ietf.org, draft-ietf-tictoc-security-requirements@tools.ietf.org
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="hgltRXMpJsb6fKqFDsCxPs6vGjeDL2mqx"
Archived-At: http://mailarchive.ietf.org/arch/msg/tictoc/WoeSMl8u9hWKX5ZJnImfDl6eTIM
Subject: [TICTOC] AD Evaluation: draft-ietf-tictoc-security-requirements
X-BeenThere: tictoc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Timing over IP Connection and Transfer of Clock BOF <tictoc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tictoc>, <mailto:tictoc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tictoc/>
List-Post: <mailto:tictoc@ietf.org>
List-Help: <mailto:tictoc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tictoc>, <mailto:tictoc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Jun 2014 14:56:26 -0000

Hi All,
     I have completed my AD Evaluation of
draft-ietf-tictoc-security-requirements as a part of the publication
process.  I found this document well-written and easy to read.  I have a
few comments/questions that I would like to see resolved before moving
this document to IETF Last Call.  Please let me know if you have any
questions/comments/concerns about these points...

Introduction
------------

* It would be useful to explain what is meant by an "inherent security
protocol" with respect to RFC 5905.

* Please explain why PTP is included in these requirements even though
it is not an IETF standard.  This will eliminate a variety of questions
come IESG Evaluation.

Section 3.1.1
-------------

* I think it would be useful to clarify the relationship between the
internal attacks and Byzantine attacks in this context.

Section 3.2.7
-------------

* Provide a few informative references to these types of attacks.

Section 3.2.8
-------------

* There is a missing "." at the end of the section.

Section 3.3
-----------

* Can you explain in what situations a False Time would not also be an
Accuracy Degradation?

Section 5
---------

* I think it may be worth mentioning when a requirement can be met by an
existing protocol/practice/technique.  Given the dependency on time
information for most security protocols, existence proofs would be useful.

Section 5.6.2
-------------

* Does this requirement apply equally to clocks at different levels of
the hierarchy?  For example, the association between a Stratum 2 clock
and a Stratum 3 clock in NTP may have different characteristics than an
association between two clocks at the same stratum level.

Section 5.10.2
--------------

* The MAY seems too weak.  It makes the support of a solution completely
optional.  How will operators ever transition to a secure mode if
vendors ignore the MAY?


Regards,
Brian