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

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 04 Nov 2015 18:31:08 -0800

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).“

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 05 Nov 2015 13:24:10 +0900

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.

Paul

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

   

 		

   
The new text says:

   

_______________________________________________
bfcpbis mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bfcpbis

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 5 Nov 2015 13:46:21 +0900

Hi, Paul,

On Thu, Nov 5, 2015 at 1:24 PM, Paul E. Jones <[email-masked]> 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?
>

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:

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 <[email-masked]>
> *Sent:* November 5, 2015 11:31:08 AM GMT+09:00
> *To:* The IESG <[email-masked]>
> *Cc:* [email-masked], [email-masked],
> [email-masked], [email-masked],
> [email-masked]
> *Subject:* [bfcpbis] Spencer Dawkins' Discuss on
> draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT)
>
> ------------------------------
>
> DISCUSS:
> ------------------------------
>
>
> good (at the Discuss level), but have one remaining concern!
>  , on
> section
> with sequence numbers that are within t!
>  he
> current window. That's not
> ------------------------------
>
> COMMENT:
> ------------------------------
>
>
>
> I have a couple of Comments on !
>  new
> text:
>
>
> the
> recommendation to use a secure transport.)”
>
>    messag!
>  e with
> an unsupported version field value, the server MUST
> ------------------------------
>
> bfcpbis mailing list
> [email-masked]

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 05 Nov 2015 13:54:35 +0900

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

-------- Original Message --------
From: Spencer Dawkins at IETF <[email-masked]>
Sent: November 5, 2015 1:46:21 PM GMT+09:00
To: "Paul E. Jones" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, [email-masked], [email-masked], [email-masked], The IESG <[email-masked]>, Mary Barnes <[email-masked]>
Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT)

Hi, Paul,

Thanks,

Spencer

> Paul

------------------------------------------------------------------------

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 5 Nov 2015 15:36:13 +0900

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 <[email-masked]> wrote:
> 
> Spencer,
> 
> On Thu, Nov 5, 2015 at 1:24 PM, Paul E. Jones <[email-masked] <mailto:[email-masked]>> wrote:
> Spencer,
> 
> 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:
> 
> 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 <[email-masked] <mailto:[email-masked]>>
> To: The IESG <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>, [email-masked] <mailto:[email-masked]>, [email-masked] <mailto:[email-masked]>, [email-masked] <mailto:[email-masked]>, [email-masked] <mailto:[email-masked]>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html <https://www.ietf.org/iesg/statement/discuss-criteria.html>
> https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis <https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis>/
> 
> 
> 
> 
> DISCUSS:
> 
> 
> with !
>  sequence
> numbers that are within t!
>  he
> response messages.  See the Security Considerations sect!
>  ion
> regarding
> the
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/bfcpbis <https://www.ietf.org/mailman/listinfo/bfcpbis>
> 
> 
> 
> bfcpbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bfcpbis <https://www.ietf.org/mailman/listinfo/bfcpbis>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 5 Nov 2015 08:43:19 +0000

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 <[email-masked]<mailto:[email-masked]>>
Date: Thursday, November 5, 2015 at 1:46 PM
To: Paul Jones <[email-masked]<mailto:[email-masked]>>
Cc: The IESG <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Mary Barnes <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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 <[email-masked]<mailto:[email-masked]>> wrote:
Spencer,

Thanks,

Spencer

Paul

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

________________________________

DISCUSS:
________________________________

________________________________

COMMENT:
________________________________

The new text says:

________________________________

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

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 5 Nov 2015 23:20:41 +0900

Hi, Charles,

On Thu, Nov 5, 2015 at 5:43 PM, Charles Eckel (eckelcu) <[email-masked]>
wrote:

> 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.
>

Got it. I'm holding my nose on this one, based on backward compatibility,
and given the degree of difficulty in splicing attack packets into the TCP
sequence numbering space if you're off-path. I'm not thrilled, but someone
else needs to decide when threats reach the level where making that
incompatible change is necessary - and that might not be the right thing to
do today.

> 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.
>

OK, I'm not the Protocol Security Police, so, fine, but it seems like the
draft could be clearer about this, and what you said in your answer would
be really helpful in the document.

