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

["Charles Eckel (eckelcu)" <[e-mail]>]

Please see comments inline.

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

>Some responses from me below.
>
>Regards
>Andy
>
>
>
>
>> -----Original Message-----
>> From: Stephen Farrell [mailto:[e-mail]]
>> Sent: 26 May 2015 23:41
>> To: The IESG
>> Cc: [e-mail]; draft-ietf-siprec-
>> [e-mail]; [e-mail]; [e-mail]; draft-
>> [e-mail]; [e-mail]
>> 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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/siprec