[Ballot comment]

Thanks for addressing my discuss points.

You still have a reference to 3.1.1 in section 5.1.2, which I guess
should now be a reference to 5.1.1. I didn't check if there are any
other similar internal references that need fixing.

[Ballot comment]
I support at least some of Alissa's and Stephen's DISCUSS points.

In particular, I'm not fully in agreement with Alissa on her point 1: We do sometimes (and should) make normative statements about how protocols should work and should be used, even with knowledge that those statements may (will) be ignored.  Sometimes it's to keep the protocol tight; sometimes it's to provide a lever ("The IETF has a standard that says that what you're doing is wrong!").

Because of that, Alissa's point 2 is particularly important: We have to stop the general practice of watering down normative statement in protocols as a way of mollifying people who don't like them.  If the right thing is to say "MUST do X", we should not say "SHOULD do X" because we know that some implementations don't and won't do X.  In particular, here, if there's any value in this, it's necessary to be strict and clear to expose that value.

[Ballot 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?

[Ballot 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.)

[Ballot comment]
I like the idea of documenting the methods used for MiTM to provide ways to avoid that in practice, but support Alyssa'a discuss points to make this point more clear (purpose of this documentation) and her concerns about what happens in actual implementations.  I'd like to hear more on whether this should be standards track or informational as well and will follow along with her discuss thread.

[Ballot discuss]
(1)
I have a fairly fundamental concern about this document that I'd like to discuss. My impression is that most B2BUAs in the market today that handle DTLS-SRTP do so with the explicit purpose of accessing the media. That is, if I need a box that doesn't access the media I use a SIP proxy, and if I need one that does access it I use a B2BUA. I realize that there are more flavors of B2BUA defined in RFC 7092, but in terms of how real SBCs work, it seems to me that they break DTLS-SRTP intentionally if they do so at all.

If that's the case, the question then arises about the value of writing down normative recommendations that are more than likely to be ignored. Perhaps this document would have made more sense as informational, offering a non-normative explanation of what a B2BUA should do if it does not want to break e2e security. Even as an informational document it's still not obvious to me that there is much at all to say here for media-aware B2BUAs that isn't entirely reductive -- "don't terminate DTLS-SRTP if you don't want to break DTLS-SRTP" -- but at least as an informational document it wouldn't be suggesting normative requirements that are out of sync with real deployments.

Could you articulate the reasons why someone would build a B2BUA that follows the recommendations in this draft? I note that the draft says nothing about using a TURN server as a media relay, which seems like it would be more common than using a B2BUA for the same purpose. Aren't B2BUAs typically deployed *because* they are media-aware?

(2)
Taking into account the above comment, I think 3.1.2.1 and 3.1.2.2 are problematic. 3.1.2.1 creates a normative SHOULD NOT-level requirement for inspection B2BUAs without explaining what the exception cases are, and 3.1.2.2 creates no normative requirements for modification B2BUAs. It's not even clear to me why the distinction is being drawn between the two kinds of B2BUAs if the bottom line is that in both cases the recommendation is to not terminate DTLS-SRTP. But this brings us back to the above comment. The problem here seems to be that what the WG and the IETF would want to say here is that B2BUAs MUST NOT terminate DTLS-SRTP to man-in-the-middle the media, but that is what B2BUAs generally do, so instead the text waffles and the recommendations are watered down and unclear.

(3)
The characterization of the RFC 4474 mechanism seems to contradict the way the mechanism is actually specified. The 4474 mechanism was designed such that intermediaries would be able to provide signatures on behalf of users (e.g., see RFC 4474 Section 3, "This specification allows either a user agent or a proxy server to provide identity services and to verify identities ... in the initial use of this mechanism, it is likely that intermediaries will instantiate the authentication service role"). So the claim that terminating DTLS-SRTP would cause 4474 identity and integrity checks to fail isn't true, because an SBC can decrypt and re-sign the request itself. A B2BUA that bridges two administrative domains can check the validity of the signature in the domain on on side as authorization to form a new signature that is valid in the domain in the other side.

The fact that user-provided identity assertions are not guaranteed to persist end-to-end is one key reason for the ongoing work in the STIR WG. The work there and elsewhere shows that it's fairly widely acknowledged that 4474 has not seen the deployment that was hoped for when it was specified. Making its use a normative requirement here again seems out of sync with deployment reality. I would encourage you to review draft-ietf-stir-rfc4474bis and reconsider what security mechanism should form the basis of the recommendations in this draft.

[Ballot comment]
Section 3.1.1:

Is there anything new being specified here that isn't already specified in other SIP documents?

Section 3.2:

Is this saying anything that RFC 5763 doesn't already say?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-straw-b2bua-dtls-srtp-08, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
CC: draft-ietf-straw-b2bua-dtls-srtp@ietf.org, ben@nostrum.com, christer.holmberg@ericsson.com, straw-chairs@ietf.org, straw@ietf.org
Reply-To: ietf@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: EXTENSION of Last Call: <draft-ietf-straw-b2bua-dtls-srtp-08.txt> (DTLS-SRTP Handling in Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)) to Proposed Standard


