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

["Hutton, Andrew" <[e-mail]>]

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


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

> 
>