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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Paul,

On Thu, Nov 5, 2015 at 1:24 PM, Paul E. Jones <[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]>
> *Sent:* November 5, 2015 11:31:08 AM GMT+09:00
> *To:* The IESG <[e-mail]>
> *Cc:* [e-mail], [e-mail],
> [e-mail], [e-mail],
> [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]
> https://www.ietf.org/mailman/listinfo/bfcpbis
>
>