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

[Stephen Farrell <[e-mail]>]

Hi Andrew,

Thanks for the quick response... mine below.

S.

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

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.



> 
>> 
>> 
>