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

[Yaron Sheffer <[e-mail]>]

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.

Summary

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.

Details

• 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 
(TLS_RSA_WITH_AES_128_CBC_SHA256)?
• 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 
frames.
• 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.