IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2013-02-28. These are not an official record of the meeting.
Narrative scribe: John Leslie, Susan Hares, and Richard Barnes (The scribe was sometimes uncertain who was speaking.)
Corrections from: Barry, Benoit
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning Items
2.2 Individual Submissions
2.2.1 New Items
Telechat:
2.2.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
Telechat:
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
Telechat:
3.2.2 Returning Items
3.3 IRTF and Independent Submission Stream Documents
3.3.1 New Items
3.3.2 Returning Items
1207 EST no break
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat:
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
5. IAB News We can use
6. Management Issues
Telechat:
Telechat:
Telechat:
7. Agenda Working Group News
1248 EST Entered Executive Session
(at 2013-02-28 07:30:01 PST)
draft-ietf-6man-ipv6-atomic-fragments
- The abstract tries, but fails, to explain how some attacks are enabled via atomic fragments. I mean the "Thus..." sentence, which cannot be understood by itself and is not a good thing to have in an abstract - Section 4 here is not clear as to what changes in 2460 and 5722. - Section 6 says "this document describes..." but it doesn't; you have to read 5722 or other references to actually understand the threat. - In the light of the above I would suggest rewording the abstract to something more like this: The IPv6 specification allows packets to contain a Fragment Header without the packet actually being fragmented into multiple pieces (we refer to such packets as "atomic fragments"). Atomic fragments are typically sent by hosts that have received an ICMPv6 "Packet Too Big" error message that advertises a "Next-Hop MTU" smaller than 1280 bytes. Atomic fragments are processed by some implementations as "fragmented traffic" whereas they ought properly be processed independently of all other fragments since handling these as non-atomic fragments can allow for expoitation of unrelated vulnerabilities related to improper fragment handling. This document formally updates RFC 2460 and RFC 5722 such that Atomic fragments are handled independently, thus avoiding pitfalls related to fragment handling that can be set up via "Packet Too Big" messages.
My DISCUSS is solved by the RFC editor note. Thank you.
1) I tend to agree with Stephen's suggestion wrt the abstract.
2) s4: I think it would be clearer if you said:
Section 4.5 of [RFC2460] and Section 4 of [RFC5722] are updated to include
the following new checks:
This draft is just adding new checks right ;)
From Simon's secdir review
(https://www.ietf.org/mail-archive/web/secdir/current/msg03710.html):
3) Section 2:
Offset set to 0 and the M bit set to 0.
^^^
RFC 2460 uses the term "M flag", not "M bit".
4) s3, 2nd bullet: is it's the "Destination's Cache" or is just the queue?
5) s4: For consistency: r/{IPV6/{IPv6
6) s4: This is actually more of a question about the new rule text. I'm having
trouble understanding what should happen in the following situation:
* A host has a fragment with fragment identification X in its cache,
with fragment offset 42 and M=1 indicating there are other
outstanding fragments.
* A host has received an atomic fragment (i.e, fragment offset 0 and
M=0) with the same fragment identification X.
* A host never receives any more fragments with the fragment
identification X.
RFC 2460 says:
If insufficient fragments are received to complete reassembly of a
packet within 60 seconds of the reception of the first-arriving
fragment of that packet, reassembly of that packet must be
abandoned and all the fragments that have been received for that
packet must be discarded. If the first fragment (i.e., the one
with a Fragment Offset of zero) has been received, an ICMP Time
Exceeded -- Fragment Reassembly Time Exceeded message should be
sent to the source of that fragment.
Now given the following updated text in section 4:
A host that receives an IPv6 packet which includes a Fragment
Header with the "Fragment Offset" equal to 0 and the "M" bit equal
to 0 MUST process such packet in isolation from any other packets/
fragments, even if such packets/fragments contain the same set
{IPv6 Source Address, IPv6 Destination Address, Fragment
Identification}.
The atomic fragment should be dealt with in isolation, so it is reassembled
immediately. Now, after 60 seconds, what should the host do? Should it send
an ICMP Time Exceeded or not? It has already completed assembly but it is also
waiting for more fragments.
draft-ietf-dhc-secure-dhcpv6
The Gen-ART Review by Francis Dupont on 20-Feb-2013 raised a major issue, and I have not seen any response from the authors. > > Major issues: the proposal fails to provide the expected security, > in particular it does nothing real against replay and the basic > function (anti-spoofing) relies on pre-configuration.
I don't get why a client would use this - if the client generates a CGA then why does it even use DHCP? (If that's mentioned already in one of the other discusses I'm happy to make this a comment - will check when I've time.)
- I agree with Sean's discuss based on Steve Kent's thorough secdir review. - My suggestion for how to fix this is to cut it down to server authentication only (or possibly server and relay authentication only); get rid of the idea of clients using this; make the leap-of-faith much clearer, and fix the crypto protocol issues from the secdir review. Such a spec could be quite useful. - I made the same point as my discuss above in relation to another (now-dead?) draft from the same authors. [1] [1] https://datatracker.ietf.org/doc/draft-ietf-csi-dhcpv6-cga-ps/ballot/#stephen-farrell
Question: 5.2 and 5.3: Is it normal practice to have a separate "Padding" field displayed in the data structure and defined instead of just defining Signature as "padded with zero to an octet" or something like that? It's just an odd way to say it. And a couple of nits: 6.1, paragraph 2: The node MUST have -> The node needs to have 6.2, paragraph 6 & 7: MAY record -> can record 8, paragraph 1 and 2: MUST be assigned -> have been assigned (or the last could be "will be assigned" and IANA and the RFC Editor can update the text when they're done)
A COMMENT from the OPS directorate review, take or leave it, but I wanted to share it. Readability of the document could be improved by adding an acronym section and by adding diagrams to the introduction section showing the various network configurations, with and without the relay element.
This is a fine idea, and I support it -- certainly no objection to the document in general. I have two things I'd like to discuss first: -- Section 5.2 -- In the definition of Key Hash, you say it's from the "hash value of the public key used for constructing the signature." I presume you mean the "hash value of the public key from the public/private key pair that was used for constructing the signature," because the signature is made with the private key, not the public one. -- Section 6.2 -- I don't understand the purpose of the Key Hash field. It appears to be for some pre-verification that the key you need to use to verify the signature is the one you have and intend to use. But it doesn't appear to help you select the right one -- you either have the right one or you don't. Why is this useful; why doesn't the receiver just verify the signature with the public key it has? What's the point of checking the hash first?
A few non-blocking comments that I think will improve things: -- Section 4.2 -- I find the first two paragraphs and their lead-in to the third to be convoluted and confusing. I also think the first two paragraphs are unnecessary, so maybe the best answer is to do something like this: OLD Hash functions are the fundamental security mechanism, including CGAs in this document. "...they have two security properties: to be one way and collision free." "The recent attacks have demonstrated that one of those security properties is not true." [RFC4270] It is theoretically possible to perform collision attacks against the "collision-free" property. Following the approach recommended by [RFC4270] and [NewHash], recent analysis shows none of these attacks are currently possible, according to [RFC6273]. "The broken security property will not affect the overall security of many specific Internet protocols, the conservative security approach is to change hash algorithms." [RFC4270] However, these attacks indicate the possibility of future real-world attacks. Therefore, we have to take into account that attacks will improved in the future, and provide a support for multiple hash algorithms. Our mechanism, in this document, supports not only hash algorithm agility but also signature algorithm agility. NEW Cryptographic hash functions and signature algorithms that are accepted as secure today are likely to show weaknesses in the future, as computer systems get faster and attacks become more sophisticated. It is, therefore, important to provide algorithm agility: the ability to easily replace these algorithms when necessary. Our mechanism, in this document, supports both hash algorithm agility and signature algorithm agility. END -- Section 5.2 -- In the definitions of HA-id, SA-id, and HA-id-KH, you give registry names from which these values come: "The value is from the Hash Algorithm for Secure DHCPv6 registry in IANA." "The value is from the Signature Algorithm for Secure DHCPv6 registry in IANA." It would probably be useful to say that those registries are newly created in this document. I think it's sufficient to do that with a forward reference in each case: "The value is from the Hash Algorithm for Secure DHCPv6 registry in IANA (see Section 8)." -- Throughout -- Please make sure your capitalization for "Relay-Reply" and "Relay-Forward" is consistent (I see "Relay-reply" and "relay-reply" as well, for example). The RFC Editor will raise this, and it's better to fix it now rather than wait.
I think the proposed approach is a good one and support seeing it published. I do have some issues that I would like to get ironed out... 1) The discussion on the server-relay-client seems incomplete. For example, do I need to include a Signature-Option *per relay* if I have a chain of relay agents? Are the processing rules affected by such chaining? 2) It is unclear how feasible the following assumption is : "the receiver has already been have the CGAs of the sender, which may be pre-configured or recorded from previous communications". In an enterprise environment, I can see this assumption being valid, but not for a Wi-Fi hotspot scenario (where this type of solution would improve things dramatically). It would be good to clearly state what assumptions have been made in this solution.
From the secdir review: The document does not provide a thorough system-level description of how the security mechanisms are to be used, and how clients, servers, and relay agents might need to be configured accordingly. For example, if the primary focus is thwarting fake DHCPv6 server attacks, then a client might not need to signature a query directed to a server. On the other hand, if the goal is to enable servers to selectively provide service to clients, e.g., based on cached CGA values, then a client would need to sign a query. The document needs to provide additional background in this regard, to enable readers (and implementers) to understand what features need to be present in system components making use of these security mechanisms. A description of local configuration variables that can be used to achieve the desired system-level behavior is needed. Section 4 describes the proposed mechanism. The section states the assumptions that underlie use of CGAs in this context, but it does so in a confusing manner. The use of CGAs provides intrinsic authentication of the sender of a signed message, in terms of the IPv6 address of the sender. For DHCPv6 clients, this may be all that is required, but the text does not make that argument. For DHCPv6 servers, clients (and relay agents) simple address authentication does not suffice; a client (or a relay agent) needs to know that the sender of a message is authorized to act as a server (or relay agent). The text is not at all clear on this point, i.e., it fails to state for which entities it is necessary to pre-configure CGA parameters, to enable meaningful authentication (and authorization). The text here states an exception to the need for pre-configuration saying that an entity could have “ … recorded [the parameters] from previous communications.” This leap of faith (LoF) key management approach is discussed again only in Section 7. The discussion there is superficial. More text is needed to explain when LoF may be viewed as appropriate, and to address issues such as how a client that acquired a server’s CGA would transition to a new server CGA, securely. Section 4 ends by noting that the “authentication options” (presumably the signature option) can be used to counter replay attacks. This is not quite accurate, i.e., it is the integrity aspect of the signature that provides a basis for anti-replay mechanisms, vs. the authentication aspect. More worrisome is that fact that there is no later mention of anti-reply in the document. The authors need to add text discussing anti-replay in this context. Section 4.2 discusses algorithm agility, but does so only for hash algorithms. This section needs to be expanded to discuss signature algorithm agility as well. Also, the text here states that “mainly unilateral notification” is the means by which an algorithm change is made known to a peer communicant, but that not all senders in a network need to transition to a new algorithm at the same time. This section needs to describe how an orderly transition to a new algorithm can be effected in a network. For example, one might add an option that a sender could include in a message, indicating a preferred list of algorithms (signature and has) that it supports. This would enable a server to know whether clients are prepared to transition to a new algorithm. Section 5.2 defines a signature option. There is a timestamp here, which is present to help “reduce the danger of replay attacks.” However, the processing rules for a receiver (Section 6.2) make no mention of this timestamp. This mismatch needs to be fixed. The description of what data is protected by the signature is a bit complex to follow. A diagram is needed. A padding field is defined, but there is no mention of what padding bits are to be used. Section 5.3 defines a signature option for relayed replies. It is used to enable encapsulation of a reply that passes through one or more relay agents, so that there are separate signatures for each agent and for the target client. The description here is not clear to me, especially if there is more than one relay agent. Sections 6.1 and 6.2 provides processing rules for senders and receivers, respectively. This is a very good structure, but, as noted above, some details are missing, e.g., there is no mention of timestamp use. (If timestamp processing rules are defined elsewhere, e.g., 3515, then this text should include the relevant cite). The description of when the CGA, Signature and DUID options MUST and MUST NOT be used is sufficiently complex that a table needs be included. There is a reference to an Authentication Option near the bottom of page 11, but none is defined in this document. The opening discussion for Section 6.2 is confusing when it discusses how a Secure DHCPv6 “enabled” receiver might, or might not, discard messages that omit the CGA and Signature options. The authors may need to distinguish between a receiver that is Secure DHCPv6 “capable” vs. “enabled” to clarify what they mean. Maybe the purported source address of the sender plays a roll here as well. Discarding a packet for which the required options are absent is a SHOULD, here. But, near the bottom of page 12, there is text that says a packet that does not pass all of the checks MUST be discarded. These two statement need to be reconciled. There is no discussion of how a receiver verifies that a message is from an authorized server or relay agent, e.g., by reference to pre-configured CGA data. There is no discussion of when a receiver should cache CGA data for future use, despite an allusion to this possibility in Section 4. These topics must be addressed if the processing rules are to be considered complete. The “minbits” description is bit confusing, as its name specifies a minimum key size, but the description discusses both min and max key sizes. Also, this variable needs to be augmented with an algorithm ID, so that it is clear to which algorithm the key size applies. The security considerations section states that “… clients should be pre-configured with the DHCPv6 server CGA.” This seems important enough to be “SHOULD” vs. “should.” Similar language is used to describe the need to pre-configure CGAs for relays and servers, and it too needs to be stated more firmly. In both cases the text states that how secure pre-configuration of CGAs is achieved is out of scope. Later in this section the authors suggest that a leaf of faith (LoF) approach to acquisition of these CGAs by clients may be a reasonable alternative to secure distribution of server CGA values. This suggestion ignores the issue of how a key change for a server will be accommodated, or how the addition of a new server would work. Absent a discussion of these issues, the LoF suggestion seems questionable. This section contains a brief discussion of collision attacks against hash functions, and why the current levels of attacks are not a serious concern in this context. Hash functions, per se, do not have a “non-repudiation feature” so I think the text here should be improved. Discussion of the hash function security in the SeND context seems relevant. As noted earlier, the test in 4.2 that talks about why hash functions are adequately secure for this context should move here, and the redundancies should be removed.
Also from the secdir review: Section 3 provides a very brief discussion of the vulnerabilities associated with unsecured DHCPv6, and then reviews the security mechanisms offered in RFC 3315. It notes that the symmetric key management approach offered in 3315 is difficult to manage, a conclusion with which I concur. However, the authors overstate the simplicity of their proposed approach, deferring to the Security Considerations section a discussion of public key management. Section 3 notes that 3315 suggests use of IPsec to secure communications between servers and relay agents (or between relay agents), but dismisses that approach due to complexity. I am less sympathetic to this statement. IPsec is already implemented in all major operating systems, so an argument about its complexity, relevant to a set of proposed new mechanisms, is not especially relevant. Perhaps the authors intend to argue that management of IPsec for this application is more complex than their proposed solution. If so, I suggest that the text in bullet “c” of Section 3 be revised. Much of the text in 4.2 should be moved to the Security Considerations section, as it is motivational material not describing the working of the protocol. Section 6.3 describes special processing performed by relay agents, above what is described for them as senders and receivers, in the preceding two sections. Because relay agent processing has already been discussed in 6.1 and 6.2, the additional text here seems confusing to me. The closing paragraph is especially confusing to me, but maybe DHCPv6 experts will find it understandable.
draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt
- Section 2 says that "...it can be used along with other identifiers to associate DHCPv4 and DHCPv6 messages from a dual stack client." Why would this be needed? (Saying "lawful intercept" is not a good answer here.) I think it'd be useful to provide a non-LI reason for why this is useful. - Section 7 could usefully note that if IPsec is not used then anyone who can see packets sent between the relay agent and server with this option, or anyone who can see a log that contains this options's value, can probably track the client in a new way. That'd be a privacy issue so yet again motivates use of IPsec but also motivates not logging this option value, or at least considering security and privacy when doing that.
I have one point to clarify: Section 4., paragraph 1: > DHCPv6 Relay agents which receive messages originating from clients > (for example Solicit and Request, but not, for example, Relay-Forward > or Advertise) MAY include the link-layer source address of the > received DHCPv6 message in Client Link-layer Address option in > relayed DHCPv6 Relay-Forward messages. The DHCPv6 Relay agent > behavior can depend on configuration that decides whether the Client > Link-layer Address option needs to be included. What happens if the client has already included such an option on its own? Are clients allowed or not allowed to add such an option? This isn't specified explicitly.
s2: r/For e.g./For example, ;) s7: I agree with Stephen's point about the need for a new privacy consideration.
draft-ietf-geopriv-flow-identity
This is borderline for me, but I am trying to understand how an existing deployed implementation of RFC 6155 handles the case that a protocol element it is using has been deprecated. More importantly, how a new implementation handles receipt of a now-illegal protocol element. I understand that the change is "before, we said you could do this, but we have discovered that you can't get it through some NATs, so don't." but it seems to me that the problem is not with all NATs, and anyway, not all circumstances inevitably involve the presence of a NAT. So surely there will be some deployments using the deprecated feature that are operating just fine and will find this deprecation at least inconvenient. You can probably resolve this by adding a short section on backwards compaitiblity noting: - that deprecation means that new implementation MUST NOT, but that existing implementations MAY continue - that new implementations SHOULD continue to receive and process
I had a chat with Robert where he conviced me I was mistaken about some of this. (1) Can we add the following (or similar) to section 6: "This specification assumes that the LIS already has access to the internal state of e.g. a NAT and so can usefully map the flow information to locations. If the LIS did not have access to that internal state then sending the flow information to the LIS would represent an additional privacy exposure for the client." (2) cleared, now a comment
- I had a security discuss on this draft but Robert convinced me there was no problem so I'll record it here as a comment. The potential problem would be if a bad actor could ask about flows and received "no information" for non-existent flows but "unauthorized" when the bad actor stumbled onto an existing flow. Robert told me that in that case the bad actor will get "unauthorized" all the time so its not a problem. - general: how (if at all) would this be affected by shared address space? (I ask since you say this is motivated by CGNs.) - section 3: Interesting that the example on p5 looks like its not something from which you could (by itself) determine a specific location. Where does it explain how you could determine a location based on that info? - section 3: I was confused on 1st reading by the last para here - I thought you were saying that the src/dst elements from the example were attributes, might be worth saying that src is both an element name and an attribute value or something. - 4: The "layer3" attribute just seems broken since it assumes both ends of the flow are using the same address family and they might not. - 4: I guess the layer4 attribute might be broken by an ALG. I'm also not sure how tcp or udp will really help there. - 4: What'd you put in layer4 if using e.g. SCTP/UDP? Don't you need to say? - 4: I don't get what it might mean if I put in number for a port that's usable with either tcp or udp, e.g. 53. Its just hard to believe there are no tricky combinations based on use of port numbers that'd need explaining. I've gotta say: given the above comments, and that this is deprecating a feature from a pretty recent (2011) but presumably now known-faulty RFC, and that there are no known implementations (inferred from the write-up), and that this'll be referenced from other "national" specs, I'd be quite nervous that this isn't fully baked and might have to be fixed yet again after someone does write code and try it out.
In support of Stephen's DISCUSS points abut security and privacy, i.e., I did also wonder if nothing has really changed.
I support Stephen's discuss.
draft-eastlake-additional-xmlsec-uris
The Gen-ART Review by Suresh Krishnan on 23-Feb-2013 raised two concerns about the language associated with MD5. In addition, I have a concern with the language associated with SHA-384. In Section 2.1.1, the following text is a bit misleading as it looks like this document is taking a stance on the use of MD5: > > Use of MD5 is NOT RECOMMENDED [RFC6151]. > Suresh proposed this rewording, and I agree with it: > > Please note that the use of MD5 is no longer recommended for digital > signatures [RFC6151]. In Section 2.3.1, the following text is concerning to me: > > Because it takes roughly the same amount of effort to compute a > SHA-384 message digest as a SHA-512 digest and terseness is usually > not a criteria in XML application, consideration should be given to > the use of SHA-512 as an alternative. > There are more criteria than hash size when selecting a hash algorithm. This is just one consideration, and this advice ignores all other aspects of the decision. Note that Suite B that is being advocated by NSA uses SHA-384 (not SHA-512) at the higher of the two security strengths. So, I suggest that a more complete picture be included or that this advice be removed. In the Security Considerations, this test duplicates the RFC 6151. > > Due to computer speed and cryptographic advances, the use of MD5 as > a DigestMethod or in the RSA-MD5 SignatureMethod is NOT RECOMMENDED. > The cryptographic advances concerned do not affect the security of > HMAC-MD5; however, there is little reason not to go for one of the > SHA series of algorithms. > I think that a warning might be better. For example, this text comes from RFC 2630: > > Implementers should be aware that cryptographic algorithms become > weaker with time. As new cryptoanalysis techniques are developed and > computing performance improves, the work factor to break a particular > cryptographic algorithm will reduce. Therefore, cryptographic > algorithm implementations should be modular allowing new algorithms > to be readily inserted. That is, implementers should be prepared for > the set of mandatory to implement algorithms to change over time. > Taking the ideas from this paragraph from RFC 2630 and a reference to RFC 6151 seems like a very good way to make the point about MD5 and make it clear that all algorithms age.
The subject material of this document is so far from my competence that I will rely on the Security ADs to provide the necessary reviews. I have a meta question for them which is: does the publication of this document as a PS imply IETF endorsement for the use of these algorithms? And wouldn't it be easier to turn this into an IANA registry to avoid frequent updates? While reading the document, I found a few nits and questions: --- Section 1 Informational or Standards Track documents Is that s/documents/RFCs/ ? --- Section 1 All of these are now W3C Recommendations and IETF Informational or Standards Track documents. The table that follows is ambiguous since it looks like maybe [XMLENC] does not have an RFC equivalent. --- Section 1 s/[XMLENC}/[XMLENC]/ --- Section 2.1.5 NIST has recently completed a hash function competition for an alternative to the SHA family. The Keccak-f[1600] algorithm was selected [Keccak]. This section is a space holder and reservation of URIs for future information on Keccak use in XML security. I really don't understand this! It seems to say - Here are the URIs for SHA-3 - NIST says don't use SHA-3 - This document will be updated to include URIs for Keccak. That seems odd to me. Why not: - Include URIs for SHA-3 but say you expect their use to be deprecated soon - Include a separate section for Keccak - If no URIs yet exist for Keccak, then don't include them. --- 2.2.1 Although cryptographic suspicions have recently been cast on MD5 for use in signatures such as RSA-MD5 below, this does not affect use of MD5 in HMAC [RFC6151]. "suspicions" seems to rather underplay the situation, doesn't it? The last paragraph of Section 2 of RFC 6151 says it all.
I don't get why RIPEMD, Whirlpool, ESIGN, PSEC-KEM and SEED are all included, I do see some were in 4051 but I don't know that any "substantial" community makes use of each of these. I think that you therefore need to include a statement something like: "Inclusion of an algorithm in this document has no implication that the authors or the IETF consider those algorithms fit for any purpose. At present, specific protocol documents specify the algorithms that are mandatory to implement for that protocol. As security considerations for algorithms are constantly developing those are also documented in relevant protocol specifications. This specification therefore simply provides the URIs and defines relevant formatting for when those URIs are used."
- general: it'd be far better if you could include test
vectors for more/all algorithms.
- I think this document needs to be, but is not, clear as to
whether its making any new RECOMMENDations regarding use or
non-use of algorithms for IETF applications that make use or
URIs for algorithm identifiers. If it is makeing new
recommendations then more review would be needed. If its just
listing the URIs and making comments in passing, then the use
of 2119 terms for innovative algorithm recommendations is not
appropriate and nor are qualitative assessments of algorithm
strength. If you want to make new recommendations then I think
we need text that says that explicitly and a new IETF LC that
makes that clear. If you want to just have an inclusive list
of well-defined URIs (which I think is better) then some text
changes in sections listed below are needed. Note that if
some existing IETF consensus document has already got 2119
terms about use of an algorithm then its perfectly fine to
quote that, e.g. say that "RFC foo, section bar, says that
'MD5 is NOT RECOMMENDED for use in signatures'" etc. but I'd
like all such statements to be quotes so that we know that
we're not innovating here, without proper review. These are
the places I spotted that need looking at based on the above:
- 2.1.1 "NOT RECOMMENDED"
- 2.6.3 - "the implementation of camellia is OPTIONAL"
- 2.6.2 - please delete claims that camellia is "efficient
and secure" or else add similar descriptions to all other
sections. (Same for SEED in 2.6.5)
- 2nd para of section 6
- intro: what is the definition of "substantial interest"
which seems to be used as the criterion for inclusion here? I
think that'd be better changed, e.g. to say that you're aiming
to be inclusive here, but that that has no significance in
terms of algorithm strength or suitability.
- intro: refers to "Draft Standard" which doesn't exist any
more. The reference is historical but maybe ought be fixed?
(I don't care much, but maybe someone does.)
- intro: I'd suggest you add the example that sha-256 is
defined in XMLENC (5.8.2) and hence is not here.
- 1.1, I think you could say here that this isn't innovating
in terms of alg strength etc and that all 2119 terms on that
topic are just quotes from existing RFCs.
- 2.1.1 and elsewhere: when you say that the encoding of the
output "shall be" something, is that intended as a 2119 term?
I think it ought and would be better as SHALL (or MUST) since
people do get these subtly wrong all the time.
- 2.1.1 and elsewhere: you assume I know what a DigestValue
element is. Maybe you ought say that camel case element names
are all from either xmldsig or xmlenc (or whereever they are
from). That's almost obvious enough, but you never know there
might be another DigestValue definition somewhere else that'd
confuse someone.
- 2.1.2 - suggest adding a reference to where sha-256 is
defined in XMLENC. Similarly for 2.1.3
- 2.1.5 - wouldn't it be better to make NIST's sha-3 FIPS a
normative reference and add the details needed here for base64
encoding of outputs and just let this wait on the FIPS to
issue before the RFC does? If not, won't someone have to do
that then anyway?
- 2.3.7 - the title of this section is wrong since it doesn't
only define sha-1 stuff
- 3.2 - I assume retrieval is via HTTP - where's that stated?
Is the "Type attribute" mentioned in the last sentence meant
to be a Content-Type or what? I think you ought clarify.
- wouldn't section 4 be better put into an IANA registry? Why
not?
- references: XMLENC 1st URL gives a 404, why not just use the
2nd?
h
No really sure why the acknowledgements section is in the front? I thought that we had guidelines for section order somewhere, but I can't find them right now... So this comment is more about my own question: do we actually have requirements regarding the sections order? I'll shoot an email now to the RFC editor notes. Note: RFC 4051 had the acknowledgements section at the usual place.
I agree with Adrian and further wonder why, if we need an RFC, this document does not simply update RFC4051 rather than apparently duplicating much of its material.
draft-ietf-tcpm-proportional-rate-reduction
The Abstract is quite long. I propose a shorter version: This document describes an experimental Proportional Rate Reduction (PPR) algorithm as an alternative to the traditional Fast Recovery and Rate Halving algorithms. These algorithms determine the amount of data sent by TCP during loss recovery. PRP minimizes excess window adjustments and the actual window size will be as close as possible to the window size determined by the congestion control algorithm.
I appreciate this work and the open presentations of the results of experimentation. However, the document left me feeling that this was an Informational report on an experiment rather than an Experimental document where you wanted the IETF to participate in the Experiment. The former is very useful, but would need the status to be changed to Informational. The latter, would, IMHO be a far better thing. To get there you need to describe the experiment you want to be undertaken, the limits and risks (can it be done on the Open Internet? do both ends need to know that the experiment is happening? are there interactions with other algorithms in use through congested areas?), what feedback you are looking for, and how/when the experiment will be judged. While this sort of explanation has not been conventionally present in Experimental RFCs, I believe including it makes life simpler and clearer for everyone.
- " RFC 793: snd.una": too terse - Is it PRR+SSRB or PRR-SSRB? Using only one consistently is better. other typos: p3, s/slight difference/slight differences/ p3, s/discussions algorithms/discussions of algorithms/
The protocol itself seems buried in the definition of DeliveredData in section 2, and the pseudo-code in section 3. I really think you should separate out the description of the protocol. Getting independent interoperable implementations from the current document is likely to be difficult. I agree with Adrian that this needs a bit more to be Experimental. The information in the document is helpful, but probably overkill for a specification of this sort.
See Nevil's Brownlee's feedback (OPS Directorate)
- - - -
1. Is the specification complete? Can multiple interoperable
implementations be built based on the specification?
The Proportional Rate algorithm and two reduction bound algorithms
are described in some detail, with C source code and explanations
of what the variables represent. I believe there's enough detail
to implement PRR-SSRB (PRR with Slow Start Reduction Bound) from
this draft.
2. Is the proposed specification deployable? If not, how could it be
improved?
The draft doesn't consider this, however I see no reason why a TCP
sender using PRR would not interwork properly with other TCP
implementations, e.g. TCP Reno. It would be good to see some comment
in the draft to say that, or - better - reporting on such an
interoperability test.
3. Does the proposed approach have any scaling issues that could
affect usability for large scale operation?
No.
4. Are there any backward compatibility issues?
No, but see (2) above.
5. Do you anticipate any manageability issues with the specification?
Since this draft proposes an update to TCP, it will be implemented
in Operating Systems. Site managers will need to be aware of which OS
versions that use it, as one more thing to check on should any
TCP interoperation problems manifest themselves.
6. Does the specification introduce new potential security risks or
avenues for fraud?
No.
A few typos:
- Early in the draft PPR is often used when it should be PRR
- last para page 4:
missing comma, s/of RFC 3517 we are/of RFC 3517, we are/
s/General discussions algorithms/General discussions of algorithms/
- section 4 last para:
s/Bound in very appealing/Bound is very appealing/
I agree with Adrian this has more of an "Informational" feel about it.
draft-harkins-brainpool-ike-groups
The use of the Internet Key Exchange (IKE) registry by protocols other than IKE is not a good idea. This overloading results in new registry entries that cannot be used by IKE, and it leads to implementer confusion for IKE as well as the other protocols that use the IKE registry. That said, the overloading of the IKE algorithm registry has been going on for too long to easily correct now. For that reason, I am not blocking the addition of these entries, but I want to strongly discourage future overloading of any algorithm registries.
I agree with the principles in others' Abstain positions and with Pete's notion that some of the text from Russ's position should appear in an IESG Note. I think that if the registry is indeed already overloaded, and if the community and sponsoring AD do think it's the right thing to do at the moment, it does seem odd to suddenly draw the line here, and block this from happening with too many Abstains ... thus I'm balloting No Objection.
- Intro: Would it make sense to add a bit more text e.g. saying "these were generated by <foo> in <20xx> and have been widely used since then by <bar> and papers [refs] on their goodness have been published by <baz>, technial details of all of that can be found in [EBP] and 5639." You do almost but not quite say that kind of thing. - Section 2 nitty nits;-) I'm sure anyone who'd implement would not need these clarified, but you never know... - its confusing to say "x,y" are the co-ordinates of the generator G when x,y are used in the equation of the curve just above. Wouldn't it be better to use e.g. x(P_0) as used in [EBP]? - you don't say what group you mean - you don't say that h or z are for (z is explained well enough at the end of section 2 though) typos: - s/varient/variant/ - s/arithmatical/arithmetic/ I think or maybe arithmetical but the RFC editor should know;-) - And finally: I didn't check the values are all correct vs. [EBP] or 5639, though I did compare a few bits. I sure hope someone has:-)
If this registry is obsolete, perhaps we should strengthen the note that appear on the registry: these values were reserved as per draft-ipsec-ike-ecc-groups which never made it to the RFC. These values might be used by some implementations as currently registered in the registry, but new implementations should not use them. The note doesn't explicitly say, "This is obsolete. It remains here for historical purposes only and should not be used." Having this document update the note on the registry seems like a good thing to do. Also, it seems to me that some of the text in Russ's Abstain should appear in an IESG Note in this document. There should probably be explicit text in the document that this is a "bad idea".
What Russ said. This is the right thing to do in this case at this time, but is the wrong thing to do in general.
Please see Russ' Abstain position. This is a unique situation, and the pattern should not be followed.