The IESG has received a request from the Sip Traversal Required for
Applications to Work WG (straw) to consider the following document:
- 'DTLS-SRTP Handling in Session Initiation Protocol (SIP) Back-to-Back
  User Agents (B2BUAs)'
  <draft-ietf-straw-b2bua-dtls-srtp-08.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-11-17.  Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)
  often act on the media plane, rather than just on the signaling path.
  This document describes the behavior such B2BUAs can adhere to when
  acting on the media plane that uses an Secure Real-time Transport
  (SRTP) security context set up with the Datagram Transport Layer
  Security (DTLS) protocol.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-dtls-srtp/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-dtls-srtp/ballot/


No IPR declarations have been submitted directly on this I-D.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-straw-b2bua-dtls-srtp-08, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
CC: draft-ietf-straw-b2bua-dtls-srtp@ietf.org, ben@nostrum.com, christer.holmberg@ericsson.com, straw-chairs@ietf.org, straw@ietf.org
Reply-To: ietf@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-straw-b2bua-dtls-srtp-08.txt> (DTLS-SRTP Handling in Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)) to Proposed Standard


The IESG has received a request from the Sip Traversal Required for
Applications to Work WG (straw) to consider the following document:
- 'DTLS-SRTP Handling in Session Initiation Protocol (SIP) Back-to-Back
  User Agents (B2BUAs)'
  <draft-ietf-straw-b2bua-dtls-srtp-08.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-11-10. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)
  often act on the media plane, rather than just on the signaling path.
  This document describes the behavior such B2BUAs can adhere to when
  acting on the media plane that uses an Secure Real-time Transport
  (SRTP) security context set up with the Datagram Transport Layer
  Security (DTLS) protocol.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-dtls-srtp/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-dtls-srtp/ballot/


No IPR declarations have been submitted directly on this I-D.

Hi,

This is my AD Evaluation of draft-ietf-straw-b2bua-dtls-srtp-07. I think at least some of this needs to be resolved prior to IETF last call.

Thanks!

Ben.
-------------------

Comments and Questions
======================

- There's a marked lack of mention of B2BUAs that inspect or modify media content. I realize that this draft does not seek to enable that particular elephant-in-the-room. Is it worth mentioning them as out of scope? Does this draft intend to make them illegal for SRTP protected sessions with it's proscription about terminating dtls?

- 1.2: "The following sections describe the behavior B2BUAs MUST follow in
  order to avoid any impact to end-to-end DTLS-SRTP sessions."
Does that need the MUST, since the described behavior also uses normative language? Also, is this really a matter of things the b2bUA MUST do, or a set of other things it MUST NOT do?

