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

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 26 May 2015 15:41:18 -0700

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? 

(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?

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 26 May 2015 19:30:32 -0400

While I have some thoughts about these comments, I think the authors 
should get the first crack at responding.

We always expected that security considerations would be the sticky 
point, and so they are. I think we need to be very solicitous in our 
responses, and very clear about important use cases that drive some of 
the decisions.

	Thanks,
	Paul

On 5/26/15 6:41 PM, Stephen Farrell wrote:
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 27 May 2015 20:21:53 +0000

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

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. 

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

> hop-by-hop stuff is needed when there are proxies between

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.

---

From: Adam Roach <[email-masked]>
Date: Wed, 27 May 2015 15:37:34 -0500

On 5/26/15 17:41, Stephen Farrell wrote:
> standardised?

I'm not commenting on SIPREC or how it chooses to handle RTP keying, as 
I'm not overly familiar with either. I'm only responding to the comment 
regarding EKT.

As has been pointed out, this citation should be 
draft-ietf-avtcore-srtp-ekt, which is far more recent. EKT forms a 
cornerstone of the proposed solutions for the PERC work that's been 
discussed in DISPATCH recently. If the PERC work moves forward, it will 
almost certainly drive work around EKT, substantially increasing its 
chance of publication.

/a

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 28 May 2015 17:32:56 +0100

Hi Andrew,

Thanks for the quick response... mine below.

S.

On 27/05/15 21:21, Hutton, Andrew wrote:
> 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)
>> 
>> 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/
>> 
>> 
>> 
> 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.
> 

Fair enough. I think you're missing mention of a timer though as
one would be needed and we should probably tell the server how
soon it ought have stopped recording or something otherwise some
UA might drop calls precipitously. It's not hugely likely maybe
but I'd guess could happen. (I'll clear the discuss point though
as that'd not be worth blocking on.)

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

So I need to go read that to understand and will but don't
have time now. Please bug me if I've not gotten back on this
in a day or two.

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

Well, I'll clear as I said I would but I have to say I don't find
that a very compelling answer at all. Mutually authenticating two
servers isn't be hard at all (you can use PSK if you want) and the
just-not-necessary I do not accept (haven't belgacom and gemalto
taught us a lesson? Apparently not;-).

Compared to whatever it is with EKT I'd bet that in almost all
cases it'll be simpler to just de-crypt and re-encrypt for the
SRC->SRS as you would in a b2bua.

And btw, if you do ever use the same key - what prevents a
participant in the CS who also has that key from sending bogus
packets to the SRS? (Hmm, maybe I should keep the discuss point
open a wee bit longer, didn't think of that before.)

Cheers,
S.