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

["Charles Eckel (eckelcu)" <[e-mail]>]

For TCP, the use of TLS was not required by RFC 4582. For 4582bis, we do not require TLS in order to maintain backward compatibility with RFC 4582.
For UDP, the reason for not mandating DTLS is backward compatibility with existing solutions. The IMTC Role Based Video Best Practice established a set of recommendations for getting BFCP to work  within enterprise video conference deployments. As that time,draft-sandbakken-xcon-bfcp-udp defined BFCP over UDP only. DTLS was left for future study. Today we have many implementations of BFCP over UDP, but few if any using DTLS. We need the ultimate RFC that standardizes BFCP over UDP (and over DTLS) to allow interworking with these existing deployments.

Cheers,
Charles

From: Spencer Dawkins at IETF <[e-mail]<mailto:[e-mail]>>
Date: Thursday, November 5, 2015 at 1:46 PM
To: Paul Jones <[e-mail]<mailto:[e-mail]>>
Cc: The IESG <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Mary Barnes <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT)

Hi, Paul,

On Thu, Nov 5, 2015 at 1:24 PM, Paul E. Jones <[e-mail]<mailto:[e-mail]>> wrote:
Spencer,

I think all of the suggestions in the comments are perfectly fine and I can accept those. With respect to the random conference ID, I think the issue is that this ID is considered outside the protocol. This protocol just uses this ID. If that's wrong, I would agree suggesting randomizing it would be good.

With respect to the DISCUSS point, I'm not sure what to do. Section 7 says TLS or DTLS must be supported, but that doesn't mean it must be used. I guess that's your concern. I think the security considerations section is the right place to provide warning to those who choose not use it. And there is warning. What more really needs to be said?

I'm entirely OK with more scary language, but would prefer it added only to security considerations.

So, we both want to do the right thing. Let's talk about what that is, before we spend time twiddling words.

The reason why we're having this chat, is that DTLS is RECOMMENDED, not REQUIRED. Can you help me understand why that is?

I'm seeing language in the spec that looks, to me, like it's trying to hold the door open in case another mechanism with equivalent functionality to DTLS becomes available (so, not MUST DTLS, because you couldn't use it). For example, from the Security Considerations section:


   BFCP entities MAY use other security mechanisms as long as they
   provide similar security properties.

Is that relevant to my question, or am I misunderstanding, and there are use cases where unencrypted BFCP is necessary?

Thanks,

Spencer

Paul

________________________________
From: Spencer Dawkins <[e-mail]<mailto:[e-mail]>>
Sent: November 5, 2015 11:31:08 AM GMT+09:00
To: The IESG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>
Subject: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT)


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 t!
 he
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
   messag!
 e 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).“


________________________________

bfcpbis mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/bfcpbis