If the text said something like "DTLS is REQUIRED unless you are
interworking with a pre-standardization deployment that is already
insecure, in which case you're not making things worse by running without
transport-level security", that would capture my concern and reflect what
you're saying, unless I'm missing something.

Thanks to you and Paul for the speedy response on the evening of Bits and
Bites!

Spencer

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 6 Nov 2015 07:06:31 +0900

Hi Spencer,

> On Nov 5, 2015, at 11:20 PM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Hi, Charles,
> 
>> On Thu, Nov 5, 2015 at 5:43 PM, Charles Eckel (eckelcu) <[email-masked]> wrote:
> Got it. I'm holding my nose on this one, based on backward compatibility, and given the degree of difficulty in splicing attack packets into the TCP sequence numbering space if you're off-path. I'm not thrilled, but someone else needs to decide when threats reach the level where making that incompatible change is necessary - and that might not be the right thing to do today.
>  
> OK, I'm not the Protocol Security Police, so, fine, but it seems like the draft could be clearer about this, and what you said in your answer would be really helpful in the document. 
> 
> If the text said something like "DTLS is REQUIRED unless you are interworking with a pre-standardization deployment that is already insecure,

"REQUIRED unless" strikes me as a faulty construction. That case is what RECOMMENDED is for, when there is a known exception to the requirement.

Alissa

> in which case you're not making things worse by running without transport-level security", that would capture my concern and reflect what you're saying, unless I'm missing something.
> 
> Thanks to you and Paul for the speedy response on the evening of Bits and Bites!
> 
> Spencer

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 6 Nov 2015 07:23:16 +0900

Hi, Alissa,

On Nov 6, 2015 7:06 AM, "Alissa Cooper" <[email-masked]> wrote:
>>> 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.
>>
>>
>> Got it. I'm holding my nose on this one, based on backward
compatibility, and given the degree of difficulty in splicing attack
packets into the TCP sequence numbering space if you're off-path. I'm not
thrilled, but someone else needs to decide when threats reach the level
where making that incompatible change is necessary - and that might not be
the right thing to do today.
>>
>>>
>>> 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.
>>
>>
>> OK, I'm not the Protocol Security Police, so, fine, but it seems like
the draft could be clearer about this, and what you said in your answer
would be really helpful in the document.
>> If the text said something like "DTLS is REQUIRED unless you are
interworking with a pre-standardization deployment that is already insecure,
>
>
> "REQUIRED unless" strikes me as a faulty construction. That case is what
RECOMMENDED is for, when there is a known exception to the requirement.

That usage is certainly more common in some parts of the IETF than others,
but it does get used. But ignoring that.

Do you think "RECOMMENDED unless you are interworking with a
pre-standardization deployment that is already insecure" is tight enough?

The reason I'm asking, is that offpath attacks on UDP-based protocols are a
lot easier than TCP-based protocols, and if the IETF is going to publish a
proposed standard with a known deficiency to accommodate
pre-standardization deployments, I'd prefer that the guidance about using
that accommodation be as clear as possible.

Thanks,

Spencer

> Alissa
>
>> in which case you're not making things worse by running without

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 5 Nov 2015 17:46:25 -0500

> RECOMMENDED is for, when there is a known exception to the requirement.

I don't think I agree.

I think "REQUIRED unless" is quite precise. Using "RECOMMENDED unless" 
says to me that in cases where the the "unless" doesn't apply then 
RECOMMENDED applies and hence can still be violated for cause.

Historically, SHOULD/RECOMMENDED has been used in a rather casual way, 
in the spirit of "we trust you to be responsible about this". And it 
hasn't worked out well. So now we at least *say* that you ought not use 
SHOULD/RECOMMENDED without being explicit about the conditions when it 
is acceptable to violate it. At that point, the distinction between MUST 
and SHOULD goes away.

I think the following constructions are most clear:

- You MUST do foobar except when blah blah blah.
- You are REQUIRED to do foobar except when blah blah blah.
- You SHOULD do foobar. The only acceptable situation to not do foobar
   is blah blah blah.
- It is RECOMMENDED that you do foobar. The only acceptable situation
   to not do foobar is blah blah blah.

