IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2013-04-11. 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: Ted, Adrian
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning Items
2.2 Individual Submissions
2.2.1 New Items
Telechat:
2.2.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
Telechat:
3.1.2 Returning Items
Telechat:
3.2 Individual Submissions Via AD
3.2.1 New Items
Telechat:
3.2.2 Returning Items
3.3 IRTF and Independent Submission Stream Documents
3.3.1 New Items
Telechat:
3.3.2 Returning Items
Amy: 3.3.3 was assigned to Martin this morning
1242 EDT break
1248 EDT back
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat::
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
Telechat::
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
Telechat::
Telechat::
Telechat::
Telechat::
Telechat::
7. Agenda Working Group News
1310 EDT entered Executive Session
(at 2013-04-11 07:30:04 PDT)
draft-ietf-xrblock-rtcp-xr-burst-gap-loss
The way requirements and validation requirements are set out in this document
is hard to follow. I suggest the following changes:
Section 3:
OLD:
Metrics in this block report on Burst/Gap Loss in the stream arriving
at the RTP system. The measurement of these metrics are made at the
receiving end of the RTP stream. Instances of this Metrics Block
refer by Synchronization source (SSRC) to the separate auxiliary
Measurement Information block [RFC6776] which describes measurement
periods in use(see RFC6776 section 4.2). This Metrics Block relies
on the measurement period in the Measurement Information block
indicating the span of the report and MUST be sent in the same
compound RTCP packet as the measurement information block. If the
measurement period is not received in the same compound RTCP packet
as this Metrics Block, this Metrics Block MUST be discarded.
NEW:
Metrics in this block report on Burst/Gap Loss in the stream arriving
at the RTP system. The measurement of these metrics are made at the
receiving end of the RTP stream. Instances of this Metrics Block
refer by Synchronization source (SSRC) to the separate auxiliary
Measurement Information block [RFC6776] which describes measurement
periods in use(see RFC6776 section 4.2).
This Metrics Block relies on the measurement period in the
Measurement Information block indicating the span of the report.
Senders MUST send this block in the same compound RTCP packet
as the measurement information block. Receivers MUST verify that the
measurement period is received in the same compound RTCP packet
as this Metrics Block. If not, this Metrics Block MUST be discarded.
In section 3.2, the text is needlessly repetitive, and also doesn't say what
must be discarded; I suspect that it should be changed to something like this:
OLD:
In this document, Burst/Gap Loss Metrics can only be measured over
definite intervals, and cannot be sampled. Accordingly, the value
I=01, indicating a sampled value, MUST NOT be sent, and MUST be
discarded when received. In addition, the value I=00 is reserved
and also MUST NOT be sent, and MUST be discarded when received.
NEW:
In this document, Burst/Gap Loss Metrics can only be measured over
definite intervals, and cannot be sampled. Also, the value I=00 is
reserved for future use. Senders MUST NOT use
the values I=00 or I=01. If a block is received with I=00 or
I=01, the receiver MUST discard the block.
In section 3.3, there's a very awkward parenthetical note which refers back to
the first paragraph of section 3. This is the text that prompted my DISCUSS;
on review I see that rather than actually adding requirements to the sender and
receiver, it's merely reiterating them. The easy fix is to just take it out:
OLD:
The metrics described here are intended to be used as described in
this section, in conjunction with information from the Measurement
Information block [RFC6776] (which MUST be present in the same RTCP
packet as the Burst/Gap Loss block (see section 3,1st paragraph) )
and also with the metric 'cumulative number of packets lost' provided
in standard RTCP [RFC3550].
NEW:
The metrics described here are intended to be used as described in
this section, in conjunction with information from the Measurement
Information block [RFC6776] and also with the metric 'cumulative
number of packets lost' provided in standard RTCP [RFC3550].
However, of course the authors had some reason for putting this note into
section 3.3; if removing it entirely feels uncomfortable, how about something
like this?
OLD:
The metrics described here are intended to be used as described in
this section, in conjunction with information from the Measurement
Information block [RFC6776] (which MUST be present in the same RTCP
packet as the Burst/Gap Loss block (see section 3,1st paragraph) )
and also with the metric 'cumulative number of packets lost' provided
in standard RTCP [RFC3550].
NEW:
The metrics described here are intended to be used as described in
this section, in conjunction with information from the Measurement
Information block [RFC6776], which, as mentioned previously, must
be present, and also with the metric 'cumulative number of packets
lost' provided in standard RTCP [RFC3550].
I prefer the former edit, but something like the latter edit would also satisfy
me. I've removed my DISCUSS on this because now that I understand the context
better, I don't think this _has_ to be fixed. However, I would appreciate it
if the authors would consider fixing it; I think it would improve the
readability of the document.
Couple of minor things, and one less minor: In Section 1.1., 'this draft' should be 'this document' (hopefully, it won't be a draft soon!) In Section 5.1., Is there a reason that 'u' is the only letter left out of 'brst-gap-loss'? In Section 7., it seems worth noting that the gaps indicated with this XR block could be used to detect the timing of other events on the path between the sender and receiver. For example, a competing multimedia stream might cause a loss burst for the duration of the stream, allowing the receiver of the XR block to know when the competing stream was active. This is not a significant threat, however, because the only information leaked is the timing of the loss, not the cause.
- 2.1, 'specific time-window' could maybe do with a reference to RFC 6921? - 3.2, sum of burst durations has a max of <5 hours, which I guess is ok unless the 'period of the report' (where's that defined?) is very long. Is that ok? - 3.2, Do you need to say fields are unsigned values? All those 0xF.... might be a problem otherwise. (Maybe that's a general xrblock thing though.)
Did the performance metrics directorate review wrt RFC 6390 happen in the meantime?
Still waiting for a Gen-ART review on this document. I have done an overview review of the document myself.
Thanks for addressing the DISCUSS comments. We had a conversation in email about the contact info in 6.3. RFC 3611 did not itself provide specific contact information for the registrations it made, nor have some other documents (5093, 6679). Other documents have provided contact info, usually using an author, even though it is a standards track document. I suggest that contact information should *not* be used when IETF consensus documents are making the registration. Perhaps 3611 needs to be clarified. Though I'm not balloting DISCUSS, I would appreciate a few minutes to chat about this during the telechat.
Thanks for addressing my DISCUSS, and answering my COMMENT.
I agree with Pete's DISCUSS.
if peet's discuss is cleared I have no other objections.
draft-ietf-pkix-rfc2560bis
Section 5.1.2 contradicts section 5.1.1, in the sense that following the line of reasoning in 5.1.1 might lead to opening a window for a downgrade attack. I don't think there's an easy fix for this, but it argues to me that the advice in 5.1.1 about insufficiently secure algorithms ought to be removed.
Stefan has proposed the following change in 4.4.8, which addresses the point raised about that section in my earlier DISCUSS: 'If this extension is absent, the responder MUST NOT respond 'revoked' to a status request for a non-issued certificate.'
I have no objeciton to the publication of this document, and only two minor points which you can take or leave as you see fit. --- In Section 1... Additional mechanisms addressing PKIX operational requirements are specified in separate documents. When RFC 2560 was written, you could probably get away with this. Now those document probably exist so it would be good to include citations. --- I should have liked to see a summary of the configuration/management aspects of the protocol. There are a number of configurable values that could be called out into one section for convenience, but more important is to discuss how OCSP is managed and operated.
Thanks for making the document easy to diff against RFC 2560 :) These changes look reasonable, and the explanation in the introduction makes it clear why they were needed.
- Forgot to say: please consider the nits identified in the secdir review. [1] [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03874.html - Do we or the RFC editor have a policy on deceased authors? I can see why folks might leave a name on, but it doesn't really seem correct to me. Adding an ack that does or doesn't make it clear that that person is no longer with us would be better. - 3.1, it'd be good if more guideance could be given about the forms of URI the need to be supported, presumably http at least? The same could be said for other fields, where we have information about what implementations currently do. However, since the wpkops WG are planning to document that, I can buy the argument that its better to not delay this for that additional detail. - 4.2.2.1, why did the producedAt sentence here from 2560 get deleted? I think this is to be fixed in a -17, right? - 4.3, I'm surprised DSA/SHA-1 is still a SHOULD. Does anyone actually use it?
I won't comment on the security-related aspects: I'll trust the security experts. Let me, however, copy here Adrian's feedback, which makes a lot of sense: I should have liked to see a summary of the configuration/management aspects of the protocol. There are a number of configurable values that could be called out into one section for convenience, but more important is to discuss how OCSP is managed and operated. Maybe it's addressed already in one of the numerous pkix RFCs. I browsed throuhg http://datatracker.ietf.org/wg/pkix/, but it was not obvious to me.
I have a few points I want to talk about before we're done with this. Thanks
in advance for addressing these with me.
-- Section 2.2 --
The 'revoked' state indicates that the certificate has been revoked
either permanently or temporarily (i.e. the revocation reason is
certificateHold). This state MAY also be returned if the associated
CA has no record of ever having issued a certificate with the
certificate serial number in the request, using any current or
previous issuing key (referred to as a 'non-issued' certificate in
this document).
The 'unknown' state indicates that the responder doesn't know about
the certificate being requested.
A few things here:
1. I was confused for a while about the 'i.e.' parenthetical, but now I think I
understand that its scope is only the 'temporarily' part, not both 'permanently
or temporarily'. In other words, I first read it to mean that the only time
'revoked' would be returned would be when the revocation reason was
certificateHold. But now I think I understand that it means to say either
{permanently} or {temporarily (i.e., certificateHold)}. I think re-wording is
critical here. Moving 'temporarily' first might be the easiest answer. So,
also eliminating the unnecessary Latin abbreviation:
NEW
The 'revoked' state indicates that the certificate has been revoked,
either temporarily (the revocation reason is certificateHold) or
permanently.
END
2. I do not understand how 'the associated CA has no record of ever having
issued a certificate with the certificate serial number in the request, using
any current or previous issuing key' is substantively distinct from 'doesn't
know about the certificate being requested.' Please explain that.
3. I'm not really following the explanatory note that comes after this. What
sort of 'fall back mechanism'? Are you suggesting that we want to avoid having
requestors use OCSP as a way of checking validity of certs and revocation at
the same time (good == valid, revoked == revoked, unknown == invalid)? If so,
I think you need to be clearer about that. If not, I think you need to be
clearer about what you are trying cover.
4. The subsequent text, which prescribes a particular contrived 'revoked'
response (reason == certificateHold, revocationTime == 1 Jan 1970) seems to
make this particular type of 'revoked' response distinct from others anyway.
Doesn't that defeat the mechanism you're trying to create, by allowing
requesters to distinguish them?
5. If they are *not* distinguishable, are we quite certain that there will be
no undesirable client effects that result? Is it really OK to have a
possibility that a completely unrecognized cert can get any response, 'good',
'revoked', or 'unknown'?
-- Section 2.7 --
If an OCSP responder knows that a particular CA's private key has
been compromised, it MAY return the revoked state for all
certificates issued by that CA.
6. I know this hasn't changed since 2560, but... is 'MAY' really all we want
here? Not 'SHOULD'? Shouldn't we be strongly encouraging dissemination of
information about CA compromises, and isn't there a way to make this a
RECOMMENDable thing?
-- Section 4.2.2.3 -- The response MUST include a SingleResponse for each certificate in the request and SHOULD NOT include any additional SingleResponse elements. OCSP responders that pre-generate status responses MAY return responses that include additional SingleResponse elements if necessary to improve response pre-generation performance or cache efficiency. (According to Section 2.2.1 of [RFC5019]). This doesn't seem to be a correct use of 'SHOULD NOT' and 'MAY' together. Remember that 'MAY' specifies that something is entirely optional. I suggest not using 2119 key words in the second sentence, and making it clear that it's giving a reason for the previous 'SHOULD NOT'. Maybe this?: NEW The response MUST include a SingleResponse for each certificate in the request. The response SHOULD NOT include any additional SingleResponse elements, but, for example, OCSP responders that pre-generate status responses might include additional SingleResponse elements [...] END Nit: The parenthetical at the end is a sentence fragment; attach it to the end of the previous sentence: 'efficiency (according to [RFC5019], Section 2.2.1).' (By the way: the HTML generator will generate a link fragment in the RFC to the specific section, if you use '[RFC5019], Section 2.2.1', but not if you use 'Section 2.2.1 of [RFC5019]'.)
draft-ietf-tls-multiple-cert-status-extension
If this document were updated to reference 2560bis instead of 2560, I think this text could simply be removed, since the correction is present in 2560bis: In the case of the 'id-pkix-ocsp-nonce' OCSP extension, [RFC2560] is unclear about its encoding; for clarification, the nonce MUST be a DER-encoded OCTET STRING, which is encapsulated as another OCTET STRING (note that implementations based on an existing OCSP client will need to be checked for conformance to this requirement). If the authors do not want to reference 2560bis for some reason, then the above language seems to me to update 2560. The items in the list of CertificateStatusRequestItemV2 entries are in order of the client's preference (favorite choice first). Does the idea of 'favorite choice first' really make sense? Either an OCSP responder is trusted or not, right? I'm not so clear on the architecture here that I can be sure this question makes sense, but I wonder if randomizing the list doesn't make just as much or more sense than ordering it according to some unspecified notion of favorites.
Thanks for quickly handling my discuss points! I note the 2560/2560bis issue still needs fixing and am ok that that'll be done. If the answer is that 2560bis becomes the normative reference then that's fine, but in that case I do think it'd be good to retain the text that clarifies how to handle id-pkix-ocsp-nonce if you're coding this based on a 2560 and not a 2560bis implementation, since that will be the case for a while yet. And that'd mean keeping 2560 as an informative ref too.
Two points that I would like some clarification on: 1. It seems like this document should Update RFC 6066. It doesn't change anything in the document, but it's effectively a 'v2' of the OCSP status request extension. 2. It seems like this document should reference RFC 2560bis instead of RFC 2560.
In the Abstract, this phrase seems unclear: 'multiple certificate status methods (commonly referred to as OCSP stapling)'. Suggest: 'multiple certificate status methods. (The use of the Certificate Status extension is commonly referred to as 'OCSP stapling'.)' In Section 2.2., it would be helpful if you could clarify which parts are new, and which are restated from RFC 6066. In Section 2.2., 'see also' should be 'as defined in'
draft-ietf-appsawg-webfinger
This is a really neat idea, and while the protocol specification seems reasonably solid, it's still got some pieces missing. Specifically, the security model for this work is alluded to, but left as an exercise for the reader. Section 6, paragraph 1, talks about authentication, but doesn't require it, nor does it define any default access control mechanism. Paragraph 2 talks about revealing different amounts of information to different users, but doesn't explain how this would work, nor describe default behavior or a default model for deciding how such information might be filtered. There are some good ideas expressed in section 6; what this draft needs, arguably, is one of two things: First option, add substantial additional text describing the authentication model, the access control model and the data filtering model. Second option, write up a separate document describing a model for how this would be done, and then reference that document from this document. This would be preferable in my mind because such a model would be useful for more than just webfinger. Not being knowledgable in this space, perhaps such a document already exists and could be referenced. But without this, what we have is essentially what we had in 1977 with the finger protocol. The state of the art has evolved significantly since then; we have Google Plus, which supports public access to restricted data, plus various levels of sharing on the basis of circles, and we have Facebook, with detailed privacy settings. These models evolved not in the abstract, but as a response to user demand. This document addresses a need similar to that addressed by Facebook and G+ user profiles, but in a distributed fashion. With a solid security model, I think it would be very beneficial. So the action for this DISCUSS, if it isn't clear, is to develop a security model. I realize that's a big ask, but without a security model I think this document is going to cause a lot of harm, or else not get used, neither of which is a desirable outcome.
I've been following the conversation about privacy as it relates to automatic querying of data by user agents (e.g., your mail application). I think this is a useful and valuable function, but I have been unsatisfied by the responses that I have been seeing on the topic of how to prevent this from turning into an attack surface through which information probes can be sent. I think this snippet illustrates the problem best: However, this thread is starting to head down the path of mail user privacy issues, not WebFinger privacy issues. Even if we removed the example, it would not preclude a MUA from doing this. And the example provides a very good use of WF, IMO. It *is* functionality that I would like to have. If I am so paranoid about my privacy, I would disable the WF feature. If I'm paranoid that people will learn when I read email, I'll stop downloading images, I'll batch replies, and I might even set a timer to have them sent out when I'm asleep. I'm just not that concerned. When I hit send on this message, the world will know I'm sitting at my computer. That's the way things work and I'm OK with it. The problem here is that we are being presented with a false dichotomy: no security, or disable the feature. But this doesn't address my needs. I like the idea. I want the feature. But I don't want it to turn into a privacy hole. This is very easily addressed, since it's not even a problem with webfinger per se—just a problem with how someone might _use_ webfinger. The solution: add some text to the security considerations section. I would suggest adding some text to section 8.3: Automatic user agents such as mail readers and web browsers SHOULD NOT automatically query webfinger on the basis of unsolicited messages received over the network. For instance, a mail reader that has the capability to query webfinger for information about the sender of an email message, such as an avatar, jabber ID, etc., SHOULD NOT issue such a query unless the message has been validated as coming from a known source, and unless the source appears on some kind of white list available to or maintained by the mail reader. Implementors are advised that merely checking the 'From:' header or the 'envelope from' header of an email message is definitely not sufficient validation, because such headers are easily forged in the absence of some additional validation mechanism, such as PGP, S/MIME (for per-message validation) or DKIM [RFC 6376]. I don't know if this would satisfy Stephen's concerns about privacy, but it would satisfy mine—I agree with the authors that the privacy issue is only incidentally a webfinger issue. Oh, one last thing: I agree with Pete's DISCUSS on this: although it's fairly obvious to me what the authors intend with respect to the acct URI, it's seriously underspecified, and I don't believe that it would be obvious to every potential reader of the document. I don't have a specific action for this, so I'm not adding it as a DISCUSS, but it bears thinking about. E.g., if the _only_ transform we're expecting is s/mailto:/acct:/, then that's really easy to specify; why not specify it? If we're expecting other possible transformations, do we have any idea what they might be? Jabber IDs? I think Kerberos principals were mentioned in some conversation; are they also fair game?
I have no objection to the publication of this document, but I have
some questions/concerns. Apologies if these are stupid questions
caused by lack of clue - and in that case please just respond with
'this would be obvious if you had any idea what you were talking
about.'
---
Can the WebFinger source provide that his information can be accessed
at different levels by different people. For example, make his blog
and website available to everyone, but his phone number require a
specific access level?
---
I don't understand how the source can certify that the information
being read from the server is information he supplied rather than
information that a malign (or error-prone) third party has placed
on their own WebFinger server. Can the information be signed as a
set such that information outside the set is marked as not
authenticated?
As I understand it, the value of the information supplied by the
WebFinger server depends on the level of trust that the reader places
on the server. Obviously, if my email is hosted by example.com, then
I might trust that the information I write (perhaps through a web
interface) to the example.com server will be present in the WebFinger
response, but what if example.com decides to add to the information or
place data there that I do not want made public? Is the claim that this
is simply an issue for the commercial relationship between me and
example.com? How does the reader distinguish between information I have
supplied and information example.com has decided to add?
Furthermore, it isn't clear to me what control there is on example.org
supplying WebFinger responses for an example.com user. That is, if the
request is:
GET /.well-known/webfinger?
resource=acct%3Abob%40example.com HTTP/1.1
Host: example.org
---
I was a bit uneasy about calling the process in the example in Section
3.3 'autoconfiguration'. I think, in fact, it is just normal
configuration. But, of course, it is remote configuration. Perhaps its
would better be called 'Configuration Retrieval'.
---
I am really uneasy about the inclusion of the example in section 3.4.
Not only is it 'totally fictitious', but I think it is widening the
scope of WebFinger into dynamic device-level information. That sort of
thing needs, IMHO, a wider discussion within the IETF.
Since the example is not a real one and is dependent on extensions to
a spec that might not be extended and is out of scope for the IETF,
perhaps we can regard the section as 'marketing' in support of
WebFinger. Since WebFinger has clearly been accepted as an idea, would
it be possible to delete this section?
There would also be a small change to the Introduction as well.
1. In general, this seems like more of a 'framework' document than an actual protocol. It concerns me to put something like that on the Standards Track without some plan to add more specificity. As the document stands, it defines a generic system for mapping an octet string to a set of attribute/value pairs. While that level of generality can be useful for building applications, it makes it hard to evaluate the security and privacy implications. I think this is what's at the root of Stephen's DISCUSS points on the examples. If this were part of a working group that were chartered to define details, this would be fine as a first deliverable. But it doesn't really seem to stand on its own. Setting those concerns aside for the moment, I have some concerns about the interoperability of this protocol. While the JSON body returned from a query is well specified, the process of making a query is much less so. 2. Section 4.1. does not actually tell the implementor how to construct a WebFinger URI. A few issues/questions that need to be addressed: 2.1. What are the inputs to this process? An 'acct:' URI and optional 'rel' values? 2.2. How does one choose the host part of the WebFinger URI? 2.3. The section as it currently stands allows arbitrary octet strings to be placed in the 'resource' and 'rel' fields. Is that really your intention? It seems like these should be constrained to something like the syntax of the 'source' and 'rel' fields in the JRD, namely, an ASCII token or URI. 2.4. The scheme and path paragraphs from 4.2. should be moved up to this section. 3. Section 4.2. I couldn't figure out what HTTP methods a client is allowed to use. It seems to me that it would be sensible to allow only GET, unless there is a concrete use case for something else. 4. Section 4.5. says 'use of the 'acct' URI scheme is recommended, since it explicitly identifies an account accessible via WebFinger'. This does not seem compatible with what is in draft-ietf-appsawg-acct-uri, 'Therefore, any protocol that uses 'acct' URIs, such as the WebFinger protocol [I-D.ietf-appsawg-webfinger] or the Simple Web Discovery protocol [I-D.jones-simple-web-discovery],' Suggest removing this text. 5. In general, the use of 'acct' URIs do not seem all that useful. The only way they are used in the example use cases are (1) as a replacement for a 'mailto' URI, and (2) as a 'dummy' URI scheme for a 'user@host' string lacking other context. In the former case, you might as well have just used the 'mailto' URI. The latter case is kind of artificial, since the whole example is premised on the use of 'acct'. It might help motivate these URIs if Section 4.1. actually used part of the resource URI to derive part of the WebFinger URI, e.g., using the host part of the URI as the host for the WebFinger URI. 6. In Section 5., the requirement that servers MUST send an Access-Control-Allow-Origin is kind of useless; since the server can put any value it likes in the header, it can put in something bogus, in which case it would be the same as if the header were omitted. So the CORS requirements should either be a SHOULD, or a MUST that also requires '*'. The latter case might seem a little extreme, but it might not be unreasonable. The server can always filter requests based on the Origin header; the only thing CORS does is push the filtering to the browser, arguably making the server less secure. 7. With regard to Section 8.2., I agree with Stephen that there should be some mechanism specified for users to control what information is accessible about them through WebFinger. What's even more concerning here is that it's not even clear which servers a user should contact to control his information. If my address is 'mailto:rlb@example.com', do I just need to contact the WebFinger resources at 'example.com'? Or is it possible that there's some other WebFinger server out there serving information about my address, say 'http://evil.com/.well-known/webfinger?resource=mailto%3Arlb%40example.com'? This is another area where a tighter specification would help.
As will be seen, I (still) have issues with the privacy aspects of this specification. Some of those are most apparent through the use-cases/examples so I've taken the unusal step of DISCUSSing those since they really seem to convey the real intent of this protocol. To an extent, some of the suggested changes there do represent personal preferences of mine but I believe that the DISCUSSion is still worth having between the authors and IESG and perhaps the WG. (1) 3.1, having the MUA automatically do the webfinger thing is a privacy disaster and would cause MUAs to visit sources of spam continually and to expose the email addresses of their correspondents. Other references to having a UA automatically do webfinger also need to be deleted kind of behaviour needs to be the subject of a 'MUST NOT' statement IMO. In fact, it already is, since 8.2 says: 'WebFinger MUST NOT be used to provide any personal data to any party unless explicitly authorized by the person whose information is being shared.' Having a MUA automatically send out a WF request where the query target is the mail sender/from contradicts this requirement. The 3.1 example also fits the anti-pattern given in 8.3. Suggested fix, easy: say that a MUA MUST NOT do the automatic thing, as per 8.2, which would be a fine forward reference. (2) 3.3, this example is odd - why should Sue expose her username in this interaction - there's no occurrence of anything clearly user-dependent in the response except what was given in the request. Why should we expose user information unnecessarily in this manner? I think the fix here is for user Sue to send a request for 'anon@example.com' and for the text to specifically say that making use of the real username isn't a good plan and making use of an invented non-existent string for username in this case is a fine plan and perhaps even specifying such a 'nonexistent' username value that can be supported by and understood by all clients and servers and saying when it'd be sensible to use that. (3) 3.4, making devices discoverable like this, esp if device type and firmware revisions were to be exposed represents a significant increase in an existing risk. (We had a recent discussion related to vCard for a similar use case.) This section seems to be too speculative to be honest, so I'd suggest just deleting it. If not, maybe add text like that added in the vCard case. (4) 4.2, can you explain the security consdiderations associated with re-directing a client from https://example.com to https://example.net? Why don't you need to do that explicitly in the document? I think you might need to explicitly say that in re-direct cases, both sessions MUST be good TLS sessions or else clients might well accept 3xx from a MITM. Are there no requirements to compare the original request and final response? (I could buy that but want to check.) (5) 8.2 and 8.3, given the privacy and abuse considerations here why is there no definition for the DELETE method in order to provide a way for users to be able to at least ask that their information no longer be available? Or another .well-known URI could be used. Was that discussed? (6) 8.3: A possible missing security consideration - I think it'd be good if this section said that WF servers SHOULD implement mitigations against harvesting or overuse of WF, perhaps via rate controls or other mechanisms.
- Thank you for requiring TLS! That's a good precedent. - intro: 'facilitate logging into a web site' hmm, lots of security alarm-bells ring there, maybe better to say 'facilitate, with additional security mechanisms, logging into a web site' or choose a non-security example? - 3.2, I'd much prefer that the security of this kind of interaction be explained, if only by reference, e.g. add something like 'the security aspects of this kind of interaction are discussed in [ref].' If such a [ref] exists then that ought be easy and useful. If no such [ref] exists that would be interesting. - 4.1, I'm a bit confused here. Can I use WF to ask about 'http://tcd.ie/thing?foo=bar&baz=bat' as the query target? I think this section says that's ok but I'm not sure so maybe I'm confused. Maybe making that explicit would be good. I'm also not sure that its ok to not percent-encode the '?' in that query target but I guess it must be ok if you've said nothing about it. - 4.3, the example 'rel's are http URLs and not https. Are these intended never to be de-referenced? If so, maybe say so and that its therefore ok to not insist on https? If not, then I think you do need to say that de-referencing those URLs can invalidate some of the confidentiality guarantees provided by requiring TLS for WF. - 4.4.3, same comment as for 4.3; maybe for 4.4.4.x too - section 7 uses the term 'service URI' - I think that and 'query target' and 'subject URI' would be better defined up front - 8.1, you don't say if you require certificate status checking. It'd be better to say. - 8.2, this is outstandingly glib: 'If one does not wish to share certain information with the world, do not allow that information to be freely accessible on the Internet or discoverable via WebFinger' - most users are never given a choice as to whether or not much of their information is freely accessible or not. I think the best that can be done with that is to delete it.
Just a comment: I would add an informative reference to RFC 1288, just for historical completeness. Not everybody still knows finger.
I support Stephen Farrell's questions on privacy, however.
[All: As I noted earlier to the Webfinger mailing list, I have Cc'ed this to the Webfinger list along with the document authors, the document shepherd, and the rest of the IESG. Also note that I intend to DISCUSS this until Thursday. If I get no further support from the IESG and/or the WG that this is a serious and showstopper problem, I will simply ABSTAIN on both this and on the -acct-uri document (on which I also currently have an open DISCUSS position). But it looks like Richard and I are in some agreement on this.] There appears to be a big giant semantic gap for the client side of this protocol. I can find nothing in the document that indicates to the client how it shall determine what sort of URI to use is the resource part of the query or what the semantics of any given URI are supposed to be. I suspect that the semantics are so underspecified that there could not possibly be interoperable implementations without lots of out-of-band information. The first example provides a mapping from an email address (or perhaps a mailto URI; that's not clear) to an acct URI, but neither the example nor anything in the rest of the document gives any clue why you would choose to query an 'acct' URI based on the contents of an email message. I think the assumption is that if there is an email address, there must be some sort of 'account' associated with it, and therefore querying the host on the RHS of the '@' for that account will get some interesting information. But I don't see any reason to choose an 'acct' scheme over 'mailto' or 'smtp' or 'email' or 'foobar'; as far as I can tell, the choice is semantics-free. Reading the above alongside 3.3 makes me all the more suspicious: In 3.3 (also mentioned in 4.5), a 'mailto' URI gets you configuration information for all email configuration parameters. Does an 'acct' URI get you configuration information for email *and* xmpp *and* sip *and* calendaring *and* all other configuration information (since you are no longer asking for a particular protocol, but rather the general account information), or do you only get 'information' about the person and not their account? (I might also insert privacy and security worries here, but see Stephen's DISCUSS regarding that.) How can the client know what sort of information it can ask for and how to get it? And for that matter, how does the server tell what information to pass back? You'd think there would be a hint about this in 4.3, but 'rel' only seems to provide for the client to request those things that the client already knows about it. In particular, there appears to be no way to say, 'Give me user provided information, but not config information' or 'Give me config information, but not blog entries'. I find the semantics for 'device' in 3.4 all-the-more mysterious. As far as I can tell, this URI scheme simply means, 'Give me all of the information for the entire host.' Again, the semantics of all of these interactions seem so underspecified that I don't understand how interoperation is supposed to happen. This also leaves me with the question about why the resource query part is a URI at all. It seems to me that the resource you are asking about is not a URI (or URN) at all; it's simply an identifier for an entity that the particular host knows about. Given that, why not pass a simple identifier? (See http://datatracker.ietf.org/doc/draft-ietf-radext-nai/ for example.) If the scheme is not providing any particular semantics about the response, I see no reason to provide the scheme. If more semantics (beyond rel) are needed, another parameter indicating the type of identifier being used seems much more appropriate than using a URI scheme.
I agree with Stephen's concerns re: privacy.
Replying to a single point below from Adrian's review, which Adrian and I just discussed privately. Thanks to Adrian for opening up my eyes on something I overlooked. > > > I am really uneasy about the inclusion of the example in section 3.4. > Not only is it 'totally fictitious', but I think it is widening the > scope of WebFinger into dynamic device-level information. That sort of > thing needs, IMHO, a wider discussion within the IETF. > > Since the example is not a real one and is dependent on extensions to > a spec that might not be extended and is out of scope for the IETF, > perhaps we can regard the section as 'marketing' in support of > WebFinger. Since WebFinger has clearly been accepted as an idea, would > it be possible to delete this section? > > There would also be a small change to the Introduction as well. This comment made me re-read the abstract and the introduction, and triggered some new thoughts. They implicitly mention the query of static information, except for the sentence ' for example, the amount of toner in a printer or the physical location of a server.'. I overlooked the fact that the example in Section 3.4 is actually about status report. The section 3.4 title is 'Retrieving Device Information', but you really mean 'Retrieving Device Status Information'. And I have an OPS problem (*) with this WebFinger potential applicability to status reporting, because now, WebFinger is comparable to SNMP, polling a MIB OID to get the printer toner level. The solution is to stress that WebFinger is targeting the query of static information (i.e. not reporting)
I support both Pete's and Stephen's DISCUSS points.
8.2 Further, WebFinger MUST NOT be used to provide any personal data to any party unless explicitly authorized by the person whose information is being shared. This is a usage guideline not a part of the protocol specification. At a minimum it should use non-normative language. probably it should be replaced with a description of the potential for exposure. 8.3 When discussing abuse potential, the document neglects to think about the potential for clients to reveal information about themselves based on the information that they are asking about. particularly in the context of phishing that might actually be goal of sending someone a webfinger uri. In the context of the automatic retrevial of uri's by agentts as described in 3.1, this is certainly the case.
draft-saintandre-urn-example
I have no objection to the publication of this document. In your position: - I would not have sent this out as a BCP, but would have made it standards track as it allocates 'codepoints' - I would have tidied the Abstract to remove 'and the like' possibly replacing it with something more specific if there is anything that can be said. - Not have encouraged 'private testing' using the 'example' namespace. If an experimental namespace is needed, I think it should exist separately. That said, I don't have a strong enough opinon on any of these three points to do more than flage them for consideration.
I am ambivalent about whether this is appropriate for PS or BCP. Other points made by the Farrel(l)s seem reasonable to consider.
- I was confusd a bit by this, (before I asked Barry:-) Its not clear when or if its ok for this BCP to be used as the basis for an IESG DICSUSS. I think it'd be great if this spec were more clear that its entirely ok to use 'urn:example:foo' in almost all cases without anyone having to register 'foo' with IANA. And that'd imply that it'd not be ok for an AD to put on a DISCUSS saying 'you need to go register foo as a sub-namespace with IANA before using urn:example:foo' - section 4: Why does the NSS *need* to be a unique string? I suggest s/needs to/is best as/ Section 2.6 gets this right I think though.
Christer Holmberg made this comment: Editorial nits: Section 2.6 contains the word “counseled”. While not wrong, is there a reason why more common IETF language can’t be used here? E.g. “recommended against”, or something? :)
Like others, I don't find the analogy to 'X-' headers appropriate. That is, it doesn't really seem like the arguments against 'x-' in RFC 6648 really apply here. By that analogy, you would be expecting example URNs to leak into standards-like usage, which it seems like you are expressly not trying to do here. The better analogy would be to RFC 3849 -- things you never would expect to see in the real Internet. That said, this URN namespace is a fine thing to have.
DISCUSS-DISCUSS Like Adrian, I'm confused by the connection between private testing and an 'example' namespace. You should expand on: how you plan on using this 'example' namespace in private testing. An example would be good. Most importantly, what is the connection between using the experimental NID (RFC3406) and this 'example' namespace used for private testing? You mentioned: The experimental namespaces take the form 'X-NID' (where 'NID' is the desired namespace identifier). Because the 'x-' convention has been deprecated in general [RFC6648], it seems sensible to achieve the same objective in a different way. I don't see anywhere in this BCP which namespace I should use for my private testing/experiment. In my mind, private testing = experiment. And I don't get what you meant, in your reply to Adrian, with 'in documentation, private testing, and truly experimental contexts.' I was hoping to see a sentence such as: The experimental namespaces [RFC3406] MUST not use the 'X-NID' form any longer. Is this implied by [RFC6648]? Alternatively, I was hoping for a sentence such as: the experimental namespaces [RFC3406] MUST not use any longer, and the 'example' namespace MUST be used instead. This draft just gives 'a different way to achieve the same objective.'. So what is the BCP in this document? I'm confused, so I filed this as DISCUSS-DISCUSS.
I think I am more confused by Stephen's comments than the text itself.
draft-ietf-intarea-nat-reveal-analysis
This title of this document suggests that it is scoped to all address-sharing models, but in fact the text about host identifiers only accurately relates to DS-Lite. I think the document is relevant to all address-sharing models, but really reads as if it were written specifically with DS-Lite in mind. I'm just throwing this comment out to see what reaction it gets; I'm not convinced that there's an action item here. If the authors really do intend to address all address-sharing models, some tweaking of the wording in section 2 would help, and maybe a mention in section 3 that in a MAP or lw4over6 scenario, port set allocation is mandatory and host identities don't need to be revealed at all—only the HG identity is actually revealed.
A few minor revisions: In Section 1. Adding a comma to 'application proxies or A+P' would help clarify that the two are not equivalent. In Section 3.1. The sentence after 'Interference between HOST_IDs' didn't really parse for me. Suggested revision: 'If an address sharing system can inject multiple types of HOST_ID value at different layers, then all injected HOST_ID values must reference the same underlying data. For example, one might reference a full IP address, while another references the lower 16 bits.' In Section 4.2.2. Change 'host-hint' to 'HOST_ID'. In Section 4.3.2., Second bullet. It might also be worth noting that including the HOST_ID in the ACK would interfere with TCP Fast Open. If the server wanted to deliver different data based on HOST_ID, then it would have to wait for the ACK before transmitting. <http://tools.ietf.org/html/draft-ietf-tcpm-fastopen> In Section 4.6.1. It could be helpful to reference some current BEHAVE-related work here: <http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements> <http://tools.ietf.org/html/draft-donley-behave-deterministic-cgn> In Section 4.8.2., next-to-last bullet. It might be more helpful to reference the NAT-specific logging documents being developed in BEHAVE: http://tools.ietf.org/html/draft-ietf-behave-ipfix-nat-logging http://tools.ietf.org/html/draft-ietf-behave-syslog-nat-logging
- abstract: saying 'is used' makes the reader think that you will provide a preferred solution, but since you're not going to, 'could be used' would be better. - abstract: Saying 'a remote server' without qualification is odd - do you mean any other host on the Internet and do you really mean a server only? Maybe an 'authorized remote host' would be better? - section 2: it might be clearer if you clarify that you still mean a host when that host is one computer in a home behind a DSL modem. I think that's implied, when you say that HOST_ID is not designed to reveal the identity of a subscriber, but it'd be good to be extra clear on that. - section 3: shouldn't possible solutions say if they allow for some control somewhere as to which remote hosts can or cannot freely access the HOST_ID? In particular some of the possible solutions seem to differ in how the user's ISP could or could not control some of that on behalf of the user. - section 3: similarly the solutions differ as to whether or not middleboxes or just the remote hosts with which a user wants to interact can track users and that's also a consideration esp. if TLS were used. - section 3: a HOST_ID can also expose location information depending on how its done. (And without any geopriv style protection.) I think that should get a mention here too and also be considered by HOST_ID specification documents. I think that also warrants a mention in 3.1. - section 3: Shouldn't the honest end-user also be given some element of control too? I think adding a design consideration that different end-user preferences should be supported would be good. - section 3.1: I think all the above points on section 3 would be fine additions to 3.1 (of course:-) - section 5: I think 'encrypted traffic' here means encryption via TLS or above, is that right? What about IPsec? Anyway a note on that would be good. - section 5: the 'success ratio' figures don't seem to correlate that well with the earlier 'analysis' sections which surprised me. (just a comment) - the end: ...is very abrupt:-) I guess the WG just couldn't reach even a rough consensus on something to recommend? If so, it might be worth saying a bit about that if its not too controversial as that might help future readers know what to do with this document.
Updated based on the discussions as of 4/11 Here are my DISCUSS issues: 1) Section 1., paragraph 3: > The risk of not mitigating these issues include: OPEX (Operational > Expenditure) increase for IP connectivity service providers (costs > induced by calls to a hotline), revenue loss for content providers > (loss of users audience) and customers' dissatisfaction (low quality Content providers usually do not have issues with NATs, as the did get used to it in the last 15 years (or so). For instance, you can run your favorite social media site and move between private and public IP addresses, even move between IP address versions, and they can exactly identify you. So this is a non issue here. They have HTTP cookies, browser finger printing, web bugs, URL signing etc. It is very limited to HTTP, but that's where most of the content is flowing over, isn't it? I would suggest to remove the content provider part. 2) Section 4.2.1., paragraph 1: > A solution alternative to convey the HOST_ID is to define an IP > option [RFC0791]. A HOST_ID IP option can be inserted by the > address-sharing function to uniquely distinguish a host among those > sharing the same IP address. An example of such option is documented > in [I-D.chen-intarea-v4-uid-header-option]. This IP option allows > the conveyance of an IPv4 address, an IPv6 prefix, a GRE (Generic > Routing Encapsulation) key, an IPv6 Flow Label, etc. The description and also the analysis is neglecting any MTU issue: If some middlebox is adding an IP option to a packet, the packet might just to big for the path MTU. Further, what happens if the options space in the IP header is already occupied by other options? Please document the issues as you did also for the other approaches. 3) moved to the comments section. 4) Section 4.3.1., paragraph 1: > HOST_ID may be conveyed in a dedicated TCP Option. An example is > specified in [I-D.wing-nat-reveal-option]. This option encloses the > TCP client's identifier (e.g., the lower 16 bits of its IPv4 address, > its VLAN ID, VRF ID, or subscriber ID). The address-sharing device > inserts this TCP Option into the TCP SYN packet. Adding a TCP option somewhere in the e2e path is contradicting the e2e approach of TCP -- this is an architectural concern that cannot be easily addressed. Further, what should the middlebox do, if the TCP option space is already fully occupied by other options in a packet? Not insert the HOST_ID option, let the TCP connection fail, or remove some other TCP option? FIXED & done: The MTU issues can also be present in TCP SYNs if at any future time TCP SYNs carry already user data, see also draft-ietf-tcpm-fastopen-03. 5) Section 5., paragraph 5: > Provided success ratio figures for TCP and IP options are inspired > from the results documented in [Options], > [I-D.abdo-hostid-tcpopt-implementation], [ExtendTCP]. Can you please explain how you come to 99 % success ratio for TCP with new options? The latest data in [ExtendTCP] does not support your figures. The reference [Options] is outdated, as it is dated 2005 and the network has changed a lot.
This draft is proposing, or at least elaborating, a lot of hacks in order to determine specific hosts behind a NAT (irrespectively if it is a CGN or not). However, I do not see any viable approach in this that can be deployed in a wider scale, as each solution has its severe limitations. 4.3. Define a TCP Option This section is referring to a number of individual drafts that describe some solution approaches that have not tested in wider deployments, nor do they have received adequate community review in my opinion. E.g., wing-nat-reveal-option and abdo-hostid-tcpopt-implementation.
4.4 You talk about HTTP here, which more or less has the same mechanism as SIP, but you don't really go into SMTP. SMTP can do similar things, but the mechanisms are going to be much different than HTTP or SIP. It's not even alluded to in section 5. I'd say either analyze SMTP properly, say something like, 'Related mechanisms could be developed for other application-layer protocols, but the discussion in this document is limited to HTTP and similar protocols', or drop it from the discussion completely. 4.5.1 The solution, referred to as Proxy Protocol [Proxy], does not require any application-specific knowledge. The rationale behind this solution is to prepend each connection with a line reporting the characteristics of the other side's connection as shown in the example depicted in Figure 2. The header line shown in this example is for a TCP over IPv4 connection received from 192.0.2.1:56324 and destined to 192.0.2.15:443. The 'PROXY' string is used to identify the Proxy Protocol while '\r\n' indicates CRLF. You wouldn't know what the above was talking about unless you read the Proxy document. I suggest: The solution, referred to as Proxy Protocol [Proxy], does not require any application-specific knowledge. The rationale behind this solution is to insert identification data directly into the application data stream prior to the actual protocol data being sent, regardless of the protocol. Every application protocol would begin with a textual string of 'PROXY', followed by some textual identification data, ending with a CRLF, and only then the would the application data be inserted. Figure 2 shows and example of a line of data used for this, in this case for a TCP over IPv4 connection received from 192.0.2.1:56324 and destined to 192.0.2.15:443.
No objection on the publication of this document, but please engage the discussion on my COMMENT. From the abstract The host identifier must be unique to each host under the same shared IP address. And later on: Because HOST_ID is used by a remote server to sort out the packets by sending host, HOST_ID must be unique to each host under the same IP address. Shouldn't the HOST_ID be unique across IPv4 and IPv6, so unique per host, as the name implies? I have in mind a scenario such a MultiPath TCP with two addresses, IPv4 and IPv6. If agreed, this following sentence is not correct The volatility of the HOST_ID information is similar to that of the internal IP address: a distinct HOST_ID may be used by the address- sharing function when the host reboots or gets a new internal IP address. If disagreed, I believe that the term HOST-ID is wrong. What you speak about is actually a HOST-IPADDRESS-ID, or mabye a HOST-NAT-ID.
Comments about the shepherd writeup:
'This document does not define a protocol. Hence there are no implementations
of this document.'
Well, but the document 'analyzes a set of solution candidates to mitigate some
of the issues encountered when address sharing is used.' There certainly could
be implementations of some or all of these solution candidates, and it would be
useful to know about those.
'In particular, as a result of WG consensus, this version of the
draft does not make any recommendations as to a preferred solution
among those analyzed.'
I would have appreciated a brief summary explaining why the working group did
not want to make any recommendations -- that would have been a useful part of
the working group discussion for the shepherd to summarize, especially given
the answer to question 9 (and my former DISCUSS, because I didn't understand).
------------------------------------------------------------------------------
On the document:
-- Section 1 --
Total nit: in paragraph 1, 'SPAM' is not an acronym, and the custom is to spell
it with no caps, as 'spam'. The canned meat is 'SPAM' or 'Spam', and those are
trademarked.
-- Section 2 --
HOST_ID is not designed to reveal the identity of a user, a
subscriber, or an application. HOST_ID is designed to identify a
host under a shared IP address.
I understand that it's not *designed* to reveal the identity of a user.
Nevertheless, it's *likely* to reveal the identity of users often. Because you
address privacy issues in Section 3, I think this paragraph needs a forward
reference to that section.
-- Section 3 --
The proposals considered in this document add a measure of
identifiability back to hosts that share a public IP address. The
extent of that uniqueness depends on what information is included in
the HOST_ID.
The extent of what uniqueness? Do you mean 'the extent of that
identifiability'?
The volatility of the HOST_ID information is similar to the source IP
address:
Later in the paragraph you say 'internal IP address'. For clarity, you should
be consistent in how you refer to the IP addresses on either side of the NAT.
Also fixing a nit, I think this should be, 'The volatility of the HOST_ID
information is similar to that of the internal IP address:'.
-- Section 3.1 --
Uniqueness of identifiers in HOST_ID: It is recommended that
HOST_IDs be limited to providing local uniqueness rather than
global uniqueness.
I don't understand how that matters at all: as you point out above, if the
HOST_ID is locally unique, the combination of it and the external IP address is
globally unique. Perhaps an explanation of what you're actually recommending
and why might make this clearer.
In fact, I think that's true of all four items in this section: I'm having
trouble understanding the real point of any of them, so a bit more explanation
of what they're really trying to say, and including 'why', would really help.
-- Section 4.1.1 --
You cite RFC 6864 here, and that document consistently refers to the field
you're talking about as 'the IPv4 ID field'. You're calling it 'the IP-ID
field'. Wouldn't it make sense to make your usage consistent with that of the
document you're citing?
Note that this field is not altered by some NATs; hence,
there are some side effects such as counting hosts behind a NAT
Not altered: isn't that the point? I thought the whole *point* of this was to
provide a HOST_ID that survives the NAT and can be inspected outside. Now I'm
confused.
Address-sharing devices using this solution would be required to
indicate that out of band, possibly using a special DNS record.
What is the antecedent of 'that'? This seems very odd in a paragraph all on
its own.
-- Section 4.1.2 --
Complications may arise if the packet is fragmented before reaching
the device injecting the HOST_ID. To appropriately handle those
packets, the address-sharing function will need to maintain a lot of
state.
'The packet' and 'those packets' disagree in number, making this confused.
Perhaps you mean, 'To appropriately handle the multiple packets created by
fragmentation, ...' ?
one can argue this coordinated NAT scenario is not a typical
deployment scenario but still using IP-ID as a channel to convey a
HOST_ID is ill-advised.
I can't parse this, and don't know what you're trying to say (though I do get
that the end result is that this is ill-advised). Perhaps you need some
punctuation?
The risk to experience session failures due to handling a new TCP
Option is low as measured in [Options].
[I-D.abdo-hostid-tcpopt-implementation] provides a detailed
implementation and experimentation report of a HOST_ID TCP Option.
[I-D.abdo-hostid-tcpopt-implementation] investigated in depth the
impact of activation HOST_ID on the host, the address-sharing
function, and the enforcement of policies at the server side.
[I-D.abdo-hostid-tcpopt-implementation] reports a failure ratio of
0.103% among top 100000 websites.
I strongly suggest that you re-word this paragraph. Having three citations to
the same document in three consecutive sentences is really awkward, and the
whole thing is choppy and hard to follow.
-- Section 5 --
o 'Success ratio' indicates the ratio of successful communications
with remote servers when the HOST_ID is injected using a candidate
solution.
Measured how? So these are actually coded and people did experiments? Are
there raw numbers that we can look at?
Ah, I see that you kinda-sorta try to answer this below the table. Please
re-organize the text (or maybe just use a 'see below' reference) so that it's
clearer what this row of the table means and where it comes from. (Mostly, I'm
sensing that it's a 'wild guess', rather than anything remotely real.)
(7) The solution is a theoretical construct.
In other words, this is just an idea that someone threw out, which isn't
completely baked? It would have been *really* nice to have said that up in
Sections 4.1, 4.6, and 4.7, rather than only including it as a note in this
table!
-- Section 7 --
You should refer to Section 3 in here. Perhaps insert a new third paragraph
that says something like, 'For more discussion of privacy issues related to
HOST_ID, see Section 3.'
I support Martin's #2.
no objection once the current dicuss points are resolved.
draft-ietf-savi-threat-scope
I suggested the following changes to the authors, which they have agreed to: In section 4.2.3.2: OLD: When SLAAC is used for IPv address assignment, the switches can observe the SLAAC messages and use those to create the enforcement bindings. NEW: When SLAAC is used for IPv6 address assignment, the switches can observe the duplicate address detection messages and use those to create the enforcement bindings. In Section 8: OLD: Until every Internet-connected network implements source address validation at the ultimate network ingress, and assurances exist that intermediate devices are to never modify datagram source addresses, source addresses must not be used as an authentication mechanism. NEW: Even if every Internet-connected network implements source address validation at the ultimate network ingress, and assurances exist that intermediate devices are to never modify datagram source addresses, source addresses cannot be used as an authentication mechanism.
I had a huge discuss on this back in 2011. Since I've lost most of the state, (apologies for that), I've re-reviewed this starting from my old discuss points and the delta from -05 to -07. If there are things that were resolved via mail 2 years ago, please do point me at the mail so we can clear those points quickly. (The discuss is alreayd only about half as long, so we are getting there:-) A note on discuss-worthiness of these points: I think that SAVI has clear downsides in terms of its potential for worsening privacy problems, so I think its important that this document very accurately characterise what SAVI can and cannot do, since otherwise SAVI standards documents are liable to stray too far towards privacy intrusive features even if those may not be very effective in countering threats resulting from source address spoofing. (1) Intro, 3rd para: What is the evidence that 'Source address verification is necessary in order to detect and reject spoofed packets'? I'm asking why this is 'necessary' as opposed to sufficient. I'd suggest 'Source address validation allows for detection and rejection...' (2) p4, 1st para: Where in the SAVI charter is 'local traceability' in scope? The concern is that SAVI mechanisms could be (and probably will be) used for tracking users, but tracking users is not in scope for the WG and touches on RFC 2804. I'd suggest just deleting the phrase or maybe defining it so its limited to tracing attacks. (3) Spoofing is defined on p5 to cover both IP and MAC address spoofing. SAVI does not address the latter I believe (right?). If so, then I think best is to limit the term when used here to refer to IP address spoofing and exclude MAC address spoofing. If you don't do that, then I suspect many of your uses of the term won't be correct. (4) Does the ARP example in 3.2.1 really involve a spoofed IP source? I think this isn't correct - if an IP address is spoofed here its not a 'source IP address' meaning that field in an IP packet but the spoofing rather occurs a field within the payload of the ARP message. (Or am I mis-remembering?) So if SAVI devices were to help here, they'd need to also be watching specifically for this kind of threat to be countered, which seems odd - will SAVI also watch to check if SIP messages used spoofed IP addresses in their payloads? I'm also not sure this fits with your definition of spoofing. Clarifying that this kind of attack isn't countered by SAVI would be good. More generally, it'd be good to say somewhere which parts of sections 3 and 4 are really things where SAVI can help. (5) cleared (6) cleared (7) cleared (8) cleared (9) Section 6: 'If address usage can be tied to the kinds of anchors described earlier, then it is possible to respond to security incidents.' SAVI is not needed for responding to all incidents. Maybe say SAVI can help and not say that its absolutely needed. (10) cleared (11) If binding anchors are personally identifying or stable over time or location then recording those create new possibilities for tracking the user or host associated with the binding anchor. That needs to be noted, but is not (I mean the persistence issue). I think you need to add guidance that introducing SAVI creates this kind of threat, but that frequently deleting bindings might be a good mitigation, or this might be a reason to want to have some form of more dynamic binding anchor.
3.1.1: Expand 'LAND' A very quick search for 'LAND attack' via duckduckgo turns up https://en.wikipedia.org/wiki/LAND as the very first hit.
I support Stephen's DISCUSS on this document.
I enjoyed reading this document: I found it well written, informative, and interesting. I have only a few non-blocking comments, all editorial, mostly at nit level. -- Section 3.1.1 -- Another form of blind attack is a RST probe [RFC0793]. Forgive me, please: this is a general peeve of mine, and I'm applying it here. OK, so I go to RFC 793. I search for 'RST probe'. Guess what: I don't find it. RFC 793 is 85 pages, and I have *no idea* where in RFC 793 you're trying to send me with that citation. If this needs a citation at all, it needs one that will help. This one doesn't help. Can you please do better (refer to a section number, or use a reference phrase that I *can* find in a search of the cited document)? [I'll leave off the discussion of whether it's pronounced 'an R-S-T probe' or 'a Reset probe'. :-) ] -- Section 3.2.2 -- Use of 'sighted attack' as a synonym for 'non-blind attack' might not work so well with non-native English readers, and could also invite confusion with 'sited attack' (which might refer to an attack that's tied to a particular network site). Probably best to avoid it, especially as this is the only place it's used. -- Section 4.2.3 -- However, establishing this binding is not trivial, and varying across both topologies type and address allocation mechanisms. There's a part-of-speech problem here. Maybe you want 'varies', rather than 'varying'? Or some other rewrite, because 'topologies type' doesn't work either. -- Section 4.2.4 -- Another pet peeve of mine (I have quite a menagerie): the phrase 'needless to say' is pretty much always silly. If it really doesn't need to be said, don't say it. But, in fact, what's *really* needless to say is 'needless to say'. Need I say more? -- Section 5.2 -- This paragraph is troubled: one very long sentence with severe commatosis (some extra, some misplaced, and some actually missing). May I presume to offer a re-write?: NEW From the perspective of network topology, consider hosts connected to switch ports that may have one or more IP addresses, and devices that forward packets from other network segments: it is much harder to enforce port-MAC-IP bindings on traffic from such hosts and devices. END And then think about the 'much harder' bit: much harder than what? What's the antecedent here? Or is it sufficient just to say 'hard' or 'difficult'? -- Section 5.2.1 -- The most obvious example of devices that are problematic when attempting to implement port-MAC-IP bindings is that of routers. The 'that of' is wrong, but, really, the sentence is upside-down (the subject is at the end). How about this?: NEW Routers are the most obvious examples of devices for which it is problematic to implement port-MAC-IP bindings. END -- Section 5.2.2 -- Another difficult paragraph, with a few grammatical problems. Maybe (also eliminating the Latin): NEW Validating traffic from Prefix-based and multi-address NATs is also problematic, for the same reasons as for routers. Because they may forward traffic from an array of addresses, validation requires advance knowledge of what IPs should be associated with a given port-MAC pair. END -- Section 5.2.3 -- While tractable, this creates some complexity for determining where enforcement logic can or should live. I don't think 'tractable' is the word you want here: I think 'tractable' has a connotation of ease of manipulation -- it refers to something that's *easily* done. The sense I get from what you're saying is that it can be done, but it's *not* easy. Perhaps 'feasible' (or even 'possible') works better here. Logically distinct hosts such as are provided by many varieties of virtualization logic result in a single physical host, connect to a single port on the Ethernet switch in the topology, actually having multiple internal virtual machines, each with IP and MAC addresses, and what is essentially (or sometimes literally) an internal LAN switch. There are missing commas in the beginning of this (before 'such as' and before 'result'), and then far too many comma-separated clauses in one too-long sentence. I suggest that you re-word this, and try to split it into two sentences. -- Section 7 -- No action here, but I have to give you the award for the longest 'empty' IANA Considerations section ever.
I have no issues with the publication of this document. The following are non-blocking points that I have derived from the document modulo the comments/issues raised by other ADs... * 'At the IP Network Layer, or Internet Layer, there is typically no required transactional state when communicating...' just reads wrong to me. IP does not require transactional state, so why is 'typically' thrown in there? Can you provide an example of where *IP* needs any state? * Section 3.2.1 describes a mechanism for performing on-link hijacking using ARP and then says 'Similar vulnerabilities exist in IPv6 NDP'. However, the ARP attack is effective mainly due to the use of broadcast messages. It would be good to take a few sentences to explain *how* the corresponding NDP attack would be carried out since broadcast messages are not used in IPv6 and the message validation & neighbor cache update rules defined in 4861. * Was there a reason why Section 4.2 does not describe some of the existing (albeit proprietary) solutions that have been widely deployed? For example, the Cisco Clean Access Agent is capable of doing some of this validation. Or was there a conscious decision to only focus on standardized solutions? * Section 4.2.3.2 says the following about IPv6 SLAAC-based addresses : 'This enables the switches to ensure that only properly claimed IP addresses are used for data traffic'. But, it can do more than that. If the switch is snooping NDP traffic, it can create MAC<->IPv6 mappings that allow the switch to drop packets that do not have the correct MAC/IP source address pairs. * Section 5.2.6 : Another possible option is that MIP Home Agents can act as an enforcement point prior to forwarding received traffic from mobile hosts.
A useful document which I enjoyed reading
draft-merkle-ikev2-ke-brainpool
Based on Stewart Bryant's response: That only takes an IETF LC with the down-refs call out. Indeed I think that if you change the track and regenerate the LC text the tool does that for you. I am going to hold a DISCUSS on this until we discuss it in the telechat. I am not deeply attached to an outcome either way, and fully understand the authors' motivation for going with Informational—I would just like us to hold off on approving the document until we've discussed this.
I agree strongly with Stephen Farrell's advice that you remove the IPR section—I think it contains no useful information, and arguably creates the potential for increased liability for implementors, since it may be more difficult for them to claim that they didn't know about whatever patents may, in the future, surface. I think you would be hard-pressed to find a protocol implementor today who is not keenly aware of the risk of a submarine patent, so there is no special need to call out that risk in this document.
+1 to Stephen's comments on Section 5 and RFC 6090.
- I don't really like how this document has a section (5) that says 'there may be patents' but yet there are no IPR declarations for this and hence no concrete information. The authors did explain that they put this in because they worry that the ideas referenced seem like the kind of thing that'd be patented but that they don't know of any such patents. I can understand that but this seems to me to just add to the IPR FUD around ECC and would be better deleted I think. - Section 5 also refers to 2.1 but I think you mean 2.2? - Don't you need once of RFC 6090 or SEC1 to be normative since you're using the FieldElement-to-OctetString conversion function from one of them? I'd much prefer 6090 be normative.
Just two nits: Section 5., paragraph 1: > Although, the authors have no knowledge about any intellectual > property rights which cover the general usage of the ECP groups > defined herein, implementations based on these domain parameters may replace 'may' by 'could'. Section 5., paragraph 2: > require use of inventions covered by patent rights. In particular, > techniques for an efficient arithmetic based on the special > parameters of the twisted curves as explained in Section 2.1 may be > covered by patents. replace 'may' by 'could'.
I agree with Stephens comment on Section 5
conflict-review-templin-v6ops-isops
- The title and text read a bit like a BCP, I assume that's ok with OPS folks, in which case its ok for me. - Figure 1: you could explain a bit more about where the value 5efe comes from in the text after the figure. (Maybe that's obvious to someone who knows ISATAP, but that someone is not me:-)