[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
- [TICTOC] AD Evaluation: draft-ietf-tictoc-securit… Brian Haberman