IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2016-03-03. 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:
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:
3.1.2 Returning items
3.2 Individual submissions via AD
3.2.1 New items
Telechat:
3.2.2 Returning items
3.3 Status changes
3.3.1 New items
3.3.2 Returning items
3.4 IRTF and Independent Submission stream documents
3.4.1 New items
3.4.2 Returning items
1017 EST 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
Telechat::
Telechat::
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
Telechat::
Telechat::
7. Working Group News
1030 EST scribe left call
(at 2016-03-03 06:00:02 PST)
draft-ietf-siprec-metadata
(1) In section 10 you have a MUST for integrity and confid, which is good, but then RECOMMEND S/MIME, which is, I think, mythical. Wouldn't it be better to reflect reality (hop-by-hop TLS) and then say what actual security considerations arise, e.g. who might be on the path and how can they (mis)behave? (2) 6.10: Don't you need to say to use UUID version 4 with random numbers and to not use MAC addresses? IOW, refer to RFC4122, Section 4.4 for how to generate UUIDs. Note that issues related to both of the above were part of the discussion that ensued from the secdir review. [1] [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06370.html
- section 4, last para: How could an SRC know this and hence what it's safe to omit? - 6.9: I would have thought that more precision about fractional seconds support would be useful here, or else, to just say that you're limiting to single-second granularity. Wouldn't doing one or the other be better? Otherwise you might get different s/w ordering events in different orders unexpectedly.
I'm going to ballot no-objection on this, but I do have some comments = Substantive = - I'm confused about the associations between an RS (as modeled by <recording>) and a CS or CSG. As far as I can tell, a <recording> element is associated with a given CS/CSG by the fact of enclosing it. But the UML and related text indicates that a CS or a CSG can be associated with more than one RS. How does that work in the XML? Along the same lines, what would it mean for a CS or CSG to be associated with more than one RS? - 5.1: Does the xml doc contain _exactly_ one <recording> element? - 5.1.2: See question on 5.1. (Also, the normative language seems redundant between the sections.) - 6.1.2: Can you elaborate on "persistent recording" and why it removes the need for a CS/CSG? - 6.2: What does a CSG model? What does it mean for a CS to be part of a group or not part of a group? -6.2.2: The UML suggests that a given CS cannot be associated with more than 1 CSG. That’s worth mentioning here. - 6.3: Can a given CS be directly associated with an RS and also a CSG? (I guess that will always be true in the XML, but it's not apparent from the UML). -6.3.1, sipSessionID: I gather this is the session-id from the media session, not the recording session. If correct, it would be helpful to say it explicitly. - 6.3.3: "A stream in a persistent RS is not required to be associated with any CS..." It's not apparent how you would do that in the UML. I can see how you would do it by virture of being contained in a <recording> element. - 6.5.1: Remote-Party-ID? Citation needed ;-) - 6.10: Why not MUST? Can you envision good reasons to not use this method? -6.11: Do I understand correctly that means no extensions are allowed without changing the version number? Is that really the intent? -10, first paragraph: Why is the SHOULD not a MUST? Also, what does the SRC need to authenticate/authorize? -- 2nd paragraph: Do you really expect people to implement s/mime? -- last paragraph: I'm not sure what "Implementations MUST control what metadata is recorded" means. Is the point that the implementation must let someone control that policy? That it must not record unnecessary metadata? (If the later, how is "necessary" determined?) - 13.2: I think RFCs 3325 and 3326 need to be normative references. That's an issue for 3325, but section 6.5.1 normatively states that P-AID is a potential source for nameID. (which should probably be scoped to only be true for deployments where P-AID makes sense.) = Editorial = - Figure numbers and captions would be useful. - I found the organization to be a bit odd. Section 5 starts talking about some but not all XML details, then 6 goes over the UML model, but switches back to XML in the last few sections, then we've got more XML stuff (schema, etc) further down. - There are a lot of missing articles and commas, especially in the in section 6 and subsections. The RFC editor will fix this, but it would save them work if the authors did a proofreading pass, if they otherwise have reason to update the draft. - 6.1: It would have been helpful to mention that the <recording> element represented a recording session back when <recording> was first mentioned in section 5.
I don't see how a reader can understand this without understanding what an SRC,
an SRS, an RS, and a CS are, and those are defined in RFC 6341. Why isn't 6341
a normative reference?
Please expand "AoR" on first use. You might also cite 3261 there as defining
it. (I find it a bit odd that there's no citation to 3261 except in the
Security Considerations.)
You refer twice to "Unified Modelling Language(UML)": is there a reference for
UML?
On the other hand, while we're on references, I really don't think you need any
of the citations in Section 5.1.1 (and can remove their associated references).
No one reading this needs to know the details of what a URN is or how the ietf
URN namespace is organized (just like you don't have a reference for "URI", and
don't need it). I would just simplify it to this and take out the three
unnecessary references:
NEW
The namespace URI for elements defined by this specification is
the following URN:
urn:ietf:params:xml:ns:recording:1
END
A really tiny point (which the RFC Editor might also bring up): In Section
6.1.1 you refer to "a RS class" and "a RS object". Unless that's actually
pronounced "Recording Session" when you read it, it should be "an RS
[class|object]".
There are a lot of missing articles ("the", "a", "an") throughout. The RFC
Editor will fix these, but...
In Section 6.3.1, the definition of the "reason" attribute is slightly
confusing because "reason" is also an English word that can fit into the
sentences also. So, here:
The reason XML element has
'protocol' as an attribute, which indicates the protocol from
which the reason string is derived.
...I initially read "the reason XML element has 'protocol' as an attribute..."
differently to how you meant it. I suggest making it this:
The 'reason' XML element has
'protocol' as an attribute, which indicates the protocol from
which the reason string is derived.
I also suggest going back through this and consistently quoting the words when
they refer to attribute or element names, to distinguish them from just plain
English ("the 'session' XML element", "the 'reason' XML element", " 'protocol'
attribute", and so on). You could skip this for the camel-cased items (such as
"sipSessionID"), and the hyphenated ones ("group-ref"), because they can't be
confused with plain words... but it might be better to be consistent.
In Section 6.3.2, I don't like the two non-parallel lists at the end. I think
the RFC Editor will fix these, so I'll just point them out and let you decide
what to do (or not). (In contrast, the list in Section 6.5.2 is properly
parallel.)
In Section 6.9, just checking here:
As a security measure, the timestamp element SHOULD be included in
all tuples unless the exact time of the status change cannot be
determined.
Are there other reasons one might not include a timestamp element? Or is the
fact that you can't determine the time the only one? If the latter, then it
should be "MUST ... unless", rather than "SHOULD ... unless", and I think
that's what you mean.
draft-ietf-dprive-edns0-padding
Thanks for producing this draft. I do have one question about this text: The PADDING octets SHOULD be set to 0x00. Other values MAY be used; for example, in cases where there is a concern that the padded message could be subject to compression before encryption. PADDING octets of any value MUST be accepted in messages received. I'm not entirely sure I understand the point of "SHOULD be set to 0x00". I'm not questioning the SHOULD (you explain why choosing another value would be a good idea, thank you ), but I'm wondering why there's a normative requirement at all. I was trying to guess, and one hypothesis was that if the padding is consistently 0x00, it's less likely to provide a covert channel (or at least you'd be more likely to notice packets using different padding), but the security considerations section didn't mention that, so I'm still lost. If there's a reason to zero the padding bytes in the uncompressed case, a sentence of explanation might be useful.
- intro: "significantly hampering" is over-stated, even though you do limit that to size-based correlation as a form of traffic analysis. This is a basic mechanism (a fine thing) but by itself does not counter traffic analysis that much. See e.g. [1] for a relevant study. Referencing [1] and/or [2] and saying that this mechanism isn't itself enough would be a good improvement. ([2] is a colleague's work btw, but I think is good:-). Neither [1] nor [2] are DNS-specific, not sure if there are publications that cover that. Without such a caveat, people might over-claim and not do the right things. Happy to help craft words for that if you want. [1] http://kpdyer.com/publications/oakland2012-peekaboo.pdf [2] http://arxiv.org/pdf/1410.2087v2.pdf - typo: "meta data of could still"
Looking at this logic ... Responders MUST pad DNS responses when the respective DNS query included the 'Padding' option, unless doing so would violate the maximum UDP payload size. Responders MAY pad DNS responses when the respective DNS query indicated EDNS(0) support of the Requestor. Responders MUST NOT pad DNS responses when the respective DNS query did not indicate EDNS(0). ... I believe we need to improve the second paragraph. Taken out of context of the first paragraph, it might be misleading. Responders MAY pad DNS responses when the respective DNS query indicated EDNS(0) support of the Requestor and the 'Padding' option is not included. Editorial: However, even if both DNS query and response messages were encrypted, meta data of could still be used to correlate such messages with well known unencrypted messages, hence jeopardizing some of the confidentiality gained by encryption. One such property is the message size. meta data of?
changing my discuss to a comment since terry and the authors have a way forward that I am happy with and which I trust them to pursue. was - This is just something I want to discuss, it's not an objection... At this point we say: Implementations therefore SHOULD avoid using this option if the DNS transport is not encrypted. If you did allow this on unencrypted dns transport this seems like it serves as a utility function for DNS amplification. Wouldn't it be better to say MUST NOT? e.g. this is exclusively for use with TLS / DTLS supporting sessions?
draft-ietf-httpbis-alt-svc
- If TLS1.3 continues to have 0rtt replayable early-data, could that interact badly with Alt-Svc? Or what about false-start? For example, if such a combination meant that an otherwise functional replay detection scheme would fail to spot a replay that would be bad. This is not a DISCUSS, as neither TLS1.3 nor false-start are formally "done" so blocking this for that reason would be "odd";-) However, both are implemented or will be, so I would love to chat about it and that might lead to some new security considerations text, here or in a TLS document. - Does this still all work for opportunistic security for HTTP? If not, why not? Note: I'm not asking if the WG have reached consensus on oppo, rather I'd like to be reassured that if they do, this will still work for that. I think that's all ok, though, right? - section 3: with "clear" you say alternatives are to be invalidated. Does that mean anything about cached resources? I assume not, but just checking. - section 5: I wondered why you didn't include the ALPN identifier here? - 9.2: What does "might also choose" mean and which "other requirements" have you in mind? That's very vague. - 9.5: What are you telling me with the last para?
Just a few minor comments: = Substantive = - 2.2, last paragraph: Why might a client choose not to to remove non-persistent alternatives from cache on a network change? (i.e., why not MUST)? - 2.4, first 2 paragraphs: These paragraphs seem to be equivalent to saying “Clients MAY use alternative services; also they SHOULD.” Or is the intent that, if a client uses alternative services, it SHOULD do so under these conditions? = Editorial = - 2.3, first paragraph: I find "MUST only" constructions to be confusing and sometimes ambiguous due to the implied NOT. I suggest making that explicit: OLD A client MUST only use a TLS-based alternative service if the client also supports TLS Server Name Indication (SNI). NEW A client MUST NOT use a TLS-based alternative service unless the client supports TLS Server Name Indication (SNI).
A clear sentence such as this one would have helped me: OLD: This specification defines a new concept in HTTP, "Alternative Services", that allows an origin server to nominate additional means of interacting with it on the network. NEW: This specification defines a new concept in HTTP, "Alternative Services", applicable to both HTTP 1.1 and HTTP 2.0, that allows an origin server to nominate additional means of interacting with it on the network. I overlooked this info in the following sentence, i.e. the fact that HTTP header = HTTP 1.1: It defines a general framework for this in Section 2, along with specific mechanisms for advertising their existence using HTTP header fields (Section 3) or HTTP/2 frames (Section 4), plus a way to indicate that an alternative service was used (Section 5).
A couple of very nitty nits.
In this text
When the protocol does not explicitly carry the scheme (e.g., as is
usually the case for HTTP/1.1 over TLS, servers can mitigate this
^
I think there's a missing closing parenthesis right around here.
If there's not, I'm having trouble parsing the sentence.
risk by either assuming that all requests have an insecure context,
or by refraining from advertising alternative services for insecure
schemes (such as HTTP).
If there was an obvious reference for SPDY in this text
The Alt-Svc header field was influenced by the design of the
Alternate-Protocol header field in SPDY.
that might be useful to include.
Couple of places where the language used was confusing for me: = Sec 2.4 = s/it can be used until the alternative connection is established./the existing connection can be used until the alternative connection is established./ = Sec 3.1 = OLD Unknown parameters MUST be ignored, that is the values (alt-value) they appear in MUST be processed as if the unknown parameter was not present. NEW Unknown parameters MUST be ignored. That is, the values (alt-value) in which they appear MUST be processed as if the unknown parameters were not present.
draft-ietf-tsvwg-behave-requirements-update
- Thanks for the info about the IPR declaration in the write up. It's useful to know that. - intro: Phrases like "greatly advanced" always make me think I'm getting sales talk and make me wonder why. (In this case, there was no other sales talk though, and thanks for that:-) I think s/greatly advanced/documented/ would have been fine.
Some very minor comments: - I echo Stephen's thanks to the shepherd for the details on the handling of the IPR disclosure. - 14, third paragraph: Please consider changing the "MUST...only" construction to either "MAY...only" or "MUST NOT...unless". I personally prefer the latter. (OTOH, isn't this already covered normatively in section 3? Perhaps it could be descriptive here.) -- Third paragraph from end: s/"Hosts which require..."/"Hosts that require..."
draft-ietf-netext-logical-interface-support
I would have thought that noting that different layer 2 interfaces can have different security properties would be worth noting, even if we might not want to recommend that logical interfaces only group physical interfaces with similar security properties (which may be an interesting idea, but I can see it is also likely impractical today). I note that the secdir review [1] raises the same issue but I don't think there was a response to that. (If there was, apologies, I didn't find it;-) [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06352.html
As mentioned by Jürgen Schönwälder in this OPS-DIR: The 'grandfather' model for interfaces in the OPS world is RFC 2863 and RFC 7223 builds on that. I think your definitions are reasonably compatible (except that the other models do not restrict a logical interface to an IP interface). Perhaps it makes sense to discuss this related work or at least provide pointers, e.g., add a paragraph at the end of section 2 explaining how the terminology introduced here relates to RFC 2863 and RFC 7223? I also believe it would be a nice addition to the draft.
Juergen schoenwaelder performed the opsdir review againt version 12
draft-ietf-ntp-checksum-trailer
Question:
As described in Section 1, an intermediate entity that updates the
timestamp in the NTP packet can use the Checksum Complement in
order to maintain the correctness of the UDP checksum field.
I'm wondering about the "can use" here.
What is the alternative? Correct the UDP checksum field, which is incompatible
with your use case (hardware timestamping)? Or use the zero checksum (not
possible for IPv6)?
Isn't more like this?
As described in Section 1, an intermediate entity that updates the
timestamp with hardware timestamping in the NTP packet MUST use
the Checksum Complement in order to maintain the correctness of the
UDP checksum field.
And, for the record, I agree with Barry's questions.
-- Section 3.2 --
The extension field includes 22 octets of padding. This field
SHOULD be set to 0, and SHOULD be ignored by the recipient.
Why are these "SHOULD"? Under what conditions might a sender not set them to
zero? Under what conditions might a recipient not ignore it, and what might it
do if it doesn't ignore it?
Thanks for synchronizing this with the IPPM checksum trailer draft!
draft-sparks-genarea-mailarch-improvements
In this text:
o Provide a link on each row of the list to the URL for that row's
message.
o Add an export type that produces a file containing a list of URIs
to each message in in the list.
o Add a hint to the UI that double-clicking on a row in the list
will open a single-message view of the associated message in a
separate view.
"in the list" means "in the message list display", doesn't it? That may be
obvious in context, but I found myself wondering if someone could think things
like "oh, they want a list of URIs to each message in the mailing list", or
something equally confused.
"in (in) the list" has an extra "in", since I'm commenting on this text anyway.
I have a requirement to ask about. Note that I am not trying to convince you now to accept this if you don't want to, I'm just asking for clarification, as to whether or not you mean you'll meet my requirement. If your answer is "no, that's not what's meant" then please do consider this as a new feature request, and handle those as you think best, as part of this work, or later, or never. Here's my question: - Does section 3 mean that there'll be a way to get from the usual https://mailarchive.ietf.org/ view to an equivalent mhonarc view? I'd like if one could do that for an individual message or (maybe) a thread. I'd be ok if that function stopped working if we decided to not keep mhonarc archives too, but I, and I think some others, prefer mhonarc's simplicity when I don't need to search, and a lot of IETF list information pages now send me to this new archive so having a way to get to the mhonarc equivalent would be great. (That might also be a way to meet some of your non-JS requirement maybe?) - section 2.7: thank you!
I agree with Stephen that it'd be very nice to still have access to the old "by date" and "by thread" archive format.