Re: [secdir] secdir review of draft-ietf-tictoc-multi-path-synchronization-05

Tal Mizrahi <> Mon, 19 September 2016 13:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BCB8B127735; Mon, 19 Sep 2016 06:24:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AWnrl1zh-F8w; Mon, 19 Sep 2016 06:24:08 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7E72912B029; Mon, 19 Sep 2016 06:24:08 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id u8JDL8IJ017382; Mon, 19 Sep 2016 06:24:02 -0700
Received: from ([]) by with ESMTP id 25h5bp0d99-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 19 Sep 2016 06:24:01 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 19 Sep 2016 16:23:59 +0300
Received: from ([fe80::5d63:81cd:31e2:fc36]) by ([fe80::5d63:81cd:31e2:fc36%20]) with mapi id 15.00.1104.000; Mon, 19 Sep 2016 16:23:58 +0300
From: Tal Mizrahi <>
To: Ben Laurie <>
Thread-Topic: [secdir] secdir review of draft-ietf-tictoc-multi-path-synchronization-05
Thread-Index: AQHSEeSgVxkDrkl/jE+0/2Rx8wj6kqB/4pcA///YqYCAADiWMIAAgDWAgABXvyA=
Date: Mon, 19 Sep 2016 13:23:57 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_ff13c3a269a84fd8969171109ee8064cILEXCH01marvellcom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-19_08:, , signatures=0
X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609020000 definitions=main-1609190184
Archived-At: <>
Cc: "Karen ODonoghue (" <>, "" <>, Suresh Krishnan <>, "" <>, "<>" <>
Subject: Re: [secdir] secdir review of draft-ietf-tictoc-multi-path-synchronization-05
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 19 Sep 2016 13:24:12 -0000

Hi Ben,

Just to clarify, we are talking about an attacker that adds a malicious delay that may be as low as, say five microseconds (yes, microseconds) beyond the ‘normal’ path delay. A five microsecond additional delay is certainly enough to kill the protocol in various environments such as mobile base stations or power substations.

Five microseconds is just an example. The point is that the attacker adds some additional delay which is at least an order of magnitude lower than the path delay.

Correct me if I am wrong, but a challenge/response will probably not be effective in detecting delay attacks in this order of magnitude.

Best regards,

From: Ben Laurie []
Sent: Monday, September 19, 2016 2:01 PM
To: Tal Mizrahi
Cc: Watson Ladd;; Karen ODonoghue (; <>; Suresh Krishnan;
Subject: Re: [secdir] secdir review of draft-ietf-tictoc-multi-path-synchronization-05

On 19 September 2016 at 01:34, Tal Mizrahi <<>> wrote:
Time protocols have a pretty unique property: even if you use the strongest cryptographic mechanisms, the protocol can still easily be attacked by a man-in-the-middle who simply adds a constant delay to some of the packets, and thereby easily manipulates the protocol. The only way to mitigate delay attacks is by redundancy: multiple time sources and/or multiple network paths.

Surely not - challenge/response, for example, would also reveal a delay.