I have had implementers tell me that when they get an assignment to 
implement a spec, their management tells them to only do the MUSTs, 
because that is all that is required to satisfy the checkoff!

	Thanks,
	Paul

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 6 Nov 2015 08:32:48 +0900

> On Nov 6, 2015, at 7:46 AM, Paul Kyzivat <[email-masked]> wrote:
> 

Either of the above would be fine. SHOULD and RECOMMENDED are equivalent according to RFC 2119.

Alissa

> 
> I have had implementers tell me that when they get an assignment to implement a spec, their management tells them to only do the MUSTs, because that is all that is required to satisfy the checkoff!
> 
> 	Thanks,
> 	Paul
>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 5 Nov 2015 23:42:21 +0000

From: Spencer Dawkins at IETF <[email-masked]<mailto:[email-masked]>>
Date: Friday, November 6, 2015 at 7:23 AM
To: Alissa Cooper <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Paul Jones <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Mary Barnes <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Charles Eckel <[email-masked]<mailto:[email-masked]>>
Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT)

Hi, Alissa,

On Nov 6, 2015 7:06 AM, "Alissa Cooper" <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi Spencer,
>
>
>
> On Nov 5, 2015, at 11:20 PM, Spencer Dawkins at IETF <[email-masked]<mailto:[email-masked]>> wrote:
>
>> Hi, Charles,
>>
>> On Thu, Nov 5, 2015 at 5:43 PM, Charles Eckel (eckelcu) <[email-masked]<mailto:[email-masked]>> wrote:
>>>

That usage is certainly more common in some parts of the IETF than others, but it does get used. But ignoring that.

Do you think "RECOMMENDED unless you are interworking with a pre-standardization deployment that is already insecure" is tight enough?

The reason I'm asking, is that offpath attacks on UDP-based protocols are a lot easier than TCP-based protocols, and if the IETF is going to publish a proposed standard with a known deficiency to accommodate pre-standardization deployments, I'd prefer that the guidance about using that accommodation be as clear as possible.

I agree with your intent. My concern with calling out exceptions is that it can make the existing recommendation in the draft seem weaker. How about this:

OLD:

   … It is RECOMMENDED that TLS/DTLS with an

NEW

   … 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 to interwork with
   legacy implementation that do not use TLS/DTLS as long as these
   mechanisms provide similar security properties.

Cheers,
Charles

Thanks,

Spencer

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 11 Nov 2015 14:38:05 -0800

Hi Spencer,

Does Charles’ proposal below work for you?

Thanks,
Alissa

> On Nov 5, 2015, at 3:42 PM, Charles Eckel (eckelcu) <[email-masked]> wrote:
> 
> 
> From: Spencer Dawkins at IETF <[email-masked] <mailto:[email-masked]>>
> To: Alissa Cooper <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, Paul Jones <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, Mary Barnes <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, Charles Eckel <[email-masked] <mailto:[email-masked]>>
>> On Nov 6, 2015 7:06 AM, "Alissa Cooper" <[email-masked] <mailto:[email-masked]>> wrote:
>> >
>> > Hi Spencer,
>> >
>> >
>> >
>> > On Nov 5, 2015, at 11:20 PM, Spencer Dawkins at IETF <[email-masked] <mailto:[email-masked]>> wrote:
>> >
>> >> Hi, Charles,
>> >>
>> >> On Thu, Nov 5, 2015 at 5:43 PM, Charles Eckel (eckelcu) <[email-masked] <mailto:[email-masked]>> wrote:
>> >>>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 13 Nov 2015 11:57:35 -0600

So, we're getting there.

On Wed, Nov 11, 2015 at 4:38 PM, Alissa Cooper <[email-masked]> wrote:

