Subject: Secdir last call review of draft-ietf-trill-p2mp-bfd-07

From: Stephen Farrell <[email-masked]>
Date: Thu, 28 Dec 2017 06:54:01 -0800

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:

"...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. 

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.

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 29 Dec 2017 18:37:23 -0500

Hi Stephen,

Thanks for your review.

> 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...

> be a reason for using TRILL authentication mechanisms.

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

> 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
 [email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 29 Dec 2017 23:53:06 +0000

Hiya,

>    encryption and authentication.

Were that change acceptable to the WG, I'd be supportive,
and it'd clearly solve what I thought was an issue with
the current spec.

Cheers,
S.

-- 
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)