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

[Alissa Cooper <[e-mail]>]

Hi Spencer,

My understanding is that DTLS is not REQUIRED because that would be a non-backwards-compatible change with RFC 4582, and the goal with this bis was to remain backwards compatible.

Charles may be able to elaborate.

Alissa

> On Nov 5, 2015, at 1:54 PM, Paul E. Jones <[e-mail]> wrote:
> 
> Spencer,
> 
> Unfortunately, I don't know the answer to that question and we need to ask one of the authors. I came in at the end here to try to address DISCUSS points, but don't have background on why a non-secure option was allowed.
> 
> Any other authors or folks in the WG able to answer that question? Is anyone opposed to making (D)TLS mandatory?
> 
> Paul
> 
> From: Spencer Dawkins at IETF <[e-mail]>
> Sent: November 5, 2015 1:46:21 PM GMT+09:00
> To: "Paul E. Jones" <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>, [e-mail], [e-mail], [e-mail], The IESG <[e-mail]>, Mary Barnes <[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 <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 <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 sect!
>  ion
> 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 <https://www.ietf.org/mailman/listinfo/bfcpbis>
> 
> 
> 
> bfcpbis mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bfcpbis <https://www.ietf.org/mailman/listinfo/bfcpbis>
> _______________________________________________
> bfcpbis mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bfcpbis