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

Watson Ladd <watsonbladd@gmail.com> Mon, 19 September 2016 14:41 UTC

Return-Path: <watsonbladd@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9998C12B3CF; Mon, 19 Sep 2016 07:41:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 5hfaKU8BP0Zf; Mon, 19 Sep 2016 07:41:37 -0700 (PDT)
Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A25C12B3E5; Mon, 19 Sep 2016 07:41:36 -0700 (PDT)
Received: by mail-yw0-x230.google.com with SMTP id t67so147943316ywg.3; Mon, 19 Sep 2016 07:41:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=JNDC2VSS2CyDG/VoeC+Uf8Qs6eQ+aRlbnDYaWhFWnGQ=; b=OLEb8h8LXSDNKHapsIqtC0I+Fyin15I/7bYAeCyPB9tHdSpdOTg7G+0fCPLDp7lLoF LVr4smlghMn5Pc0wYQ+306HCBrcNEXWfihJpXqn4tVV9HCNDN8fJN7lmgB8Xm1cz37ma DE0LYkICPOvvLTWwToHpYrKuAoSwFa1zNzSjnR19zDfHC0Vh59hxWryVsOJnvoT/OBDI wvkGtR6mjxxKsp43tXDd87w2RVAssCyGupTNA2cTugfs126WBkxB9HJRE+soi5Fro1Jq 6w4kvPoFaAlzzwy+LEcnjy1vzfWizzFxBh7FezAGZsnb9fE9hBqvDdTUGWyH9/l00Trb 7i0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=JNDC2VSS2CyDG/VoeC+Uf8Qs6eQ+aRlbnDYaWhFWnGQ=; b=MPBN10RR/wqHqKmHY1qD9A1wWYN6D42qdiG1x8VHieBywSCoecOWmt/h9mWsLRcBVn ZhKWDjbiCDwzkJi01nyKJq59UygHanmSnh7lzSHLXDZ5KktW3ZJpux8GeJrRDZryKLzl djmU3yZE1ZXkm2Vb6pz3/hPyPBFoNeezWhHafDWqBWlwDp4FYw+ixy75CCN/QNcUJZdx 40zQkZgoaheQEq3mk3jVXou2a4jX7v8LYS2+tkFKBALOOJ3fVF5tk3Sd47V9xzy0k+XP RzPFIscXW76fUlVilYtq6pIKvHwvr6uf2iiDwHusFBB16TkW8Y9MTYU4RlPovHyV94A8 DBrA==
X-Gm-Message-State: AE9vXwPAmjhbXSscJjiTZ4lUgPhjP/jtITGBDKxBHnlVXwuPX1ppTg4ZqbTj1/U0iklDfwyio7EL/Ort1HLHZg==
X-Received: by 10.13.252.132 with SMTP id m126mr24914293ywf.307.1474296095683; Mon, 19 Sep 2016 07:41:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.4.102 with HTTP; Mon, 19 Sep 2016 07:41:35 -0700 (PDT)
In-Reply-To: <3993e58a01f4472992ae6fcdfaa8e0f7@IL-EXCH01.marvell.com>
References: <CACsn0cmCGrpaHtiLNEpnN52_+FqM4XiCtUHhZm9XQD1qfbFH3w@mail.gmail.com> <2c34b139112a45ac9a68ff000aa7d934@IL-EXCH01.marvell.com> <CACsn0ckk0egkREuvfhwU6FJV5LBV4BPs5HsNoRk63yWjVdBB_g@mail.gmail.com> <3993e58a01f4472992ae6fcdfaa8e0f7@IL-EXCH01.marvell.com>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Mon, 19 Sep 2016 07:41:35 -0700
Message-ID: <CACsn0cmD7akVUyL-3mA43tYRa4jntfowNbhD85vYh+7w_1PypQ@mail.gmail.com>
To: Tal Mizrahi <talmi@marvell.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/MjMCYEJTGMLTKg_FbSejKpTrY_w>
Cc: "draft-ietf-tictoc-multi-path-synchronization.all@tools.ietf.org" <draft-ietf-tictoc-multi-path-synchronization.all@tools.ietf.org>, "Karen ODonoghue \(odonoghue@isoc.org\)" <odonoghue@isoc.org>, "<iesg@ietf.org>" <iesg@ietf.org>, Suresh Krishnan <suresh.krishnan@ericsson.com>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-tictoc-multi-path-synchronization-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Mon, 19 Sep 2016 14:41:41 -0000

On Sun, Sep 18, 2016 at 5:34 PM, Tal Mizrahi <talmi@marvell.com> wrote:
> Dear Watson,
>
> Thanks for the prompt response.
>
>>Multipath shouldn't be discussed as a security measure at all. My reading of
>>the document was that it was simply to get more reliable packet delays and
>>synchronization. You cannot throw this claim into the security considerations
>>alone without explaining the rest of the picture. Why not remove it entirely?
>>
>
> The multi-path scheme addresses both an accuracy issue and a security issue. The security aspect is mentioned well before the security considerations section, including in the abstract and in the introduction.