> To: Alissa Cooper <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>, Paul Jones <[email-masked]>, "
> [email-masked]" <[email-masked]>, Mary Barnes <
> [email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <
> [email-masked]>, Charles Eckel <[email-masked]>
> Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on
> The reason I'm asking, is that offpath attacks on UDP-based protocols are
> a lot easier than TCP-based protocols, and if the IETF is going to publish
> a proposed standard with a known deficiency to accommodate
> I agree with your intent. My concern with calling out exceptions is that
> it can make the existing recommendation in the draft seem weaker. How about
> this:
>
> OLD:
>
Probably for Charles:

This last sentence seems to be responsible for most of my remaining
heartburn.

My understanding was that TLS and (especially) DTLS were RECOMMENDED, not
REQUIRED, because there are legacy implementations that have been deployed
already. I can live with that, but is it obvious to everyone how a legacy
receiver tells a sender to use a non-TLS/DTLS mechanism? I'm looking at the
"use TLS" and "use DTLS" error codes in Table 5, and wondering where the
"use legacy security mechanism" error code might be.

Do legacy endpoints "just know" this?

Thanks,

Spencer

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 13 Nov 2015 19:11:38 +0000

Hi Spencer,

Please see inline.

From: Spencer Dawkins at IETF <[email-masked]<mailto:[email-masked]>>
Date: Saturday, November 14, 2015 at 2:57 AM
To: Alissa Cooper <[email-masked]<mailto:[email-masked]>>
Cc: IESG <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Paul Jones <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Mary Barnes <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Charles Eckel <[email-masked]<mailto:[email-masked]>>
Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT)

So, we're getting there.

On Wed, Nov 11, 2015 at 4:38 PM, Alissa Cooper <[email-masked]<mailto:[email-masked]>> wrote:
Hi Spencer,

Thanks,
Alissa

On Nov 5, 2015, at 3:42 PM, Charles Eckel (eckelcu) <[email-masked]<mailto:[email-masked]>> wrote:

Hi, Alissa,

OLD:

NEW

Probably for Charles:

This last sentence seems to be responsible for most of my remaining heartburn.

My understanding was that TLS and (especially) DTLS were RECOMMENDED, not REQUIRED, because there are legacy implementations that have been deployed already. I can live with that, but is it obvious to everyone how a legacy receiver tells a sender to use a non-TLS/DTLS mechanism? I'm looking at the "use TLS" and "use DTLS" error codes in Table 5, and wondering where the "use legacy security mechanism" error code might be.

This draft describes how to use SDP to establish a BFCP connection. The determination of whether to use TLS or TCP or DTLS or UDP is based on the SDP offer/answer and the specification within it of the m-line, e.g.

m=application 50000 UDP/BFCP *
m=application 50000 TCP/BFCP *
m=application 50000 TCP/TLS/BFCP *
m=application 50000 UDP/TLS/BFCP *

When making the offer, an implementation has a choice of using any of these and the answerer can choose to accept of reject. Some very implementations supported TCP only. Most current implementations support UDP only or in addition to TCP. In the future, we hope all with support DTLS. Typically implementation the support more than one transport provide configuration options, such as require DTLS, or offer DTLS but accept UDP or DTLS, or offer DTLS first and if rejected offer UDP. The current IMTC best practice recommends offering UDP and if that fails offer TCP. This will be updated to include DTLS once RFC4583bis is published.

Cheers,
Charles

Thanks,

Spencer

Cheers,
Charles

Thanks,
Spencer

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 13 Nov 2015 14:51:22 -0600

Hi, Charles,

On Fri, Nov 13, 2015 at 1:11 PM, Charles Eckel (eckelcu) <[email-masked]>
wrote:

> Cc: IESG <[email-masked]>, "[email-masked]" <
>> > "REQUIRED unless" strikes me as a faulty construction. That case is
>> what RECOMMENDED is for, when there is a known exception to the requirement.
>> That usage is certainly more common in some parts of the IETF than
>> others, but it does get used. But ignoring that.
> This draft describes how to use SDP to establish a BFCP connection. The
> determination of whether to use TLS or TCP or DTLS or UDP is based on the
> SDP offer/answer and the specification within it of the m-line, e.g.
>
> When making the offer, an implementation has a choice of using any of
> these and the answerer can choose to accept of reject. Some very
> implementations supported TCP only. Most current implementations support
> UDP only or in addition to TCP. In the future, we hope all with support
> DTLS. Typically implementation the support more than one transport provide
> configuration options, such as require DTLS, or offer DTLS but accept UDP
> or DTLS, or offer DTLS first and if rejected offer UDP. The current IMTC
> best practice recommends offering UDP and if that fails offer TCP. This
> will be updated to include DTLS once RFC4583bis is published.
>

