IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2014-09-18. 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: (none)
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
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:
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
Telechat:
3.2.2 Returning Items
Telechat:
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:
3.4.2 Returning Items
Telechat:
1217 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
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat::
7. Agenda Working Group News
1225 EDT Adjourned
(at 2014-09-18 07:32:25 PDT)
draft-ietf-netmod-snmp-cfg
Though a YANG model for SNMP feels a little self-referential. Do we have a NETCONF MIB, just for completeness? ;)
- 2.7: I wondered if this gatewaying would change the security considerations for SNMP proxies? (Not that I really know what those are, but combining g/ws and proxies is often a way to create new vulnerabilities.) - 2.10: "However, the localized key can be changed. This implies that if the engine id is changed, all users keys need to be changed as well." Can you explain that a bit more? It doesn't sound so good, but I'm not sure if its avoidable or not. And I don't think that paragraph is clear as-is to be honest. - 2.12 (and more generally): I had a look at this and how it maps to RFC6353 and it wasn't entirely clear to me how the client|server-fingerprint here mapped to a 6353 implementation. For example, is the fingerprint a fingerprint of the SubjectPublicKeyInfo (as used in DANE and elsewhere), or of the full cert? Similarly can it be a fingerprint for an end-entity cert or of any or a particular CA in a (or any?) chain that certifies the client cert? I think most of this is somewhere here or in the refs but just wanted to check. - 2.12: (and more generally) Did the WG consider the kinds of issue that the websec WG considered for HTTP pinngin? For example, HTTP pins allow for a backup pin in case you brick your site and the same might (or might not) be useful here. - Should (or are) some or all of the 2.x things mandatory to implement? That wasn't clear to me.
-- Section 4.1 -- identity san-rfc822-name { base cert-to-name; description "Maps a subjectAltName's rfc822Name to a name. The local part of the rfc822Name is passed unaltered but the host-part of the name must be passed in lowercase. This mapping results in a 1:1 correspondence between equivalent subjectAltName rfc822Name values and name values except that the host-part of the name MUST be passed in lowercase. For example, the rfc822Name field FooBar@Example.COM is mapped to name FooBar@example.com."; reference "SNMP-TLS-TM-MIB.snmpTlstmCertSANRFC822Name"; } The repetition in here, and the two different "must/MUST be passed in lowercase" seems odd. Can this be reworded to say the same thing but remove the odd repetition?
Section 4.10: I know the term "privacy" is used here to match how it's used in RFC 3414, but given that we now know that privacy can be about many things beyond confidentiality, I'm wondering if it's possible to have the language here match that current understanding a bit better, e.g.: s/"when privacy is used, authentication must also be used";/"when privacy (confidentiality) is used, authentication must also be used"; If the container could be called "confidentiality" rather than "priv" that would be good too.
draft-ietf-dnsop-child-syncronization
Point 1-- 2.1.1.1 doesn't talk about SOA serial number overflow. It's not clear to me that the security goal intended by this section is correctly addressed if the implementation assumes that the comparison operators defined in section 3.2 of RFC 1982 are used, rather than doing a simple unsigned compare. I don't think there's a clearly correct answer here, but the issue should be documented and, ideally, a choice should be made. To clear this DISCUSS, the document needs to say which of the two sets of comparison operators apply, and needs to explain how serial number wrap events are accounted for (or that they are not accounted for, and this is an open issue with security implications). The easiest way to fix this would be to require a comparison for equality, but I realize that this would place an additional burden on implementations which may be impractical. Point 2-- In 3.2.1, you don't say what to do if the name server returns an NS record listing names queries on which result in NXDOMAIN, or for which neither A nor AAAA records exist. Point 3-- I don't think you've specifically excluded RRtypes not mentioned in section 3.2. It's seems obvious to me based on what's stated in section 2 that the intention of the document is to only support these two RRtypes, but I think it is necessary to say so explicitly, if that is in fact what is intended. If something else is intended, text explaining what is intended should be added. E.g., if it's okay for cooperating child name servers to set bits not listed here, and for cooperating parent name servers to process them, you should say so.
In 2.1.2, why SHOULD and not MUST here? Implementations that support parsing of presentation format records SHOULD be able to read and understand these TYPE representations as well. In 3.2.1, what happens if the parent queries a host, and that host no longer appears in the updated NS record? I think this is Mostly Harmless, but might be worth mentioning. Also, in principle if the old server is left running but no longer authoritative, this whole scheme would fail if, for example, it had been the master prior to the change, were not configured to no longer serve the zone, and were no longer being updated. This is probably worth mentioning as an operational consideration.
I have no objection to the publication of this document, but note a couple of nits. --- I'm a pedant, I know, but... Abstract OLD This document specifies how a child zone in the DNS can publish a record to indicate to a parental agent that it may copy and process certain records from the child zone. The existence of and value change of the record may be monitored by a parental agent and acted on as appropriate. NEW This document specifies how a child zone in the DNS can publish a record to indicate to a parental agent that the parental agent may copy and process certain records from the child zone. The existence of the record and any change in its value may be monitored by a parental agent and acted on depending on local policy. END - "...it may..." is marginally ambiguous - "...existence of and value of..." was sufficiently clumsy to cause re-reading - "as appropriate" always rings an alarm bell with me because it actually says nothing :-) (I may be wrong about "...depending on local policy" which would: - prove my point - allow you to substitute your own text. The same paragraph appears in the Introduction. --- Continuing the pedantic theme (don't I have anything better to do with my time?)... Section 1 It has been traditionally challenging for child DNS operators to update their delegation records within the parent's set in a timely fashion. "Tradition"? Image of my grandfather on the roof of his house with violin and DNS server. Maybe just strike the word. Also "child DNS operators" made me giggle unmercifully. Maybe "operators of child DNS zones"? In general, the inclusion of "zone" after "DNS" will help clarify. --- 2.1.1.2 and 2.1.1.2.1. c/Section Section/Section/
[Updating for -03] Sections 4.2, 4.3, and 4.4: The MAYs in there MAY be inappropriate. The ones about providing interfaces sure don't seem like protocol options. On the others it's hard to tell. Please review. The SHOULDs in 4.1 and 4.4 seems also suspiciously wrong.
- general: Couldn't a child ask for its CSYNC record to be published in the parent? (and so on up...) I think you should say a parent MUST NOT take a child's CSYNC in the same way that you say to not use CSYNC for DS RRs. - 2.1.1.2.1: Is the meaning of "blindly" sufficiently clear that all implementers and deployers will get this right? I'm willing to believe you if you say it is.
Adding on to Ted's DISCUSS: The Security Considerations need to make clear that this mechanism MUST NOT be used to synchronize DS records between child and parent (whether this is allowed through the base protocol or some extension). This is because the DS records are the only thing the parent has that allows it to validate all the DNSSEC signatures that it is required to verify -- if an attacker can change the DS record, then it can change any other record it wants to.
Overall, nicely written document. Thanks!
In the definition of the CSYNC Flags registry in the IANA Considerations, you have two conflicting statements: ONE: Assignment of new flag values are subject to "RFC Required" specifications [RFC5226]. TWO: For new assignments to be made to this registry, a new RFC must be published via a Standards Action. Which is it: RFC Required, or Standards Action? They are different (the former allows for Experimental or Informational RFCs, and RFCs in the Independent or IRTF streams; the latter requires a Standards Track RFC in the IETF stream). There's also "IETF Review", which requires an IETF stream RFC, but allows Informational or Experimental).
First sentence in Sec 1 is missing an it: "This document specifies how a child zone in the DNS ([RFC1034], [RFC1035]) can publish a record to indicate to a parental agent that can copy and process certain records from the child zone." ^ it In Sec 2: What does unpunishable data mean in "Errors due to unsupported Type Bit Map bits, or otherwise nonpunishable data, SHALL result in no change to the parent zone's delegation information for the Child." In Sec 3.1: It says " If the SOA serial numbers are equal but less than the CSYNC record's SOA Serial Field [RFC1982], the record MUST NOT be processed." which seems to contradict what is stated in Sec 2.1.1.1 "If the soaminimum flag is not set, parental agents MUST ignore the value in the SOA Serial Field. Clients can set the field to any value if the soaminimum flag is unset, such as the number zero." Perhaps I'm missing a relevant DNS clue?
Thanks for addressing my DISCUSS point.
last call was rerun should be fine.
draft-ietf-6lo-ghc
Has consideration been given to the security impacts of compressing headers withing encrypted payloads? In the context of HTTPS, there have been several attacks that exploited TLS compression in order recover information about secret values. These attacks are possible because the compression used a dictionary that was dynamically constructed based on the content sent over the channel. This allows an attacker to probe for a secret value by sending guesses and seeing if the response is compressed. It seems like the backreference mechanism in this document could have similar repercussions if backreferences were allowed over a sufficiently broad scope. It may be helpful to consult the Security Considerations in the HTTP header compression draft: https://tools.ietf.org/html/draft-ietf-httpbis-header-compression-09
"that can be defined on a single page" - I note that this document is more than one page long, even discounting boilerplate :) It would nice if you would explain where the magical 16-byte dictionary comes from. What do the underscores in Figure 5 mean? If this notation is defined elsewhere, please reference.
- abstract: 23 pages isn't very short:-) - GHC is used before expansion I think. - Has anyone had a look to see if there is a way to craft compressed packets that would be (very) costly on the receiver when decompressed? (As a DoS acceleraor say.) That can be an issue for some compression schemes but I'n not sure if its one here or not. (Sorry, haven't had time to figure that out myself yet, and maybe its quicker to ask:-)
where 0 stands for 0, 1 for 1 I can't tell you how relieved I am to see that. For the purposes of the IANA registry, the bits are numbered in most-significant-bit-first order from the 16th bit of the option onward, i.e., the G bit is flag number 15. A minor thing -- but I had to read the paragraph a couple of times before I got the point this sentence is making: Perhaps... NEW For the purposes of the IANA registry, the bits are numbered in most-significant-bit-first order from the 16th bit of the option onward: the 16th bit is flag number 0, and the 31st bit (the G bit) is flag number 15. END
draft-masotta-tftpexts-windowsize-opt
I don't know how to implement this based on the spec as written. In particular, the meaning of the error markers in the error handling section is completely obscure to me. I've been reading this document and the ones it references over and over again trying to figure out what this means, and maybe I'm just stupid, but I don't get it. Please describe explicitly what these error marks mean, and what is done in response to them. I am not convinced that updating the document to explain this will completely resolve this DISCUSS, because I literally do not know what I am missing, but I think it would be a good first step.
Thank you, Patrick and Joel, for our pre-ballot conversation. It was helpful, and short-circuited a number of points that didn't need to be part of a DIscuss. And for the record, I’m sympathetic to a desire to decrease boot times in the 21st century, and something like this proposal seems a reasonable way to satisfy that desire. My original Discuss would have overlapped Martin’s significantly, so I’m downsizing to a couple of points that I’d like to talk about, to avoid duplication. First (as my Discuss point) - as Joel has stated in various emails, this document does contain a significant number of “health warnings” about where TFTP is appropriate to use, but they are tilted toward (very real) security concerns. I’d suggest text that also points to concerns about congestion behavior. Perhaps something like this, in Section 4: “The windowsize extension is intended for use in managed networks, where any instances of sustained congestion loss will be noticed and corrected. The choice of an appropriate windowsize value depends on the underlying networking technology and topology, and likely other factors as well. This document does not make recommendations for a specific value, and it allows the operator considerable flexibility, with a maximum windowsize of 65535 blocks. Operators are encouraged to test various values, as shown in Section 5. Operators are encouraged to be conservative when selecting a windowsize, because as the table and chart in Section 5 shows, the benefit of continuing to increase the windowsize is subject to diminishing returns. Operators are encouraged to consider the possibility of events such as power-on/avalanche restarts, when a large number of clients may issue Read Requests to reboot within a small interval of time.” I think I'm capturing points that we've chatted about in e-mail already, But please rephrase as appropriate.
Second - and I emphasize this is a question, not an assertion - I keep hearing about distributed multi-tenant data centers, where a data center operator might rehome a significant number of virtual machines from one data center to another that’s an arbitrary distance away. Is that a real possibility? The reason I’m guessing that using this extension with large windowsize values would be significantly safer in the same rack than on opposite coasts, and I’m curious what a good strategy would be for an operator to either know that the clients have been moved, or to prevent the clients from being moved while the TFTP server stays.
Thanks for the effort on this document and for going the extra mile. I agree with Spencer that this version is much easier to read, and I find it clear and have no objection to its publication.
Neither of these are showstoppers at all; just suggested improvements: 1. In other protocols, the NULL-terminated thing is something that implementers often miss, so you might want to be really specific about it. I'd suggest: OLD Note that all fields except "opc" MUST be NULL-terminated. NEW Note that the filename, mode, windowsize, and #blocks fields below are all ASCII strings and MUST be NULL-terminated. and then add to each description of the fields, "...as a NULL-terminated ASCII string". 2. Several of the MUSTs in section 3 are superfluous, as they're definitions, not protocol interop instructions: s/MUST be modified/is modified s/MUST contain either a 1/either contains a 1 s/MUST be specified in ASCII/is represented as a NULL-terminated ASCII string s/MUST send an Option Acknowledgment/sends an Option Acknowledgment
Section 7 says: "The use of TFTP is appropriate on networks where the inherent protocol limitations are not a liability." I think that would be better as a negative myself, e.g. maybe something like "The use of TFTP is inappropriate on networks where confidentiality, authentication or access control are needed." (And note that I personally don't think that that means TFTP is safe on all LANs.) However, just deleting the sentence would be fine, since it has little or nothing to do with this extension. Note: I don't feel that strongly about this, so feel free to ignore me. Nothing to do with this draft, but it would be a fine thing if someone were interested doing the work to improve the security of TFTP.
I have those points to be discussed, while being supportive to get TFTP transmitted files faster. 1) This document must clearly state that this extension in its current state is solely suitable for well-mananged and monitored environments, but that it is not suitable to be used across the Internet or any unmanaged IP network. An example for a well-managed and monitored environment is a data center network. The reason for this is that there now back off mechanisms defined to loss. 2) It is not clear to me how this extension is reacting to all kinds of packet loss. Right now, it assumes sporadic losses that require a retransmission of a single or a few packets. However, more heavily losses that require an action from the data sender are not covered. Such a heavily loss could be due to congestion on the network path between both TFTP peers. In short, it doesn't make sense to keep sending large windows, if the network path is congested. My proposal is to half the window-size on losses and potentially, depending on the desired compelixty, to allow an increase of the window size if there is no loss experienced anymore. 3) What is the error handling for this (Section 3, last paragraph): " The rules for determining the final packet are unchanged from [RFC1350] and [RFC2348]. The reception of a data window with a number of blocks less than the negotiated windowsize is the final window. If the windowsize is greater than the amount of data to be transferred, the first window is the final window." You receive a data window with a number of blocks less than the negotiated window but no packet that is shorter than the negotiated block size? 6) It is not clear to me, if the sender is sending a full window out to the network and waits for the successful transmission of the window (or any error), or if the sender keeps constanly sending out new packets, once it does receive an acknowledgment for a non-terminal packet? 5) TFTP is acknowledging each non-terminal packet. I assume this behavior is unchanged also for this extension? If so, smaller windows that slide by each acknowledgment are a nice option to behave well in the network. Especially, as the test results show already a good performance gain with a window size of 8.
- Section 5: " Comparatively the same 180 MB transfer performed over an SMB/CIFS mapped drive on the same scenario took 23 seconds." Well, that is comparing two different things, as TFTP is running over UDP and with lock step or your extension and a control-loop based transport used for SMB/CIFS.
I support Spencer Dawkin's current Discuss, and Martin's Discuss item #1. I am sympathetic to the change that Kathleen proposes, although it is perhaps more with TFTP than this extension. Finally, I'm also sympathetic to Ted's issue, but I think it is easily fixable. Some comments. These are all comments, something you might consider but none of the issues are serious enough to block the document. Fixing them might improve readability, however. Note that all fields except "opc" MUST be NULL-terminated. +-------+---~~---+---+---~~---+---+-----~~-----+---+---~~---+---+ | opc |filename| 0 | mode | 0 | windowsize | 0 | #blocks| 0 | +-------+---~~---+---+---~~---+---+-----~~-----+---+---~~---+---+ I thought this was a bit unclear, should I include a zero byte in the windowsize field for instance, or is the zero byte the one in above diagram already? One or two zero bytes. The number of blocks in a window MUST be specified in ASCII. MUST be specified in decimal in ASCII. The rate at which TFTP UDP datagrams are sent SHOULD follow the CC guidelines in Section 3.1 of RFC 5405 [RFC5405]. It would be REALLy helpful if you pointed directly to the one that should be implemented, e.g., Section 3.1.1. Which I think is the right one.
Thanks for your work on this draft. I have some text recommendations to make sure all of the security concerns are covered. My main points are covered in the proposed text. Security Considerations section: Propose the following change to the first sentence: From: "TFTP includes no login or access control mechanisms." To: "TFTP includes no authentication, integrity protection, confidentiality, or access control mechanisms." Propose text for the first sentence of second paragraph: From: "TFTP includes no protection against an on-path attacker, care must be taken in controlling windowsize values according to provider, requester, and network environment capabilities. " To: "TFTP also does not support session encryption and therefore does not protect against an on-path attacker from active (session hijacking) or passive (monitoring) attacks. Care must be taken in controlling windowsize values according to provider, requester, and network environment capabilities. " I think it's enough to just list monitoring as an example as with TFTP, as it's likely to be a targeted attack and unlikely to be privacy related since it is typically used to do things like update firmware on a local network, etc. Those attacks fit into the general category of monitoring.
Thank you for addressing the comments received int he SecDir review. From the SecDir review, there was a recommendation to include other references in the the security considerations section of this document. One of those was from RFC5405. The first paragraph of that section (altered a bit) could be helpful in the set of warnings given here - basically, use something else if you need any security. I don't think the rest really applies because you'd switch to SFTP or something else rather than layer on security to TFTP in reality. Here is a link to the SecDir review: https://www.ietf.org/mail-archive/web/secdir/current/msg04922.html
I agree that in addition to or instead of specifying where it *is* appropriate to use this extension, the document should say where it's *not* appropriate.
I support the discusses (Martin's, Spencer's, and Kathleen's).
I support point #1 in Martin's DISCUSS. I don't think saying where the protocol is currently used or not is the same as saying where it should not be used. And the reasons it should not be used on some networks are not confined to security, so I don't think the security considerations section should be the only place where this is discussed.
draft-ietf-bfd-intervals
I support Pete's DISCUSS, but can live with it if he doesn't get his way.
Language in the draft should change from proposed to definitive. For example, in Sec 3, "The proposed set of Common Interval values is: 3.3msec, 10msec, 20msec, 50msec, 100msec and 1sec. In addition support for 10sec interval together with multiplier values up to 255 is recommended to support graceful restart. " could become: "This document defines the set of Common Interval values to be exactly: ...."
I do not expect to hold this DISCUSSion for very long, but I do want to have it. The shepherd writeup says: This draft is being targeted for Informational status. While the draft recommends a number of timer values, they are suggested for interoperability while not mandating that any particular value be supported. There was discussion on the mailing list that while the draft was listed as Informational that some customers were likely to take the RFC as a base set of standard values - thus a de facto standard. Consensus of the list seemed to judge that this was okay and provided values that implementors may want to look at targeting as part of their implementations. First of all, the values defined/specified (cf. Alia: not "proposed") in this document are described as "SHOULD support all values in the set". That seems perfectly reasonable, but that's a protocol requirement. ("SHOULD" does not mean "OPTIONAL".) Further, the WG itself is clear that this is likely to turn into a de facto standard anyway. IETF standards are voluntary anyway. If the BFD community has consensus that this is something that SHOULD be supported by 5880 implementations and that implementers are going to do it anyway, why not call it a Proposed Standard, mark it as updating 5880, and move along?
I agree with Pete that it would be better for this to be Standards Track, both from a process-wonk perspective, and from the perspective of actually getting implementers to support these intervals. Also, since I expect many implementers will be skimming this to find out the values (rather than read the explanatory text), it would be helpful to move the numbers up front, put them in a table / bulletted list, or both.
Thank you for addressing the SecDir review comments. https://www.ietf.org/mail-archive/web/secdir/current/msg04994.html
draft-moonesamy-sshfp-ed25519
Thank you for writing and pushing through this document. It is high time that it gets out as an RFC.
This document seems OK on its own, but I'm kind of perplexed that we're pondering publishing it without any spec for how it should be used (!) Nobody has bothered to document how Ed25519 is actually used with SSH. At least not in an RFC, or anything referenced from this document. It seems like this at least needs a reference to some spec for how Ed25519 is used, and probably also needs to update the other SSH registries so that, e.g., there's a defined key format / algorithm name for Ed25519.
A problem was discussed in detail through the SecDir review and I don't see an update in the draft to reflect that discussion. It would be good to understand how to make this interoperable - "there is not enough information in the draft to know what goes into the hash that is the subject of the code point assignment.". If Stephen's okay with not having that included, since the draft is a code point assignment, I won't argue it, but would like to know if the sentence will be added as listed in response to the SecDir review to state that it isn't specified anywhere: https://www.ietf.org/mail-archive/web/secdir/current/msg04831.html > That's a fair point. I propose adding the following text in Section 2 > as a warning to the reader: > > The format of the ED25519 public key with SHA-256 fingerprint is > not documented in an authoritative specification.
draft-dukhovni-opportunistic-security
I think this document needs to state explicitly that opportunistic security is _not_ appropriate in the same set of applications as mandatory security. E.g., we never want "opportunistic security" when connecting to the bank, or doing a credit card transaction. We want mandatory security. I think that is so obvious to the security folks that nobody thought to mention it, but it must be stated in large friendly letters both in the introduction and in the security considerations section, because this document will be read by non-security-geeks. You should also advise that documents that describe implementations of opportunistic security should mention this in _their_ security considerations section. An opportunistically secure protocol that can be MiTM'd to look secure on the server end whilst being in cleartext on the client end would be disastrous in such contexts.
Aside from issues of accuracy, the choice of the phrase "opportunistic security" is unfortunate because it leads to abbreviation as "OS" which is a well known acronym for "operating system," and a slightly less frequently used acronym for "open source." I'm not raising this as a strong objection, because I know this topic was hotly debated during IETF last call, but the arguments I saw during the debate that it's just not that important and can't be fixed anyway fall flat for me because of this problem. Every time I see "OS support" or something similar in the text, I read "operating system support," not "opportunistic encryption support." If you are going to use this term, I think you should get over the wish for brevity and just spell it out. I would call it "opportunistic protection" or something like that to get a better acronym. Nobody's going to read "OP support" as "original poster support". In section 5: When protection only against passive attacks is negotiated over a channel vulnerable to active downgrade attacks, and the use of encryption fails, a protocol might elect non-intrusive fallback to cleartext. An active attacker could equally have suppressed the use of encryption during negotiation, so failure to encrypt may be more often a symptom of an interoperability problem than an active attack. The last sentence doesn't make sense—the first half of the statement doesn't actually imply the second half as a conclusion, as the "so" in the middle would suggest. It implies the opposite. I don't think you are saying anything wrong here, but you need to clean this text up, because as written it doesn't make sense. When the DISCUSS is cleared, I will change this to a no objection, but while I don't necessarily agree with Barry's remedy for the DISCUSS, I do agree with the general thrust of his DISCUSS.
I'm balloting "No Objection" primarily on Stephen's assurance that the text changes in this version of the draft are editorial in nature, and I accept his assertion that continued discussion is unlikely to result in improvements to the document. I suspect that continued discussion wouldn't result in the Internet being more resistant to passive monitoring, either, although I'm not one who has enough security clue to assert that in a meaningful way. I agree with the vast majority of Adrian's detailed comments, and think the document would be improved by considering them. I agree with Stephen's statement that publishing this document in the Independent Stream is unlikely to be helpful.
It is good and helpful, in my opinion, for the IETF to give an explanation of Opportunistic Security and advocate its use. The data tracker currently shows "Consensus: Unknown" and I think that is actually a fair representation of the state of affairs. It is, however, not a state in which we can publish an IETF Stream RFC. Having read a lot of the email thread resulting from IETF last call and looked at the changes in the last few revisions I conclude that there is general support for the technical content of this document, but that there are a good number of unaddressed issues with the development and presentation of that content. It may be true that addressing those points would not make a substantive difference to the technical ideas in the document, but that does not mean that the document would not be improved by attentive work. At the moment I am sufficiently unclear on the consensus for the publication of this document to be either able to place a Discuss on the absence of consensus or to be able to ballot No Objection. Hence this Abstain. I wish more work had been / would be done to build consensus or that the document was advanced either as "published without consensus" or on the Independent Stream. ========== I have spent too long hanging around with sales staff and this has made me over-sensitive to the use of language that smells of marketing. I apologise for any over-reaction on my part, but I presume that the purpose of publishing the document is to deliver a useful and clear statement, so I think that polishing might not be a waste of time. If I was entering this Comment as part of IETF last call I would expect a reasonable discussion of the cost/benefit of not changing the text to address my thoughts. But, obviously, I am not. Furthermore, I am not raising these points as Discusses so you can work through them with your shepherding AD and ignore me if you think that I am wrong or that the effort is not worth the results. - - - - Abstract... Protocol designs based on Opportunistic Security remove barriers to the widespread use of encryption on the Internet by using encryption even when authentication is not available So, this says "remove barriers to X by using X". I think there is probably something additional you need to say before this sentence. For example, "Most approaches to the use of encryption on the Internet depend on the use authentication to foo. This makes encryption unattractive because bar." --- Introduction Broadly speaking, Opportunistic Security (OS) is a pragmatic risk management approach. "pragmatic" is redundant in the description of "risk management". "...approach" to what? --- Introduction With Opportunistic Security, one applies the tools at hand This implies to me that no changes or modifications to protocols are needed to achieve OS. I don't believe that is true. --- The definition presented in Section 1 is OK as far as it goes, but isn't it missing also the existence of the capability in the protocol itself? Isn't a fundamental part of OS that the operation of encryption can be without manual keying and therefore without the configuration of security adjacencies? I think that what is missing from this document, and possibly from this definition, is a description of why security (specifically encryption) is not widely used in the Internet today. It is also a little questionable to me what is "opportunistic" in this definition. You seem to be defining "Best Effort Security". Hey-ho. It's only a name, and just words. --- Introduction Since encryption alone mitigates only passive attacks, this risk is consistent with the expected level of protection. "Since encryption alone..." can be read two ways: 1. Only encryption can do this 2. Using only encryption with nothing else can only go so far I suggest you make some clarification to remove this ambiguity. "this risk is consistent with the expected..." I don't think so. I think the risk defines the level of protection that can be delivered. Expectations need to be set and this document can do so by describing the risks and the likelihoods. --- For authentication based on peer capabilities to protect against MiTM attacks, capability advertisements need to be over an out-of-band authenticated channel that is itself resistant to MiTM attack. I had a lot of trouble parsing the first clause in this sentence. Is it the peer capabilities that can protect against MiTM attacks? Or is it the authentication that does the protection? I think you are saying... In order that authentication mechanisms can protect against active MiTM attacks on capability exchanges between peers, those capability exchanges need to be performed over... But why are you insistent on an out-of-band channel? Surely any authenticated channel that is resistant to MiTM attacks will be good enough? --- OS protocols will attempt to establish encrypted communication whenever both parties are capable of such, and authenticated communication if that is also possible. This last outcome will occur if not all parties to a communication support encryption (or if an active attack makes it appear that this is the case). Is there any element of choice here? The text says not. --- For a particular protocol or application, if and when all but a negligible fraction of peers support encryption, the baseline security may be raised from cleartext to always require encryption. Similarly, once support for authentication is near-universal, the baseline may be raised to always require authentication. I don't know what this means! I think it says that at some moment in time the Internet Police will ban the use of unencrypted use of a protocol or application. Or maybe it says that new implementations can require encryption and refuse to operate with legacy implementations. Or perhaps you mean that the default behaviour should be to try for encryption. Or perhaps you are just talking about what the user can expect. --- The abbreviation "CA" is used without expansion. --- Section 1.1 DNSSEC is not sufficiently widely deployed to allow DANE to satisfy the Internet- wide, any-to-any authentication requirement noted above. Did I miss the any-to-any requirement? I looked back but didn't find it. --- Section 1.1 makes a good case about encryption without authentication being of value. But this seems to be making a different (although equally valid) case from the basis of the document that is about OS. This comes back to the "opportunistic" versus "best effort" thing. --- Section 1.1 The use of encryption defends against pervasive monitoring and other passive attacks (which are employed not only by nation states). The parenthesised text can probably be dropped. It is not a discussion you need to have here. --- Section 1.1 For some applications or protocols the set of potential peers includes a long tail of implementations that support only cleartext. On third reading I got what the "long tail" refers to. How about... For some applications or protocols it is anticipated that the set of potential peers that only support cleartext will persist for a long time. --- Section 1.2 This document proposes a change of perspective. Why is it a proposal in what you plan to publish as an IETF Consensus RFC? I assume you don't really want this to be Experimental. --- I am fine with the concept of opportunistic security and like it. But I think I reject the hypothesis in Section 1.2 that the old world is "expect full security and notify when not achieved" and that the new world is "expect no security and get the best you can." I think the new world is / should be "configure the level of security that is acceptable to you, get at least that security and maybe better, or get notified if it is not as good." This is more subtle than your proposal but involves the user in a way that I think is important. That is, if a user desires security, it is not enough to say "the protocol is designed to get as much security as it can" - the user actually wants to know if the security level is low, and may want no traffic if the security level is too low. This does not reject the idea of OS, but merely the choice presented in Section 1.2. In fact, Section 3 makes these trade-offs pretty clear, so I think that all that is needed is to moderate the language in this section. (Although Section 5 seems to favour some sort of autonomy within the protocol or protocol implementation such that various fallbacks might "just happen".) --- Section 3 OS provides a near-term approach to counter passive attacks by removing barriers to the widespread use of encryption. This is probably true, and definitely a motivation, and not a Design Principle. Not appropriate in this section of the document. --- Section 3 I had to read "Emphasize enabling communication" and the following text a couple of time to extract the right meaning. What you have has two different meanings, and you mean "enablement of" (otherwise "an enabling communication" is inferred). --- Section 5 has... The choice to implement or enable fallback should only be made in response to significant operational obstacles. ...but no mention of who makes the choice for enablement. I think you need that such fallback is never a default action and always requires operator/user intervention since forcing such a fallback sounds like an effective attack. --- One point that I would possibly have entered as a Discuss were I not Abstaining is that I am surprised that there is no discussion of mechanisms that can be used to detect MiTM attacks on unauthenticated encryption key exchanges. Detection is a useful tool since, while it can't help with protection of data, it can at least warn the user to stop relying on the security of the data channel.
I am not done with my review, but in the meanwhile I have question: How does this draft related to the old Better-Than-Nothing Security (btns) working group [1] and their output? [1] http://www.ietf.org/wg/concluded/btns.html
I had a full-out rant prepared about "tracking of issues" and such, but a night's sleep is a good thing. I've decided things are much simpler than that: There were substantive non-editorial changes between -03 and -04, substantive changes that *I* think have damaged the document in a substantive way, and changes about which the community does not have consensus. I believe there are things that need fixing, and therefore discussing. (For those playing at home, I'm hanging my hat on the last bullet of http://www.ietf.org/iesg/statement/discuss-criteria.html#stand-disc for this.) Let's start with the Intro: Broadly speaking, Opportunistic Security (OS) is a pragmatic risk management approach. With Opportunistic Security, one applies the tools at hand to mitigate the risks that can reasonably be addressed, and accepts the rest. This is new text, not an editorial change. I find both of those sentences, and most of the other sentences in the Introduction, completely useless to the task of explaining what is important about OS, and unfortunately I think the Introduction as a whole now makes it *harder* for the reader to understand what OS is. I don't think there is community consensus that the new intro captures the intent. Most importantly: Thus, use of an OS protocol may yield communication that is authenticated and encrypted, unauthenticated but encrypted, or cleartext. I find completely insidious because it damages the message of 1.2: Instead of a build up from a base of cleartext, which I absolutely agree is the way we should be thinking about security and is the essential bit of the OS model, this sentence and the one that follows it reinforce the notion that we start from fully authenticated communication and work our way down, precisely the notion that this document is supposed to be moving us away from. -03 made it clear to me that there was an order to things. It said that there was "stepping up from" cleartext. That text disappeared. In its place, there is the above text that apparently has the steps in the reverse order. The definition of the term in -04 doesn't even refer to the order. I do not remember seeing any discussion in which the participants came to consensus that this discussion of order should be removed. The definition presented in this section also hides this important point. The two essential bits of intro are the first paragraph of section 1.1 (which was once the first paragraph of the document) and the first two paragraphs of section 1.2, and we don't get to read them for another 6 to 15 paragraphs. They need to be moved up and the rest of this new intro needs to be deleted. In section 3: Coexist with local policy: Local security policies preempt OS. Opportunistic security never displaces or preempts local policy. Many applications and types of data are too sensitive to use OS, and more traditional security designs are appropriate in such cases. The title of section 3 is "Opportunistic Security Design Principles". Coexisting with local policy is not part of the OS design principle; it's a caveat to that design principle for times when you should *not* use OS. Again, this undermines the discussion of OS, and I do not believe that the community has consensus that the above is part of the OS design principle. (One overarching point: Others have made comments with other serious problems that need fixing. That's fine. But if the result of addressing my comments or other folks's comments is to *add* more text, you've probably gotten it wrong. The main problem with -04 is the text that it added. Text needs to be deleted and simplified.) This is important work and really needs to be done. In retrospect, I would have preferred to see this work done as a BCP in UTA or as an IAB document instead of simply a definition document. But we are where we are. We need to come to consensus on the text in here. We're not there yet.
Thanks for your work on this draft, Viktor. I have some suggested text to update a few sentences that I would like you to consider. Bottom of page 2, suggested text edit to clarify meaning on the last sentence: Change from: Protection against active attacks requires authentication. The ability to authenticate any potential peer on the Internet requires an authentication mechanism that encompasses all such peers. No IETF standards for authentication meet this requirement. To: Protection against active attacks requires authentication. The ability to authenticate any potential peer on the Internet requires an authentication mechanism that encompasses all such peers. No IETF standards for authentication scales as needed and have been deployed widely enough to meet this requirement. on page 3, I recommend updates to the 2nd and third sentences to more correctly describe the issue with CAs (it's not just one that we all need to trust) change from: With so many certification authorities, which not everyone is willing to trust, the communicating parties don't always agree on a mutually trusted CA. Without a mutually trusted CA, authentication fails, leading to communications failure in protocols that mandate authentication. To: With so many certification authorities, which not everyone is willing to trust, the communicating parties don't always agree on a mutually trusted CA from their respective lists of trusted CAs. Without a mutually trusted CA, authentication fails, leading to communications failure in protocols that mandate authentication. For the terminology section, I do like that OS is defined in the introduction and saw that many provided feedback asking for that to be done. Thanks for making the change. Should there also be a pointer from the terminology section back to section 1 for the definition of OS? Security Considerations section: I'd be happier if the first sentence had a pointer to section 3 so there is context to the statement. Perhaps change from: OS supports communication that is authenticated and encrypted, unauthenticated and encrypted, or cleartext. To: OS supports communication that is authenticated and encrypted, unauthenticated and encrypted, or cleartext (see Section 3. Opportunistic Security Design Principles). Or something similar just to make the point that the purpose of OS is to offer another option between authenticated and encrypted and cleartext as opposed to just saying they are all supported. Side note: Thank you for your work on this draft and partaking in the many discussion threads about the contents of the draft. The discussion on this draft were heated at times and I would have preferred to see more detailed responses to the list on *some* of the threads, those which offered direct suggestions. I think that could have helped the overall tone and interactions for a least a few of the commenters. Some reviewers put in considerable time helping to revise the draft, Steve Kent in particular, and that is very much appreciated. I do think the draft is good enough, but I would like to see my comments addressed to clarify a few more points.
This DISCUSS is on process grounds; I think we have two serious process issues that prevent our claiming that we have rough consensus on the document. 1. The community reviewed and commented on version -03. The IESG is being asked to approve version -04, and is being told there is rough consensus on its content. And yet vesion -04 is essentially a complete rewrite of the document. I understand the assertion that the changes are "just editorial", but that doesn't help: the fact is that the community has *not* reviewed anything close to the version we're being asked to approve. It would be a terrible precedent to say that a document could be rewritten after last call and sent to the IESG for approval that way. I believe that, despite any concern about the usefulness of another last call, this document must get another last call in its current form. To do otherwise would be to trash our rough consensus process. 2. I think the way the document editing was done, and the way the comments were (and were not) responded to was poor, and calls into question what does and doesn't have rough consensus (certainly according to RFC 7282). There were substantive comments that were made that were not explicitly discussed; those comments were then declared "in the rough". I don't believe such declaration can be made purely on the basis of lack of visible support, with no actual discussion or refutation. Dave Crocker and Stephen Kent have both brought up some such issues. I think that re-last-call needs to be accompanied by instructions for people to raise issues that they think they raised before that were not properly discussed, so that there is a chance for them to *be* discussed and, perhaps, for them to be properly declared in the rough once there's real discussion about them. I know some people will think this is a PitA at best, but it should have been done before. An issue tracker, carefully managed, would have been an appropriate tool for a document with this much discussion -- and this much diverse discussion.
I also have two major issues with the document, but note that these are *not* un the DISCUSS portion. Consider this to be strong input, but not part of the blocking process: I'm quite unhappy with the decision to go with "Opportunistic Security" here (rather than "Opportunistic Encryption", since it *is* talking about encryption, or rather than finding another appropriately focused term if there are good reasons not to use "OE"). My sense is that the reasons to use "OS" amount to marketing, but there are solid reasons to use "Encryption" when encryption is central, and not to use the overly broad term "Security" for something that is not actually meant to be broad. I don't like the organization of the document; I don't think it's well written and sufficiently coherent. I know this is vague, but short of having me do yet another rewrite I don't know how to be more specific. The general thing is that topics seem to drift in and out, and the whole document doesn't read as a clear path from one idea, through another, to a set of conclusions.
First, I am quite supportive of a revision of this document going forward. It provides a pragmatic and useful mindset towards mitigating pervasive monitoring. However, I do support Barry's Discuss. I have not followed all of the discussion on the IETF list about the draft, but enough to feel uncomfortable about the interactions. There can certainly be rough consensus but the reaction seems to be more about transparency of what and why things were changes. Secondly, I am not fond of the term "Opportunistic Security" as compared to "Opportunistic Encryption" if encryption is really all that is meant. For instance, does OS have the ability to improve over clear-text to prevent replay attacks? That's something that encryption alone doesn't necessarily provide; of course, it can also be protocol-specific. IF this is about OS and not OE, I would find it useful to be clearer about the dimensions/aspects of security that can be opportunistic. It definitely reads like this is only about opportunistic encryption and nothing else.
I did not have the time to dig through all of the IETF Last Call comments, so I am observing the process DISCUSSion with interest. I do support the clarity issues raised by Adrian, Alissa, and Pete.
Thanks to everyone who worked on this document. I think it is a helpful contribution. On process, prior to taking a deep dive into the LC mailing list traffic and talking with the AD, shepherd, and author, I was originally skeptical about whether this document had achieved rough consensus and whether IETF process had been followed effectively. After having taken those steps, I am convinced that both are true. I also now understand why the term "opportunistic security" was chosen and believe there is rough consensus in support of using that term. However, for a document that is quite short and a concept that is fairly straightforward, I find this document really difficult to understand in places. I've listed the bits that are so ambiguous that I think readers will not understand them as DISCUSS points and other comments as COMMENT points. DISCUSS: o Section 1: "For a particular protocol or application, if and when all but a negligible fraction of peers support encryption, the baseline security may be raised from cleartext to always require encryption. Similarly, once support for authentication is near-universal, the baseline may be raised to always require authentication." I agree with Adrian that it is unclear what this means. And in fact it seems to contradict other language in the document by assuming that a protocol has one mode of operation for *all* peers. I thought one of the goals of OS was that within any single protocol interaction or within any single group of peers, the level of encryption used could be negotiated up to the lowest common denominator among the peers. Perhaps this would be clearer if it emphasized that the default mode for a particular protocol or application might be chosen to be cleartext, unauthenticated encryption, or authenticated encryption, with the ability for peers to negotiate up if they are capable. o Section 1: "In essence, OS is employed when one might otherwise settle for cleartext (or the minimum protection possible if the protocol is always encrypted)." I don't understand the parenthetical, either in substance or grammar. o Section 1: "For example, a policy might require authenticated, encrypted communication, in contrast to the default OS security policy." This sentence presents another reason why the previous paragraph does not make sense. The previous paragraph seems to say that in some cases, the default OS security policy could be to use authenticated encryption. In those cases, this sentence is not correct. o Section 1.2: I find the document's guidance about the extent to which OS protocols "work behind the scenes" to be confusing. There is this text in this section: "OS protocols work transparently behind the scenes, without disrupting communication. When less than complete protection is negotiated, there is no need to prompt the user with "your security may be degraded, please click OK" dialogs. The negotiated protection is as good as can be expected. Even if not comprehensive, it is often better than the traditional outcome of either "no protection" or "communications failure"." And then in Section 3 there is this: "No misrepresentation of security: Unauthenticated, encrypted communication must not be misrepresented to users or in application logs of non-interactive applications as equivalent to authenticated, encrypted communication." The bit about working "behind the scenes" and not prompting the user seems to me to be distinct from the issue of misrepresenting security. That is, (1) whether the user is proactively informed of the extent to which his communications are protected, (2) whether the user is able to find out about that protection on his own, and (3) whether the information provided to the user about that protection is accurate are three separate questions. I find that Section 1.2 argues against (1), although this is not elevated to the level of a "design principle" as it is not included in Section 3. Section 3 argues in favor of (3) -- providing accurate information -- and includes that as a design principle. I believe the document is silent about (2). I get the sense that (1) is viewed by people who worked on this document as an important by-product of wider deployment of OS, so I would have expected support for it to be more explicit in the document, rather than somewhat latent as it is. If there were a fuller discussion of (1), I would also expect (2) to be addressed, as it is natural to ask just how "behind the scenes" OS protocols are expected to be (as Adrian pointed out). This seems like a fairly significant gap in the document.
o Section 1: s/For authentication based on peer capabilities to protect against MiTM attacks/For authentication based on peer capabilities to be able to protect against MiTM attacks/ (FWIW, the above makes more sense to me than Adrian's suggested edit to the same sentence.) o Section 1.1: General comment: It is really unclear what the point of this section is and why this set of paragraphs is strung together as one section. I would suggest adding an opening paragraph along the lines of "This section provides some background about historic and current challenges associated with the use of encryption on the Internet, illustrated using discussion of the Web PKI." o Section 1.1: s/With so many certification authorities, which not everyone is willing to trust, the communicating parties don't always agree on a mutually trusted CA./With so many certification authorities, all of which are not trusted by all entities, the communicating parties don't always agree on a mutually trusted CA./ o Section 1.1: "In interactive applications, security warnings are all too frequent, and end-users learn to actively ignore security problems" This point is orthogonal to the rest of the paragraph to which it is attached. The fact that choices were made to pop security warnings was separate from other choices made about the web PKI. It doesn't quite make sense to me why this is mushed together with a paragraph about "cost and management burdens." o Section 1.1: "For encryption to be used more broadly, authentication needs to be optional. The use of encryption defends against pervasive monitoring and other passive attacks (which are employed not only by nation states). Even unauthenticated, encrypted communication (defined below) is preferable to cleartext." This seems like it should be the first paragraph of Section 1.2. It is rather out of place in Section 1.2. o Section 3: "OS offers an incremental path to authenticated, encrypted communication in the future, as suitable authentication technologies are deployed." As in Section 1, this text seems to assume one mode of operation for a particular protocol. What about protocols that can already support authenticated encryption? Doesn't OS offer an incremental path towards using that mode right now, not in the future, for peers that already support it? o Section 3: s/Communication should generally be at least encrypted./At a minimum, communication should generally be encrypted without authentication./ (I think this was the intention here, although I'm not completely sure what "at least" means.)
conflict-review-zeilenga-email-seclabel
- Is it appropriate for the authors to "hope" a standard will help in an ISE RFC? (last para of 1.2) I don't care much, as their hopes are for them to figure out, but it seems like an odd statement here. - section 4: It'd be good to provide the XML for the ":xml" example as well as the b64 for it
I'm fine with this and don't have an objection. The editors may want to follow along with the endymail@ietf.org discussion list. Questions are being raised as to why we have subjects exposed as we do since they sometime contain sensitive data. Having this marker in the subject will make it apparent that the message contain sensitive information. Maybe there is a better way to do this going forward depending on how messaging evolves.
conflict-review-deng-pcp-ddns
I think this document could have been published also from the DNSOP WG. And perhaps some additional review would be welcome still. In any case, I have no problem publishing the document as an RFC either in the RFC Editor or IETF streams.
... and presumably PCP?
Given Ted's email comments, I'm OK with this. Ted, you might consider putting a version of those comments into your ballot, so they're on record in the datatracker.