Subject: [straw] Stephen Farrell's Discuss on draft-ietf-straw-b2bua-dtls-srtp-09: (with DISCUSS and COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 01 Dec 2015 15:30:19 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-straw-b2bua-dtls-srtp-09: 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-straw-b2bua-dtls-srtp/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I wonder if you've gotten wrapped around the axle here knowing that
we won't standardise a (D)TLS MitM, but yet trying to describe
things that basically are often deployed as MitMs.  Anyway, while I
do agree with Alissa's discuss, I also have some additional points
to raise, some of which I think came up when we had some mail
exchanges about an earlier version of this draft back in January of
this year.

(1) Alissa is correct that the unqualified SHOULD NOT "terminate"
DTLS is insufficient, but in addition to her call for qualification
of that, (or I guess moving to a MUST NOT,) I would like to chat
about the consequences should one (for whatever reason) ignore that
SHOULD NOT. Whether or not this discuss point is worth talking
about depends on how Alissa's discuss on this is resolved.  It
seems to me (as I said back in January) that keeping the SHOULD NOT
would mean that any UA that is able to inter-operate with a B2BUA
that does "terminate" DTLS (because it fits with whatever
qualifiers you end up adding to the SHOULD NOT) can never ever be
confident of the identity of any DTLS peer (since it has code that
lets the call happen regardless of the DTLS-layer peer identity). I
can't see how that wouldn't make the Internet worse, hence the
discuss.

(2) In the introduction you say "B2BUAs terminating DTLS-SRTP
session are outside the scope of this document." yet if you keep
the SHOULD NOT and don't move that to a MUST NOT (which was an
option we discussed back in Jan, I assume the WG didn't like
that?), then you are in fact including those are within the scope
of this document and therefore you would need to specify how to
"terminate" a DTLS or DTLS-SRTP session when one is a B2BUA but yet
respect RFC2804.  I just can't see how one might do that to be
honest.

(3) 3.1.2 says: "There are two types of media-aware relays, those
that merely inspect the RTP headers and unencrypted portions of
RTCP packets, and those that inspect and modify the RTP headers and
unencrypted portions of RTCP packets." Logically, those are not the
only options, as one can modify the encrypted portions too.
(Hopefully resulting in the integrity checking causing the packets
to be dropped.) I think this particular lack of clarity does raise
to the level of a DISCUSS as it's crucial for this document to be
clear about not standardising a MitM. ("Sins of omission" are 
probably not a good idea here:-)

(4) 3.1.2.2 says: "This security and privacy problem can be
mitigated by having different keys for protecting RTP header
integrity and encrypting the RTP payload.  For example, the
approach discussed in [I-D.jones-perc-private-media-reqts] can be
used." I have two issues with that. First, where is having
different keys documented? If only in the draft referenced, then
what is the status of that? And secondly, doesn't perc require a
KMS to exist? In which case I can't see how this specification
works for calls between UAs (via a B2BUA) where there is no KMS. I
think there are both security and interop (and hence also process)
issues with what you're saying here.

(5) 3.2 says: "the ClientHello message from a B2BUA (acting as DTLS
client)" I don't see how a B2BUA can send it's own ClientHello (as
opposed to forwarding a UA's) unless it is a MitM.  Since we do not
standardise MitM (cf. RFC2804) this text must be wrong or out of
place?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- I don't see what Figure2 is trying to tell me, though the
preceding text is clear enough. I'd recommend maybe dropping that
figure or else making it a full ladder diagram of (most of) the
messages involved.

- There's a repetition of the "SHOULD NOT" problem that affects my
point (1) above and Alissa's discuss points in the security
considerations when you say "Attempting to cover media-aware relay
modifying RTP headers and media termination scenarios involving
secure sessions (like DTLS-SRTP) will inevitably lead to the B2BUA
acting as a man-in-the-middle, and hence it is RECOMMENDED that
B2BUAs do not terminate DTLS-SRTP session."

- As with Alissa, I think the reliance on 4474, especially if that
is not deployed, is odd. It would be bad if that were read as
encouragement to not check DTLS client/server certs unless one
implements 4474. (But this is covered in Alissa's discuss so is
just a comment here.)

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 3 Dec 2015 05:36:33 +0000

Hi Stephen,

Thanks for the comments, Please see inline