Also, this paragraph could use some elaboration. There are a number of use cases that violate this(e.g. 3GPP's e2ea security model). This doesn't seem to forbid those, since they don't purport to support e2e crypto--is that the intent? Can "impact" be more precise?

-3.1.1, 3rd paragraph from end: "the B2BUA SHOULD be prepared
  to receive DTLS, STUN and media on the ports it advertised to Bob in
  the INVITE request. "

What are the consequences if it's not prepared to do so? Also, this is a timing issue, right? So shouldn't is say something like "SHOULD be prepared immediately prepared" or "should be prepared to receive...before the it receives the SIP response"?

-3.1.1, 2nd to last paragraph:
Is the a general proscription, or is it limited to cases where 4474bis is in use?

Also, I think the 4474bis reference needs to be normative, given that one needs to understand that draft to implement the normative bits about modifying anything protected by the signature. OTOH, does this need to reference 4474bis, or would 4474 suffice?

-3.1.2: "The mechanism described in Security Considerations section MUST be
  used by endpoint to detect malicious B2BUA’s that MAY attempt to
  terminate the DTLS-SRTP session."

I'm not sure it makes sense for this draft to put normative requirements on endpoints. Do you mean to say they "can" use
the mechanism? Also, that MAY is a statement of fact, not a normative requirement.

I'm confused by language about "inspect[ing] the RTP headers and RTCP packets" here and in the subsections. What do you mean about inspecting rtcp packets? Is this an attempt to dance around content inspection? Won't a good portion of the "rtcp packets" be encrypted?

- 3.1.2.2:
Is the point of this to say b2buas that modify things are out of scope? Not allowed?
The paragraph takes the form of "To do A, you must do B, and B is not allowed". It might be easier to say that "You can't do A, because of the issue with B."

Can you be more precise about what "break end-to-end security" means? e.g. the receiver would consider the packets invalid? Also, this paragraph might could use another mention of 4474/4474bis.

- 4: "Since DTLS operates on
  the 5-tuple"

What does that mean? It sounds something like "encrypts" or "authenticates" the 5, tuple--but I don't think that's what you mean.

"unique transport addresses"
Do you mean the b2bua must replace each answerers's address with a distinct address? Also do you mean distinct address, or distinct combination of address and port?

-5: "This document does not
  introduce any specific security considerations beyond those detailed
  in [RFC5763]."

It seems like the previous sentence qualified as a security consideration beyond those in 5763.

Editorial and nits
==================

- Section 1.1: "DTLS-SRTP is defined for point-
  to-point media sessions"
I suggest "currently defined". That's starting to change with PERC.

- 3.3, 3rd paragraph from end:
s/"B2BUA cannot decrypt..."/"The B2BUA cannot decrypt..."

- 3.3, 2nd to last paragraph: "the B2BUA MUST
  ensure that it does not modify..."
I suggest "the B2BUA MUST NOT modify..."

- 5:"A malicious B2BUA MAY try to
  break into the DTLS connection"
That shouldn't be a 2119 MAY; it's a statement of fact.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?

Intended status: Standards Track

Why is this the proper type of RFC?

The document contains normative procedures.

Is this type of RFC indicated in the
title page header?

Yes.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) often act on the media plane, rather than just on the signaling path. This means that B2BUAs often act on the media path leading to separate media legs that the B2BUA correlates and bridges together. The document describes the behavior such B2BUAs can adhere to when acting on the media plane that uses a Secure Real-time Transport (SRTP) security context set up with the Datagram Transport Layer Security (DTLS) protocol.

Working Group Summary

The WG path of this document was reasonably short and efficient. Several technical comments were made during reviews and all were resolved with consensus.
There is consensus in the STRAW WG to publish this document.

Document Quality

The guidelines and procedures in the document is based on input  and experience from the implementer community.

Personnel

  Who is the Document Shepherd?

Christer Holmberg (christer.holmberg@ericsson.com -- STRAW WG co-chair)

Who is the Responsible Area Director?

Ben Campbell <ben@nostrum.com>

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The WG as a whole understand and agree with it.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

idnits 2.13.02

/tmp/draft-ietf-straw-b2bua-dtls-srtp-07.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  http://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to http://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  -- The document date (September 14, 2015) is 7 days in the past.  Is this
    intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

    No issues found here.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Not Applicable.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

This document makes no request or reference to IANA.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

This document makes no request to IANA.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

This document does not use formal language such as XML code, BNF rules or MIB definitions.