Subject: Re: [siprec] Stephen Farrell's Discuss on draft-ietf-siprec-protocol-16: (with DISCUSS)

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 1 Jun 2015 20:03:02 +0000

Please see comments inline.

On 5/27/15, 1:21 PM, "Hutton, Andrew" <[email-masked]> wrote:

>Some responses from me below.
>
>Regards
>Andy
>
>
>
>
>> -----Original Message-----
>> From: Stephen Farrell [mailto:[email-masked]]
>> Sent: 26 May 2015 23:41
>> To: The IESG
>> Cc: [email-masked]; draft-ietf-siprec-
>> [email-masked]; [email-masked]; [email-masked]; draft-
>> [email-masked]; [email-masked]
>> Subject: Stephen Farrell's Discuss on draft-ietf-siprec-protocol-16:
>> (with DISCUSS)
>> 
>> Stephen Farrell has entered the following ballot position for
>> draft-ietf-siprec-protocol-16: 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-siprec-protocol/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>> 
>> 
>> (1) 5.3: How does a UA know if it's preference to not be
>> recorded has been ignored?
>
>If the UA is a recording-aware UA (i.e. supports SIPREC) and it is
>talking to a compliant recording server then it will know via the
>"a=record" SDP attribute there is some further explanation of this in
>https://tools.ietf.org/html/draft-ietf-siprec-protocol-16#section-7.1.3.
>
>
>
>> 
>> (2) 12.2: Why is a 2011 ([I-D.ietf-avt-srtp-ekt]) expired
>> I-D ok as the method for supporting DTLS-SRTP for the CS,
>> esp when DTLS-SRTP is our currently favoured method for
>> handing WebRTC security? When is that going to be finished?
>> On what basis is that an informative and not normative
>> reference? And is that reference ever likely to be
>> standardised? (Given that it seems to be a form of TLS MitM
>> - is that fair?) Perhaps it'd be better to just admit
>> that re-encryption is needed and get over it?
>
>
>Firstly the reference appears to be wrong as I think it should point to
>https://tools.ietf.org/html/draft-ietf-avtcore-srtp-ekt-03.

I updated the reference.

>DTLS-SRTP without EKT is certainly allowed in the CS as the draft does
>not restrict the keying mechanism on the CS.  Some members of the WG
>wanted to include the EKT case to allow for the case when there is
>DTLS-SRTP on the CS and SDES on the RS without requiring re-encryption
>and I believe everybody understood that this is a corner case but maybe
>those that requested it will comment further.

The consensus forming compromise within the WG was that at a minimum the
SRC and SRS MUST support the SDP Security Descriptions (SDES) key
negotiation mechanism [RFC4568]. EKT was seen as a way to enable things to
move forward to support DTSL-SRTP on the CS side without the performance
and security penalties that come with decrypting and re-encrpting on the
SRC before sending to the SRS.

>
>
>> 
>> (3) I'll clear once you answer: but wouldn't it be easier
>> all around to just mandate use of mutually authenticated
>> TLS between SRC and SRS in all cases?  (Even if some
>> hop-by-hop stuff is needed when there are proxies between
>> SRC and SRS.)
>> 
>
>I think the issue here is that the SRC and SRS will often be co-located
>in an environment where mutual authentication was just not necessary and
>therefore the WG did not want to mandate this in all cases.

Yep.

Cheers,
Charles

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

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 01 Jun 2015 21:18:39 +0100

Hi Charles,

One question on just one part of this, but one that puzzles me and
may be helpful in clearing this up...

On 01/06/15 21:03, Charles Eckel (eckelcu) wrote:
> the performance

If you don't re-encrypt isn't it possible for anyone who is part
of the CS to send bogus packets to the SRS that will then be
recorded? (Assuming the sender can get the packets to the SRS but
let's assume they can, because that's not so hard.)

Not re-encrypting seems to just be broken, if e.g. this is supposed
to be a thing one could use to hold a rogue trader accountable when
there's big piles of money at stake.

Ta,
S.

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 1 Jun 2015 23:59:56 +0000

Hi Stephen,

My comment was meant to be interpreted within the context of an EKT
session. In this case, the SRC is still using SRTP-SDES with the SRS for
the RS, and using TLS to establish the RS and exchange the keys. But in
doing it would not need to decrypt and re-encrypt the payload with a new
key.
I may be getting in over my head here, but I believe the SRTP
authentication tag would be sufficient to determine the source of the SRTP
packets is in fact the SRC and not simply any one of the UAs participating
in the CS injecting random SRTP packets encrypted with the same key into
the stream.
I also expect that in practice there would be a firewall that allows only
appropriate SRCs to access the SRS.

Cheers,
Charles

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 02 Jun 2015 01:04:34 +0100

Hi Charles,

> doing it would not need to decrypt and re-encrypt the payload with a new

I guess I need to go check the updated reference(s) on that
stuff. (It might make sense to shoot out a revision with that
fixed and other changes just to simplify the discussion, but
your AD will guide you on that.)

> in the CS injecting random SRTP packets encrypted with the same key into

Yeah, that's one we do need to bottom out on.

> appropriate SRCs to access the SRS.

Could well be, but even if so, that'd not be considered sufficient
really I guess.

S.

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 16 Jun 2015 22:33:36 +0000

>Could well be, but even if so, that'd not be considered sufficient

I checked with Dan Wing on this. Your concerns about spoofing are correct.
Let me paraphrase here:

With a design in which EKT is used within a conference and the SRC
forwards media streams for recording purposes to an SRS using SRTP/SDES
with the same keys, each conference participant could send traffic,
pretending to be any other participant, and the crypto wouldn't protect
against that. But if all the keys are flying around with SDES, the only
way to design a system that protects Alice from spoofing Bob (in a two
party call) is to add a mixer which -- yes -- has to suffer the
decrypt/re-encrypt, so that Alice only talks to/from the mixer, and Bob
only talks to/from the mixer, and Alice and Bob don't know each other's
keys.

Personally I still expect this is a model that will be used due to the
performance characteristics; however, some deployment scenarios will
obviously require tighter security. Would adding something to this effect
in the security considerations section be sufficient?

Cheers,
Charles