[secdir] Early SecDir review of draft-ietf-trill-channel-tunnel-07

Yaron Sheffer <yaronf.ietf@gmail.com> Sun, 30 August 2015 21:00 UTC

Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 782871A92AF for <secdir@ietfa.amsl.com>; Sun, 30 Aug 2015 14:00:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id VZtlwpC2jDx2 for <secdir@ietfa.amsl.com>; Sun, 30 Aug 2015 14:00:55 -0700 (PDT)
Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (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 621711A9253 for <secdir@ietf.org>; Sun, 30 Aug 2015 14:00:55 -0700 (PDT)
Received: by wicfv10 with SMTP id fv10so46792546wic.1 for <secdir@ietf.org>; Sun, 30 Aug 2015 14:00:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=eYhpkSRzsdtqzfEzWf9KQRWH6wNi5GLmukpGzTnk5QQ=; b=UbsB2rG3xAhUc1wsxlSCyFiQ8LER1Ckt3jT3EgomYNmt2Iaw35YPfTxdHyzocftCix cGHtyp4nENtgsrRCczrB2kCk+IpR16pW+sndNn0LCjW2CWzA8/b55RODVjxvhA6veEkc apXYh38KtrQhymoKDPjVcdLqNX532xzhbh+KWFu726CPf4ORPX7Fro4U/jPAXCCLZo2m KRgPKW3zTCCZCbuQQj+fWo1/sfpzP4/u2+mCxkgUNZVmCekF1e3Qs45Q0BTqGS8jkFjJ ACiM+MgiNwePBtJnFZVG3lFA8HVFvF0zNIcpqlvgIXXsX7kBSibqrCps7iPS2Kp18gvT N3yw==
X-Received: by with SMTP id r2mr23512245wjq.72.1440968454105; Sun, 30 Aug 2015 14:00:54 -0700 (PDT)
Received: from [] (bzq-79-180-179-66.red.bezeqint.net. []) by smtp.googlemail.com with ESMTPSA id d17sm18936294wjs.32.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 30 Aug 2015 14:00:52 -0700 (PDT)
From: Yaron Sheffer <yaronf.ietf@gmail.com>
To: IETF Security Directorate <secdir@ietf.org>, draft-ietf-trill-channel-tunnel.all@tools.ietf.org
Message-ID: <55E36EFC.6000508@gmail.com>
Date: Mon, 31 Aug 2015 00:00:44 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/m5FmN7gxI4OcFHPNiG_eXmaMy7g>
Subject: [secdir] Early SecDir review of draft-ietf-trill-channel-tunnel-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: Sun, 30 Aug 2015 21:00:57 -0000

This is an early security review, written at the request of the TRILL WG.

The document defines a way to tunnel arbitrary frames of related control 
protocols within the TRILL "channel". Most of the document (and the 
focus of this review) is about security this tunnel.


I believe the draft is not ready for IETF LC in its current form. I 
assume the original intention was to use DTLS, but the use of DTLS is 
not well specified and the alternative that's proposed for multicast 
comes with inferior security.


• In general, I don't understand why it makes sense to define a whole 
new security protocol, just for control-plane traffic of one specific 
protocol, important as it may be. At the very least I would expect an 
analysis of potential alternatives (IPsec? MACsec?) and why they do not 
fit this use case.
• As a result of the home-brew transport protocol, we also don't get a 
standard key management protocol.
• And from a process POV, the TRILL WG may not be the best place, as far 
as participants' expertise, to develop a security protocol. An early 
SecDir review certainly helps, but I'm not sure the current reviewer is 
capable of detecting every last issue that might be lurking in the protocol.
• 4.1: the A and E bits are not guaranteed to be correct? Then why are 
they here? They describe critical security properties, and therefore 
someone is bound to use them to make critical policy decisions. If the 
bits' semantics are not guaranteed, we'd better drop them.
• A bit: I think we are confusing authentication with integrity 
protection. With opportunistic security, you usually don't have 
authentication, but integrity protection is still worthwhile.
• 4.2: Coverage - it would be nice if Fig. 2.1 showed the coverage of 
authentication (integrity protection!) and encryption. Why is an 
Ethernet frame's FCS not covered by integrity protection? Is there any 
non-malicious reason someone would want to modify the FCS in transit?
• 4.3: "in some cases" - why not simply say, "When SType is 1 or 3"?
• 4.3: why deconstruct HKDF and use HKDF-Expand instead of simply using 
the whole thing, including HKDF-Extract?
• I am confused about 4.1 vs. 4.5, and specifically, what does the Size 
byte cover. I think this is incorrect in 4.5.
• 4.6: this section starts with certificates (presumably, both client 
and server should authenticate with a cert) and then moves on to PSK. 
Are both allowed?
• 4.6: TLS is rapidly moving toward perfect-forward secrecy. Why require 
a cipher suite that's being deprecated across all of industry 
• 4.6.: I am still unclear on how CT keys are derived from DTLS.
• 4.6: Why have a TRILL-level key ID with DTLS-PSK has the notion of key ID?
• 4.6: with certificates the frames may be very large. Does the protocol 
support such sizes?
• 4.6: there should be a lot more text about how DTLS is used to wrap L2 
• 4.7: if this mode is assumed for multicast, what is the 
assumed/recommended mode for unicast?
• Obviously integrity protection where the MAC key is shared with all 
peers is very weak. There are various ways to deal with that, starting 
with RSA signatures but including more efficient methods (TESLA comes to 
mind). Have you considered any of them?
• 4.7.1: if the authentication data is variable length, you must ensure 
that the field that indicates its size is integrity-protected as well.
• Actually, I'm not sure where this size is indicated.
• It seems to me that a fully random 128-bit nonce would be both simpler 
to implement and more secure than the scheme proposed here.
• Typo: designed -> designated.
• 5: assuming we will have DTLS handshakes nested within CT, how are 
errors indicated?
• General: is there any facility for replay protection? If no, why not?
• 7: The more normative parts of the Security Considerations would 
probably fit nicely into a separate Applicability section.
• 7: I think the document should be much more clear (normative) about 
what message types are allowed within the tunnel, or not. And possibly 
about required filtering by address.