This all makes perfect sense to me. I'm not understanding how legacy
implementations offering "UDP only" maps onto "other mechanisms that
provide similar security properties" in the proposed text.

Is "other mechanisms that provide similar security properties" even talking
about the same thing?

And thanks for the quick follow-up.

Spencer

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 13 Nov 2015 21:07:23 +0000

From: Spencer Dawkins at IETF <[email-masked]<mailto:[email-masked]>>
Date: Friday, November 13, 2015 at 12:51 PM
To: Charles Eckel <[email-masked]<mailto:[email-masked]>>
Cc: Alissa Cooper <[email-masked]<mailto:[email-masked]>>, IESG <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Paul Jones <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Mary Barnes <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT)

Hi, Charles,

On Fri, Nov 13, 2015 at 1:11 PM, Charles Eckel (eckelcu) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Spencer,

Please see inline.

So, we're getting there.

Thanks,
Alissa

Hi, Alissa,

OLD:

NEW

Probably for Charles:

This all makes perfect sense to me. I'm not understanding how legacy implementations offering "UDP only" maps onto "other mechanisms that provide similar security properties" in the proposed text.

Is "other mechanisms that provide similar security properties" even talking about the same thing?

Likewise. An example of other mechanisms is IPSEC and having a UDP based BFCP  connection within it.

Cheers,
Charles

Spencer

Cheers,
Charles

Thanks,

Spencer

Cheers,
Charles

Thanks,
Spencer

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 13 Nov 2015 15:15:14 -0600

Hi, Charles,

On Fri, Nov 13, 2015 at 3:07 PM, Charles Eckel (eckelcu) <[email-masked]>
wrote:

> To: Charles Eckel <[email-masked]>
> Cc: Alissa Cooper <[email-masked]>, IESG <[email-masked]>, "
> [email-masked]" <[email-masked]>, Paul Jones <
> [email-masked]>, "[email-masked]" <[email-masked]>,
> Mary Barnes <[email-masked]>, "
> [email-masked]" <
> [email-masked]>
> On Fri, Nov 13, 2015 at 1:11 PM, Charles Eckel (eckelcu) <
> [email-masked]> wrote:
>
>> Hi Spencer,
>>
>> Please see inline.
>>
>>> >>> 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.
>>> >>
>>> >>
>>> The reason I'm asking, is that offpath attacks on UDP-based protocols
>>> are a lot easier than TCP-based protocols, and if the IETF is going to
>>> publish a proposed standard with a known deficiency to accommodate

OK, so you're talking about security mechanisms that aren't under
application control at all then. I love those :D

I'll clear, but I think the document might be clearer if you said that
(even as an example).

Thanks,

Spencer

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 13 Nov 2015 21:32:17 +0000

Thanks Spencer. Based on your feedback, I have updated the proposal:

OLD:

NEW

   … 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 to interwork with
   legacy implementation that do not use TLS/DTLS as long as these
   mechanisms provide similar security properties. An example of other
   mechanisms is IPSEC to effectively secure a non-secure BFCP
   connection.

Cheers,
Charles

Date: Friday, November 13, 2015 at 1:15 PM

Hi, Charles,

On Fri, Nov 13, 2015 at 3:07 PM, Charles Eckel (eckelcu) <[email-masked]<mailto:[email-masked]>> wrote:

Hi, Charles,

Please see inline.

So, we're getting there.

Thanks,
Alissa

Hi, Alissa,

OLD:

NEW

Probably for Charles:

OK, so you're talking about security mechanisms that aren't under application control at all then. I love those :D

I'll clear, but I think the document might be clearer if you said that (even as an example).

Thanks,

Spencer

Cheers,
Charles

Spencer

Cheers,
Charles

Thanks,

Spencer

Cheers,
Charles

Thanks,
Spencer

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 13 Nov 2015 21:44:00 +0000

OK, we have this and several other suggested changes from Spencer we 
discussed during 94 that were agreed.

I'll revise the text and submit a new version of the draft to include 
this and the other suggestions.

