Re: [Gen-art] [tsvwg] Gen-art LC review: draft-ietf-tsvwg-rsvp-pcn-09
Thanks Georgios - these are improvements. RjS On 9/14/14 3:58 AM, karag...@cs.utwente.nl wrote: Hi Robert, Thank you for your comments! We have worked out your comments in the following way, see in line! Please let us know if you are satisfied with these changes! -Original Message- From: tsvwg [mailto:tsvwg-boun...@ietf.org] On Behalf Of Robert Sparks Sent: donderdag 21 augustus 2014 22:44 To: General Area Review Team; i...@ietf.org; ts...@ietf.org; draft-ietf- tsvwg-rsvp-pcn@tools.ietf.org Subject: [tsvwg] Gen-art LC review: draft-ietf-tsvwg-rsvp-pcn-09 I am the assigned Gen-ART reviewer for this draft. For background on Gen- ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-tsvwg-rsvp-pcn-09 Reviewer: Robert Sparks Review Date: 21 Aug 2014 IETF LC End Date: 26 Aug 2014 IESG Telechat date: 2 Oct 2014 Summary: Ready (with nits) for publication as Experimental. David's shepherd writeup points out that implementation and usage experience is desired before producing a proposed standard. Are there any points of concern about how this might behave (or misbehave) in a deployed network that such experience would inform? If so, it would be useful to call them out in the document. Georgios: Added the following paragraph at the end of Section 1.1: This draft is intended to be published as Experimental in order to: o) validate industry interest by allowing implementation and deployment o) gather operational experience, in particular around dynamic interactions of RSVP signaling and PCN notification and corresponding levels of performance. It would be nicer if the document argued why there are no new security considerations introduced by the new behavior defined in this draft, rather than tacitly asserting that there aren't any. Georgios: Added the following text in Section 5: In particular, the security considerations within the PCN domain come from the Trust Assumption Section 6.3.1, of [RFC5559] i.e., that all PCN-nodes are PCN-enabled and are trusted for truthful PCN-metering and PCN-marking. In the PCN domain environments addressed by this document, Generic Aggregate Resource ReSerVation Protocol (RSVP)messages specified in [RFC4860] are used for support of the PCN Controlled Load (CL) and Single Marking (SM) edge behaviors over a Diffserv cloud using Pre- Congestion Notification. Similar, to [RFC4860], [RFC2747] and [RFC3097] may be used to protect RSVP message integrity hop- by hop and provide node authentication as well as replay protection, thereby protecting against corruption and spoofing of RSVP messages and PCN feedback. Based on these assumptions, it is considered that this document is NOT introducing any additional security concerns/issues compared to [RFC5559] and/or [RFC4860]. The terminology section has lots of 2119 words in it. It's hard to tell when these have been copied from some other draft (and this is just restating them) vs when this draft is introducing a new requirement. Since a new requirement would likely be missed if it appeared only in a terminology section, would it be feasible to make sure anything new is well covered in section 3 or 4 and remove 2119 from these definitions altogether? Georgios: Removed all RFC 2119 words from the terminology section (Section 1.3) The rest of these comments are minor editorial nits: Section 1.2, paragraph 3: Intserv over Diffserv can operate over a statically provisioned Diffserv region or RSVP aware. is missing a a word somewhere. Georgios: changed From: Intserv over Diffserv can operate over a statically provisioned Diffserv region or a RSVP aware. INTO Intserv over Diffserv can operate over a statically provisioned or a RSVP aware Diffserv region Section 1.2 paragraph 4: By using multiple aggregate reservations for the same PHB allows enforcement of the different preemption priorities within the aggregation region. doesn't parse. Should the initial By be deleted? Georgios: Changed from: By using multiple aggregate reservations for the same PHB, allows enforcement of the different preemption priorities within the aggregation region. INTO: By using multiple aggregate reservations for the same PHB, it allows enforcement of the different preemption priorities within the aggregation region. The definition for PCN-domain is very close to circular. Perhaps some words can be removed? In Section 1.3, we have replaced PCN-domain with domain in the text, see below: Channged from: PCN-domain: a PCN-capable domain; a contiguous set of PCN-enabled nodes that perform Diffserv scheduling [RFC2474]; the complete set of PCN-nodes that in principle can, through PCN-marking
Re: [Gen-art] Gen-ART LC Review of draft-ietf-avtcore-srtp-aes-gcm-14
Ben et al: Here is the reasoning behind some of the issues you raise. At least one of them (SSRC re-use) is security critical. = SSRC Management: If I read this section correctly, the draft requires central management of SSRC values when you have a master key shared among endpoints in a SRTP session, and goes so far to require authentication of data a central SSRC manager. Yes indeed, having unique SSRC values is a crucial requirement in aes-gcm, since using the same IV (i.e. (ROC,SEQ,SSRC) triple) with the same key K more than once results in two undesirable consequences: 1) It compromises secret authentication value H which is used to authenticate ALL messages that use the key K. 2) It effectively reveals the contents of any packets using this common IV value. Revealing the authentication key is a risk common to aes-gcm and many other AEAD algorithms. But revealing the message content is a risk for any key stream, including AES counter mode. RFC 3711 is willing to accept the compromise of some data, using the SRTP SSRC collision detection process to detect such a compromise after it has occurred. But for my user base, detecting a data compromise after it has occurred is insufficient. For any high value data stream, any data compromise has potentially disasterous consequences Though I didn't want to specify a mechanism for achieving the goal of having unique SSRCs, the solution I had in the back of my mind was a) Each source has its own key for encrypting its outgoing data streams. b) The key it uses to decrypt incoming data depends upon the originator. c) For a given key K, the burden of preventing SSRC reuse with K depends solely upon the single source forming outgoing data streams using that key. One way or another, using either the current I-D or RFC 3711 with high value data streams requires a mechanism that prevents the use of the same SSRC with two or more data sources that are using the same key on their outgoing data. This decentralizes the burden on SSRC management, but requires each source have its own outgoing data key. If some usage of STTP requires that multiple sources must use the same outgoing data key, a mechanism needs to be in place to impose some discipline on how the members of this subnet assign SSRC values. This holds for both RFC 3711 and the current I-D. = -- References: The draft has normative down ref to RFC 3610. This was not explicitly mentioned in the IETF last call email, and does not appear to be included in the down ref registry. Mea culpa, need to update this. = -- 8.1: If this draft contradicts normative language from RFC 3711, it should explicitly update 3711. Its not so much that tie I-D updates updates as that it deale with a different context. In AEAD an algorithms integrity, is an intrinsic part of the encryption/decryption process, not a separate independent process. RFC 3711 implicitly assumes integrity and privacy are two separate processes, but that it not true of AES-GCM. For non-AEAD algorithms, RFC 3711 is correct in how it handles integrity, but AEAD an algorithm handle integrity in a radically different way and requires the modifications outlined in section 8.1. = -- 8.2 Can you offer guidance on when it might be (or not be) necessary to disguise the length of the plaintext? Especially how that might be known at the SRTP layer? = -- 14.1: Does the master salt need to be kept secret? If the answer is it depends, can you offer guidance? Lurking in section 3.2.1 of RFC 3711 is the following bullet. * a master salt, to be used in the key derivation of session keys. This value, when used, MUST be random, but MAY be public. Use of master salt is strongly RECOMMENDED, see Section 9.2. A NULL salt is treated as 00...0. We took that to say that if the master salt MAY be public, it is also possible for it to be secret. I can not think of any instance in which it needs to be secret, but apparently the authors of RFC 3711 weren't quite so certain. = Also, can you offer a definition of properly erased? Gladly! I mean overwritten, not just dereferenced. It's a bad idea to leave secret values floating around in memory, just waiting for an adversary to read them out. =
