IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2015-04-09. These are not an official record of the meeting.
Narrative scribe: John Leslie and Susan Hares (The scribe was sometimes uncertain who was speaking.)
Corrections from: John
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning Items
2.2 Individual Submissions
2.2.1 New Items
Telechat:
2.2.2 Returning Items
2.3 Status Changes
2.3.1 New Items
2.3.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
3.2.2 Returning Items
3.3 Status Changes
3.3.1 New Items
3.3.2 Returning Items
3.4 IRTF and Independent Submission Stream Documents
3.4.1 New Items
Telechat:
Telechat:
3.4.2 Returning Items
1033 EDT no break
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
Telechat::
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
Telechat::
4.2.2 Proposed for Approval
Telechat::
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
Telechat::
Telechat::
Telechat::
Telechat::
Telechat::
Telechat::
7. Working Group News
Jari: do we want to ask Andrew to stay on during executive session? (general agreement, yes)
1116 EDT entered Executive Session
(at 2015-04-09 06:00:02 PDT)
draft-ietf-oauth-dyn-reg
(1) General: there are many URIs sent to the AS from the client here. Nothing prevents the client messing about with the content served from those later, after registration. What mechanism holds clients accountable for such misbehaviours? (Examples, logo_uri, tos_uri, policy_uri, jwks_uri) Section 5 does say that the AS "SHOULD check" but does not say what "checking" means, nor what to do if the check fails. I think a bit more security considerations-like text here, reflecting what is (or ought;-) actually be done would be good. Do you agree? (2) If the response (defined in 3.2.1) includes metadata that the server has altered, but that the client doesn't like, then what does the client do? (It may be that that's ok, but I'm not following why that is the case.) I'm also not sure the "https" requirement (1st bullet in section 5) is useful there. (3) What is the "delete action" referred to in section 5, 3rd para (just after the bullets)?
- s2, software_version: what is the impact if the s/w is updated twice a day, every day? - 3.2.1 - why is the response status 201? That may be correct, but seems to subtle if so to only state in an exmaple. - s5, last para - "be very particular" is not good spec language - what do you actually mean that can be implemented? - thanks for section 6 - it's great to see thought being devoted to these issues. - Did the secdir review [1] get a response? And I think I quite agree with Charlie's point#2 about versions. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05519.html
Section 2: The software_version "SHOULD change on any update identified with the same software_id" --why not MUST? What happens if this doesn't happen? "Extensions and profiles MAY expand this list.." -- That seems more like a statement of fact than a normative requirement. 3.2.1: client_id "SHOULD NOT be currently valid for any other registered client": Why not MUST? What happens if it is valid for another client? 4.1 and 4.2 allow the designated expert to accept preliminary registrations if they are confident a spec will be published. Shouldn't this follow the normal processes for preliminary registrations? Is there a way to walk back registrations if the spec isn't published after all? section 5: 4th paragraph after bullet list: "... authorization server needs to take steps to mitigate this risk...": Other statements like this have been normative. Is there a reason this one is not? 2nd paragraph from end: "... treat the new registration as being suspect": ... and do what?
I support Stephen's DISCUSS point #1.
draft-ietf-appsawg-uri-scheme-reg
I put what I think it my most important comment first and hope to see a response to that. (I don't think it'd be correct for it to be a DISCUSS, but it's close.) - 3.7, probably too late in the day to ask for it, but if there are privacy considerations those would also be good to note - and there will be for some of the application-specific schemes, that e.g. have personally identifying information in the scheme specific part. I'd suggest that renaming 3.7 to "security and privacy considerations" would be good and saying e.g. that where the scheme specific part is likely to be privacy sensitive, then that ought be documented and ways of minimising privacy-unfriendliness ought be documented. - 3.2, all except the last para: I personally think the SHOULDs here are bogus. Why does it matter at all, really? In any case, even if you maintain it matters, I'd suggest adding a bit saying that even minor deployment is a reasonable justification for going against the SHOULDs. If that's not likely to garner immediate consensus, as I suspect, then I'll not insist - we can drop the topic and leave it to folks registering new schemes to continue to battle the URI police:-( - 3.2, last para: I'd suggest moving this quite reasonable constraint away from the rest of this section. - 3.6, 2nd para: I don't think you've quite said what you mean here. "As restrictive as possible" could favour "all octets are U+00A2" - that is very restrictive, but would be problematic for many parsers I guess. (The U+00A2 value has no specific significance.) I think what you meant to say was that the scheme specification SHOULD be as close as possible to (or deviate as little as possible from) what is allowed in 3986. - 3.8: (very nitty nit:-) com.example.info isn't a good choice as both com and info are gTLDs which may confuse some reader. I'd suggest com.example.mything or similar. - 3.8: I'm not sure, but are you really saying here that the these scheme, after you take away the rightmost component, ought be in the public suffix list? If so, that might actually be good guidance as com.example.a.b.c.d is much more likely to suffer bitrot over time I'd say. (Compared to com.example.abcd I mean.) - 7.3, 1st para: it'd have been nice if you could have avoided IESG action being required for some details (e.g. a change of contact address from a@example.com to b@example.com), but I guess that might be too tricky to get right in text, so ok. - I agree with Ben's comment wrt loads of SHOULDs
I am curious how the expert review required in the document interacts with bona-fide standards actions. There's already an ongoing discussion on that, and Barry has noted it in his on comments, so I will leave this as a comment. In particular I wonder if the "On receipt of a registration request" section of 7.2 should be different if the request was part of an IETF/IESG reviewed and approved action in the first place. There are a lot of SHOULDs in this document. I wonder how an expert reviewer is supposed to interpret deviations from SHOULD level requirements. This is especially true in statements like "... SHOULD include clear security considerations or explain [why not]". The expert's life might be easier if there was some text encouraging that deviations from SHOULDs be accompanied by an explanation.
I support Stephen's comments and was wondering about privacy considerations for the contact information provided as well in scheme registration requests. Just noting the concern would be good and maybe recommending using a generic organizational contact if possible cold work if that's possible, may not always be.
There's ongoing discussion about the effect this has on existing registered schemes, particularly "urn:", including concern that this constrains other working groups (such as urnbis) inappropriately. I will hold back the final approval until that's sorted out.
draft-ietf-nfsv4-lfs-registry
I think there is a possibly missing security consideration in section 4 - if two label formats "overlap" so that a value for one could represent a (different) value for the other and if the label format specifier is not somehow bound to the packet/object, then some confusion attacks may be possible. The mitigation I think is to either (maybe implicitly) bind the format specifier into the object/label or to ensure that label values cannot be valid for other label format specifiers. (Note that attacks here are probably only interesting in highly specific cases, so it's not a huge deal, but maybe worth a mention.)
Setting up this registry is a fine thing, and I just have two points I'd like to sort out before we approve this: -- Section 5.2 -- 1. Is it your intent that the Designated Expert still has to do expert review when the specification is a Standards Track RFC? 2. You have no instructions to guide the Designated Expert; some instructions are needed. Is the DE expected to just give a basic sanity check to the specification? Is more thorough review of the specification expected? Will the DE be making any judgments about whether the specified label format is useful, or is or isn't a "good idea", or is the DE expected to approve any request with a suitable specification? Both DEs and applicants need to know what's expected.
Some non-blocking, minor comments here: Very much a nit, but drafts have this sort of thing all the time, and we should probably say something more generally (I think I'll post to the IETF discussion list about the general point): In the abstract... To allow multiple MAC mechanisms and label formats to co-exist in a network, this document proposes a registry of label format specifications. This registry would contain label format identifiers and would provide for the association of each such identifier with a corresponding extensive document document outlining the exact syntax and use of the particular label format. When the draft was written, it was "proposing" a registry, and should that registry be created it "would contain" and "would provide" things. But it's now up for approval for RFC publication, and these characterizations are inapt; when it's published, the registry will have been created and will be providing all that. Drafts should be written -- at least by the time they enter last call -- to have the right tone as published RFCs. Here, I suggest these changes: 1. "proposes" -> "creates" 2. "would contain" -> "contains" 3. "would provide" -> "provides" -- Section 5 -- As best I can tell, this question from IANA wasn't answered in the last call discussion, and it needs to be: > Where should this new registry be located? Should it be placed at an > existing URL? If not, should the title of the new webpage be "NFS > Security Label Format Selection," or do you expect other registries > that would require a different title to be placed there? Also, should > it be filed under a new or an existing category at http://www.iana.org/protocols? IANA will sort this out with you in any case, but it would be good for the document to say where you would like IANA to put the registry. In Table 1, I think "Available for IANA Assignment" would be better than "Reserved for IANA Assignment", but it's a really small point. In Section 5.2, I suggest using the full name for the registry (add the word "Security").
draft-ietf-appsawg-multipart-form-data
- abstract: the "(re)defines" is a bit confusing, I'd say just stick with "defines" - 4.3, typo "may seems to be present"
Thanks for adding the form-data parameter to the registration update. I concur with Kathleen's comment to move the last paragraph in the security considerations to the front.
Please consider moving the last paragraph to the first in the security considerations section. I agree with the point made by the SecDir reviewer that it improves readability and makes this point clear with reasons before subsequent paragraphs detail it a bit more specifically. https://www.ietf.org/mail-archive/web/secdir/current/msg05555.html I also agree with the SecDir reviewer and suggest you reword the following paragraph in Appendix B: More problematic is the ambiguity introduced because implementations did not follow [RFC2388] because it used "may" instead of "MUST" when specifying encoding of field names, and for other unknown reasons, so now, parsers need to be more complex for fuzzy matching against the possible outputs of various encoding methods. Perhaps to something like: More problematic is the ambiguity introduced because implementations of [RFC2388] opted to not follow the specification of encoding field names when the term "may" appeared, where in hindsight it should have been "MUST". As a result, parsers need to be more complex for fuzzy matching against the possible outputs of various encoding methods. If I go something wrong, hopefully you get the point and can easily adjust the text. From the SecDir review: Please correct me if I'm off base here, but it sounds like the ambiguity set in because implementations WERE following RFC 2388 by making choices on their own (due to the "may"s) rather than being directed to make uniform choices which would have been mandated if that RFC had used "MUST"s. Thanks for your work on this draft!
draft-ietf-ippm-ipsec
(1) Are O/TWAMP vulnerable to reflection attacks with this scheme? If so that's not good. Sorry that I didn't manage to figure that out in the time available but I'm hoping you can just tell me the answer quickly:-) If it's not vulnerable, that's great though it might be worth making that clearer. If it is, then that seems like a bad plan about which we ought chat. The usual solution would be to derive different keys for each direction of use, and just say to use those appropriately. And even if O/TWAMP are thusly vulnerable with a PSK, it'd be fine, and quite possible to fix that here now we're doing better key mgmt. (2) Is it clear what to do if a key needs to be derived for O/TWAMP whilst re-keying is in progress for the IKE SA? (Hannes' review made me wonder, and I don't recall if the text on this is quite clear enough to not allow for a case where the two sides end up with different values derived from the DH share.)
Since you're touching on the key managment code, I'd have loved to see you also update the O/TWAMP crypto itself to e.g. use an AEAD cipher rather than AES-CBC. Did the WG consider that? (I assume it's too late now, but I'm not clear from the write-up if this is implemented or not, so I guess there's a small chance that the WG may want to update more than just the key mgmt.)
In the last paragraph, the text indicates that if the IKEv2 SA is rekeyed or deleted, O/TWAMP can continue to use the same shared secret. The language seems to make such a continuance optional. Does that cause an interoperability problem if the endpoints don't agree on the strategy? If so, this may need a 2119 MUST (or possibly SHOULD).
Section 1, paragraph 4: This paragraph casts the decision whether to send O/TWAMP inside or outside of an IPSec tunnel as a question of how you want to secure the O/TWAMP packets. It seems to me that this is really more a matter of what you want to measure, given that the tunneled data and non-tunneled data may have different performance capabilities. Sentence starting with "In this case...": The antecedent of "this" is unclear. Section 1, 2nd to last paragraph: I assume the last sentence means that IKEv2 derived keys SHOULD be used instead of shared secrets when otherwise using IKEv2. That seems to add a normative requirement to OWAMP and TWAMP in general, in which case this doc should be listed as updating those. Section 3: I agree with Brian's DISCUSS. Section 4.1: Please expand HMAC on first mention. Section 5.1: "SK_d MUST be computed as per [ref]" :That doesn't need 2119 language. "string "IPPM" comprises four ASCII characters ": This is oddly constructed. Is this intended to observe that IPPM has 4 letters? Section 5.2, paragraph after Figure 2: "Clearly, an implementation .... MUST ..." It is not as clear to me. Why does the use of IKEv2 create a stronger requirement to support all 3 protection modes? Section 5.3:, first paragraph: "The Set-Up-Response Message should be updated": Do you mean to say it _is_ updated? Paragraph after figure 3: s/ "can uniquely identify" / "uniquely identifies" 5.4, last sentence: The sentence is confusing. Do you mean to say that O/TWAMP SHOULD be configured to use the tunnel?
Thanks for considering the SecDir review and providing edits in the current draft revision. https://www.ietf.org/mail-archive/web/secdir/current/msg05444.html
General: the "implementations compatible with this specification" stuff is really awkward and unnecessary. It would be better if it were changed to "implementations of this method" (and similar phrasing, such as "clients implementing this method") throughout the document. But this is non-blocking, and there's no reason to discuss it. I urge you to consider the change, but please do with that urging as you think best. -- Section 3 -- This document reserves from the TWAMP-Modes registry the Mode value IKEv2Derived which is equal to 128 (i.e. bit set in position 7) and MUST be used by TWAMP implementations compatible with this specification. Pete Resnick has left the IESG in body only, but not in spirit. I think what you mean here is that you signal that you're using this method by setting IKEv2Derived. Is that correct? Assuming so, this would be more clearly and simply said in a way such as this (definitely without any 2119 words, which aren't appropriate for that): NEW TWAMP implementations signal the use of this method by setting IKEv2Derived (see Section 7). END Please leave the details of the registry, and which bit was assigned, to the IANA Considerations section, where that stuff belongs. The reference to Section 7 makes it easy to find. -- Section 5.2 -- As in Section 3, it's better just to refer to IKEv2Derived, and not to talk about the registration details here. So: OLD The Modes field in Figure 2 will need to allow for support of key derivation as discussed in Section 5.1. As such, the Modes value extension MUST be supported by implementations compatible with this document, indicating support for deriving the shared key from the IKEv2 SA. The new Modes value indicating support for this specification is IKEv2Derived and is equal to 128 (i.e. bit set in position 7). Clearly, an implementation compatible with this specification MUST support the authenticated, encrypted and mixed modes as per [RFC4656][RFC5357][RFC5618]. NEW The Modes field in Figure 2 will need to allow for support of key derivation as discussed in Section 5.1. Therefore, when this method is used, the Modes value extension MUST be supported. Support for deriving the shared key from the IKEv2 SA is indicated by setting IKEv2Derived (see Section 7). The authenticated, encrypted and mixed modes (see [RFC4656][RFC5357][RFC5618]) MUST also be supported. END
I hope this is a short discussion and I can change my ballot to a Yes... The applicability section says "Until an IANA registry for OWAMP Mode values is established, the use this feature in OWAMP implementations MUST be arranged privately among consenting OWAMP users." Is there an issue with this document creating that registry? Or, if separation is needed, a companion document spun quickly to create this registry? The functionality specified here seems quite applicable to OWAMP and requiring private agreements to use it seems sub-optimal.
draft-ietf-payload-rtp-opus
Meta-comment - it looks like the notification field is pointing only to Ali. If that's intentional, rock on, but I've had some accidentally-minimal notification lists on drafts recently, and wanted to mention that. This draft seemed very clear to me, one not skilled in the art. Thank you for that. I have a few comments. If you have questions, please ask, but they're non-blocking (so do the right thing). In this text: 3. Opus Codec Further, Opus allows transmitting stereo signals. I wasn't sure what this was telling me until I got to section 3.4, and saw this text: "signaled in-band in the Opus payload". Perhaps adding that phrase in Section 3 would be helpful? In this text: 3.1.2. Variable versus Constant Bitrate One reason for choosing CBR is the potential information leak that _might_ occur when encrypting the compressed stream. See [RFC6562] for guidelines on when VBR is appropriate for encrypted audio communications. I THINK I know what "potential information leak" means in this case, but I'm guessing. I learned a lot from the [RFC6562] reference. Is it possible to provide a short clue here? Would it be correct to say something like "One reason for choosing CBR is that some codecs have been observed to provide predictable VBR patterns for highly structured dialogs where only a few phrases are expected, and potentially leaking information without requiring an eavesdropper to decrypt the payload"? Also in 3.1.2: The bitrate can be adjusted at any point in time. To avoid congestion, the average bitrate SHOULD NOT exceed the available network bandwidth. I'm kind of wondering how you intend for the sender to know what the "available network bandwidth" is. I notice a reference in Section 3.3 to (2) an externally-provided estimate of the channel's capacity; Is "the available network bandwidth" this externally provided estimate? What should a sender be looking at, to fulfill this SHOULD NOT? Of course, I'm wondering why this is SHOULD NOT, instead of MUST NOT. Is this recognizing that available network bandwidth can change instantaneously (so a careful sender might still find itself sending too fast for a short period of time), or is there something else going on? As long as I'm mentioning section 3.3, if the "externally-provided estimate" had some reference, that would be helpful (unless, of course, this is obvious to those skilled in the art). The term only appears twice in 3.3, with no pointers. In this text: 5. Congestion Control It is RECOMMENDED that senders of Opus encoded data apply congestion control. Is there a particular mechanism you're thinking of here? If you could make that clearer, even just providing a reference, that would be helpful for me as a reader. In other news, I support Kathleen's Discuss on SHOULD SRTP, and if it becomes a SHOULD and not a MUST, I'd suggest adding a sentence or two explaining why not using SRTP is the right thing to do.
- 3.1.2: s/_might_ occur/occurs/ the information leak does occur unquestionably, the only uncertainty is whether or not someone cares about that, whereas the current text implies that the leak might not be real. As written, the text is misleading, though not sufficiently to make this a DISCUSS. (I am assuming there is no result that shows that encrypted OPUS traffic is somehow not leaking information in the way other codecs do.) - 6.1, maxptime and ptime: I read this as saying that 3, 6, 9 etc are all valid values, but that e.g. 43 is not. Is that correct? In other words can I mix frames that contain different durations of audio into one RTP packet? (You may have told me earlier, but I've forgotten already, sorry:-)
Section 7.1 has some normative language that seems more about the meaning of parameters than about SDP Offer/Answer considerations. That might be more appropriate in the parameter definitions. It might be worth having the security considerations mention the VBR security discussion in section 3.1.2. Section 3.1.3, last sentence: s / restraints / constraints
Thanks for your work on this draft. This is a very simple discuss that we should be able to clear quickly. In the security considerations section, there is a MAY that I think should be a SHOULD to encourage the use of session encryption. OLD: Any suitable external mechanisms, such as SRTP [RFC3711], MAY be used. NEW: Any suitable external mechanisms, such as SRTP [RFC3711], SHOULD be used. It came up in the SecDir review, but maybe wasn't seen by the draft editors. https://www.ietf.org/mail-archive/web/secdir/current/msg05453.html Thank you!
Very clear document; well written. The Abstract and Introduction both understate what this document is. It doesn't just define the payload format and registrations, but also provides what I would consider an Applicability Statement in Section 3: normative, Standards Track advice about how to use the Opus codec, complete with MUST and SHOULD and SHOULD NOT. That's fine, but both the Abstract and Introduction should say that. -- Section 4.1 -- Opus supports 5 different audio bandwidths, which can be adjusted during a call. Wouldn't "during a stream", or "during active streaming", or perhaps "during an RTP session", or some such be better than referring to "a call"? -- Section 5 -- It is RECOMMENDED that senders of Opus encoded data apply congestion control. Does this SHOULD come with any reference to how to do congestion control? The previous paragraph has some vague statements about doing congestion control, but is there anything more concrete that I could refer to if I were implementing this? -- Section 6.1 -- I see that the document shepherd asked for a media-types review in December, and that there were no comments. Thanks for making sure that got done, Ali.
I agree with Barry that Section 3 should be explicitly called out as an applicability statement.
draft-ietf-6man-resilient-rs
I'm piling on Barry's Comment as a Discuss, which should be easy to discuss, but ... in this text: 3. Configuring the use of retransmissions Implementations of this specification MAY provide a configuration option to enable or disable the use of such potentially infinite retransmissions. If the implementation provides such a configuration option, it MUST be able to enable/disable retransmissions on a per- interface basis. You can tell me that it's a LAN, so the transport ADs can go back to sleep, but I was surprised that this configuration option was a MAY. I was also surprised that there was no guidance about the default setting (on or off), but let's start with the MAY. IP does get tunneled to new and exciting places ... and infinite retransmissions are infinite ...
Extreme nit alert: In general, the delay may be unacceptable in some scenarios. would make more sense to me without the "in general".
Similar to Barry's comment, I would expect some operators' would prefer a system-wide default also be supported vs. per interface granularity.
security considerations: I note that RFC 4861 has been updated, including by RFC 5942, which specifically says it addresses a security concern in 4861. (I didn't check the others.) I think it'd be better to say here "beyond those discussed in [RFC4861] and RFCs that update that" or some such. Or point to all the relevant ones, or tell me that it doesn't matter for this:-)
In support of Spencer's discuss.
-- Section 1 -- In certain scenarios, these router solicitations transmitted by the host might be lost. e.g. The host is connected to a bridged residential gateway over Ethernet or WiFi. LAN connectivity is achieved at interface initialization, but the upstream WAN connectivity is not active yet. Purely minor editorial: I got a little tangled in that, and suggest tying it together better this way: NEW In certain scenarios, these router solicitations transmitted by the host might be lost. For example, if the host is connected to a bridged residential gateway over Ethernet or WiFi, LAN connectivity is achieved at interface initialization but the upstream WAN connectivity is not yet active. END -- Section 3 -- Implementations of this specification MAY provide a configuration option to enable or disable the use of such potentially infinite retransmissions. If the implementation provides such a configuration option, it MUST be able to enable/disable retransmissions on a per- interface basis. I find this a slightly odd usage of MAY and MUST: you're making the configuration option entirely optional, but then you're saying that if I have that configuration option, it MUST work a certain way. Is it really better not to be able to disable the infinite retransmissions at all, than to make it all or nothing? What is harmed by having a configuration option that affects all interfaces at the same time... that is worse than not having that configuration option at all? In the end, do as you think best; I just wanted to bring up the comment.
To continue a bit on Spencer's Discuss and Barry's Comment, I'd prefer to see a default for the configuration. I'd assume it would be "off" to continue to provide current behavior, but I don't really care. Consistency is my concern.
I can live with it. It doesn't really dwell on costs to devices from the potential for devices on very large but unrouted adhoc networks to spend resources soliciting routers essentially forever.
draft-ietf-roll-applicability-home-building
Please correct me if I'm getting this wrong, I honestly may have forgotten the plan. My understanding was that RPL and RFC 7416 etc. were approved on the basis that you needed to get to specific applications of RPL before you could sensibly specify interoperable security with automated key management (AKM) as is clearly required by BCP107 and as has been discussed between security ADs and the ROLL WG numerous times. This is going back to the 2010 discuss from Tim Polk that I inherited in 2011, hence me being uncertain if I remember the plan for sure;-) In any case it seems to me that this draft also doesn't get us to the point where we have a defined way to do AKM (Again, sigh.) I also have a set of comments on that below that I won't make into specific discuss points (at least until we figure out or re-discover the plan). So, with that context, and with real regrets for sounding like an old and broken record, the discuss point: why is this not the ROLL WG draft where we finally get to specify AKM for RPL? If your answer is that this is just an applicablilty statement then I'll ask why it's going for proposed standard, and when to finally expect the AKM spec for RPL (for this application).
- I don't get how there's an IPR disclosure for this, but whatever. - The non-security parts of this were quite a good read. - 4.1.8: 1st sentence makes no sense. It says RPL does X or not-X in order to Y. There is no choice but for RPL to do X or not-X. - 4.1.8 seems to me to imply that link layer security is always needed since there can always be some node that will send an unsecured RPL messsage. If you agree, then I think that should be made more clear. If you disagree, I'd like to understand how. - 4.1.8, I am surprised not to see a recommendation that separate group keys SHOULD be used for different applications in the same bulding network. But that may be too fine grained a recommendation for this document perhaps. - 5.1.2.1, I think it'd be clearer to say Imin should be between 10 and 50 ms. The "10 - 50 ms" notation can be confusing. (Same elsewhere.) - section 7, 3rd para, "can rely on" is sales language, please strike that or s/rely on/depend upon/ - section 7, 3rd para, last sentence: this is sales language and should be deleted. Or perhaps s/is/SHOULD be/ would turn it back into a piece of specification language. - 7.1 - this is odd text to see in a proposed standard, but I think it's accurately describing the level of interop to expect in RPL security, so is probably the right thing to say. I'd argue that it'd be even better to bluntly admit/say that there is currently no interoperable automated key management for RPL. (Same for 7.3) Or, and better, to fix that lack. (See my discuss point.) - 7.2, 1st sentence: this is meaningless as I read it - what are you trying to say? - 7.2, when a node is stolen, the chances are that any keys contained in the node are at significant risk of being leaked. - 7.3, I do not believe that [I-D.keoh-dice-multicast-security] is necessarily going to proceed via the DICE WG. Depending on it would be fairly high-risk in any case. - 7.4, last sentence: more sales talk - 7.5, what is this specifying? I don't get it. Does 7416 set out what to implement to get interop? (I didn't think so, but nor does this seem to.)
The draft looks good, thank you for your work on it. I see privacy isn't mentioned, but think that's okay as I can't think of a scenario where privacy isn't covered by the security already provided (through confidentiality protections) since the scope is within a network - home or office. I'm just mentioning this here in case someone else does think of a scenario that may be necessary to note in the draft. The SecDir review had some requests for clarification in the text. In my read, I understood what was intended, but in seeing her questions, I think it would be good to consider rewording the text she points out so it is clear to all readers. This is non-blocking and just something to consider as I understood the intent of the current text, but that doesn't mean it can't be improved :-) http://www.ietf.org/mail-archive/web/secdir/current/msg05589.html
I like this document a lot; thanks for the work on it.
draft-ietf-netconf-rfc5539bis
- section 2: be no harm to say the server has to send a CertificateRequest as part of the handshake and/or to say (or point to) how e.g. to configure that in apache or similar. (Not normatively, but as an illustration to save folks time when they go to do it.) - section 7, if we get the ID via step (b) option 2 and step (c) option A then anyone certified below that CA gets to use that identity. I'd say that's a sufficiently bad plan in almost all cases to be worth noting as a security consideration. (Sorry for not spotting that in RFC7407 but I think the alg there is harder to see in the yang module(s) so I guess I missed it;-) - I agree with Sam's second comment in the secdir review [1] that specifying how to fingerprint is a good idea, even if it's non-normative. I think in this case you may need to fingerprint the full certificate and not the public key, as the latter could allow attacks - but someone would need to spend more time that I have today to figure out if there are any interesting attacks. (Did the WG think those issues through?) [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05522.html
I found the discussion on the SecDir review interesting, so thanks for the more detailed explanations. I do agree that the draft already does state that this is a certificate fingerprint, but don't see (maybe point me to where it is if I missed it), that this is all local, per: https://www.ietf.org/mail-archive/web/secdir/current/msg05526.html I'm wondering why the yang model that was spilt out into another draft isn't referenced as that would be helpful as well (last 2 paragraphs of Tom's response): https://www.ietf.org/mail-archive/web/secdir/current/msg05524.html This is non blocking as I'd like to figure out if it's helpful to avoid questions and link drafts where appropriate (unless I missed something). Thanks, Kathleen
-- Section 5 --
presented X.509 certificate may also be considered valid if it
matches a locally configured certificate fingerprint. If X.509
certificate path validation fails and the presented X.509 certificate
does not match a locally configured certificate fingerprint,
It's probably worth it here to allow for things such as DANE, by slightly
changing the wording. what do you think of this, perhaps?:
NEW
presented X.509 certificate may also be considered valid if it
matches one obtained by another trusted mechanism, such as
using a locally configured certificate fingerprint. If X.509
certificate path validation fails and the presented X.509 certificate
does not match a certificate obtained by a trusted mechanism,
END
Does something like that make sense? Or is it better to limit it to
preconfigured certs?
-- Section 7 --
Similarily, if the
username does not comply to the NETCONF requirements on
usernames [RFC6241] (i.e., the username is not representable in
XML)
Checking: Is "not representable in XML" really the only way the username would
not comply? That is, is "i.e." correct here, or do you mean "e.g."?
-- Section 9 --
If third-
party authentication is needed, the SSH transport can be used.
Very small point: you have four citations to 6242 in two paragraphs in Section
3, but none here. This would probably be a good place to stick another
citation.
draft-ietf-tls-sslv3-diediedie
Thank you for writing this. Even the transport dorks know it matters. I wish you had used the word "die" in the draft name more than three times, but you're the experts :-) I'm not parsing this text the way I think you want me to: The predecessor of SSLv3, SSL version 2 [RFC6101], is no longer considered secure [RFC6176]. SSLv3 now follows. I'm struggling with "is no longer considered secure" in the present tense, describing an action taken several years ago. Is the point that negotiating SSLv2 was prohibited in 2011 because SSLv2 was no longer considered secure, and negotiating SSLv3 is now being prohibited in the same way, for the reasons listed in this document? If so, saying something like that might be clearer ...
The abstract says (as it should) that this updates all versions of TLS... yet the metadata only updates 1.2. For most situations I'd think that appropriate (no need to update the ones that are obsoleted), but in this case the deployment of earlier versions is sufficiently widespread (and, after all, you do have them as normative references) that I think we should add 2246 and 4346 to the "updates" list. Note, though, that this is not a DISCUSS, so I'll leave it to y'all to decide what's best. I think prohibiting-rc4 doesn't need to be a normative reference; I'd make it informative. I think the same is true for RFC 4492. -- Section 3 -- Pretty short litany, here, really. I guess it's not the whole megillah. Jus' sayin'.
draft-ietf-httpbis-auth-info
Please mention that this draft updates 2617 in the abstract.
draft-klensin-smtp-521code
Sections 3 and 5.1 suggest different text strings for 521 (server vs. host). I'd say just one would be better.
draft-ietf-lmap-framework
This document provides a framework, as such it is not defining the specific
final pieces. Section 2 reads:
Other LMAP specifications will define an information model, the
associated data models, and select/extend one or more protocols for
the secure communication: . . .
I believe there are at least 2 superfluous forward references that the document
can live without.
1. Information Model. For example, in Section 5:
The protocol model is closely related to the Information Model
[I-D.ietf-lmap-information-model], which is the abstract definition
of the information carried by the protocol. (If there is any
difference between this document and the Information Model, the
latter is definitive, since it is on the standards track.) The
purpose of both is to provide a protocol and device independent view,
which can be implemented via specific protocols. LMAP defines a
specific Control Protocol and Report Protocol, but others could be
defined by other standards bodies or be proprietary. However it is
important that they all implement the same Information Model and
protocol model, in order to ease the definition, operation and
interoperability of large-scale Measurement Systems.
Reference is made to Information Model work in progress that could match this
document. Given the disclaimer in the text about potential differences, I
think that leaving a reference in the text could cause confusion. IOW, I'm
suggesting you take out the reference and the disclaimer, and just let the
Information Model draft speak for itself.
2. Registry for Performance Metrics. Section 5.2.2:
o the Measurement Task configurations, each of which needs:
* the Metric, specified as a URI to a registry entry; it includes
the specification of a Measurement Method. The registry could
be defined by the IETF [I-D.ietf-ippm-metric-registry], locally
by the operator of the Measurement System or perhaps by another
standards organisation.
The framework is leaving the door open for multiple ways to define a registry,
but is making reference to a specific one (still WIP)..it just causes confusion.
Neither of these comments are major, not do they take away from the technical
value of the document. Mostly suggestions to improve the clarity of what the
framework is proposing.
Section 1, paragraph starting with "Broadly speaking there are two types of Measurement Method. " s / Method / Methods Figures: Several figures that start at the top of the page have the first line out of alignment. Figure numbers might be useful. (For example, had there been numbers I could have referenced the figures with the alignment problem :-) )
Thank you for your very careful and detailed attention to security and privacy, with options suggested to protect privacy in practice through group ids instead of ones that identify an individual. I just have one question. The security considerations section has a lower case 'must' for providing session encryption, but then the privacy section warns that monitoring can be possible when sessions are not encrypted. When I saw the privacy considerations, I went back to the security section to make sure active attacks against session traffic that was not encrypted was addressed as I didn't see this same 'must' and by that time needed to go back to make sure something as in place. I'm wondering why these weren't just addressed together since more security things could happen too if sessions were not encrypted (in other words, there could be less text, unless I am missing something and we need more on the security side). Thanks!
draft-ietf-sacm-use-cases
- general: there seems to be no mention or consideration at all of privacy which I think is a significant flaw in this document. However, so long as privacy issues are considered in later documents, that's not a problem. It would be a problem if privacy were similarly ignored later on. As an example of why this matters, enterprises will have to adhere to privacy legislation in various jurisdictions which would for example introduce a data controller as a relevant entity to be considered (and that is not considered here). Once one collects e.g. log information about authentication times and locations then I suspect you need a data controller and you might have to delete that data or anonymise it or do other privacy friendly things with or to such data. I think for now, adding a statement that later documents will have to consider the privacy issues associated with these use cases would be a good idea that would be sufficient to ensure that it's not forgotten. Note: I do think it would be preferable if someone had (or still would) spend time on an analysis of the possible privacy considerations of some of these use-cases. I suspect those aren't as bad as may be feared and could perhaps be relatively easily covered in a few paragraphs, once that work has been done. (If doing that, please do not only consider the typical US private enterprise network scenario - those in other parts of the world and in non-profit or public service can differ significantly in privacy terms.) - 2.2.5 - I've been to places like that for research purposes (as stipulated here) and this use-case seems unrealistic to me. - section 4: I think you might end up need to consider the confidentiality and origin authentication of some of the data at rest as well as in transit. That could get tricky, but OTOH, if you have any conception of provenance and of privacy then it's likely to be needed. I'd say just adding a sentence here to recognise that that can also be an issue would be enough. - The secdir review [1] noted a bunch of nits. I didn't check if those have been fixed or not, but seems like a good idea. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05536.html
draft-ietf-radext-dynamic-discovery
draft-ietf-oauth-dyn-reg-management
I agree with Ben's point. A short paragraph such as sent in mail earlier would be good.
It would be nice to see a a description of the "Experiment". Is there an expectation that some or all of this would eventually move to the standards track?
draft-ietf-netext-pmip-qos-wifi
Just a small question/comment: Given that rfc7222 considers an access network independent way of negotiating QoS, and that this document describes the negotiation when the access is WiFi, it seems to me that this document updates rfc7222 for this specific case and it should be marked as such. Am I missing something?
conflict-review-farinacci-lisp-rig
conflict-review-mohali-rfc6044bis