IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2016-09-01. 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: Suresh
1 Administrivia
2. Protocol actions
2.1 WG submissions
2.1.1 New items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning items
2.2 Individual submissions
2.2.1 New items
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:
3.1.2 Returning items
3.2 Individual submissions via AD
3.2.1 New items
Telechat:
Telechat:
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
3.4.2 Returning items
1054 EDT no break
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat::
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
Telechat::
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
7. Working Group News
1131 EDT Entered Executive Session
(at 2016-09-01 06:06:30 PDT)
draft-ietf-nfsv4-multi-domain-fs-reqs
I am a little bit confused about the purpose of this draft. My confusion is probably related to Brian's Gen-ART comments. Specifically, who/what do the normative requirements in section 6 apply to. Are these implementation requirements or deployment requirements? If the former, should this update any of the nfsv4 RFCs? If deployment, then I also wonder why this is PS and not BCP.
- general: I agree with Kathleen who agrees with Russ' secdir review. [1] I was left puzzled as to how this would be useful to readers. But I've no objection if that's felt to be the case. However, I'd really encourage the editors/WG/AD to consider that a number of folks (who are familiar with GSS etc.) have found this draft pretty unclear. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06642.html - abstract: 1st sentence seems unwieldy - it puzzled me anyway;-) - (various places): Would "identifier syntax" not be better than "identity syntax"? There's no need to bikeshed on it, but I do prefer the latter a good bit in case that helps:-) - 5.3: Would that "must never" in the 2nd last para be clearer as an RFC2119 "MUST NOT"? (Just checking.) - 6.1: Are there any cases of domain names that allow for escaping or have other syntatic features that involve more than just octet string comparisons to check domain name equality? I don't think there are, so just checking. If there were, then you might need to say something about that somewhere.
Agree to other comments about clarity. As also mentioned by Ben, I believe this should probably update rfc7530 (and maybe even rfc5661) and the updates made should then be indicated clearly.
I do note the BCP/PS question from Brian in his Gen-ART review. My own opinion is that BCP would have equal strength, and if it were up to me, I’d pick that category. However, I’m not religious about this — clearly you could go two ways on this.
I think using more examples in the document would improve readability. A couple of very small nits with this document: "mulit-domain" typo at least 4 times. LDAP reference should probably be listed on first mention. Similar for Kerberos.
Thanks for following the advice in the SecDir review: https://www.ietf.org/mail-archive/web/secdir/current/msg06652.html I think the draft could be a bit more clear, following Russ' comments a bit further. I had similar questions in this version, but then read his review and the responses. I'll leave this as a comment for the AD since my comments would be similar to those already made. If the draft could read a bit better, that would be helpful.
Everything that came to mind when reading this draft has already been raised in Kathleen's (Russ's), Stephen's, and Jari's comments. That doesn't really need a +1, but "+1". ;)
draft-ietf-nfsv4-scsi-layout
- 1.4: (A question for the IESG/RFC editor and not the document authors.) How will shell scripts like this be affected by new RFC formats? Have we thought about whether that'll work? Maybe the text here (and in similar cases) ought in future say that it's the plain ascii form of the RFC that needs to be fed into the script, as odd things may happen with other formats. (Note: I don't think this document ought be held up while that is discussed, if discussion is needed.) - 2.4.10: MDS is used without expansion or reference. A very quick search didn't help me figure out for sure what that means btw;-) Is it metadata-server? - 2.4.10: is "device device ID" a typo? - section 6: Is the SAM-5 reference correct? Is the XXXXX something that the RFC editor will need to fix? If so, that probably should be noted in the document so it's not forgotten. If the XXXXX means that that's a draft that's not yet final then you probably also need to tell the RFC editor to wait until the final document is published.
For the security considerations, it would be good to include a few examples of the security provided by iSCSI, like encryption via IPsec (tunnel and transport mode - IMO opinion this RFC makes it difficult to set this up in an interoperable way, but that's not the responsibility of this draft), authentication, etc. RFC7143 is such a large document, just a pointer isn't as helpful here in comparison to the no security example. This is just at the comment level since the pointer is technically sufficient, but sets one up for a lot of reading.
Victor Kuarsingh <victor@jvknet.com> performed the opsdir review.
draft-ietf-mpls-entropy-lsp-ping
As noted on the list discussion, the chairs, authors, and I discussed "what is an update": https://mailarchive.ietf.org/arch/msg/mpls/c1lVXUC6xruy0hvl5i5GzSKUVwE We concluded the document only really updates RFC6790 as the update isn't mandatory for the "general" lsp-ping RFCs to implement. The authors will correct this on their next respin.
Just to note that there's an editorial change that was agreed [1] as a result of the secdir review that has still to be made. (No big deal, just noting it in case it gets forgotten.) [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06754.html
As Scott mentioned in his review, I also think that the following sentence needs more discussion: "All LSRs along the LSP need to be able to understand the new flags and the new multipath information type." How can you ever know if this is true? Isn't the whole problem that you don't know what different LSRs implement?
Editorial observations from Peter (in his Gen-ART review) are worth noting before final sending of this draft to the RFC Editor.
As noted by Scott Bradner in his OPS DIR review, 2 issues worth addressing IMO. I did an OPS-DIR review of Label Switched Path (LSP) and Pseudowire (PW) Ping/Trace over MPLS Network using Entropy Labels (EL) (draft-ietf-mpls-entropy-lsp-ping-04) The draft extends the existing MPLS LSP Ping and Traceroute multipath mechanisms to support LSPs that use an Entropy Label. The primary operational impact of this technology is to provide an additional tool for network operators to debug their networks - a good thing. I found the draft a bit hard to follow, it seems to be more a collection of data points than a clear narrative but I do not think it is worth a rewrite to make it easier to understand. I found one thing that raises an operational concern - the next to last paragraph in section 2 says: “All LSRs along the LSP need to be able to understand the new flags and the new multipath information type.” But I do not see a mechanism discussed to check to see if that is the case (like the high order two bits of IPv6 options). If there is a mechanism it might be good to describe it, if there is not, a statement that verifying this condition is outside of the scope of the draft would be helpful The same paragraph goes on to say “It is also required that the initiating LSR can select both the IP destination address and label to use when transmitting MPLS echo request packets.” It might be helpful to say under what conditions this is or is not the case. Otherwise, the draft seems ready for publication.
The description of what is added in this draft in the Security Considerations section is good, but aren't there additional security considerations (risks) with this addition? This document extends the LSP Ping and Traceroute mechanisms to discover and exercise ECMP paths when an LSP uses ELI/EL in the label stack. Additional processing is required for responder and initiator nodes. The responder node that pushes ELI/EL will need to compute and return multipath data including associated EL. The initiator node will need to store and handle both IP multipath and label multipath information, and include destination IP addresses and/or ELs in MPLS echo request packets as well as in multipath information sent to downstream nodes. BTW, the above is a nice description that would have been nice to see sooner in the text. The draft then says: This document does not itself introduce any new security considerations. Isn't there anything that should be said about risks with the extended capabilities to discover and exercise ECMP paths? Does this help network reconnaissance? Does it help attackers to have this additional information? If it doesn't, please explain why and that will clear up this discuss or adding text would be good. Thanks.
Just a nit: It would be nice to move Section 10 towards the front of the document. I know there are a couple of references to it, but knowing upfront the scope would be helpful to any reader.
draft-ietf-avtcore-rfc5764-mux-fixes
Thank you for doing this update. You're helping avoid problems later. This specification was pretty dense and difficult for me to understand (there's quite a bit going on), until I got to the OLD TEXT/NEW TEXT in Section 7, which made everything much clearer. You might consider moving Section 7 forward, so that the organization of the document becomes "here is the new multiplexing scheme", followed by "here's why the changes are needed". In these list entries: 1. It implicitly allocated codepoints for new STUN methods without an IANA registry reflecting these new allocations. and 3. It implicitly allocated codepoints for new Transport Layer Security (TLS) ContentTypes without an IANA registry reflecting these new allocations. is it correct to say "without entries in an IANA registry reflecting these new allocations"? I was reading the text as saying there were no registries for STUN methods or TLS ContentTypes, but that's not what you meant, is it?
Ersue, Mehmet (Nokia - DE/Munich) <mehmet.ersue@nokia.com> provided the opsdir review
draft-ietf-avtext-rid
In this text from the Introduction, RTP sessions frequently consist of multiple streams, would it be possible to add a word or two explaining why this happens? If it's true that this happens because multiple media types, or codecs, or ... are in use in the same RTP session, that's the level of detail I'm thinking about. In this text: At the same time, when redundancy RTP streams are in use, could you provide a reference for redundancy RTP streams? I'm guessing this is using RFC 7198, but that's just a guess. I was impressed that you included this, These redundant RTP streams may also contain their own unique RtpStreamId. but (of course) started wondering why you'd do that - can the RtpStreamId for a redundancy RTP stream appear as a RepairedRtpStreamId for a third RTP stream? Or is there some other reason to assign an RtpStreamId?
Thanks for the "don't use PII" text!
There is one use of normative language but no rfc2119 boilerplate: "RtpStreamId and RepairedStreamId MUST contain only alphanumeric characters." I would actually recommend to add more normative language (and the boilerplate), e.g.: " To be clear: the value carried in a RepairedRtpStreamId MUST match the RtpStreamId value from another RTP stream in the same session. For example, if a source RTP stream is identified by RtpStreamId "A", then any redundancy RTP stream that repairs that source RTP stream will contain a RepairedRtpStreamId of "A" (if this mechanism is being used to perform such correlation). These redundant RTP streams MAY also contain their own unique RtpStreamId."
I don't see a response to the SecDir review, but maybe missed it? https://www.ietf.org/mail-archive/web/secdir/current/msg06724.html
draft-ietf-tram-turn-mobility
Hi, I have a few minor comments and (mostly) questions: - General: I wonder if this should consider the potential for allocation flapping, e.g. if a client is sitting on the border between two wireless networks. Is this an issue, and is their any reasonable guidance that could be offered? - 3.1.2, 2nd paragraph: I'm curious why the server disallows this mechanism would explicitly reject a request with the MOBILITY-TICKET attribute rather than ignoring it as if it didn't understand it? Is there an advantage in letting the client know that the server undertands the extension but chooses not to use it, verses simply not understanding it? - 3.1.4: If the client receives "Mobility Forbidden", is it allowed (or encouraged) to retry without mobility? - 3.2.2: I'm (also) curious why the server rejects a refresh request with the original 5-tuple and the mobility ticket. Also, during the transition window (before it gets a Send Indication or ChannelData message on the new allocation), am I correct to assume that the server forwards inbound data _only_ to the old client address? That is, not both? If so, I think that could use some reinforcement. - 5.1: Does MICE here refer to the draft in it's current state, or an earlier version? (assuming there is any material difference.) Editorial: -1, 2nd paragraph: "the TURN client has to request for a new allocation" s/request for a new/request a new -- "new relayed candidate address would have to be tricked" s/tricked/trickled
Apologies if these discuss points are off-base, I was pressed for time when reviewing this:-( (1) section 6 correctly says that encryption and integrity protection are needed to prevent attacks, but the wording seems ambiguous. Does the MUST here mean that a) TURN servers MUST use strong crypto whenever they send tickets or b) if a TURN server does not use strong crypto then tickets can be abused? I hope it's the former, but in any case I think you need to clearly say. (2) I guess the use of (D)TLS is fairly clear here. But I'm less clear that things are ok for the other cases when the ticket is (I guess?) visible to a network attacker. Don't you need to say that in those other cases the server MUST NOT honour the ticket unless the authentication mechanisms have worked out ok?
* Section 3 In the figure (without number/title) why is there an Allocate failure in the second message? I could not find the associated text. * Section 3.2.1 The section on sending a Refresh when the IP address does not change needs a little bit more tightening. Given that the server would reject the request with a mobility ticket in this case, it would be good to put in an explicit restriction to not add the mobility ticket in the following statement OLD: If a client wants to refresh an existing allocation and update its time-to-expiry or delete an existing allocation, it will send a Refresh Request as described in Section 7.1 of [RFC5766] NEW: If a client wants to refresh an existing allocation and update its time-to-expiry or delete an existing allocation, it MUST send a Refresh Request as described in Section 7.1 of [RFC5766] and MUST NOT include a MOBILITY-TICKET attribute.
= Section 3 = The diagram needs a caption and some explanation. Why does the first Allocate request result in a 401 error? This is not discussed anywhere in the document. = Appendix A = In the data structure there is a "state" field but the text below it refers to an "encrypted_state" field.
Is the following scenario worth to be discussed in the doc? A client receives a MOBILITY-TICKET from the server but when it tries to send a Refresh Request the server ignors the ticket and sets up a new association (maybe because the server seemlessly migrated to a machine that does not support/understand MOBILITY-TICKETs or because of policy reasons) and therefore also does not send a new MOBILITY-TICKET back. I guess in this case the client would probably still want to communication with the destination server and just start a new transport connection, right?
draft-ietf-tram-turn-server-discovery
in requesting special use assignments, please read the registries and provide guidance on the scope of the allocations i.e. o Source - A boolean value indicating whether an address from the allocated special-purpose address block is valid when used as the source address of an IP datagram that transits two devices. o Destination - A boolean value indicating whether an address from the allocated special-purpose address block is valid when used as the destination address of an IP datagram that transits two devices. o Forwardable - A boolean value indicating whether a router may forward an IP datagram whose destination address is drawn from the allocated special-purpose address block between external interfaces. o Global - A boolean value indicating whether an IP datagram whose destination address is drawn from the allocated special-purpose address block is forwardable beyond a specified administrative domain.
* Section 4.1.1. The DHCP procedure is underspecified. I think this can be easily fixed but it requires some work. Please describe what sort of messages you would be using. i.e. are you going for a stateful exchange to piggy pack with other address and config information or are you going for a stateless Information-request based exchange(Most likely). Is there an ORO? If so, what options are requested in the ORO? Are there multiple request-response round trips as implied by the text?
-9, first paragraph says: "Use of Session Traversal Utilities for NAT (STUN) [RFC5389] authentication is OPTIONAL for TURN servers provided by the local network or by the access network. A network provided TURN server MAY be configured to accept Allocation requests without STUN authentication, and a TURN client MAY be configured to accept Allocation success responses without STUN authentication from a network provided TURN server. " This seems to relax the MUST level requirement in RFC 5766 that says TURN MUST use STUN long-term credential authentication, or use some other equally strong mechanism. From a purely process perpective, this would either require an update to 5766, or it would require an argument that the local/access network is somehow equally protected. I think the latter would only be true if the access network has some sort of protection beyond just being the access network (e.g. a vpn, ipsec, or physical isolation.) I don't recall seeing text that suggested any of those. But in any case, I think relaxing that requirement needs some discussion about how the server or client can be sure that all communication is in fact constrained to the local network.
Substantive: - general: I agree with the DISCUSS positions from Terry, Alexey, and Kathleen. -3, paragraph 1: Are the MUST and MAY in this paragraph _new_ requirements, or just statements of fact about previously existing requirements? If the latter, they should not use 2119 keywords. -4.1.2, first paragraph: It would be helpful to have a discussion about clients that may support multiple users, potentially with different domains, or for a single user to use different domains for different services. -4.2, general: Do I correctly understand that most of this section describes the results of applying RFC 5928 procedures to the extracted domain name? If so, is it not enough reference 5928 and leave it at that? -4.2, last paragraph, last sentence: Is this requirement new to this draft, or something from 5928? If the latter, please use descriptive language. -9, paragraph 5: "Any discovered TURN server outside the criteria is considered untrusted and is not used for privacy sensitive communication." It seems like this needs stronger guidance, maybe even "MUST NOT be used..." - Informational References: I-D.ietf-rtcweb-return and RFC 6125 are cited as part of normative requirements, which makes them by definition need to be normative references. I-D.ietf-tram-turn-mobility, RFC6024, and RFC7250 are borderline; I think one could make an argument that one needs to read them to fully understand this draft. Editorial: -3, last paragraph: "MAY optionally" is redundant. -5.1, first paragraph, first sentence: I got lost in the nested “or”s. Please consider breaking this up into a few simpler sentences. - Figure 1: Why merge the query and reply for the A/AAAA query but not the other queries? -6, first paragraph, last sentence: I'm not sure what that sentence means.
= Section 6 = "Using the TURN anycast address, the only two things that need to be deployed in the network are the two things that actually use TURN." This is a bit opaque. I would suggest adding the qualifier "for discovery" somewhere in this sentence. = Section 7.2 = "WebRTC endpoints SHOULD treat any TURN server discovered through the mechanisms described in this specification as an enterprise/gateway server, in accordance with Recursively Encapsulated TURN [I-D.ietf-rtcweb-return]." I think this needs to be re-phrased to include auto-discovery of a TURN server hosted by any access network, not just an enterprise network. = Section 9 = "Any discovered TURN server outside the criteria is considered untrusted and is not used for privacy sensitive communication." This is stated as a fact, but I would have thought it's more of a recommendation to implementers, e.g., servers outside the criteria ought to be considered untrusted and therefore not used.
This should be easy to resolve. In reading the draft, it doesn't cover any mechanism for the TURN server to limit what clients can discover it. For the second and third method, it seems like there are possible ways to do this. Could these be added to the security considerations? You'd need to state that this isn't possible with the first method. If there is a reason why it is always okay to discover a TURN server, please let me know why this is not appropriate to add. Thanks.
In Section 9: o For certificate-based authentication, a pre-populated trust anchor store [RFC6024] allows a TURN client to perform path validation for the server certificate obtained during the (D)TLS handshake. If the client used a domain name to discover the TURN server, that domain name also provides a mechanism for validation of the TURN server. The client MUST use the rules and guidelines given in section 6 of [RFC6125] to validate the TURN server identity. I am glad that you are referencing RFC 6125, but unfortunately you don't provide enough details. Please add details as specified in Section 3 of RFC 6125 to your document.
draft-ietf-6man-deprecate-atomfrag-generation
I'm not going to stand in the way of publication, but I don't think we need to publish this document: it already served it's purpose. Evidence of that is in RFC7915, rfc2460bis...
I have to say I agree with the tsv-art review that it is not fully clear to me that this explanation needs an own document. For me a much short rational for this change (1 or max. 2 paragraphs) that could be integrated in 2460bis would be sufficient (also given that this document has soe redundancy).
draft-ietf-ice-dualstack-fairness
Thanks for doing this work. The document thinks it's going for Best Current Practice, but the shepherd write-up and datatracker think it's going for Informational. It would be good for that to match ... I'm a little confused by These recommendations are backward compatible with a standard ICE implementation. The resulting local and remote checklist will still be synchronized. The introduced fairness might be better, but not worse than what exists today Is the point that the introduced fairness - might be better, or - might be the same as, but - won't be worse? If so, that wasn't clear to me on first (or second) reading. (Nit: missing period at the end of "what exists today")
I'm willing to resolve my discuss quickly but I would like to start some discussion: To me the recommenations given in this doc are not very clear. To my understanding are there two recommenations: 1) intermingle IPv4 and IPv6 addresses, and 2) put lower priority for adresses that are know to have connectivity problem. However, that leaves tons of open questions to the implementor, e.g. - How many IPv6 addresses should I have before the first IPv4? - How do I measure/track that an interface has connectitivy problems: connectivity failed once, or twice, or X-times? How long do I keep this track: 1h, one day, one week, forever? Would it be possible to be more specific and give further guidance? E.g. how are these points implemented in the existing implementations?
Further, I think the term 'fairness' is just wrong here. The goal is to avoid delay in case there are connectivity problems with IPv6 in general, while still prioritizating IPv6. For me, that's nothing about fairness.
* Section 4 I am trying to see if there is any background for the following statement "It is worth noting that the timing recommendations in [RFC6555] are not optimal for ICE usage." Why is it not optimal? Do you want smaller or larger timings? Some explanations here would be good. Additionally, it might be worthwhile for this document to provide alternate timing recommendations that *are* optimal.
* Agree with Alissa's DISCUSS point. I ran into the same circular reference * Agree with Mirja's comment about fairness being the wrong term to use
This should be very easy to resolve: The Intended RFC status on the datatracker, the Last Call, Shepherd write-up, etc. says Informational, but the header in the document says Best Current Practice. Please update.
The draft is intended as a BCP, but we ran the IETF Last Call as an informational. This is entirely my fault. I'm entering a "process" discuss to hold approval until we can re-run the last call. Let's complete resolve any other issues that come up in IESG evaluation, then I will re-run an abbreviated last call focusing on the status change.
Thanks for addressing the SecDir comments: https://www.ietf.org/mail-archive/web/secdir/current/msg06670.html
= Section 4 = "However, modifying the check list directly can lead to uncoordinated local and remote check lists that result in ICE taking longer to complete or in the worst case scenario fail. The best approach is to modify the formula for calculating the candidate priority value described in ICE [I-D.ietf-ice-rfc5245bis] section "4.1.2.1 Recommended Formula"." ICEbis section 4.1.2.1 then says: "If a host is multihomed because it is dual-stack, the local preference should be set according to the current best practice described in [I-D.ietf-ice-dualstack-fairness]." So, there is a circular reference, and nowhere is it specified how the formula should actually change. I think it's fine to put this in ICEbis, but if this draft is going to reference it then it actually needs to be specified there. Alternatively, if this text is meant to reference the discussion further down in Section 5, I wouldn't call that modifying the formula, but rather providing guidance about how to set local preferences within the formula.
= Section 3 = "If the agent has access to information about the physical network it is connected to (Like SSID in a WiFi Network) this can be used as information regarding how that network interface should be prioritized at this point in time." I think this needs further elaboration, as it's not obvious how knowledge of the SSID correlates to knowledge of the stability of the network. "Candidates from an interface known to the application to provide unreliable connectivity should get a low candidate priority. This ensures they appear near the end of the candidate list, and would be the last to be tested during the connectivity check phase. This allows candidate pairs more likely to succeed to be tested first." All three of these sentences say more or less the same thing, so two of them could be dropped. = Section 8 = Doesn't following the recommendations in Section 3 potentially leak information to a remote peer about the quality of a local peer's connectivity on different interfaces? That is, if the remote peer maintains some state about past ICE interactions, would it be able to detect a change of priority that could indicate a change in connectivity quality? If so, this seems worth mentioning.
draft-ietf-6man-ipv6-mibs-obsolete
draft-ietf-httpauth-extension
1) The following disclarer is a little odd: "The terms "encouraged" and "advised" are used for suggestions that do not constitute "SHOULD"-level requirements. People MAY freely choose not to include the suggested items. However, complying with those suggestions would be a best practice; it will improve the security, interoperability, and/or operational performance." Both terms are only used once. I would recommend to remove the text above and simply use MAY later in the doc (or not use MAY and leave the later text as it is just without the disclaimer). 2) I agree that the section on username should point to the secturity section to give a clear warning. However, I also don't really understand why username is needed. If there is a good use case for it, maybe it's worth to explain this as another example.
Comments from the Gen-ART reviewer Matt Miller should be taken into account, see below. I considered making a Discuss about the reference to Authentication-Info RFC but I trust that you guys will make the correct modifications. Thanks! ---- * There is at least a couple of mentions of the "Authentication-Info" header, but no reference to RFC 7615 in which it is defined. I think an informational reference is warranted here. * Just reading sections 4.5. "Location-when-logout parameter" and 4.6. "Logout-timeout parameter", it is unclear how these are meant to interact to inform a client the user's authentication session. Frankly, I think the text in section 4.5 is too vague about how a client can detect termination of a user's authenticated session, and could use more of a hint on how "logout-timeout" is involved to accomplish it. At the least, I think both sections 4.5. and 4.6. need pointers to section 5. to help readers get a sense of how to apply them. * In section 4.7. "Username parameter", I think there should be an explicit pointer to the Security Considerations to warn about potential issues this parameter presents. I also recommend separating that portion of the Security Considerations about "username" into its own subsection to make such a callout better. * Since this document is acknowledging that cookies are used for authentication, and Nits/editorial comments: * In section 2.1. "Terms for describing authentication protocol flow", the word "distinguishable" should instead be "distinguished" in the phrase "it can't be distinguishable from a non-authenticated response." * In section 3. "Optional Authentication", the word "be" is missing in "Optional-WWW-Authenticate header MUST NOT sent on 401 responses". * In section 3.1. "Note on Optional-WWW-Authenticate and use of WWW-Authenticate header with non-401 status", the word "is" should be replaced with "are" in the phrase "clients which is unaware of this extension will ignore the header". * Also in section 3.1., the word "authentications" should be "authentication" in the phrase "secondary fallback method of authentications". * Also in section 3.1., the word "ignores" should be "ignore" in the phrase "just ignores the WWW-Authenticate headers". * Also in section 3.1., all instances of the word "implementer" should be replaced with "implementers" in the phrase "the authors propose implementer of the standard HTTP/1.1 specification (especially implementer of this extension)". * In section 4. "Authentication-Control header", the word "an" should be "a" in the phrase "and MUST be sent in an plain". * In section 4.1. "Non-ASCII extended header parameters", the interoperability note as a number of grammatical challenges. I believe the following addresses the grammar issues while retaining its meaning: """ Interoperability note: [RFC7235], Section 2.2, defines the "realm" authentication parameter which cannot be replaced by the "realm*" extend parameter. It means that the use of non-ASCII values for an authentication realm is not the defined behavior in HTTP. Unfortunately, some people currently use a non-ASCII realm parameter in reality, but even its encoding scheme is not well-defined. Given this background, this document does not specify how to handle a non-ASCII "realm" parameter in the extended header fields. If needed, the authors propose to use a non-extended "realm" parameter form, with a wish for maximum interoperability. """ * In section 4.2. "Auth-style parameter", the word "preferences" should be replaced with "preference" in the phrase "server's preferences for user interface behavior". * In section .4.4. "No-auth parameter", the word "authentications" should be replaced with "authentication" in the phrase "content is desired before authentications". * In section 4.6. "Logout-timeout parameter", the word "from" should be removed in the phrase "has passed since from the time this header was received". * In section 5.3. "When to use Cookies", the first sentence has some grammatical challenges, which I believe the following text addresses: """ In current Web sites using form-based authentication, Cookies [RFC6265] are used for managing both authorization and application sessions. """ * In section 5.4. "Parallel deployment with Form/Cookie authentications", the META tag example should be "<META http-equiv="refresh" ...>" instead of ">META http-equiv="refresh" ...<". * In section 7. "IANA Considerations", the word "documents" should be "document" in the phrase "a publicly-accessible documents".
In Section 2.2: bare-token = 1*(%x30-39 / %x41-5A / %x61-7A / "-" / "_") Did you intent to allow leading "-" (and possibly "_") above? As you are using "-<bare-token>.<domain-name>" for private extensions, I think the ABNF is not right. I think you meant: lead-token-char = (%x30-39 / %x41-5A / %x61-7A / "_") bare-token = lead-token-char *(%x30-39 / %x41-5A / %x61-7A / "-" / "_") In Section 3, last paragraph: Support of this header is OPTIONAL; clients MAY also implement this extension only for some selected authentication schemes. New authentication schemes can make support of the optional authentication mandatory by its specification, though. I don't think this paragraph is needed, as this is granted, because support for any extension like specified in this document is optional. So I suggest deleting it. Section 3.1: I am still not convinced that Optional-WWW-Authenticate is needed, but the section provides a reasonable overview of the current situation. In Section 4: Support of this header is OPTIONAL, and clients MAY choose any subset of these parameters to be supported. The set of supported parameters MAY also be authentication scheme-dependent. However, some authentication schemes can require mandatory/recommended support for some or all of the features provided in this header. As above, I don't think this paragraph is needed. 4.4. No-auth parameter This parameter SHOULD NOT be used along with the location-when-unauthenticated parameter. Why is this only a SHOULD NOT (or to rephrase it: what are possible conditions for violating this)? If both were supplied, clients MAY choose which one is to be honored. I would rather you pick one behaviour in order to improve interoperability. In 4.5: When the user requests termination of an authentication period, and if the client currently displays a page supplied by a response with this parameter, the client will be redirected to the specified location by a new GET request (as if it received a 303 response). Is this value advisory? Should the client go to this page automatically or would the server redirect it? If the latter, why does this need to be told to the client? The log-out operation (e.g. erasing memories of user name, authentication credential and all related one-time credentials such as nonce or keys) SHOULD occur before processing a redirection. 4.6. Logout-timeout parameter The parameter "logout-timeout", when contained in a successfully- authenticated response, means that any authentication credentials and state related to the current protection space are to be discarded if a time specified in this header (in seconds) has passed since from the time this header was received. The value MUST be an integer. As a special case, the value 0 means that the client is requested to immediately log-out from the current authentication space and revert to an unauthenticated status. It sounds like this is not just a request, but the client will be logged out. If this is correct, then you should reword this, for example: As a special case, the value 0 means that the server is logging the client out immediately from the current authentication space and that the client is now returns to unauthenticated state.
draft-seantek-ldap-pkcs9
Given section 4.1, shouldn't this doc upadte RFC 2985? Also, I'd really prefer to use rfc number for reference keys...
As mentioned by Dan Romascanu in his OPS DIR review: The following comments are not related directly to the operational aspects, but can improve the quality of the document and its readability and usability by IT personal and network operators: - It would help to expand PKCS and include one paragraph that describes where it comes from and how it is used – this may be very trivial for security experts but not to all operators or other users of the future RFC - The following sentence in section 4 is cumbersome because of the double negation, I suggest to reformulate it: ‘The attributes in Appendix B.3 that are not highly unlikely to be stored in a Directory are registered via this document.’ - Section 4.1 includes the phrase: ‘Since all specifications are under the change control of the IETF, …’ – actually the abstract of RFC 2985 makes clear that ‘change control is retained within the PKCS process’ (which as I understand belongs to the RSC Laboratories. If things have changed since the publication of RFC 2985 (November 2000) it would be useful to document this
This is discuss is entirely my fault and requires action from me... sorry I didn't catch it sooner that PKCS#9 had not yet been transferred to the IETF for change control. We can handle this in a couple of ways, I think. The cleanest is for me to get PKCS#9 transferred and I can start that process right away. The second option is for me to see if just putting the Intellectual property statement in the IANA registry too would be enough. I see you have that in the draft. License to copy this document is granted provided that it is identified as "RSA Security Inc. Public-Key Cryptography Standards (PKCS)" in all material mentioning or referencing this document. Sorry about this! I thought we caught all of the remaining ones that had to be transferred.
Did someone check all these attributes vs. what's deployed in current code? There's the potential for errors here if that wasn't done, and cross-checked, which'd be a pity. I agree with the secdir reviewer's nits [1] and would recommend they be handled. (I don't think I saw a response? Apologies if I missed that.) [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06723.html
Stephen: I cross checked OIDs against RFC 2985 and http://www.alvestrand.no/ (The latter doesn't contain all of these, but has many). Mirja: "Updates RFC 2985" seems sensible. Benoit: I will make sure the Ops-Dir review is taken into consideration.
draft-hardy-pdf-mime
I agree with others that the security section doesn't provide much: it neither describes how attacks could look like, nor how to handle them concretely. However, it also not clear to me if this is the right document to discuss these things or if a different doc would be needed.
Why are there "<x>" paragraph numbers in this document? They feel distracting.
I agree with all the security comments. I also agree with Suresh that the paragraph numbers are distracting. While they may be useful in the review process, they will distract readers down the road.
In the Security considerations, the text starts off saying: The PDF file format allows several constructs which may compromise security if handled inadequately by PDF processors. Shouldn't this go a step further to also include the consideration that the feature could be exploited by an attacker? I don't see how it is enough for the processor to handle all possible exploits. If I am wrong, please explain.
I have two things I'd like to discuss about this draft: (1) section 3: Are there any potential security issues with namedest as a parameter? E.g. has any PDF reader or MIME handler followed an absolute URL for the value there perhaps? If so, is there a warning it'd be useful to give? Are there any other similarly known potential vulnerabilities for other parameters? (Maybe fdf or ef?) (This is also related to discuss-point-2 below) (2) section 6: It's a pity there's no ISO document to reference in this section as PDF files have been the vector for various threats over the years. Can't you find some reference (from ISO or not) that a viewer or author developer would find helpful? That section seems pretty vague to me as-is. (In particular the last clause of the last sentence in this section is not useful.) And I see from the discussion of the secdir review ([1], did any authors respond to that? If so I didn't see it, sorry). The discuss point here is that we seem to have less good security considerations compared with RFC3778, and I think that ought be justified if it's the right thing to do. (Not necessarily in the document if that's not correct, but at least as part of the record, e.g. in response to this.) [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06674.html comments
- section 4: why no reference for PDF/A? I'd have thought that was the most important one for which a good reference is needed? The referred document is [ISOPDFA] in 8.2 so I guess this is just an editing glitch.
A reply to SecDir review is needed from editors.
Agree with others' comments about the security considerations.