> -----Original Message-----
> From: straw [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: Wednesday, December 02, 2015 5:00 AM
> To: The IESG
> Cc: [email-masked]; [email-masked]; straw-
> [email-masked]; [email-masked]
> Subject: [straw] Stephen Farrell's Discuss on draft-ietf-straw-b2bua-dtls-srtp-
> 09: (with DISCUSS and COMMENT)
> 
> 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.)
> 
> 
> I wonder if you've gotten wrapped around the axle here knowing that we
> won't standardise a (D)TLS MitM, but yet trying to describe things that
> basically are often deployed as MitMs.  Anyway, while I do agree with Alissa's
> discuss, I also have some additional points to raise, some of which I think
> came up when we had some mail exchanges about an earlier version of this
> draft back in January of this year.
> 
> DTLS is insufficient, but in addition to her call for qualification of that, (or I
> guess moving to a MUST NOT,) I would like to chat about the consequences
> should one (for whatever reason) ignore that SHOULD NOT. Whether or not
> this discuss point is worth talking about depends on how Alissa's discuss on
> this is resolved.  It seems to me (as I said back in January) that keeping the
> SHOULD NOT would mean that any UA that is able to inter-operate with a
> B2BUA that does "terminate" DTLS (because it fits with whatever qualifiers
> you end up adding to the SHOULD NOT) can never ever be confident of the
> identity of any DTLS peer (since it has code that lets the call happen
> regardless of the DTLS-layer peer identity). I can't see how that wouldn't
> make the Internet worse, hence the discuss.

Agreed, will change to "MUST NOT"

> 
> (2) In the introduction you say "B2BUAs terminating DTLS-SRTP session are
> outside the scope of this document." yet if you keep the SHOULD NOT and
> don't move that to a MUST NOT (which was an option we discussed back in
> Jan, I assume the WG didn't like that?)

Will make it normative.

> , then you are in fact including those
> are within the scope of this document and therefore you would need to
> specify how to "terminate" a DTLS or DTLS-SRTP session when one is a B2BUA
> but yet respect RFC2804.  I just can't see how one might do that to be honest.
> 
> (3) 3.1.2 says: "There are two types of media-aware relays, those that merely
> inspect the RTP headers and unencrypted portions of RTCP packets, and
> those that inspect and modify the RTP headers and unencrypted portions of
> RTCP packets." Logically, those are not the only options, as one can modify
> the encrypted portions too.
> (Hopefully resulting in the integrity checking causing the packets to be
> dropped.) I think this particular lack of clarity does raise to the level of a
> DISCUSS as it's crucial for this document to be clear about not standardising a
> MitM. ("Sins of omission" are probably not a good idea here:-)

We can add the following text for clarify that if B2BUA acts MitM it will be detected by the endpoint:
If B2BUA modifies unencrypted or encrypted portions of the RTP or RTCP packets then the integrity check will fail and the packet will be dropped by the endpoint.  The unencrypted or encrypted portions of the RTP or RTCP packets are integrity protected using the HMAC algorithm negotiated during DTLS handshake (discussed in section 4.1.2 of [RFC5764]).

> 
> (4) 3.1.2.2 says: "This security and privacy problem can be mitigated by
> having different keys for protecting RTP header integrity and encrypting the
> RTP payload.  For example, the approach discussed in [I-D.jones-perc-
> private-media-reqts] can be used." I have two issues with that. First, where is
> having different keys documented? If only in the draft referenced, then what
> is the status of that? 

Yes, different keys are discussed in [I-D.jones-perc-private-media-reqts] draft and it's an individual document. 

> And secondly, doesn't perc require a KMS to exist? 

Yup, Perc requires KMS.

> In which case I can't see how this specification works for calls between UAs (via
> a B2BUA) where there is no KMS. I think there are both security and interop
> (and hence also process) issues with what you're saying here.

Agreed, will remove all discussions related to Perc and different keys.

> 
> (5) 3.2 says: "the ClientHello message from a B2BUA (acting as DTLS client)" I
> don't see how a B2BUA can send it's own ClientHello (as opposed to
> forwarding a UA's) unless it is a MitM.  Since we do not standardise MitM (cf.
> RFC2804) this text must be wrong or out of place?

Yes, it's wrong. We will fix that in the next revision, B2BUA is just forwarding the DTLS handshake messages from the UA. 

> - I don't see what Figure2 is trying to tell me, though the preceding text is
> clear enough. I'd recommend maybe dropping that figure or else making it a
> full ladder diagram of (most of) the messages involved.

Figure 2 is added to aid the example of Alice request getting forked.

> 
> - There's a repetition of the "SHOULD NOT" problem that affects my point (1)
> above and Alissa's discuss points in the security considerations when you say
> "Attempting to cover media-aware relay modifying RTP headers and media
> termination scenarios involving secure sessions (like DTLS-SRTP) will
> inevitably lead to the B2BUA acting as a man-in-the-middle, and hence it is
> RECOMMENDED that B2BUAs do not terminate DTLS-SRTP session."

NEW:
These B2BUAs MUST NOT terminate DTLS-SRTP session.

> 
> - As with Alissa, I think the reliance on 4474, especially if that is not deployed,
> is odd. It would be bad if that were read as encouragement to not check DTLS
> client/server certs unless one implements 4474. (But this is covered in
> Alissa's discuss so is just a comment here.)

We will update the draft to point to 4474bis.

-Tiru

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