What should a client do with multipath to integrate the data in a way
that is strong against malicious delays inserted even on one path?
This draft says there are various discussed algorithms, but some (like
pure Kalman filtering, which the draft suggests) won't be robust
against adversarial manipulation. It needs to say more about this!

>
>>Real attackers get the job done: they grab the community strings and use
>>them to own every single router you have, or own the sysadmins PC and go
>>for all the routers at once.  And it's not uncommon for machines to be
>>connected to only one router: most desktops and laptops have a single
>>Ethernet port. The proposed text makes extremely common things sound
>>rare.
>
> 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.
> The delay attack is one of the most significant threats in time protocols, and therefore we defined delay attack protection as a MUST in RFC 7384.
> Security is an important aspect of multi-path synchronization, and I believe the current draft has to talk about this aspect.

Just because you demanded that a certain solution have a property
doesn't mean it actually has that property. In fact RFC 7384 is
unreasonably strong: most applications can survive with degraded
clocks and degrading the clock accuracy (say to an amount depending on
observed roundtrip time) is probably acceptable, and in the face of
the standard network attacker (who manipulates all packets at will)
this is the best we can do.

Multipath is extremely limited as a mitigation technique. Given the
demands the systems you are discussing place on reliable timing (to
the point where downthread you indicate microseconds required)
multipath shouldn't be considered effective. If you really need
microseconds secure timing, and actually need things to be secure you
need to trust at least one path.

>
> Best regards,
> Tal.
>
>
>
>>-----Original Message-----
>>From: Watson Ladd [mailto:watsonbladd@gmail.com]
>>Sent: Monday, September 19, 2016 2:59 AM
>>To: Tal Mizrahi
>>Cc: <iesg@ietf.org>; secdir@ietf.org; draft-ietf-tictoc-multi-path-
>>synchronization.all@tools.ietf.org; Suresh Krishnan; Karen ODonoghue
>>(odonoghue@isoc.org)
>>Subject: Re: secdir review of draft-ietf-tictoc-multi-path-synchronization-05
>>
>>On Sun, Sep 18, 2016 at 4:22 PM, Tal Mizrahi <talmi@marvell.com> wrote:
>>> Dear Watson,
>>>
>>> Thanks for reviewing the draft.
>>>
>>> To address your comments, I would like to suggest the following text for the
>>Security Considerations section.
>>> Please let us know if this addresses the comments:
>>>
>>>
>>> The security aspects of time synchronization protocols are discussed in
>>detail in [TICTOCSEC]. The methods describe in this document propose to run
>>a time synchronization protocol through redundant paths, and thus allow to
>>detect and mitigate man-in-the-middle attacks, as described in [DELAY-ATT].
>>It should be noted that when using multiple paths, these paths may partially
>>overlap, and thus an attack that takes place in a common segment of these
>>paths is not mitigated by the redundancy. Moreover, an on-path attacker may
>>in some cases have access to more than one router, or may be able to
>>migrate from one router to another. Therefore, when using multiple paths it is
>>important for the paths to be as diverse and as independent as possible,
>>making the redundancy scheme more tolerant to on-path attacks.
>>
>>Multipath shouldn't be discussed as a security measure at all. My reading of
>>the document was that it was simply to get more reliable packet delays and
>>synchronization. You cannot throw this claim into the security considerations
>>alone without explaining the rest of the picture. Why not remove it entirely?
>>
>>Real attackers get the job done: they grab the community strings and use
>>them to own every single router you have, or own the sysadmins PC and go
>>for all the routers at once.  And it's not uncommon for machines to be
>>connected to only one router: most desktops and laptops have a single
>>Ethernet port. The proposed text makes extremely common things sound
>>rare.
>>
>>>
>>>
>>>
>>> Regards,
>>> Tal.
>>>
>>>>-----Original Message-----
>>>>From: Watson Ladd [mailto:watsonbladd@gmail.com]
>>>>Sent: Sunday, September 18, 2016 10:41 PM
>>>>To: <iesg@ietf.org>; secdir@ietf.org; draft-ietf-tictoc-multi-path-
>>>>synchronization.all@tools.ietf.org
>>>>Subject: secdir review of
>>>>draft-ietf-tictoc-multi-path-synchronization-05
>>>>
>>>>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.
>>>>
>>>>The document presents a mechanism for servers and clients to conduct
>>>>synchronization protocols over multiple paths. I didn't see anything
>>>>wrong with the mechanism, but I am worried that its security benefits
>>>>are
>>>>overstated: independent paths may only be partially independent, and
>>>>attackers can easily migrate from one router to another in most networks.
>>>>
>>>>Sincerely,
>>>>Watson Ladd
>>
>>
>>
>>--
>>"Man is born free, but everywhere he is in chains".
>>--Rousseau.



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.