Re: [siprec] Stephen Farrell's Discuss on draft-ietf-siprec-metadata-20: (with DISCUSS and COMMENT)

[Stephen Farrell <[e-mail]>]

Hiya,

On 02/03/16 17:51, Ram Mohan R (rmohanr) wrote:
> Hi Stephen,
> 
> See inline
> 
> -----Original Message-----
> From: Stephen Farrell <[e-mail]>
> Date: Wednesday, 2 March 2016 at 4:38 PM
> To: The IESG <[e-mail]>
> Cc: "[e-mail]"
> <[e-mail]>, Brian Rosen <[e-mail]>,
> "[e-mail]" <[e-mail]>, Brian Rosen
> <[e-mail]>, "[e-mail]" <[e-mail]>
> Subject: Stephen Farrell's Discuss on draft-ietf-siprec-metadata-20: (with
> DISCUSS and COMMENT)
> 
>> Stephen Farrell has entered the following ballot position for
>> draft-ietf-siprec-metadata-20: 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-metadata/
>>
>>
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>>
>>
>> (1) In section 10 you have a MUST for integrity and confid,
>> which is good, but then RECOMMEND S/MIME, which is, I think,
>> mythical. Wouldn't it be better to reflect reality
>> (hop-by-hop TLS) and then say what actual security
>> considerations arise, e.g. who might be on the path and how
>> can they (mis)behave?
> 
> Yes. This needs some changes. After the discussions with SecDir we thought
> it would be good to refer to Security Consideration section of protocol
> draft (section 12 general and 12.1 of
> https://tools.ietf.org/html/draft-ietf-siprec-protocol-18#page-38) 12.1
> covers the TLS the mutual Authentication and also talk about who else can
> be in the path (para 2).
> 
> Since the metadata is always going to be carried as a body in the
> protocol, all the considerations there are equally applicable here.
> 
> With this the proposed text for Security consideration in this draft would
> be:
> 
> NEW:
> The procedures mentioned in security consideration section of
> [I-D.ietf-siprec-protocol] MUST be implemented by SRC and SRS
> for mutual authentication.
> Some implementations may have the SRC choose parts of metadata that
>      can be sent to the SRS.  In other cases, SRCs may send metadata that
>      is not appropriate for the SRS to record.  Which metadata is actually
>      recorded by the SRS must be carefully considered to balance privacy
>      concerns with usability.  Implementations MUST control what metadata
>      is recorded, and MUST NOT save metadata sent by the SRC that does not
>      conform to the recording policy of the SRS.  Metadata in storage
>      needs to be provided with a level of security that is comparable to
>      that of the recording session.
> 
> 
> Would this be better ? Or else we will have to replicate most of the text
> from Protocol to here again.

Yes, that's good, and no I'd not replicate text from the protocol
spec, your reference with a MUST above is fine. (I re-read the
security considerations of the protocol spec, and I think it covers
things well enough.)

Thanks,
S.

> 
> 
> Ram
>>
>> (2) 6.10: Don't you need to say to use UUID version 4 with
>> random numbers and to not use MAC addresses?  IOW, refer to
>> RFC4122, Section 4.4 for how to generate UUIDs.
>>
>> Note that issues related to both of the above were part
>> of the discussion that ensued from the secdir review. [1]
>>
>>   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06370.html
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>>
>>
>> - section 4, last para: How could an SRC know this and hence
>> what it's safe to omit?
>>
>> - 6.9: I would have thought that more precision about
>> fractional seconds support would be useful here, or else, to
>> just say that you're limiting to single-second granularity.
>> Wouldn't doing one or the other be better? Otherwise you
>> might get different s/w ordering events in different orders
>> unexpectedly.
>>
>>
>