Paul

------ Original Message ------
From: "Charles Eckel (eckelcu)" <[email-masked]>
To: "Spencer Dawkins at IETF" <[email-masked]>
Cc: "Alissa Cooper" <[email-masked]>; "IESG" <[email-masked]>; 
"[email-masked]" <[email-masked]>; "Paul E. Jones" 
<[email-masked]>; "[email-masked]" <[email-masked]>; 
"Mary Barnes" <[email-masked]>; 
"[email-masked]" 
<[email-masked]>; "[email-masked]" 
<[email-masked]>
Sent: 11/13/2015 4:32:17 PM
Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on 
draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT)

>Cc: Alissa Cooper <[email-masked]>, IESG <[email-masked]>, 
>"[email-masked]" <[email-masked]>, Paul Jones 
><[email-masked]>, "[email-masked]" <[email-masked]>, 
>Mary Barnes <[email-masked]>, 
>"[email-masked]" 
><[email-masked]>, "[email-masked]" 
><[email-masked]>
>>On Fri, Nov 13, 2015 at 3:07 PM, Charles Eckel (eckelcu) 
>><[email-masked]> wrote:
>>>
>>>Cc: Alissa Cooper <[email-masked]>, IESG <[email-masked]>, 
>>>"[email-masked]" <[email-masked]>, Paul Jones 
>>><[email-masked]>, "[email-masked]" 
>>><[email-masked]>, Mary Barnes <[email-masked]>, 
>>>"[email-masked]" 
>>><[email-masked]>, "[email-masked]" 
>>><[email-masked]>
>>>
>>>>On Fri, Nov 13, 2015 at 1:11 PM, Charles Eckel (eckelcu) 
>>>><[email-masked]> wrote:
>>>>>Hi Spencer,
>>>>>
>>>>>Please see inline.
>>>>>
>>>>>Cc: IESG <[email-masked]>, "[email-masked]" 
>>>>><[email-masked]>, Paul Jones <[email-masked]>, 
>>>>>"[email-masked]" <[email-masked]>, Mary Barnes 
>>>>><[email-masked]>, 
>>>>>"[email-masked]" 
>>>>><[email-masked]>, "[email-masked]" 
>>>>><[email-masked]>, Charles Eckel <[email-masked]>
>>>>>
>>>>>>>>Cc: "[email-masked]" <[email-masked]>, "[email-masked]" 
>>>>>>>><[email-masked]>, Paul Jones <[email-masked]>, 
>>>>>>>>"[email-masked]" <[email-masked]>, Mary Barnes 
>>>>>>>><[email-masked]>, 
>>>>>>>>"[email-masked]" 
>>>>>>>><[email-masked]>, "[email-masked]" 
>>>>>>>><[email-masked]>, Charles Eckel <[email-masked]>
>>>>>>>>> >>> 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.
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>>compatibility, and given the degree of difficulty in splicing 
>>>>>>>>>attack packets into the TCP sequence numbering space if you're 
>>>>>>>>>off-path. I'm not thrilled, but someone else needs to decide 
>>>>>>>>>when threats reach the level where making that incompatible 
>>>>>>>>>change is necessary - and that might not be the right thing to 
>>>>>>>>>do today.
>>>>>>>>> >>
>>>>>>>>> >>>
>>>>>>>>> >>> 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.
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >> OK, I'm not the Protocol Security Police, so, fine, but it 
>>>>>>>>>seems like the draft could be clearer about this, and what you 
>>>>>>>>>said in your answer would be really helpful in the document.
>>>>>>>>> >>
>>>>>>>>> >> If the text said something like "DTLS is REQUIRED unless you 
>>>>>>>>>are interworking with a pre-standardization deployment that is 
>>>>>>>>>already insecure,
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > "REQUIRED unless" strikes me as a faulty construction. That 
>>>>>>>>>case is what RECOMMENDED is for, when there is a known 
>>>>>>>>>exception to the requirement.
>>>>>>>>>That usage is certainly more common in some parts of the IETF 
>>>>>>>>>than others, but it does get used. But ignoring that.
>>>>>>>>>The reason I'm asking, is that offpath attacks on UDP-based 
>>>>>>>>>protocols are a lot easier than TCP-based protocols, and if the 
>>>>>>>>>IETF is going to publish a proposed standard with a known 
>>>>>>>>>deficiency to accommodate pre-standardization deployments, I'd 
>>>>>>>>>prefer that the guidance about using that accommodation be as 
>>>>>>>>>clear as possible.
>>>>>>>>
>>>>>>>>I agree with your intent. My concern with calling out exceptions 
>>>>>>>>is that it can make the existing recommendation in the draft 
>>>>>>>>seem weaker. How about this:
>>>>>>>>
>>>>>>>>OLD:
>>>>>>>>
>>>>>>My understanding was that TLS and (especially) DTLS were 
>>>>>>RECOMMENDED, not REQUIRED, because there are legacy 
>>>>>>implementations that have been deployed already. I can live with 
>>>>>>that, but is it obvious to everyone how a legacy receiver tells a 
>>>>>>sender to use a non-TLS/DTLS mechanism? I'm looking at the "use 
>>>>>>TLS" and "use DTLS" error codes in Table 5, and wondering where 
>>>>>>the "use legacy security mechanism" error code might be.
>>>>>>
>>>>>This draft describes how to use SDP to establish a BFCP connection. 
>>>>>The determination of whether to use TLS or TCP or DTLS or UDP is 
>>>>>based on the SDP offer/answer and the specification within it of 
>>>>>the m-line, e.g.
>>>>>
>>>>>When making the offer, an implementation has a choice of using any 
>>>>>of these and the answerer can choose to accept of reject. Some very 
>>>>>implementations supported TCP only. Most current implementations 
>>>>>support UDP only or in addition to TCP. In the future, we hope all 
>>>>>with support DTLS. Typically implementation the support more than 
>>>>>one transport provide configuration options, such as require DTLS, 
>>>>>or offer DTLS but accept UDP or DTLS, or offer DTLS first and if 
>>>>>rejected offer UDP. The current IMTC best practice recommends 
>>>>>offering UDP and if that fails offer TCP. This will be updated to 
>>>>>include DTLS once RFC4583bis is published.
>>>>
>>>>>>>>> >> in which case you're not making things worse by running 
>>>>>>>>>without transport-level security", that would capture my 
>>>>>>>>>concern and reflect what you're saying, unless I'm missing 
>>>>>>>>>something.
>>>>>>>>> >>
>>>>>>>>> >>mailto:[email-masked]

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 13 Nov 2015 15:48:03 -0600

