Re: [secdir] Secdir last call review of draft-ietf-trill-p2mp-bfd-07

Donald Eastlake <d3e3e3@gmail.com> Fri, 29 December 2017 23:37 UTC

Return-Path: <d3e3e3@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 57F12126D0C; Fri, 29 Dec 2017 15:37:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 P3IowQt14guZ; Fri, 29 Dec 2017 15:37:40 -0800 (PST)
Received: from mail-ot0-x233.google.com (mail-ot0-x233.google.com [IPv6:2607:f8b0:4003:c0f::233]) (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 1CAE71200F1; Fri, 29 Dec 2017 15:37:40 -0800 (PST)
Received: by mail-ot0-x233.google.com with SMTP id v40so27964510ote.13; Fri, 29 Dec 2017 15:37:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iSCCSylnMx8wvQxmZ2eIZ1exYkYZ/Z/Yciv5GiB/828=; b=OhGbJJxZuEyDqiXniH9J/2Bs3e5YDTU0F6ypjmoIJglXrOZ1505QQy2urcIPocunpm kKoDmRS8FZ8d2HAXdAMJT9ha9iti0u3yZlzrzxlPsEzYTlPc4BvnYa/abPDEqU90P8Nd i6wL7LKtHZxJo6xvYusBd+ClazxUjE0dt+Eyyx2eTcH6oqAcMLrX27c32+1l4GHL41PB bZ3voi8OktjLmAay5H4Zjm4uDpKmdkF2SGlXcVzRu/S42C9OB2yCkXXDZN4be6kCwCK5 3NO+urkr/BGfqUnaYFoJrdhtflBtpQ8m/4AKC28Men7+QXziN3XbYm/oOozfvitaaSDD HkHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iSCCSylnMx8wvQxmZ2eIZ1exYkYZ/Z/Yciv5GiB/828=; b=RsbGg8uR9EWaE+/JuTMJO6eaqk2bFxy40qvymtwGb1gYN3AiHr00L8pOjXbppVO2A7 uZCCrfJ/gP7RE59W+tZeKyRyMdUOuXwK6/gVFK8DsKBYwYmk3YjodfJEWNbe0g8eoh5C uDpkEL25YsBz68U1AGoVK2oNowdng6lzHtEjAr0OMZTKr18h5dxlPbCva4evpsvrY7W0 /cx3iBs8AxgZ0u6Lqm5zsQ2p868o09WhGXOf3VfjORh5eHD8vQXlNa+XANnEnVCaSwSh PJPyI3ANO2ajQjsa4OtTAEPExS2tN0hg5fD3Yvzse0AOidcnqJWl3j+JsudhxQJEUCm6 XgSw==
X-Gm-Message-State: AKGB3mIc0ZQUgV9/ybLrAKC261skSC3SKL2E15MhIZYBXIJIU2lfZWPv KRtXkMdQQfrTEveLUYB6W6P7LMnwRSZaDp1nKiewU1rr
X-Google-Smtp-Source: ACJfBovyh5d6yNHH0opdFi+k+a7IK8oCjleZ0Ffwl6gxAOWR02rwPwE4t9JNF3XlVvhZfBUhOFnD6BBgJtjdeX4LtEw=
X-Received: by 10.157.66.233 with SMTP id c38mr29899671otj.332.1514590659213; Fri, 29 Dec 2017 15:37:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.168.53.129 with HTTP; Fri, 29 Dec 2017 15:37:23 -0800 (PST)
In-Reply-To: <151447284096.3404.9799585674492282627@ietfa.amsl.com>
References: <151447284096.3404.9799585674492282627@ietfa.amsl.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Fri, 29 Dec 2017 18:37:23 -0500
Message-ID: <CAF4+nEHryN5xUcR-sQrzTyC+g+1R0E=caZcDoVShYbwpMso_+A@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: secdir@ietf.org, draft-ietf-trill-p2mp-bfd.all@ietf.org, IETF Discussion <ietf@ietf.org>, trill@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/XoQ3PgV77bHr6sIlcMKrNSJ0eCI>
Subject: Re: [secdir] Secdir last call review of draft-ietf-trill-p2mp-bfd-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 29 Dec 2017 23:37:41 -0000

Hi Stephen,

Thanks for your review.

On Thu, Dec 28, 2017 at 9:54 AM, Stephen Farrell
<stephen.farrell@cs.tcd.ie> wrote:
> Reviewer: Stephen Farrell
> Review result: Has Issues
>
> Mostly this draft is just bookkeeping so BFD can use trill's P2MP
> capabilities.
>
> I think there is one issue to consider, though since I've not read all the
> referenced documents in detail, I'm open to correction as to whether or
> not this is a real issue.
>
> IIRC, BFD has some pretty crappy "authentication" schemes, such as
> allowing a cleartext password, and not using HMAC when doing keyed
> hashes. That's been justified by performance and implementation
> requirements for BFD. (Not that I ever found those justifications that
> satisfactory myself:-) I don't think TRILL has the same issues in
> that (again IIRC) TRILL doesn't define such "dodgy" schemes, so that
> leads me to wonder if this text is really correct/wise:

The BFD standard was adopted in 2010 and does indicate that its keyed
SHA1 method is strongest and points designers of future BFD
authentication types towards HMAC...

> "...there is little reason to use the [RFC7978] security mechanisms at
> this time..."
>
> I'd have thought that avoiding the more-dodgy BFD mechanisms would
> be a reason for using TRILL authentication mechanisms.

TRILL essentially clones the IS-IS cryptographic authentication
mechanisms which do use HMAC (RFC5310).

> In addition, it's not clear (to me) from the draft if the security
> assumptions made for BFD still hold in the environments where
> TRILL is likely to be used. If not, then that'd be another reason to
> argue that  TRILL authentication ought be used.

It seems to me that perhaps the direction of the recommendation should
be flipped so that RFC 7978 authentication is recommended over BFD
multipoint authentication. Maybe something like:

OLD
                                                   However, [RFC7978],
   while it provides both authentication and encryption for point-to-
   point extended RBridge Channel messages, provides only authentication
   for multipoint RBridge Channel messages. Thus, there is little reason
   to use the [RFC7978] security mechanisms at this time. However, it is
   expected that a future document will provide for group keying; when
   that occurs, the use of RBridge Channel security will also be able to
   provide encryption and may be desirable.

NEW
   [RFC7978] provides encryption only for point-to-point extended
   RBridge Channel messages so its encryption facilities are not
   applicable to this draft. However [RFC7978] provides stronger
   authentication than that currently provided in BFD. Thus, there is
   little reason to use the BFD security mechanisms if [RFC7978]
   authentication is in use. It is expected that a future TRILL
   document will provide for group keying; when that occurs, the use
   of [RFC7978] RBridge Channel security will be able to provide both
   encryption and authentication.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com