Re: [bfcpbis] AD evaluation: draft-ietf-bfcpbis-rfc4582bis-12

[Tom Kristensen <[e-mail]>]

Thanks Charles, will do the nit fixing locally and keep it until the next
version in some later stage.

-- Tom

On 21 February 2015 at 00:45, Charles Eckel (eckelcu) <[e-mail]>
wrote:

>  All look great Tom, except for a couple nits (inline) that would be good
> to fix if/when we have another version of the document.
>
>   From: Tom Kristensen <[e-mail]>
> Date: Thursday, February 19, 2015 at 5:54 AM
> To: Alissa Cooper <[e-mail]>
> Cc: Charles Eckel <[e-mail]>, "[e-mail]" <
> [e-mail]>
> Subject: Re: [bfcpbis] AD evaluation: draft-ietf-bfcpbis-rfc4582bis-12
>
>   Inline.
>
> On 10 February 2015 at 00:58, Alissa Cooper <[e-mail]> wrote:
>
>>  Hi Charles,
>>
>>  Thanks, some responses inline.
>>
>>  On Feb 4, 2015, at 10:40 AM, Charles Eckel (eckelcu) <[e-mail]>
>> wrote:
>>
>>  HI Alissa,
>>
>>  Thank you for the review. Please see my thoughts on your comments and
>> questions inline.
>>
>>   From: Alissa Cooper <[e-mail]>
>> Date: Thursday, January 29, 2015 at 10:19 PM
>> To: "[e-mail]" <[e-mail]>
>> Subject: [bfcpbis] AD evaluation: draft-ietf-bfcpbis-rfc4582bis-12
>>
>>   I have reviewed this draft in preparation for IETF LC. Overall the
>> document appears in good shape. I have a few questions and comments I’d
>> like to discuss before issuing the IETF last call. I’ve also included some
>> editorial nits that should be addressed together with any last call
>> comments.
>>
>>  Comments and questions:
>>
>>  = Section 5.1 =
>>  "If an endpoint receives a message with an
>>      unsupported version field value, the receiving server MUST send an
>>      Error message with parameter value 12 (Unsupported Version) to
>>      indicate this.”
>>
>>  This seems a little misleading since RFC 4582 didn’t specify what to do
>> upon receipt of a message with a version other than 1. Implementations that
>> do not get upgraded to be compliant with 4582bis (which could certainly
>> account for some of those that will not support version 2) will therefore
>> never send the error specified here. This seems like it should at least be
>> noted given the MUST-level requirement. The same applies in Section 13.7.
>>
>>
>>  Good point. I believe we made this a MUST because we were thinking in
>> terms of implementations compliant with this bis version. Adding your
>> suggested note about rfc 4582 implementations here and in section 13.7
>> seems useful to me.
>>
>>
>>  Ok
>>
>
>  Fine. Added text in 5.1 and 13.7 stating quite similarly this:
>
>  Text:
> "If an endpoint receives a message with an unsupported version field
> value, and the extensions in this document is supported, the receiving
> server MUST send an Error message with parameter value 12 (Unsupported
> Version) to indicate this. Note that endpoints supporting only the RFC 4582
> subset will not support this parameter value."
>
>      = Section 7 =
>> "BFCP entities MUST support, at a minimum, the
>>    TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6].”
>>
>>  I realize this requirement comes from RFC 4582, but I’d like to
>> understand why it has not been updated to be consistent with more current
>> guidance on cipher suite selection (e.g.,
>> https://tools.ietf.org/html/draft-ietf-uta-tls-bcp-08#section-4).
>>
>>
>>  How about we keep this minimum requirement, and add a reference
>> to draft-ietf-uta-tls-bcp along with a recommendation to adhere to the best
>> practices it outlines in section 4?
>>
>>
>>  I think MUST support TLS_RSA_WITH_AES_128_CBC_SHA for backwards
>> compatibility and SHOULD support the ones listed in the UTA drafts would be
>> ok.
>>
>
>  Hopefully, this is what new implementations will do. But of course,
> adding this as SHOULD requirements are just fine - even though the
> reference is an internet-draft and not an RFC yet.
>
>  Text:
>  "<t>BFCP entities MUST support, at a minimum, the
> TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite <xref target="RFC5246"/> for
> backwards compatibility with existing implementations of RFC 4582. In
> accordance with the recommendations and guidelines in <xref
> target="I-D.ietf-uta-tls-bcp"/>, BFCP entities SHOULD support the following
> cipher suites:</t>
>     <t><list style="symbols">
>         <t>TLS_DHE_RSA_WITH_AES_128_GCM_SHA256</t>
>         <t>TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256</t>
>         <t>TLS_DHE_RSA_WITH_AES_256_GCM_SHA384</t>
>         <t>TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384</t>
>     </list></t>"
>
>       = Sections 8, 8.1, 8.2 =
>> It seems like the transaction ID requirements regarding
>> non-reuse/monotonically increasing IDs are re-stated multiple times across
>> these three sections, in slightly different ways, to the point where it’s
>> not clear exactly what they are. It seems like they are:
>>
>>  (1) Reliable transport, server-initiated transaction: ID is 0
>>  (2) Unreliable transport, server-initiated transaction: ID MUST be
>> monotonically increasing (except for wrap-around)
>>  (3) Reliable transport, client-initiated transaction: ID MUST NOT be 0
>> and MUST NOT be reused in another message from the client until a response
>> from the server is received for the transaction, but need not be
>> monotonically increasing (e.g., a lower, recently used ID could be re-used
>> once a response is received)
>> (4) Unreliable transport, client-initiated transaction: ID MUST be
>> monotonically increasing (except for wrap-around)
>>
>>  Is (3) the correct interpretation of the text in 8.1? If so, why not
>> just require IDs in all client-initiated transactions to be monotonically
>> increasing?
>>
>>
>>  Agree we can and should simplify this. Sections 8.1 and 8.2 cover the
>> client behavior and server behavior in detail. As such, the transaction ID
>> related information at the start of Section 8 is superfluous. I recommend
>> reducing the text in Section 8 to the follow:
>>
>>  8. Protocol Transactions
>>
>>     In BFCP, there are two types of transactions: client-initiated
>>    transactions and server-initiated transactions.
>>
>>     Client-initiated transactions consist of a request from a client to a
>>    floor control server and a response from the floor control server to
>>    the client.
>>
>>     Server-initiated transactions have different behavior depending on
>>    underlying transport:
>>
>>        When using a reliable transport, server-initiated transactions
>>       consist of a single message from a floor control server to a
>>       client (notifications).  They do not trigger any response.
>>
>>        When using an unreliable transport, server-initiated transactions
>>       consist of a request from a floor control server to a client and a
>>       response from the client to the floor control server.
>>
>>     When using BFCP over an unreliable transport, retransmission timer T1
>>    (see Section 8.3) MUST be used for all requests until the transaction
>>    is completed.
>>
>>  Then in section 8.1, we add the important details removed from section
>> 8.
>>
>>  8.1.1 Client Behavior
>>
>>     A client starting a client-initiated transaction MUST set the
>>    Conference ID in the common header of the message to the Conference
>>    ID for the conference that the client obtained previously.
>>
>>     The client MUST set the Transaction ID value in the common header to
>>    a number that is different from 0 and that MUST NOT be reused in
>>    another message from the client until a response from the server is
>>    received for the transaction.  The client uses the Transaction ID
>>    value to match this message with the response from the floor control
>>    server. When using BFCP over an unreliable transport, it is important
>> to
>>    choose a Transaction ID value that lets the receiver distinguish the
>> reception
>>    of the next message in a sequence of BFCP messages from a
>> retransmission
>>    of a previous message.  Therefore, BFCP entities using an unreliable
>> transport MUST
>>     use monotonically increasing Transaction ID values (except for wrap-
>> around).
>>
>>     A client receiving a server-initiated transaction over an unreliable
>> transport
>>    MUST copy the Transaction ID from the request received from the server
>> into the
>>    response.
>>
>>
>
>>        [Question: is there a need to copy the Conference ID and User ID,
>> if present?]
>>
>>    Shouldn't be necessary for this message direction!
>
>      8.2. Server Behavior
>>
>>     A floor control server sending a response within a client-initiated
>>    transaction MUST copy the Conference ID, the Transaction ID, and the
>>    User ID from the request received from the client into the response.
>>
>>     Server-initiated transactions MUST contain a Transaction ID equal to
>>    0 when BFCP is used over a reliable transport.  Over an unreliable
>>    transport, the Transaction ID shall have the same properties as for
>>    client-initiated transactions. The server uses the Transaction ID
>> value to
>>    match this message with the response from the floor participant or
>>    floor chair.
>>
>>
>>   Thanks, this is better.
>>
>
>  Charles' trimmed text adopted. The duplication of descriptions probably
> stems from our reshuffling and restructuring of text and later rounds of
> clarifications of text pieces.
>
>       = Section 9 (impacts Section 14 as well) =
>> "BFCP clients SHOULD authenticate the floor control server before
>>    sending any BFCP message to it or accepting any BFCP message from it.
>>    Similarly, floor control servers SHOULD authenticate a client before
>>    accepting any BFCP message from it or sending any BFCP message to it.
>>
>>     BFCP supports TLS/DTLS mutual authentication between clients and
>>    floor control servers, as specified in Section 9.1.  This is the
>>    RECOMMENDED authentication mechanism in BFCP.”
>>
>>  What are the cases where clients and servers do not need to be
>> authenticating each other? I know this requirement and the other
>> SHOULD-level requirements around use of TLS/DTLS are carried over from RFC
>> 4582, but I’m concerned that they aren’t as strong as they should be. For a
>> conference where the signaling traffic is authenticated and confidentiality
>> and integrity protected, why is it ok for the floor control traffic not to
>> be? Could these requirements be adjusted to require use of TLS/DTLS at
>> least in cases where the signaling is also protected?
>>
>>
>>  Yes, but again, this would be at the expense of adding a non backward
>> compatible change from rfc 4582. How about saying TLS/DTLS MUST be used for
>> BFCP in such cases, while pointing out the rfc 4582 based implementations
>> may not comply (similar to what we did with the version field).
>>
>>
>>  Works for me.
>>
>
>  Text in Section 9:
>  "<t>BFCP clients SHOULD authenticate the floor control server before
> sending any BFCP message to it or accepting any BFCP message from it.
> Similarly, floor control servers SHOULD authenticate a client before
> accepting any BFCP message from it or sending any BFCP message to it.</t>
>     <t>If the signaling or control protocol traffic used to set up the
> conference is authenticated and confidentiality and integrity protected,
> and the extensions in this document is supported, the BFCP clients MUST
> authenticate the floor control
>
>
>  s/is supported/are supported
>
>      server and the floor control servers MUST authenticate a client
> before communicating as described above. Note that
>
>
>  s/a client/the client
>
>      endpoints supporting only the RFC 4582 subset may not comply with
> this mandatory authentication requirement.</t>
>
>
>  Text first in Section 14:
>  "<t>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 <xref target="sec:lower-security"/> always be used
> and in cases where signaling/control traffic is properly protected, as
> described
>
>
>  s/be used and in cases/be used. In cases
>
>  Cheers,
> Charles
>
>     in <xref target="sec:auth"/> it is REQUIRED to use a mandated
> encryption algorithm. BFCP entities MAY use other security mechanisms as
> long as they provide similar security properties.</t>"
>
> Text last in Section 14:
> "<t>Attackers may attempt to pick messages from the network to get access
> to confidential information between the floor control server and a client
> (e.g., why a floor request was denied). TLS/DTLS confidentiality prevents
> this attack. Therefore, it is REQUIRED that TLS/DTLS be used with an
> encryption algorithm according to <a href="sec:lower-security"/>.</t>"
>
>
>    Feel free to make all of these changes and submit a rev and I’ll issue
>> the IETF LC.
>>
>>  Thanks,
>> Alissa
>>
>>
>>
>>  = Section 14 =
>> See the point above about ciphersuites. “Non-null encryption” is not a
>> sufficient minimum baseline, and if the requirements change in Section 7
>> they should be reflected here as well.
>>
>>
>>  Yep.
>>
>>    Section 14 polished a bit, as indicated above.
>
>
>>      Editorial nits to be resolved with LC comments:
>>
>>  = Section 5.1 =
>> “The version field MUST be set to 1 when using BFCP over a reliable
>>    transport, i.e. as in [2].”
>>
>>  I find it a little odd to reference the spec you’re obsoleting in this
>> sentence, especially since BFCP over a reliable transport is completely
>> specified in this bis document. I would suggest dropping the i.e. clause.
>>
>>
>>  Good catch. This is a carry over from before this draft was adopted as
>> a bis version of rfc4582.
>>
>>    Fixed.
>
>        "The version field MUST be set to 2 when
>>    using BFCP over an unreliable transport with the extensions specified
>>    in this document.”
>>
>>  The bit about “with the extensions specified in this document” is
>> extraneous and should be removed.
>>
>>     Done
>
>       "If an endpoint receives a message with an
>>     unsupported version field value, the receiving server MUST send an
>>     Error message with parameter value 12 (Unsupported Version) to
>>     indicate this.”
>>
>>  Use of the word “server” here makes it sound as if only servers could
>> receive headers with unsupported versions. Should this be “the receiving
>> endpoint”?
>>
>>     Well, only floor control servers may issue an Error message so this
> is fixed by stating that. "If a floor control server receives...".
>
>       = Section 6.2.4 =
>> "[23], Section 6.7 provides useful recommendations …”
>>
>>  The links in the references are not quite right.
>>
>>     No way to fix with my current version of xml2rfc!
>
>>      = Section 8.3.2 =
>> s/when fires/when fired/
>>
>>     Fixed.
>
>       = Section 14 =
>> s/high-jack/hijack/
>>
>>     Fixed.
>
>       = Section B.1 =
>> "situation where multiple different and non-interoperable would co-
>>    exist in the market.”
>>
>>  There is a word missing after “non-interoperable."
>>
>>
>>  This should read “non-interoperable implementations”. Earlier in that
>> same sentence, “BFCP over UDP were already used” should read “BFCP over UDP
>> is already being used”.
>>
>>    Both fixed.
>
>
>  Will submit the new version ASAP if no reactions are triggered here!
>
>  -- Tom
>
>
>
>  --
> # Cisco                         |  http://www.cisco.com/telepresence/
> ## [e-mail]  |  http://www.tandberg.com
> ###                               |  http://folk.uio.no/tomkri/
>
>


-- 
# Cisco                         |  http://www.cisco.com/telepresence/
## [e-mail]  |  http://www.tandberg.com
###                               |  http://folk.uio.no/tomkri/