IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2015-05-28. These are not an official record of the meeting.
Narrative scribe: John Leslie (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:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning items
2.2 Individual submissions
2.2.1 New items
2.2.2 Returning items
2.3 Status changes
2.3.1 New items
2.3.2 Returning items
3. Document actions
3.1 WG submissions
3.1.1 New items
Telechat:
Telechat:
Telechat:
3.1.2 Returning items
3.2 Individual submissions via AD
3.2.1 New items
3.2.2 Returning items
3.3 Status changes
3.3.1 New items
3.3.2 Returning items
3.4 IRTF and Independent Submission stream documents
3.4.1 New items
Telechat:
3.4.2 Returning items
Telechat:
3.4.3 For action
Telechat:
1055 EDT no break
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
Telechat::
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
Telechat::
Telechat::
Telechat::
Telechat::
Telechat::
7. Working Group News
1131 EDT Adjourned
(at 2015-05-28 06:01:05 PDT)
draft-ietf-pim-rfc4601bis
4601 used IPsec AH for it's MTI security. This removes that and points at 5796 which defines how to use ESP for link local addresses and with manual keying. That raises one technical question and two ickky process questions. The ickky process questions are probably best discussed between the IESG at least initially in case we don't need to bother the authors/wg with 'em. (1) I'd like to check that 5796 defines a way in which one can secure all PIM messages that are defined here in 4601bis (should one want to do that). If there are cases where PIM-SM can be used and where there is no well defined security then I think that would be a problem. And I think maybe there are such cases. Am I wrong? If not, then how does one secure those? (2) Is it ok for an IS to depend on a PS for it's MTI security mechanism? (I think it is, but yeah, someone else might not.) (3) Is it ok for an IS to not conform to BCP107? (I think it depends, and I'm not sure in this case.) - My review was based on the diff vs 4601 [1] and the abstract of 5796 which seems fairly clear though. [1] https://tools.ietf.org/rfcdiff?url1=rfc4601&url2=draft-ietf-pim-rfc4601bis-05.txt
Just a little bit of history in case this draft looks familiar to some of you. This document was on the telechat agenda for 2015-03-12, but it was removed before the call to resolve a DISCUSS from Brian Haberman. That issue has now been resolved.
I support Stephen's discuss points. Thanks.
Thanks for working through the authentication issue with me.
draft-ietf-ccamp-wson-signaling
I'm a bit startled that the WavelengthSelection sub-TLV has a used value of 8 bits (really 1 bit plus a handful of the 127 values) but has a length of 4 which thus forces 2 octets of padding. I expect that there are implementations and this isn't a flaw - just wasteful.
Just wondering: does this (or some other document) provide me with a way to say that node X should take an input lambda and replicate it out twice? (I.e. forking the traffic) If so, then that probably ought be noted somewhere as it'd enable forms of monitoring that might otherwise require a visit to the physical node.
The security considerations say this document differs from 3473 only in "specific information communicated". In general, a change in the information carried can make a huge difference. I infer that the working group believes that this specific information does not (I hold no opinion on that), but it would be good to state that explicitly.
Thanks for addressing the SecDir review comments. I didn't see the follow up thread, but do see the adjustments in the draft. https://www.ietf.org/mail-archive/web/secdir/current/msg05537.html
I think the choice of registration policies for the new registries -- Standards Action or Specification Required -- is a good one, and provides good flexibility. Thanks for that.
draft-ietf-nfsv4-layout-types
Did I miss a response to the secdir review? [1] I think Joe's questions are worth answering so I hope you do. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05662.html
The ballot and shepherd writeup say "informational", but the document says "Standards Track." I assume the former is intended.
Some nits and editorial comments, as mentioned by Menachem in his OPS-DIR
review:
NITS
====
The tool has found the following:
== Outdated reference: A later version (-05) exists of
draft-ietf-nfsv4-flex-files-02
Additional NITS
===============
Abstract First Sentence: Repetition of the word "those".
This document provides help in distinguishing between the requirements for
Network File System (NFS) version 4.1's Parallel NFS (pNFS) and those those
specifically directed to the pNFS File Layout.
Section 2: Definitions - Not sure whether the word :striped" was intended here.
Data Server (DS): is one of the pNFS servers which provide the contents of a
file system object which is a regular file. Depending on the layout, there
might be one or more data servers over which the data is striped.
Section 2: Definitions - Suggest "lay out" rather than "lays out".
Layout Type: describes both the storage protocol used to access the data and
the aggregation scheme used to lays out the file data on the underlying storage
devices.
Section 3.3: Editorial Requirements - Suggest "separately" rather than
"separably"
"While these could be envisioned as one section in that the fencing
issue might be the only security issue, it is recommended to deal
with them separably."
Thanks for your work on this draft. I would expect the security consideration to discuss the shift to security at the client as well as to see some text on access controls and access checks, which may just refer to existing sections. The SecDir review had similar comments with some specific suggestions that do not appear to have been addressed, but please do point me to the thread if there has been follow up. Specifically, better organization of the security considerations is requested and I agree with Joe's assessment. https://www.ietf.org/mail-archive/web/secdir/current/msg05662.html
Nit, 4.3. Object Layout Type The Object Layout Type focuses security checks to occur during the allocation of the layout. The client will typically ask for a layout for each byte-range of either READ or READ/WRITE I don't think focuses is right word in this context... forces?
draft-ietf-siprec-protocol
(1) 5.3: How does a UA know if it's preference to not be recorded has been ignored? (2) 12.2: Why is a 2011 ([I-D.ietf-avt-srtp-ekt]) expired I-D ok as the method for supporting DTLS-SRTP for the CS, esp when DTLS-SRTP is our currently favoured method for handing WebRTC security? When is that going to be finished? On what basis is that an informative and not normative reference? And is that reference ever likely to be standardised? (Given that it seems to be a form of TLS MitM - is that fair?) Perhaps it'd be better to just admit that re-encryption is needed and get over it? (3) I'll clear once you answer: but wouldn't it be easier all around to just mandate use of mutually authenticated TLS between SRC and SRS in all cases? (Even if some hop-by-hop stuff is needed when there are proxies between SRC and SRS.)
I am concerned that this draft allows the recording session to downgrade security from the communication session. It says "SHOULD NOT", but then explicitly allows for the downgrade when the SRC and SRS are in the same administrative domain. This seems to create a whole new "last hop exception" for media, similar to the one for SIPS that we took so many years to deprecate. (Except it's worse because the potentially insecure hop goes to an endpoint not necessarily expected to be a party to the media.) Section 6.1.2 includes a "contract in place" as a form of recording indication. The other mechanisms seem to say that a given call is being recorded. A contract cannot do that, except in the degenerate case of "all calls are recorded." This doesn't seem to fit the spirit of the "MUST provide recording indication" language. Section 12, 2nd paragraph says the SRC and SRS "MUST support SIP with TLS and MAY support SIPS with TLS as per [RFC5630]". That actually downgrades the requirement for SIPS support from that in 3261/5630. (3261 says you MUST support SIPS if you support TLS.)
The reference to 7245 is informational. Do you expect that a reader/implementor could understand/implement this draft without understanding the architecture and terminology from that RFC? The same applies for 3550--I'm skeptical that one could implement this draft without understanding RTP. -- Figure 1: The text says the flow is basically the same whether the SRC is in an endpoint or separate. This may be logically true, but the flow really would change--none of of the flow between UA(A) and SRC would exist. -- 5.2: UPDATE needs a citation to 3311. Also, 3311 "RECOMMENDS" reINVITEs over UPDATEs for confirmed dialogs. It would be helpful to add some motivation as to why this draft seems to prefer UPDATE. -- 5.3: It seems odd to me that the SRC can ignore an explicit preference not to record. Wouldn't it be better just to refuse to complete/accept the call, if some policy overrides the end-user's preference? -- Figure 3: If the UA prefers not to be recorded, shouldn't it express that at setup time, rather than wait for the SRC to indicate recording is happening? As shown, this almost guarantees a bit of media will be recorded. (Seems like there should be some guidance about this in the text.) The last paragraph of 6.1.2 seems to reinforce the problem by suggesting the participant might base the decision to express a preference on a tag that is optional for the SRC to send in the first place. -- 6.3, last paragraph: It seems odd that the requirement to render a recording indicator be lower for a media server than for other UAs. This seems to circumvent user notification in one of the most common uses of recording these days. -- 9.1 : The last bullet seems to be a motivation to not send metadata at all, which is expressly forbidden in the first paragraph. -- 9.2: The use of the content-type value as the sole indicator that the an UPDATE request should be interpreted as an request for a metadata snapshot update is rather odd. If you end up with new kinds of metadata requests in the future, does each one get it's own media-type? -- 12: If this doc is to depend on the security considerations in 6341, that needs to be a normative reference--which is a bit of a pain because I think it's an informational RFC. -- 12.1: "recording session uses TLS" -- I assume that's for SIP? Also It's worth discussing how mutual authentication applies if the SRC is in an end-user device. Is it expected to have a client cert? No option to use SIP identity? Also, I'm a bit uncomfortable assuming devices in the same administrative domain automatically trust each other. It might be better to say "If they trust each other..." -- 12.2: I get quite a bit of heartburn out of making Security Descriptions MTI and dtls-srtp optional. I guess I may have to hold my nose on this one. Editorial: -- 4: 2nd paragraph: " ... does not represent the protocol" and first bullet: "Delivering recorded media in real-time as the CS media" I don't understand what either of those mean. -- 5.1, 2nd paragraph: "B2BUA to bridge the media between UA(A) and UA(B)" Is there a reason not to use the terminology from RFC 7092? (e.g. “relay” or “terminate” media)? -- 7.3.1: The normative language in the first paragraph is redundant to similar language in 6.3.
Peter Yee's Gen-ART review raised some good questions. For instance, I thought these at least were important points: Page 21, section 8.1.5, 2nd paragraph, 1st sentence: by “content” do you actually mean “context”? Or do you mean to the content of a SIPREC recording? ... Page 38, section 12, 2nd paragraph, 3rd sentence: perhaps the word “effective” would be more appropriate than characterizing it as an “automatic” downgrade? Page 38, section 12.1, 1st paragraph, 2nd to last sentence: just because an SRS is compromised does not mean that it cannot be authenticated. It may very well be operating “correctly” and be able to authenticate, yet the compromise allows the attacker to obtain the (decrypted) RS. Authentication does not imply that the SRS you are talking to is not compromised. It only indicates the SRS possesses some form of credential that appears to identify it correctly.
As mentioned by Scott Bradner in his OPS-DIR review: I find no additional operational concerns beyond those present in running any secure SIP infrastructure. I do observe that the stage upon which this standards track ID is dancing on is rather close to the forbidden zone as described by RFC 2804. But the stage was selected when the working group was formed and it is too late to revisit if that was a stage that an IETF working group should be dancing on.
I support Stephen's discuss. Also, I don't see a minimum version specified for TLS, right now, it's 1.2. Is there any reason that can't be added. The text on cipher suites is good, but if you'd like to have a pointer to the recommended ones, the TLS BCP has them listed and that can be referenced as well, RFC7525.
I have to raise one of Ben's comments to DISCUSS, after giving it a lot of thought. We talked about it before Ben posted his ballot, and I said that I thought the way the rs-metadata-request subtype is used is abusing media types: media types are meant to label containers for protocol elements, but are not meant to be protocol elements themselves. I said I didn't want to get too wound up with that, though, and I don't... ...except that it allows no room for extensibility. And the moment you need another, different request, we see why this mechanism is abusive. Now, you may say that you don't see any need for extensibility, but we've been proven wrong in those sorts of assumptions many times. So, the discussion is about how you will deal with that. Specifically, an alternative would be to have an rs-request subtype, with a content-type parameter such as "req=metadata" (or even use rs-metadata with "req=snapshot") and a rule that req= values that are not recognised be ignored. If this should ever need to be extended, other "req=" values could be defined. A registry could be created in future, if there turns out to be a need. There are other options, as well, but the main question is why are you sure that no such extensibility is needed? Also, what you're doing with content-disposition isn't in accord with what that field is for: it is for describing how the information in the message part should be presented -- not what it's meant to contain or be used for. This, too, could be better handled with a content-type parameter. The discussion on this point is whether thus was considered, and, if so, why it was rejected.
-- Section 7.1.1 -- Since the SRC does not expect to receive media from the SRS, the SRC typically sets each media stream of the SDP offer to only send media, by qualifying them with the a=sendonly attribute Why "typically"? Why would it not? Why not just remove the word? The same question applies to 7.2. -- Section 8.1.4 -- It is RECOMMENDED that an SRC or Recording aware UA, when acting as a mixer, sets the CSRC list accordingly, and that the SRC and SRS interpret the CSRC list appropriately when received. A few questions about this: "Accordingly" and "appropriately" are quite vague... any better guidance on what is accorded and appropriate? For the former, I presume you're saying that the UA should set the CSRC list to encompass what's being mixed. But I have no idea what's appropriate for the SRC and SRS to do when interpreting that. Further, on "RECOMMENDED", what happens if someone doesn't do this as you're hoping they do? What are the consequences to interop or security? -- Section 8.1.5 -- The ability to identify individual contributing sources is important in the content of SIPREC. I think you mean "context", yes? -- Section 8.2.1.1 -- UAs may receive multiple sets of RTCP Receiver Reports, one or more from other UAs participating in the CS, and one from the SRS participating in the RS. A UA SHOULD process the RTCP Receiver Reports from the SRS if it is recording-aware. Is it woth mentioning what the UA is likely to do with the reports from other UAs (just for information, without 2119 words)? Would the UA generally process them too? Ignore them? Doesn't matter? Is there any advantage one way or another, or any advice that would be useful for implementors to have?
From Scott Bradner's Opsdir review: I did an OPS-DIR review of draft-ietf-siprec-protocol-16. This document describes a mechanism for recording SIP sessions, ostensibly, only with the knowledge of the SIP endpoints. The document is clear and mature (which I would hope was the case for a -16 working group ID). In particular, the security considerations section seems quite well written to me. I find no additional operational concerns beyond those present in running any secure SIP infrastructure. I do observe that the stage upon which this standards track ID is dancing on is rather close to the forbidden zone as described by RFC 2804. But the stage was selected when the working group was formed and it is too late to revisit if that was a stage that an IETF working group should be dancing on.
draft-ietf-dhc-dynamic-shared-v4allocation
section 6: Why is client identifier option a MUST? Surely the PSID has to end up as a unique identifier for the client for the duration of the lease or else stuff will be broken. (And I don't see any real use of the client identifier in section 8.) So requiring the client identifier seems like something counter to data minimisation. Requiring that also seems to conflict with possible future privacy friendly dhcp profiles, which might want to use this as e.g. with some cleverness in source port randomisation, the public Internet might get less trackable evidence than would otherwise be the case. I'd argue that you might be better off here to make the client identifier a SHOULD NOT and to point out that including it may break a privacy friendly profile such as defined in [1] should that end up being standardised, which is presumably likely now that [1] is a dhc wg draft (though note that I'm not sure the treatment of client identifier in [1]-02 is what'll end up there in the end.) [1] https://tools.ietf.org/html/draft-ietf-dhc-anonymity-profile-00
- section 2: s/mediums/media/? I also wondered if cable is considered shared here or not? (I assume Ethernet and WiFi are considered shared.) - What if 1 of N of the devices with that IP operates a server, how do we ensure that clients of that server talk to the right one? - I have some questions about ports. Can I ask for port 546 or 547? Why is that ever allowed? Would port 443 be very popular I wonder? Can I ask for other well known ports in the hopes of successful typosquatting sending me traffic? What if mptcp is used? - section 6, step 3: I'm not sure I get how there can be many DHCPOFFER messages from which to choose (in the nominal case). Are you envisaging that two DHCP relays/servers on the same subnet would be handing out different PSIDs? - section 6, step 6: Could I "release" ports that had not been assigned to me? Where's it say to watch out for that. - section 9: PSID-len - the description of that isn't clear to me sorry. I've not followed the references though so I assume it would be if I had. - section 10: [I-D.bajko-pripaddrassign] is odd - that was replaced by stuff that was replaced by stuff that was replaced by stuff that's still in-work in the dhc wg. I think you need to explain why you refer to the archaic thing and not the WG document.
Section 2 (Applicability Statement) says that “this extension is only suitable for specific architectures based on the Address plus Port model (A+P) [RFC6346]”, which I take to mean that the components of the solution in RFC6346 must be present (PRR, for example). In fact, if the functionality described in RFC6346 is not present, then the forwarding won’t work as standard destination-based protocols may not deliver the packets to the right place. I think that RFC6346 should be a Normative Reference, which then results in a DOWNREF to an Experimental RFC. IOW, if the functionality in RFC6346 is needed (which I think it is), then the status of this document should not be Standards Track.
In section 10.1, how could preserving port randomization become "less" difficult?Presumably the assigned port range will never be larger than "all the ports".
I have many of the same questions as Stephen, so I support his discuss and comments. In particular, I'd like to see text int he security considerations about sending traffic to the wrong host and how that is prevented as well as risks. Stephen hits on this in his comments and I'd like to see it addressed in the security considerations section. Since that's the point of the draft (multiple hosts using the same IPs), it is a major consideration.
draft-ietf-ipsecme-ikev2-null-auth
- 2.1: just wanted to check as I didn't have time to go through it all myself - are we confident that using SK_pi/SK_pr in this way has no cryptographic downsides? The reference to the EAP methods convinces me this is no worse than an existing thing, but not (by itself) that it is cryptographically sound, so I just wanted to check as I think prf(SK_pr,IDr') has until now been calculated but not transmitted, so there's a tiny change here maybe, but as I said I didn't have time to fully check. If someone just tells me that yes, the authors/wg did consider this, that'll be fine, no need to fully explain to me why using SK_pr like this is safe (though if you want to, that'd be fine too). - 2.5: "hand out" is an odd phrase here - would be better to expand on that I think and say more precisely what should never be done.
First: Thanks, Paul, for a very informative and useful shepherd writeup. I have no problem with the reference to Experimental RFC 5739, but I do have a problem with the downref not having been noted in the last call announcement, as required by RFC 3967 (BCP 97). And I think the MUST in the last paragraph of Section 2.5 requires 5739 to be normative. I hate to say this, but I think this requires a second last call on this document, which will really serve no one. We really do need to do an update to BCP 97 to fix this, because it comes up all the time.
Editorial comment in Section 2: If a peer that requires authentication receives an AUTH payload containing the NULL Authentication method type, it MUST return an AUTHENTICATION_FAILED notification. We're referring to NULL authentication as "authentication", so maybe this should say something like "If a peer that requires positive identification receives [...]", or "If a peer that requires authenticated identity receives [...]" ?
draft-ietf-precis-saslprepbis
- Unsurprisingly, the diff between this and RFC4013 isn't useful, so I read from scratch. If I'm commenting on something that was already true of 4013, just tell me and that'll be fine. - intro: given the unsolved i18n issues and the fact that passwords are crap (security wise) would it be fair to ask that you add a sentence here to encourage folks to not use passwords at all but some better form of authentication, when that's possible? (Which is sadly not nearly common enough for user authentication.) Maybe something like: "While this document specifies how to handle passwords to the best of our current abilities, those designing and implementing protocols would be much better off if they can avoid any use of passwords. Using passwords means having to deal with the inherent insecurity of passwords, and of password verifier databases, and also the i18n issues described here. Authentication schemes based on digital signatures or other cryptographic mechanisms are, where usable, far preferable." - nitty nit: intro, 2nd last para on p3: once a password is chosen, there are no more entropy changes so you cannot maximise entropy *during* authentication. Maybe s/during/for/ works though. - 3.2.2, bullet 3: I read this as saying to use the latest Unicode default case folding and not to stick with v7.0 even if a new and in this sense different version is published. This is just to check that that is what you intended and that I've not misread the text. 4.1: zero length password - I think you're wrong on that one but it is arguable. This was a discuss until you told me that 4013 prohibited 'em too so probably no point in changing now if it's just my opinion. There are situations where an empty password is ok (say when I'm not "protecting" something but just want to know what user's profile to use, e.g. for weather) and that is supported in many systems (that hence won't be able to exactly adopt this) and insisting on a non-empty password could be more damaging than allowing a zero-length password, whenever a user re-uses a password for something for which no password is really needed (and which hence is less likely to be well protected) and where that password is also used to protect something of significantly higher value. The zero-length password is also not an interesting subset of the set of stupid passwords really so doesn't deserve to be called out as such (and you say that in the draft when you talk about length-1 passwords.) So I think allowing zero length passwords is better overall, and more consistent with implementations.
draft-ietf-tls-negotiated-ff-dhe
Not issue on the technical content and the publication of this document, but https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ and the write-up mention "Standard Track" while the draft status is Informational, as spotted by Linda in her OPS-DIR review below: This document is on the Informational Track to specify ways for client and server to establish common finite-field DH parameters with known structure and a mechanism for peers to negotiate support for these groups. The document is well written and very clear. A couple questions: 1) Why this document is not standard track? 2) Several sections requests range in reference of p, e.g. “p-1” or p (Section 5). But there are so many numbers that can be “p” (page 17). What is the significance of the range?
Thank you for your work on this draft, it is very well written, easy-to-read, while solving an important problem. Thanks for the detailed security considerations as well.
The intended status in the document text does, indeed, need to be changed to "Standards Track". The last call was issued as "Proposed Standard", and the IESG ballot is set up for that, so I think we're OK -- please just fix the text in the next document rev.
draft-ietf-dane-smtp-with-dane
Thanks for this. I only have a few trivial comments: 2.1.3, first paragraph: The seems redundant to similar normative language in 2.1.1 2.1.3, last paragraph: "...it may need to issue a separate query..." I assume that means it also may _not_ need to do so. Is it worth elaborating on that case? Editorial: 2.3.3, first sentence: This is pretty convoluted. You might consider breaking it into a few simpler sentences.
References and terminology: You use RFC 1034 to define "RR", and RFC 5598 to define "MSA", "MTA", and "MUA". And these are definitions that must be understood in order to properly understand this document. I think that makes those normative references, not informative ones, and they should be changed. (5598 is already in the downref registry, so,there's no problem with the downref here.) >> Author will move the references. In Section 2.2.1: When DANE TLS is mandatory (Section 6) for a given destination, delivery MUST be delayed when the MX RRSet is not "secure". This contradicts the "delivery MAY proceed" in the previous paragraph (and it also doesn't really fit into the paragraph about logging anyway). If you want to restrict things, I think you should put the most restrictive condition first, so move this sentence to the top of the previous paragraph. >> Author will make this change: OLD If the MX RRSet (or any CNAME leading to it) is "insecure" (see Section 2.1.1), DANE TLS need not apply, and delivery MAY proceed via pre-DANE opportunistic TLS. NEW If the MX RRSet (or any CNAME leading to it) is "insecure" (see Section 2.1.1), then if DANE TLS is mandatory (Section 6) for the given destination, delivery MUST be delayed. If DANE TLS is not mandatory, then DANE does not apply and delivery proceeds with pre-DANE opportunistic TLS (perhaps even in cleartext). END -- Section 2.2 -- contrast, DNSSEC validated TLSA records MUST NOT be published for servers that do not support TLS. Clients can safely interpret their presence as a commitment by the server operator to implement TLS and STARTTLS. I don't know that this needs any text changes, though perhaps a mention of this in the Security Considerations would be good: I'm not sure how "safely" they will be able to do that in practice. Remember that the people running the email severs often have no connection to the people who will insert or remove the TLSA records from the DNS. It's possible that a software change in the mail servers will remove support for DANE, and the TLSA record will not be correspondingly removed. I'm hoping that once this really gets rolled out, that won't be a real issue, but it could be for a while. It might be worth saying in the Security Considerations that such a situation needs to be avoided, and coordination is important, to make sure it doesn't happen. Otherwise, according to Section 2.2, mail delivery from DANE-aware MTAs will fail. >> Author will decide here -- probably not necessary to change anything: already sufficiently obvious. >> Author agrees with all of the following, and will adjust the text appropriately: -- Sections 2.2.1 and 2.2.2 -- In 2.2.1: In the absence of DNS lookup errors (Section 2.1.1), if the MX RRset is not "insecure" then it is "secure", and the SMTP client MUST treat each MX hostname as a separate non-MX destination for opportunistic DANE TLS (as described in Section 2.2.2). In 2.2.2: This section describes the algorithm used to locate the TLSA records and associated TLSA base domain for an input domain that is not subject to MX resolution or that lacks MX records. I find this combination unnecessarily confusing -- it starts to sound a bit like Fizzbin <http://en.wikipedia.org/wiki/List_of_games_in_Star_Trek#Fizzbin>. I know it's explained further (which is why this isn't a DISCUSS point), but I think clarity in the introduction would help a lot. I suggest this, but anything similar would be equally helpful: NEW In the absence of DNS lookup errors (Section 2.1.1), if the MX RRset is not "insecure" then it is "secure", and the SMTP client MUST treat each MX hostname as described in Section 2.2.2. END NEW This section describes the algorithm used to locate the TLSA records and associated TLSA base domain for an input domain that is not subject to MX resolution, that represents a hostname from a secure MX RRset, or that lacks MX records. END That latter ordering matches the order of the bullet list, and I think that's useful for making the text understandable. You might also re-think the title for Section 2.2.2, but I think that's less important. -- Section 2.2.3 -- If the ultimate response is a "secure" TLSA RRSet, then the candidate TLSA base domain will be the actual TLSA base domain and the TLSA RRSet will constitute the TLSA records for the destination. If none of the candidate TLSA base domains yield "secure" TLSA records then delivery MAY proceed via pre-DANE opportunistic TLS. SMTP clients MAY elect to use "insecure" TLSA records to avoid STARTTLS downgrades or even to skip SMTP servers that fail authentication, but MUST NOT misrepresent authentication success as either a secure connection to the SMTP server or as a secure delivery to the intended next-hop domain. When SMTP clients elect to use insecure TLSA records, this text implies, but doesn't make it completely clear, that they should only do that after checking all candidates. It would be good to be clear: check all candidates, stopping at the first secure TLSA. If no candidates produce secure TLSA, then you MAY use an insecure one, or you MAY use pre-DANE TLS. Is that right? In general, I strongly encourage you to review Section 2.2.3 and make sure that it reads smoothly to someone who's not already familiar with the DANE SMTP work. I'm not sure the organization of the thoughts in this section is very good as it's currently written. -- Section 3.1 -- In summary, we RECOMMEND the use of either "DANE-EE(3) SPKI(1) SHA2-256(1)" or "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA records depending on site needs. But later, in Section 3.1.1, you specifically single out the former: TLSA records published for SMTP servers SHOULD, in most cases, be "DANE-EE(3) SPKI(1) SHA2-256(1)" records. To be more consistent in your advice, I suggest changing the advice in 3.1 thus: NEW In summary, we RECOMMEND the use of "DANE-EE(3) SPKI(1) SHA2-256(1)", with "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA records as a second choice, depending on site needs. See the following two subsections for more details. END If that's not the advice you mean to give, then something is unclear. -- Section 3.1.1 -- Similarly, the expiration date of the server certificate MUST be ignored, the validity period of the TLSA record key binding is determined by the validity interval of the TLSA record DNSSEC signature. Editorial: "Similarly" to what? I'd remove the word. Also, the comma after "ignored" needs to be a colon (or a semicolon, but I think a colon is better here; the comma splice is just wrong). With DANE-EE(3) servers need not employ SNI (may ignore the client's SNI message) even when the server is known under independent names Editorial: This needs a comma after "DANE-EE(3)", and would do well with "they" before "may ignore"). -- Section 3.1.1 -- Such servers MUST either publish DANE-TA(2) records for an intermediate certificate or MUST instead use DANE- EE(3) TLSA records. The first "MUST" should be moved one word later, after "either" (or else the second "MUST" should be removed). -- Section 3.1.3 -- Note, this section applies to MTA-to-MTA SMTP on port 25. Earlier, in 2.2.3, you note that "the destination TCP port is typically 25, but this may be different with custom routes specified by the MTA administrator". I don't think you mean for this section not to apply in the latter case, so I suggest changing this to, "Note, this section applies to MTA-to-MTA SMTP, which is normally on port 25." Nothing is lost since the PKIX certificate usages cannot aid SMTP TLS security, they can only impede SMTP TLS interoperability. Editorial: You need a comma after "lost", and the existing comma needs to be a semicolon. The last paragraph of the section is missing a final period. -- Section 6 -- Administrators of mail servers that employ mandatory DANE TLS, need to carefully monitor their mail logs and queues. Nit: the comma should be removed.
draft-ietf-v6ops-cidr-prefix
Thank you for documenting this!
I never realized this was not documented. So thanks for this document.
Only editorial comments here, for your consideration. The one about "barring" is the most important one. -- Section 1 -- In the second paragraph, I suggest removing the parentheses from "(mis)". In the fourth paragraph, I had to read the first sentence several times in order to parse it. The word order confused me, making me think "link routing", rather than "to link". You can easily fix that by changing "to not link" to "not to link". In the fifth paragraph, "barring" is ambiguous: I don't know whether you mean that because IPv6 forwarding must follow the longest-match-first rule, configuration of an overriding policy is barred (forbidden), or whether you mean that IPv6 forwarding must follow the longest-match-first rule *unless* an overriding policy is configured. I'm guessing it's the latter, but you should reword this either way, to make it clear. In the last paragraph, what does "a historical reminder" mean? -- Section 2 -- In the second paragraph, I note that too many attributive nouns put together make for awkwardness and confusion. I suggest changing "Forwarding decision-making processes" to "Decision-making processes for forwarding", so it's clear that "forwarding" is a gerund (noun), not a participle (verb). I suggest removing the word "obviously" from the third paragraph: if it's really obvious, it needn't be said at all, and the word makes it sound haughty.
While I find it utterly amazing that this document was even written, I have been exposed to more than a handful of IPv6 implementations that get this wrong. So, I guess we do need a tool to hit folks over the head.
draft-ietf-kitten-sasl-oauth
-- section 1, description of step A: if the preferred way is different than the diagram, why not show it the preferred way in the diagram in the first place? -- 1, 2nd to last paragraph The "SHOULD" means the reference to I-D.ietf-oauth-dyn-reg needs to be be normative. -- 3: "Such a new SASL OAuth mechanism can be added by simply registering the new name(s)" Register them where? -- 3.2, 2nd paragraph : "... known to the application." Known to the "resource server"? Editorial Stuff: -- 3.1, "Port": I assume that means the destination port to which the client connected? (similar to Host?) -- 3.1.1 "Post": default value is "". Does "" represent an empty string? -- 3.2, first sentence" s/" ... according the specification..." / "... according to the specification..." - 5: "Lifetime of the appliation sessions" s/appliation/application "It is possible that SASL will be authenticating..." s/"... be authenticating..." / "... be used to authenticate..."
Thanks for your work on this draft and for requiring TLS on bearer token use.
Another excellent, informative shepherd writeup, which helped with my review of
the document. (And, I'll say, most of the really useful writeups, as this one,
seem to use the "essay" format, rather than the Q&A format.) Thanks, Ben, for
the writeup.
-- Section 1 --
way to use the Simple Authentication and Security Layer (SASL)
[RFC4422] to gain access to resources when using non-HTTP-based
protocols, such as the Internet Message Access Protocol (IMAP)
[RFC3501] and the Simple Mail Transfer Protocol (SMTP) [RFC5321],
which is what this memo uses in the examples.
When I first read this, I thought the last phrase was bound to SMTP... but then
I see that both IMAP and SMTP are used in the examples. So, a small thing, but
I'd end the sentence after the 5321 reference, and make the last phrase into
another sentence, like, "This document gives examples of use in IMAP and SMTP."
-- Section 2 --
Note that the IMAP SASL specification requires base64 encoding, see
Section 4 of [RFC4648], not this memo.
Nit: That seems kind of an odd way to put it, in addition to its having a comma
splice. Why not this?:
NEW
Note that the IMAP SASL specification requires base64 encoding, as
specified in Section 4 of [RFC4648].
END
-- Section 3.2 --
Nit: "vaialble" -> "available"
-- Section 3.2.2 --
scope (OPTIONAL): An OAuth scope which is valid to access the
service. This may be omitted which implies that unscoped
tokens are required. If a scope is specified then a single
scope is preferred, use of a space separated list of scopes is
NOT RECOMMENDED.
Why is it "NOT RECOMMENDED"? What interoperability or security issue is in
play here that makes this "SHOULD NOT"?
The server MAY return different URLs for users in
different domains and the client SHOULD NOT cache a single
returned value and assume it applies for all users/domains that
the server suports. The returned discovery document SHOULD
have all data elements required by the OpenID Connect Discovery
specification populated.
Similar questions for the SHOULD NOT and SHOULD here. In this case, I don't
understand why they aren't "MUST NOT" and "MUST": for the first, I don't
understand how a client can interoperate with a server if it violates this, and
for the second, if they data elements are "required", why isn't including them
a "MUST"?
(Nit: The "if available" at the end of the paragraph is unnecessary; if one is
not available, it certainly can't be used.)
-- Section 4.1 --
The
underlying TLS establishment is not shown but is required for using
Bearer Tokens per that specification.
S: * OK IMAP4rev1 Server Ready
C: t0 CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR
S: t0 OK Completed
The problem with this is that if the underlying TLS establishment is done
through STARTTLS on port 143, that would come between the first line ("S: * OK
IMAP4rev1 Server Ready") and the second. And that makes the example a bit odd.
The easiest way out of that is simply to remove the first line. Or, better,
to replace the first line with something like "[Initial connection and TLS
establishment...]". (This applies to the subsequent sections as well.)
I wonder why you don't wrap the decoded payload here the same way you do in
Section 4.2 (or there the same as here). I suggest that there'd be less room
for any confusion if you did them all (4.3 also) the same way (I don't care
which way you choose).
In the SMTP part, you say this:
Note
that line breaks are inserted for readability, and that the SMTP
protocol terminates lines with CR and LF characters (ASCII values
0x0D and 0x0A), these are not displayed explicitly in the example.
The same is true for the IMAP protocol and example, but you don't say this
there. Actually, I don't think you need to say it in either place, and suggest
simply removing it here (and in Section 4.4).
-- Section 4.4 --
In the SMTP protocol, you should have "[Negotiate TLS...]" before the SMTP AUTH
command, as you do in Section 4.1.
SASL mechanisms using this document as their definition do not provide a data security layer; that is, they cannot provide integrity or confidentiality protection for application messages after the initial authentication. If such protection is needed, TLS or some similar solution should be used. Additionally, for the two mechanisms specified in this document, TLS MUST be used for OAUTHBEARER to protect the bearer token; for OAUTH10A the use of TLS is RECOMMENDED. Can someone explain to me situation were intergrity protection is not desirable (possibly rhetorical). it seems like it might be better to clarify what the exception is and use a blanket must for everything else.
draft-ietf-manet-olsrv2-multitopology
Let's please have a brief, non-blocking discussion of the "updates" status here. As I read this, I don't see how this updates either 7181 or 7188. It clearly doesn't update 7188: it's just using an extension mechanism that was specified in 7188. I also don't think it updates 7181, because it's specifying an optional (indeed, experimental) extension. Here: does someone reading 7181, with no interest in implementing this experimental extension, need to read (or even know about) this document? I think the answer is no. (There's also the spurious "XXXX" in the updates list, which should be removed.) Update: The authors confirm that it doesn't matter to them, and they just want it to be right. Unless anyone thinks otherwise, I think we should remove all the "updates" on this one.
draft-ietf-sfc-architecture
(1) I note the charter calls for this deliverable to "provide a description of... security models" The charter also generally notes that "The SFC WG will closely consider and address the management and security implications when documenting these deliverables." My conclusion is that this deliverable needs to reflect the results of a security analysis that the wg are suppoed to have carried out but that it's currently too vague only saying that solutions need to consider this. (Essentially this is a continuation of the mail threads from the secdir review [1] and a satisfactory resolution of that will probably resolve this.) [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05701.html (2) Metadata that contains information that is protected in the data plane SHOULD be equally well protected when passed about by SFC. I hope that's acceptable and documented. I'm not sure myself if "passed about" ought also include within a device but maybe it should really. But at minimum, I do think you need to define confidentiality and origin authentication services for SFC metadata and/or for the SFC encapsulation as a whole. And I think this architecture document needs to say that those services have to be well-defined as part of any solution. (And I am not saying that this draft needs to define how to do those.)
- It occurs to me that it might really be better for the WG
to not publish this as an RFC now, but rather to put it on
hold until they've made progress on the solutions. Perhaps
revistiting this when the solutions are just at WGLC would
result in the eventual RFC being a much more useful document.
I think this one has to hedge so many bets that it's quite
vague and won't be very useful even in the medium term. But
that's just a suggestion, I can see why the WG might prefer
to push this out, even if that might only give the appearance
of progress and not reflect real progress.
- While IPR on an architecture document is sad to see, esp
with what seems like it may be restrictive licensing, I do
see the wg debated that and decided to move on.
- The charter text describing this deliverable notes that
"The initial scope is restricted to a single administrative
domain, keeping in mind that architectural decisions made for
the intra-domain case may have implications for the
inter-domain case." So I think there is also a currently
missing analysis (or the results of that) as to how the
single-domain elements of this architecture might impinge on
a later inter-domain architecture. So the text at the
end of section 1.1 appears to contradict the chartered
goals.
- Chains will require some representation, and re-ordering
that is security sensitive (e.g. swap order of f/w and nat
for fun) therefore there must be a requirement for some data
integrity service and origin authentication and an
authorisation decision function and therefore there must
(istm) be a need for the architecture to define a chain
producing entity of some kind that could be authenticated.
That is an example of the missing security analysis that
really is needed before this proceeds. (See my discuss point
2)
- 1.1: "classified on ingress" and applicable to mobile
networks are slightly incongrous. In the case of WiFi when do
the packet ingress? (When it gets to the AP or leaves the
mobile node transmitter?) I suspect you really mean the wired
bits of a mobile network so it might be better to say that.
- 1.2 should follow 1.3 I think.
- 1.2: What does "chaining logic" mean? You say there's no
standard chaining logic, which is maybe right, but then you
imply that a fully ordered set of SF's is a well defined
thing. I'm not sure that makes sense. Perhaps what you want
to say is that the architecture doesn't determine if an SFC
{{A,B},C} is or is not the same as {{B,A},C} but that later
protocol work will have to do that. (In fact, I think you
could say a lot more here and probably should.)
- 1.2: what is a "chaining policy"? Isn't here where those
terms need to be defined.
- 1.3: SFC definition: by ordered do you mean fully or
partially ordered?
- 1.3: I'd omit LI as a SF - we won't be standardising that
(cf. RFC2804) so better to not drag in the controversy
really. Similarly, HOST_ID injection is not afaik any kind of
standard and perhaps not likely to be (cf. some confict
reviews on the same telechat as this) so I'd also drop that.
And I think all of the exemplar SF's should really have a
reference (ideally an RFC).
- Figure 1 caption is misleading. That seems to me to show a
set of paths through (one or more) graphs but doesn't show
the full graphs themselves.
- 2.2: The concept of a bi-directional SFC seems odd. Does
the example given imply that all traffic (of what kind?) that
followed SF1->SF2->SF3 on the way "in" must follow
SF3->SF2->SF1 on the way "out"? If so, then I think more
precision is needed really. The hybrid concept seems even
odder to me.
- 2.3: How can an SFP "be vague" - surely the point of an
architecture is to avoid such vagueness? If you mean that an
SFP representation can embody an if-statement then saying
that would be the thing to do.
- Section 3: I think there's maybe a missing principle here
about not making security and privacy worse in general.
- 4.1: I wonder if one could ever get enough SFC control
traffic that congestion would be an issue? If so, should you
say rather that any transport that has some way of handling
congestion is ok. If not, then I guess the current text is
fine.
I want to talk about the intended status of this document: right now (-08) it is marked as Informational, but up to -06 it was intended to be on the Standards Track. Why did this change? [I looked at the archives, but couldn’t find a specific reason or discussion.] From the Abstract: This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFC) in a network. It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs, with a focus on those to be standardized in the IETF. If this architecture is what ongoing standardization of SFC should be based on, then I think it should be on the Standards Track. There are already a number of drafts that intend to be on the standards track that are using this document as a normative reference [1], which makes sense based on the text above. Note that none of the drafts that use the document as a normative reference have been adopted by the WG, but the point is still the same: if the intent is for this document to be used as a base for future standardization, then I think it should belong in the standards track. I know that we can always add a downref exception, but why would that be necessary if this document is intended to be guide future standardization for SFC? OTOH, if the WG decided that this is just “an architecture” (vs. *the* architecture), and that is why the intended status changed in -07, then it should be made clear in the text. [1] https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/referencedby/
Just a couple of other comments: 1. Section 1.1(Scope): “This document defines the architecture for Service Function Chaining (SFC) with minimum requirements on the physical topology of the network, as standardized in the IETF.” What is standardized, the physical topology? Confusing sentence. 2. Section 5.2 (SFC Control Plane): “This is part of the overall architecture but outside the scope of this document.” I don’t understand how the control plane, being part of the architecture, is not in scope of the architecture document..?? Especially since in this section there is a discussion of the functionality to be provided by the control plane. What am I missing?
draft-ietf-bmwg-traffic-management
Just one formatting nit: the appendixes are out of place.
Section 6.2.1 Queue/Scheduler Individual Tests Overview
I understand that is not finished work, but do we need to say a few words about
codel and pie http://datatracker.ietf.org/doc/draft-ietf-aqm-pie/ and
http://datatracker.ietf.org/doc/draft-ietf-aqm-codel/
- More of a transport AD question:
"To this end, the stateful tests will use TCP test patterns to emulate
applications." Do we need to emulate any applications on SCTP test patterns?
Asking the transport ADs about which deployed protocols use SCTP, their answer
was: WebRTC, SS7 signalling in 3gpp mobile networks.
Editorial:
- Section 1:
Specifically, this framework defines the methods to characterize
the capacity of the following traffic management features in network
devices; classification, policing, queuing / scheduling, and
traffic shaping.
Section 1.2
This testing framework describes the tests and metrics for each of
the following traffic management functions:
- Policing
- Queuing / Scheduling
- Shaping
I would add classification to that list.
- Section 1.2
"Note the NDE SHOULD be used in "full pipe" delay mode."
I don't know what "full pipe" delay mode is
- OLD:
It is not within scope of this of this framework to specify
NEW:
It is not within scope of this framework to specify
- General observation. This is one of these documents where too many acronyms
make it difficult to read (and I have some QoS background) Ex: "The tests will
verify that the network device can handle the CIR with CBS and the EIR with EBS
Note: I don't expect any action on this remark
- Section 6:
Each test SHOULD compare the network device's internal statistics
(available via command line management interface, SNMP, etc.) to the
measured metrics defined in section 4.
FYI. Most MIB interface/QoS counters are not updated real-time in routers. 10
sec for interface stats is common. So no real-time monitoring is possible.
- two instances of tester*: not sure what they mean
configure the tester* to generate a profile of emulated of an application
traffic mixture
Thanks for your work on this draft. I just have one question that was raised in the SecDir review: Was there any thought to how the tcpinc efforts might affect the ability to gather measurements? http://www.ietf.org/mail-archive/web/secdir/current/msg05726.html It doesn't have an impact on this draft yet, but could in the future.
conflict-review-williams-exp-tcp-host-id-opt
Fully agree with the DNP response and Martin's comments.
Here are comments for the ISE to consider: - The abstract says it in the first sentence: "Recent IETF proposals have identified benefits to more distinctly" This sentence is trying to make a statement into the direction that the IETF is endorsing host identification. This is not true and therefore this sentence must be removed or changed in wording. Probably the authors mean: "Recent proposals discussed in the IETF have identified benefits to more distinctly..." - Further, this draft is arguing in favor of letting middleboxes adding the proposed TCP option. This is problematic for multiple issues, such as adding a TCP option will very likely cause packets to grow beyond the path MTU and TCP option space is limited and extensively used already by TCP options added by the end hosts. The draft acknowledges both issues and discusses them briefly. However, it is clear by now that the TCP option space is almost used by modern TCP implementations to signal the properties of a TCP connection (especially with MPTCP). Adding another option will be potentially not possible, unless such a middlebox is going to remove an option that has been added by an end host. - Section 4.2.2 is discussing problematic issues when persistent TCP connections are used which are used by multiple application sessions at the same time. The text gives recommendations, but the recommendations will end up in a very complex, error prone setup, where potentially user traffic is being miss-classified. E.g. in the case the middlebox is sending nonetheless traffic of multiple users over the same TCP connection. - Section 4.3, page 10, limits the use of host_ids to middlebox only. The mechanism 1 (stripping off others host_id) options will not let arbitrary TCP end points to use this option for their own use. This falls in the same category as usually discussed that adding options in the data path will end up with removing options inserted by end hosts. - Section 4.4 disucsses that the order of multiple HOST_IDs cannot be guaranteed in the transit. However, it makes the recommendation to just concatenate any appearance of multiple HOST_IDs and use the concatenated value as the HOST_ID. How does this ensure that there are no two HOST_ID by different TCP connections that collide? It basically does not ensure this. - Section 7: - NATs do not provide any form of privacy, as there so many other mechanisms to determine the user of a data flow. - This section is not discussing the real security impacts, e.g., what is the result if any device is forging the information in the HOST_ID? Or can this be used to breach privacy of users, because a stable identifier is used across TCP sessions and applications?
I absolutely agree that a protocol -- even an experimental one -- that facilitates identification of individual hosts behind a NAT should go through the IETF consensus process.
conflict-review-boucadair-intarea-host-identifier-scenarios
The authors were "kind" enough to ack my comments sent whilst they were proposing that this be an IETF stream document. To be clear: those comments were entirely negative and very strongly against adoption for a variety of reasons. (My input to the thread starts at [1].) [1] https://www.ietf.org/mail-archive/web/int-area/current/msg03883.html From a quick look at the current table of contents and references for this version, I would guess that none of what I see as the numerous fatal flaws in this text have been addressed. (But I've not yet re-read this fully.) I think the IESG should discuss whether or not asking the ISE to add an IESG note would be appropriate in this case. If we decide not to do that, I'll pass my own comments to the ISE in any case, but I think given the previous forum-shopping and what seems like a lack of responsiveness to comment on IETF lists, an IESG note may be right in this case.
(This is really a discuss for discussion--I expect to clear it regardless, but want to make sure we think about the connection.) This may be okay, since this is a scenario document, but this seems pretty closely related to the tcp-host-id-opt draft, which we appear to be recommending against. The scenario draft even mentions it could be used as an input to solutions (assumedly like the tcp-host-id-opt draft.)
conflict-review-hao-mpls-ip-hard-pipe