[bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT)

"Spencer Dawkins" <spencerdawkins.ietf@gmail.com> Thu, 05 November 2015 02:31 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: bfcpbis@ietf.org
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BA8DB1B3668; Wed, 4 Nov 2015 18:31:08 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.8.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20151105023108.17210.54132.idtracker@ietfa.amsl.com>
Date: Wed, 04 Nov 2015 18:31:08 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/bfcpbis/bclWfKAPQdAqIN_Aohya1pBuxWU>
Cc: gorry@erg.abdn.ac.uk, mary.ietf.barnes@gmail.com, bfcpbis-chairs@ietf.org, bfcpbis@ietf.org, draft-ietf-bfcpbis-rfc4582bis@ietf.org
Subject: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT)
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.15
List-Id: BFCPBIS working group discussion list <bfcpbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bfcpbis/>
List-Post: <mailto:bfcpbis@ietf.org>
List-Help: <mailto:bfcpbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Nov 2015 02:31:08 -0000

Spencer Dawkins has entered the following ballot position for
draft-ietf-bfcpbis-rfc4582bis-15: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for working through my Discuss and Comments on -13. I'm mostly
good (at the Discuss level), but have one remaining concern, on section
14.  Security Considerations

   BFCP uses TLS/DTLS to provide mutual authentication between clients
   and servers.  TLS/DTLS also provides replay and integrity protection
   and confidentiality.  It is RECOMMENDED that TLS/DTLS with an
   encryption algorithm according to Section 7 always be used.  In cases
   where signaling/control traffic is properly protected, as described
   in Section 9 it is REQUIRED to use a mandated encryption algorithm.
   BFCP entities MAY use other security mechanisms as long as they
   provide similar security properties.
   
If I'm reading this text correctly (please correct me if I'm
misunderstanding), it is still allowed to run BFCP over TCP/UDP without
TLS/DTLS. 

If you run a protocol over TCP without TLS, you're still vulnerable to
on-path attackers, but off-path attackers have to insert attack packets
with sequence numbers that are within the current window. That's not
impossible, but it's not easy. So, I'm not happy that TLS isn't required
when you run BFCP over TCP, but OK, fine.

If you run a protocol over UDP without DTLS, off-path attackers don't
have this constraint, so inserting attack packets off-path is much
easier. That makes BFCP much more vulnerable to attack over UDP than it
was over TCP. 

Is that really OK? That seems quite odd to me, when said without a clear
warning that if you do not use DTLS (or equivalent) security mechanisms
the protocol is vulnerable to various attacks.

I’d have preferred section 7 to have said “SHOULD use TLS or DTLS” and
then have gone on to explain - “reasons for not using DTLS include ...
but when TLS or DTLS is not used the protocol becomes vulnerable to
security attacks (e.g. ...).”


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


I have a couple of Comments on new text:

6.2.2.  ICMP Error Handling	
 		
   ICMP is not used with unreliable transports due to risks asociated	
   with off-path attacks.  Any ICMP messages received over an
unreliable	
   transport MUST be ignored.
   
ICMP is inherently unreliable - and is itself a control transport, rather
than sent over another transport. I think I know what you mean, but it's
not what the text says. Perhaps you mean

   ICMP is not usable when BFCP is running over an unreliable transport
due 
   to risks associated with off-path attacks.  Any ICMP messages
associated 
   with BFCP running over an unreliable	transport MUST be ignored.
   
The new text says:

“predictable conference identifiers in conjunction with a non-secure
transport protocol makes BFCP more susceptible to forged request and
response messages.  See the Security Considerations section regarding
the recommendation to use a secure transport.)”

- This text  could be improved a little by changing this to:

“ predictable conference identifiers in conjunction with a non-secure
transport protocol makes BFCP susceptible to off path data injection
attacks, where an attacker can forge a request or response message.”

However, this falls short of saying you should randomize the conference
ID.

The current text could be OK if it is hard or impossible to randomize for
some reason, but I’d have thought if it was possible this should be
RECOMMENDED either as the default method, or at least as a more secure
alternative for an unreliable transport.
   
Cleaning up the last few Comments on -13:

I'm still working through the conflation of transports and version
numbers. It's getting better, but the current text says:

   “If a floor control server receives a
   message with an unsupported version field value, the server MUST
   indicate it does not support the protocol version by sending an Error
   message with parameter value 12 (Unsupported Version).“

I’d have expected this error message to also have been returned if the
transport did not match.

Would it be correct if the text said:

  “If a floor control server receives a
   message with an unsupported version field value
   or a message with a version number that is not permitted
   with the transport over which it was received,  the server MUST
   indicate it does not support the protocol version by sending an Error
   message with parameter value 12 (Unsupported Version).“