Thanks - and Charles' latest proposal makes me feel better about clearing.

Spencer

On Fri, Nov 13, 2015 at 3:44 PM, Paul E. Jones <[email-masked]>
wrote:

> I'll revise the text and submit a new version of the draft to include this
> and the other suggestions.
>
> Paul
>
> Cc: "Alissa Cooper" <[email-masked]>; "IESG" <[email-masked]>; "
> [email-masked]" <[email-masked]>; "Paul E. Jones" <
> [email-masked]>; "[email-masked]" <[email-masked]>;
> "Mary Barnes" <[email-masked]>; "
> [email-masked]>; "[email-masked]" <
> [email-masked]>
> On Fri, Nov 13, 2015 at 3:07 PM, Charles Eckel (eckelcu) <
>>>> 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
>>>> >> OK, I'm not the Protocol Security Police, so, fine, but it seems
>>>> like the draft could be clearer about this, and what you said in your
>>>> answer would be really helpful in the document.
>>>> >>
>>>> I agree with your intent. My concern with calling out exceptions is
>>>> that it can make the existing recommendation in the draft seem weaker. How
>>>> about this:
>>>>
>>>> OLD:
>>>>
>>> My understanding was that TLS and (especially) DTLS were RECOMMENDED,
>>> not REQUIRED, because there are legacy implementations that have been
>>> deployed already. I can live with that, but is it obvious to everyone how a
>>> legacy receiver tells a sender to use a non-TLS/DTLS mechanism? I'm looking
>>> at the "use TLS" and "use DTLS" error codes in Table 5, and wondering where
>>>> >>mailto:[email-masked] <[email-masked]>