IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2013-08-15. 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: Heather, Ted, Barry
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning Items
2.2 Individual Submissions
2.2.1 New Items
2.2.2 Returning Items
Telechat:
2.3 Status Changes
2.3.1 New Items
2.3.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
3.1.2 Returning Items
Telechat:
3.2 Individual Submissions Via AD
3.2.1 New Items
Telechat:
Telechat:
Telechat:
3.2.2 Returning Items
3.3 Status Changes
3.3.1 New Items
3.3.2 Returning Items
Telechat:
3.4 IRTF and Independent Submission Stream Documents
3.4.1 New Items
Telechat:
3.4.2 Returning Items
3.4.3 For Action
Telechat:
Telechat:
1208 EDT no break
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat::
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
Telechat::
4.2.2 Proposed for Approval
Telechat::
1240 EDT break
1245 EDT back
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
Telechat::
Telechat::
Telechat::
7. Agenda Working Group News
1313 EDT Adjourned
(at 2013-08-15 07:30:07 PDT)
draft-ietf-mpls-ldp-dod
- abstract: "specific to access" reads oddly, "specific to access networks" might be better - abstract: "fast-up convergence" isn't that clear (but I think I get it) - if there were a way to describe that in plainer language that'd be nice - I was surprised that the seamless draft is informative and not normative. Not objecting, just surprised. - intro: "access border routers (access ABRs)" seems like an oddly recursive acronym (a recursive RA:-), or maybe just a typo? - The security considerations section seems very thorough, thanks! One question though - it wasn't clear to me if there are any security mechanism(s) that are mandatory to implement - can you clarify? It may well be that that's ok for this document, and that adding some MTI security, if it were needed, ought be done elsewhere, but it just wasn't clear to me whether something here is MTI or not. - Thanks for addressing the secdir reviewer's issues as well.
Has there been a response to Gen-ART review comments from Francis Dupont?
I find this document to be quite informational indeed: well written, clear, and thorough. Thanks for the good work. Comment below has been addressed, and is retained here for posterity. -------------------------------------------- From the shepherd writeup: There has been a dioscussion if this as a Standards Track or should be Informational. Since the document specifies a new LDP TLV we have found that it needs to be on the Standrds track. In fact, the registration policy for the LDP TLV Type Name Space registry is IETF Consensus (see RFC 5036, Section 4.2), and Informational would work perfectly well. If that is the deciding reason the working group chose Standards Track over Informational, we should reconsider that now. Adrian has clarified: > I think in this case the document is describing a protocol extension to a > standards track protocol. That extension is intended for wide-scale > implementation and is neither a vendor-specific extension, not a description > of how you use existing protocol mechanisms to achieve something. Thus, > "standards track" was chosen not a requirement of the registry, but as a > statement about the content of the document.
My understanding is that this draft is simply reducing the amount of state that access nodes need to keep, as a cost optimization, and does not introduce new TSV concerns because data plane traffic would end up in the same place if MPLS routers advertise MPLS labels for all valid routes in their RIB, as they would do if Downstream On Demand was not available. As an aside, I've been reading MPLS-related drafts from time to time since the early 2000s, and found this one to be one of the clearest drafts I've seen. Good job! One nit: 4.3.2. Label Request Retry Following LDP specification LDP specification [RFC5036], if an access LSR/ABR receives a "No route" Notification in response to its Label Request message, it retries using an exponential backoff algorithm similar to the backoff algoritm mentioned in the LDP session "algorithm" negotiation described in Section 4.2.
I am voting yes, but have one small comment that I am confident that Adrian will look at: "If remote LFA is enabled, access LSR/ABR needs a label from its alternate next-hop toward the PQ node and needs a label from the remote PQ node toward its FEC/destination. " Remote LFA surely needs a reference as does PQ.
nicely done!
draft-ietf-karp-crypto-key-table
I am entering a short Discuss since my attempts to discuss this point by email have not produced a result. - Is this document intended to establish a registry for secure routing protocols or for all security protocols? - If general-purpose, how is this a legitimate product of the KARP working group? - If specific to routing protocols how is this language in the document consistent with that claim? - Why is the registry populated only with 802.1X? Essentially, and bluntly, please convince me that you are not using the KARP working group as a way of introducing a registry (that may or may not have value) that is not use by KARP but has some other unstated purpose.
I have no objection to the publication of this document as it stands,
but it is not clear to me why this document, coming out of KARP, only
populates the IANA registry with one value for a non-IP and non-routing
protocol. Surely KARP could have seeded the registry more richly, and
surely the document could have discussed the relevance of IEEE 802.1X.
I suppose this is intended to be covered by the charter work item
- Define one or more frameworks describing the common elements for
modern authentication in routing protocols.
but the discussion of routing protocols in this document seems at best
peripheral.
I would also appreciate you looking at the points below to see whether
they are issues, and fixing them if necessary.
---
I struggled with the term "security protocol".
Section 1 has:
Security protocols such as TCP-AO [RFC5925]
But I also see:
security protocols such as cryptographic
authentication for routing protocols.
I think that you are defining "security protocol" to be "any protocol
where messages are exchanged in a secure way." Is that so? Would it be
possible (whether I am right or not) to include a clearer definition
for the reader?
---
Section 2
Interfaces
The Interfaces field identifies the set of physical and/or
virtual interfaces for which it is appropriate to use this key.
When the long-lived value in the Key field is intended for use
on any interface, this field is set to "all".
Do you mean that it is set to the value "all" or is it set to a local,
implementation-dependent value that indicates "all interfaces"?
---
Section 8.1.1 lists three things that the registry must include:
- Protocol Name (unique within the registry);
- Specification; and
- Protocol Specific Info.
Section 8.1.2 shows the registry with three columns:
Protocol Protocol Specific Info Reference
While I can assume the mapping between these, perhaps they should be
consistent?
I hope this is a very short-lived DISCUSS. You never define "string" in section 2, but you do say: To accommodate manual key management, the format of the fields has been purposefully chosen to allow updates with a plain text editor and to provide equivalent display on multiple systems. That reads to me like maybe these things are expected to be US-ASCII. But then you say: The AdminKeyName field contains a string identifying the key by humans. (Side comment: That's worded really badly. I think you mean "The AdminKeyName field contains a human-readable string meant to identify the key for the user." Or something like that.) Do you intend the AdminKeyName to be internationalizable? If so, then here or 5.1 needs something more: 5.1 Key Names When a key for a given protocol is identified by an integer key identifier, the associated key name will be represented as lower case hexadecimal integers with the most significant octet first. This integer is padded with leading 0's until the width of the key identifier field in the protocol is reached. What if they are *not* identified by an integer? (Can that happen?) In that case, do you want them to be Unicode characters? In some particular format? The requirement that they be editable by a "plain text editor" doesn't quite make it clear what you mean. Something additional is needed.
Sorry to add to the DISCUSS points on this. I do think this will be a useful specification in the end and is a fine piece of work that's almost there - hopefully my questions here will be easily resolved. (1) What'd happen if I merge two databases (e.g. if I buy some new bigger kit that replaces multiple devices) and the admin key name collides? Should you add a key-table-name property that should be selected so as to avoid collisions? (2) section 2: Having registries for KDFs and AlgIDs here seems wrong, or maybe I'm confused. Either the protocol that uses the DB will specify the KDF and AlgIDs or it will not. If it does, then any such registry will be part of the protocol itself. If it does not, then I don't see how I get interop without having a specificaiton for the input bits to the KDF, etc which are not always obvious and are not specified here. Either way, the KDF registry here seems useless given that there's a registry for the Protocol field. What am I missing? (3) section 2: Direction - How would you support a key with "both" here but that is used with a KDF and direction-specific KDF inputs? I thought some of the NIST KDFs might have that property when used in protocols.
- section 2: AdminKeyName "by humans" seems wrong, I think you mean "for humans". The last sentence in this definition also hides a uniqueness requirement. I agree with Pete's discuss on i18n here. - section 2: Is there a bug in the cardinality of PeerKeyName vs. Peers? It reads as if I can have e.g. 3 Peers for a unicast case and each of those can have their own local key name, but yet I can only store one peer key name. - section 4: this seems a bit vague to me fwiw, I wondered if someone has actually tried this with a real key management protocol? (E.g. see my discuss points about KDFs above) - Should you say something (e.g. in sections 1 or 7) about keys that are stored in a HSM? I guess this spec is really not for those.
Thanks for writing this useful document. I support this work, and will gladly recommend its approval. However, there is one issue that I would like to understand first about the scope of the document and the proposed database's interaction with possible other databases in the same system. In particular, I would like to understand if the proposed database has some relationship to the IPsec PAD. For instance, if I had a box that had both IPsec and the proposed database, would there be some interaction or could information in the new database be used also for protocols such as IPsec? Or is the scope of the document related only to routing protocol applications (which might not use IPsec at all)?
I would like to talk with the authors/WG about why FCFS is the appropriate policy for the KDFs and algorithm identifiers. Can someone tell me the rationale that the WG used when this was decided? FWIW, I am very supportive of relatively open IANA policies, but I want to understand why they make sense here.
Support Pete's DISCUSS on this. It feels like this document is kind of trying to define a syntax, without actually doing it. It would make things a lot clearer if you could actually define a concrete syntax, at least at the level of fields. Also the AdminKeyName definition is mangled.
Minor point: there's an obvious (to most) formatting problem in Section 2, "AdminKeyName", introduced in -08.
One question - in 3. Key Selection and Rollover
(3) If an interface is specified, the Interfaces field includes I
or "all";
This sentence didn't parse for me. Is s/specified, the/specified and the/
what's meant?
This draft contains the use of several 2119 keywords, yet does not contain the 2119 boilerplate or a reference to 2119.
Isn't it normal for the abstract to precede the boiler-plate?
draft-ietf-weirds-rdap-sec
In 3.1, the section reference to RFC 5246, section 7.4.6 is broken, and actually links to section 7.4.6 in this document. If you are using xml2rfc, this is easy to fix, and worth fixing. It would be nice if this section linked to some document that described authentication based on CA signature; this is an interesting technique that I think is very applicable here, but I've never heard of it being used before, and it's sufficiently similar to server key signing that it's easy to imagine someone getting it wrong. The concern is that they will think that "CA" means a regular CA, rather than a CA operated jointly by the federation of RIRs. For example, if they imagined that Thawte was a CA in the sense that this document means, then anybody who got their client key signed by Thawte would get access, but I'm pretty sure that's not what you intend. Otherwise, looks great. Thanks for writing it!
- I don't get what the "Document quality" section of the write up is saying about secdir review. - I somewhat disagree with the last part of Barry's comments. The issues we've experienced with trusted-CA lists have all related to TLS server authentication, and afiak, not to client-auth, which is what's at issue here. So, if a warning is to be added, it'd relate to the list of CAs that RDAP servers trust for client-auth and not to the (large and sometimes problematic) list of CAs that browsers ship with in the current web pki.
(1) The Authentication section should be Client Authentication, since that's all it covers. Shouldn't there be some discussion of Server Authentication as well? (2) I don't see anything here or in draft-ietf-weirds-using-http that says that RDAP clients MUST support TLS. Shouldn't that be the case, since HTTPS is the standard security mechanism? You should probably also consider how this would impact requirements around URIs for RDAP services.
Just a few points in Section 3.1.1 -- nothing blocking, but I ask you to consider addressing these, please: The OAuth authorization framework [RFC6749] describes a method for users to access protected web resources without having to hand out their credentials. Instead, clients supply access tokens issued by an authorization server with the permission of the resource owner. Using OAuth, multiple RDAP servers can form a federation and the clients can access any server in the same federation by providing one credential registered in any server in that federation. The OAuth authorization framework is designed for use with HTTP and thus can be used with RDAP. One small point in the middle of that: the clients have nothing to do with supplying access tokens. The clients use access tokens that are given to them. OLD Instead, clients supply access tokens issued by an authorization server with the permission of the resource owner. NEW Instead, clients are issued access tokens by authorization servers with the permission of the resource owners. OR Instead, a client is issued an access token by an authorization server with the permission of the resource owner. END OpenID [OpenID] is a decentralized single sign-on authentication system that allows users to log in at web sites with one ID instead of having to create multiple unique accounts. An end user can freely choose which OpenID provider to use, and can preserve their Identifier if they switch OpenID providers. I would say "at multiple web sites with one ID". certificate authentication method can be used to achieve federated authentication in which multiple RDAP servers all trust the same CAs and then any client with a certificate issued by a trusted CA can access any RDAP server in the federation. It's important to note that there are problems with client authentication through this mechanism, which have interfered with widespread deployment. For example, there are issues with too-promiscuous, or even rogue, CAs that get themselves into trusted-CA lists. There are also proposals to address that. Fully getting into the issues is well beyond the scope of this document, but I think it's important for this document to warn of the problem and point readers in the right direction to find more information. There's nothing in the Security Considerations about this now.
In 3.1. Authentication, this text:
RDAP SHOULD be capable of supporting future authentication methods
defined for use with HTTP.
is a great idea, but I don't think it's a 2119 SHOULD ("SHOULD unless" what?
and how would you know you'd achieved that?).
If you could point to work in progress that RDAP might consider, or say what
kinds of things in RDAP would likely be problematic, then you could say that
RDAP needs to be prepared to use new methods if necessary, and I would be
happier with that language.
But if you mean:
Work on HTTP authentication methods continues. RDAP ought to be
agile enough to support additional methods as they are defined.
or something like that, I'd encourage you to say what you mean :-)
In a companion document,
http://tools.ietf.org/html/draft-ietf-weirds-using-http-07#section-5.5 ends
with this paragraph:
Note that this is not a defense against denial-of-service attacks,
since a malicious client could ignore the code and continue to send
queries at a high rate. A server might use another response code if
it did not wish to reveal to a client that rate limiting is the
reason for the denial of a reply.
I found that very helpful. Would it be helpful for this paragraph to appear in
http://tools.ietf.org/html/draft-ietf-weirds-rdap-sec-04#section-3.3?
I agree with Spencer's comment about the mis-use of SHOULD when referring to future security features.
s3.1 contains the following: To that end, RDAP clients and servers MUST implement the authentication framework specified in "HTTP Authentication: Basic and Digest Access Authentication" [RFC2617]. Does that mean the client and server need to support both basic and digest? s3.1: I think the gist here that should maybe be made clearer is that servers need MUST implement TLS with server side certificates - no? What I'm curious about here is whether there should be a SRV-ID or URI-ID is needed for RDAP and isn't some kind of reference to RFC 6125 warranted here?
Am a little disappointed that this didn't take on the integrity of the objects themselves. but it looks fine as far as recommendations go.
draft-ietf-weirds-using-http
This document doesn't talk about security, which sort of makes sense considering the other weirds document we're reviewing in the same telechat. However, I am concerned that there is a gap between the two documents that leaves open the possibility of password leakage. Suppose I go to an RDAP server wanting some information that is confidential, and requires authentication. Further suppose my request is to an http URL, not an https URL. Presumably the RDAP server would tell me I need to authenticate, by sending an HTTP 401 response. Suppose basic authentication is being used. The server must first redirect me to an https server, which _then_ would send the 401 response. If the response to the http query is 401, the client may send the password over the network in the clear, since this is allowed by the HTTP protocol. In practice, I would expect that anything that needs to be authenticated is going to have to go over TLS anyway, so this should be straightforward to specify. Possible responses to clear this DISCUSS would be (a) to point out that I am an idiot and this isn't a problem because I don't understand HTTP authentication properly (I know only enough to be dangerous, so this is a real possibility); (b) to argue that this needs to be fixed but should be addressed in the weirds-rdap-sec document and not in this document, or (c) to add some text to this document specifying how this should be done. Currently neither document explicitly discusses the 401 response code.
- The abstract and 1st two sentences (particularly the 2nd which I just don't get) of the intro are pretty thoroughly confusing. I was so puzzled that I read the abstracts of all 6 wg drafts and they are uniformly uninformative. That doesn't seem like a useful feature for abstracts. Sorry to be negative but its quite easy to slip into "we all know what this is about" mode, and forget that most readers will not have been active wg participants, which may be the case here. I think putting a bit of effort into improving the abstracts of the weirds drafts would be a fine thing to do generally. (The 2nd para of the intro however is just fine and does tell me weirds is about.) - intro: I wondered why you're not using ".well-known/ip" in the first example but yet you don't say that a client has to known the base URL from which to start. How is a client supposed to know to use a path of "/ip/192.0.2.0" or "/weirds/ip/192.0.2.0"? - Section 2: "Described in other documents" seems to scream for references. - 5.6: I don't get why CORS is needed here? Can you explain? (Not sure if that needs to be in the doc, but its not obvious to me.) - section 7: Are there any security properties that ought be checked in the event of a 3xx response? For example, if https is used for the initial query, should it also be used for the subsequent one? - overall: I was left wondering if this would not have been better as a part of some other document with more normative text, but I guess as long as the full set of RFCs do the job that's ok.
(1) It seems like Section 4.1 could be made bit tighter. There's not really a reason for clients not to send the specific RDAP JSON type in their Accept header. So you could say that clients must send the RDAP-specific type (when requesting RDAP JSON); servers MAY accept others (e.g., application/json). (2) In Section 5.2, do you want to recommend that the targets of redirects conform to the query syntax? If not, it might be helpful to warn implementations that redirect targets might not have the standard query format. (3) In Section 5.6, it would be helpful to provide some guidance on how the Access-Control-Allow-Origin header should be set. It seems like most RDAP servers are going to be public resources, so the value "*" would be appropriate, at least as an example. (4) The Security Considerations should point to draft-ietf-weirds-rdap-sec, since that provides the security mechanism for RDAP
Two small points, which shouldn't hold things up much: 1. Larry Masinter's AppsDir review notes an issue with using the HTTP 404 status code. 404 is meant to say that the URL you're asking for doesn't exist (or the server isn't willing to disclose that it exists). The question is whether there's a useful distinction in RDAP between "you're querying about something that doesn't exist" and "you're querying about something that exists, but there's no information available about it." If not, then 404 might be OK (it's altering the sense of 404 a little, though). If so, though, there should be different status codes, and 404 belongs to the former. Please discuss. 2. The registration of the application/rdap+json media type was removed in version -07, presumably to move it to the json-response document (which makes sense). But there are examples here in Appendix A that still use that media type, with no definition in sight. I'm not happy with that. I would be happy with an informative reference to the document where that media type is defined, and, of course, and update to that draft, including it (the latest posted version, json-response-04, predates this change). (An informative reference is OK, I think, because this is in an example.)
It appears that Olaf is having a conversation about the rest of Larry's review, and I have every confidence that Good Stuff (tm) will come from that.
I'm not completely comfortable about the use of 404 flagged in Larry Masinter's Applications Area Directorate review, but whatever you do to resolve Larry's comment will work for me, too.
updated ... On .well-known point raised by Stephen .... when EST came through the authors were told by the appsdir reviewer that: IETF standards should not define URIs or patterns of URIs, because servers may wish to provide other services (implying the possibility of collision), or deploy resources in an alternate way, for implementation or operational reasons. This is a fundamental concept in the Web architecture; see <http://www.w3.org/TR/webarch/>. Possible remedies include: 1) Specifying a "home document" format that links (in the RFC5988 sense) to the various resources as appropriate. 2) Specifying a well-known URI to root the interaction. Note that this is suboptimal; while it avoids collisions, it does not allow alternate deployments, or multiple deployments on the same host. Why doesn't the same recommendation apply here?
Just checking but does a policy reason include unauthorized access? draft-ietf-weirds-rdap-sec talks about anonymous access as well as authenticated access so I just want to make sure that's covered in all the Ifs in s1. please expand: SSAC
I read the apsdir/review comments with interest, I have no serious objections.
draft-ietf-manet-nhdp-olsrv2-sec
- Agree with Barry and Brian that this document does not update OLSRv2. That document already requires the use of this document. No change, no update. - Section 3, third bullet: I suggest changing "but MAY use different algorithms if more appropriate" to "except when use of a different algorithm is more appropriate". The mixture of the MAY and the prior SHOULD is wrong. Additionally, strike "also" from the next sentence. - Section 4, second bullet: I think it's worth changing "but not with" to "but MUST NOT use". That's an important interoperability point. - Section 6.1: I suggest changing, "In addition, in order to conform to this framework, each message MUST contain:" to "In addition, messages that conform to this framework will contain:". I don't see how the MUST is calling something useful to the attention of the implementer.
- intro: does figure 1 imply that an outbound message for which no good key exists is supposed to be dropped? It does give that impression. If that's not intended then maybe move the "(failed check)" arrow to the right hand side of the figure? - Section 3 almost but not quite says that HMAC-SHA-256 is MTI (mandatory to implement). I think you mean that it is, but it'd be better to be clear about it here. (Section 4 does say HMAC-SHA-256 verification is MTI though, so this is a nit unless you think someone might only implement checking and not generation of ICVs.) - Section 3 says that all ICVs MUST use a different algorithm. That seems a bit wrong, I think you mean that a different algorithm or key MUST be used - otherwise how could you handle different nodes that have different keys but all implementing HMAC-SAH-256? (The same phrase is used in section 4, so that might be two tweaks needed.) - The secdir review [1] notes that the granulatity of the timestamp is one second. I think that's a good point - is that really ok for MANETs? Even if so, I think you should mention it. - section 9.2: I do recall that we discussed this a good bit, in particular why bcp107's AKM requirements don't apply here. Text justfiying that is in oslrv2, section 23.6 so I'd say a pointer from the end of section 9 to that text would be good. - For completeness, I do agree that this spec is ok to not include AKM on the basis justified in oslrv2 so I'm not balloting DISCUSS for that this time, since we handled that before (see above) even though the secdir reviewer also quite understandably raised the point. [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04123.html
I agree with Brian's comment: given that olsrv2 already has a reference to this document, the "updates" metadata is entirely unnecessary.
Thank you for helping me work through my Discuss, and best wishes. (inserting Ulrich's response for reference) > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I'm more than half-expecting this Discuss to be resolved by educating the > non-RTG AD This is what am I trying to do in this email > > I'm not familiar with MANET protocols beyond the handwaving level, but I > took a quick look at > http://tools.ietf.org/html/draft-ietf-manet-olsrv2-19, and thought I > understood that this protocol was using either IP or UDP for transport. > > I think I'm seeing in Section 6.2. "Message Generation" that integrity > protection is adding TLVs. > > I'm looking at this text: > > 3. A TLV of type TIMESTAMP, as specified in Section 6.1, is added to > the Message TLV Block. The message size and Message TLV block > size are updated accordingly. > > 4. A TLV of type ICV, as specified in Section 6.1, is added to the > Message TLV Block. The message size and Message TLV block size > are updated accordingly. > > 5. All ICV TLVs that were temporary removed in step 1, are restored. > The message size and Message TLV Block size are updated > accordingly. > > Am I understanding that the message is getting longer as you add TLVs? > > If so, is it possible for IP fragmentation to occur as a result of adding > TLVs? We are considering here messages that are created within the framework of RFC 5444, that ultimately produces packets that are passed (usually via UDP) to IP. The only fragmentation possibility is at the IP level. An implementation of the RFC 5444 multiplexing process that puts messages together in packets is likely to be constrained so as to not unnecessarily create over-long packets that need fragmentation. (That is not actually a requirement, but the multiplexer has a free hand, and that is how a sensible implementation would behave.) That therefore means that the issue can be reduced to one of overlong messages. So to answer your question, yes, adding such TLVs increases the length slightly, and therefore makes handing a message that forces fragmentation to the RFC 5444 multiplexer more likely. But not much more likely. In practice this is not actually an issue because OLSRv2 messages are much shorter than any fragmentation limit. Messages under a hundred octets are common. To get a message of even several hundred octets requires very large, very dense networks, because the size of the messages is dictated by how many neighbors a router has. Having a hundred neighbors would leave you under an expected fragmentation limit, and a hundred neighboring routers is fantastically high. If it really is an issue, then NHDP and OLSRv2 have mechanisms for so-called "incomplete" (i.e., incremental) messages that can handle this. Best regards Ulrich
I fully support the publication of this document, but I am a little confused by its relationship with draft-ietf-manet-olsrv2. The base OLSRv2 spec references OLSRv2-sec and says it SHOULD be used. It is unclear why OSLRv2-sec is UPDATING draft-ietf-manet-olsrv2 given this forward reference.
This one ought to be pretty straightforward: s9.1.1: If all the routers are sharing the same key, then all you know is that it's a valid router in the network not that it's a particular router? I think that needs to be a bit clearer in s9.1.1.
s1: Is the 1st paragraph all about explaining what mandatory to implement means? I also don't think it's a framework it's a mechanism (as mentioned in the 2nd paragraph). Maybe the first paragraph could be amended as follows: This specification updates [RFC6130] and [OLSRv2] by defining the mandatory to implement security mechanisms (for integrity and replay protection). A deployment of these protocols may choose to employ alternative(s) to these mechanisms, in particular it may choose to protect packets rather than messages, it may choose to use an alternative integrity check value (ICV) with preferred properties, and/or it may use an alternative timestamp. A deployment may choose to use no such security mechanisms, but this is not recommended. s3: r/specifies a security framework/Specifies a security mechanism X2 actually I'd just replace framework with mechanism everywhere. s3: I think this is really a MUST here no? And, it's a MUST implement not should use? Deployments of [RFC6130] and [OLSRv2] using this framework MUST support a SHA-256 based HMAC ICV TLV. s3: ditto on the timestamp: Deployments of [RFC6130] and [OLSRv2] MUST support the POSIX time based timestamp, if the clocks in all routers in the network can be synchronized with sufficient precision. s4: This is a bit pedantic, but if an implementation doesn't include this specification doesn't mean that it will be ignored - isn't it that if the HMAC mechanism is used then it will be ignored ... Note that this means that routers whose implementation of NHDP and/or OLSRv2 does not include this specification will be ignored by routers using this framework, and these two sets of routers will, by design, form disjoint MANETs. s6.1: I think this a little bit confusing like in s3 (as noted by Pete): MUST support the following version of the ICV TLV, but other versions MAY be used instead, or in addition, in a deployment, if more appropriate: s9.1: r/alleviated/mitigated?
Seems like the opportunity for replay attacks is particularly acute around startup/bootstrapping.
draft-ietf-manet-rfc6622-bis
I've raised the truncation issue to a discuss based on this mail exchange with Christopher: On 08/14/2013 02:47 PM, Dearlove, Christopher (UK) wrote: > (Note that I'm writing as "we" meaning the authors, as I believe this > is the intent. However I have not actually confirmed this email with > them, so please read accordingly.) > > No, we intend to allow the HMAC-SHA-256 to be truncated after the > calculation. We intend the default in all cases to be that truncation > is allowed. > > There is, we are informed, an approach that is of interest to some > (this came from outside the group of authors), which we do not intend > to disallow, that says that a massively truncated, let's say to one > octet, ICV is still as difficult to calculate as it would be > non-truncated. But a random guess can obviously be made, with a 1 in > 256 chance of creating a successfully spoofed message. This approach > (and note that this is the general framework RFC, not the application > to a specific protocol) assumes (or more) that whatever the proposed > application is can handle such a rate. (Or a lower rate with a less > massive truncation.) Of course you can flooding with many messages, > but at this point the flood is probably the immediately greater > problem. > > So we wish to allow people to do that. What they do with it is beyond > the scope of this draft, but we shouldn't make unnecessary (at this > point) restrictions. The suggested text for Section 13 could be read > however as disallowing this in a future ICV, which is not our > intent. Ah. That I think is problematic. A one byte ICV is worse than useless. Even if the chances of success were 1/256 the fact that I could send guesses to one set of nodes until one works and then use that first time at all other nodes sharing the key. Major gotcha. And worse, if anyone can truncate and if the verifier doesn't have to agree to that in advance then the whole ICV is useless. I think you do need to fix that.
- 12.1: You say the truncation should be as specified for the relevant function(s). I think you mean that each such function registered in the IANA registry MUST specify if truncation is allowed and to what length(s). Is that right? If so, putting it that way would probably be better. And in this case and for the -sec draft, since you've not specified any truncation for HMAC-SHA-256 then that means that all 256 bits must be used - right? - section 13: I think it'd be good to say that the expert SHOULD NOT approve registrations where ICVs can be truncated so as to make them vulnerable given the state of the art when the registration is requested. - Please consider the suggestions made in the secdir review [1] about naming and IANA. And for completeness I'll note that I did discuss the lack of AKM here with the authors and am ok with it, as per the justification in the olsrv2 draft (even though the secdir reviewer also properly noted this). [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04080.html
A fine document, this. I have just two very minor comments about Section 1.1. which require no response. If you disagree with them, feel free to just set them aside: I found myself reading this sentence a couple of times as I tried to parse it: For the ICV TLV as well as repeating the specification of two type extensions, 0 and 1, it also specifies a new type extension, 2, in Section 12 of this document. May I suggest this alternative?: NEW For the ICV type, this document specifies a new type extension, 2 (see Section 12), in addition to including the original type extensions (0 and 1) from RFC 6622. END Minor organizational comment: The subsequent paragraph, which gives some explanation and rationale for type extension 2, seems to belong in Section 12 (or a subsection), rather than in the introduction. Maybe merge this into the last paragraph in 12.1.1, and get rid of it here?
I'm actually hoping these are all straight forward ;) Say there was an environment that wanted to use ICV packet/message/address block tlv extension type 2 with AES-CMAC and AES-128 in GCM mode. Would we need to register AES as a hash function and CMAC as the cryptographic function? And, how do we indicate the AES mode - or do you not need to? Maybe before answering that I'd like to know why you even need to indicate the algorithms used at all? Doesn't the key identifier tell the recipient which security association is in place and then it'll know which algorithms got used? This obviously presupposes that one a manent network is set up it uses the same security settings and doesn't change on the fly, but isn't that a pretty good bet? Even if you you use the special zero value wouldn't you already know the algorithms to be used? RFC 3447 has two signature schemes to which are you referring? Actually, are you referring to the signature algorithms or are you also referring to RSA in key transport mode or OAEP? I assume it's just PKCS v1.5, but I think you need to say that explicitly. Also, for RSA there are two common exponents 3 and 65537. 3 can be used if you don't care about confidentiality (used by DNS) but 65537 is used pretty much everywhere else. Do you need to say which exponent is to be used? Along the same lines, ECDSA uses a curve. You could infer the size of the curve from the hash algorithm - if you linked the curve to the has output size - but is that what you want to do? Now on to key formats: Do you need to specify the format of the key? For example are the public keys encoded as the SubjectPublicKeyInfo like IPsec does? If you doing AES do you need to specify the encoding for the key (i.e., MSB info?) s3: Just checking but the additional data that can be carried is only applicable to the control plane or can it also be data that might otherwise be carried on the data plane?
I support's Stephen's discussion position wrt truncating outputs. RFC 2104 makes the following recommendations and I think they should be followed: We recommend that the output length t be not less than half the length of the hash output (to match the birthday attack bound) and not less than 80 bits (a suitable lower bound on the number of bits that need to be predicted by an attacker). And now for something completely different: Do you also want to make RFC 6622 Historic - that is take it off the standards track completely? Pretty please can we point to RFC 6090 instead of ANSI X9.62? It's the RFC that David McGrew put together that uses really old references. The only upshot here is that if you're going to refer to 6090 then it would also be good to ensure you link the curve to the hash algorithm. For example, if you're using a p-256 key use SHA-256 and not SHA-1, 224, 384, or 512.
I find myself concerned that the complexity and manageability considerations become more acute as this suite matures... Statements like, This architecture is a result of the observation that with respect to security in MANETs, "one size rarely fits all" and that MANET routing protocol deployment domains have varying security requirements ranging from "unbreakable" to "virtually none". do not give me confidence in the long term usability and interoperability of manet routing protol implementations that employ fully or partially mechanisms in 6622 or 6622-bis.
draft-ietf-emu-eap-tunnel-method
These discuss points are more questions I'd really like answered than blocking points (depending on the answers I guess:-) but I expect should be easily resolved. (1) 3.4: when x.500 names or SubjectAltNames are "exported" is it clear how those are formatted? Maybe a pointer to where that's defined would be good in case implementers get it wrong. You might also want to warn here (or somewhere) about names that contain a null byte in case that attack is used e.g. with a TLS server cert subject name like "CN=www.paypal.com\0.badguy.com" Even though that's really a PKI failure, not detecting it here would be bad too. (2) 5.2, at the end: this adds a dependency on the TLS-PRF. I don't suppose TLS1.3 will be a big enough change for that to be a problem, but what if it was? E.g. if someone convinced the TLS WG to use IKE instead? Do you really need the same PRF or could you pick one for TEAP and remove the dependency? Same question for the MAC in 5.3. (3) 7.3: you have a MAY for this separation but also define what would become a cleartext password set of TLVs on the link between the two boxes here. Could you not at least REQUIRE protection (e.g. using IPsec) of that link if the basic password method will be used?
- 3.2: You're allowing TLS compression. Is there the potential for something like a CRIME attack here? I guess not, given that there's no way to programatically get a peer or inner method server to send attacker-chosen data. Is that correct? (Just checking.) - 3.2.2: Since a PAC-lifetime is a wall-clock time then it would provide a way to correlate old and new sessions (i.e. act as a fingerprint) if its ever carried in clear. Can that happen? - 3.3.3, 1st para: what does "clear text" mean here? Do you mean within the TLS tunnel or not? I hope you do mean within the TLS tunnel, but I think you need to be clear(er) in any case. - 3.8: this says mutual auth "results" if the peer trusts the server cert belongs to the server - that sounds wrong, isn't it? - 3.8.1: I think you need an s/MAY/MUST/ here - you say the request "MAY be issued only ..." but I think you mean "MUST be issued only..." - 3.8.2: Just checking, and I may be wrong here. Say if I establish a TLS server-auth tunnel and then renegotiate to get TLS client-auth (with id privacy) as well, and then the Peer wants to get a new cert. This calls for the tls-unique for the initial server-auth TLS session to be used in the pkcs#10. Am I reading it right? Is that ok? I think it is, but just want to check since its pretty confusing;-) - The secdir review [1] raised a couple of questions that I think would be good to answer. Did I miss that answer? [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04106.html
Two points about Section 3.7. "Fragmentation" - Both ends have to wait for either each fragment or fragment ack to arrive. However, the timers on how to long to wait before giving up waiting for fragments or acks are missing. - how does the sending TEAP entity determine what the maximum transmission unit (MTU) of the path is?
I can't in good conscience make this a DISCUSS point because really, the best you're going to be able to do is hand-wave or wait on a not-yet-published document. But 4.2.15 (like a bunch of other documents) is really introducing an "...a miracle occurs..." solution. It is presuming that there is a user-input username and password in UTF-8, but no discussion of normalization or mappings. If you are OK with false negatives (i.e., in some circumstances people are going to type things that they are absolutely sure are their usernames and passwords, but they are going to fail, and they will be unable to type their "true" usernames or passwords), then you're probably OK doing nothing. If that would be a really bad outcome, to make it more resilient you could look at: http://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/ (This document is not just about SASL, the filename notwithstanding.) I'd like to say that the document will be published quickly, and maybe if you all pushed on the PRECIS folks it might, but I can't make any promises. And I wouldn't suggest using RFC 4013, because it's going to be obsoleted by the above (for good reasons). I'm glad to discuss this with the authors or the WG, but I won't force you to DISCUSS it.
I'm going to raise Spencer's comment to a DISCUSS: I find the version negotiation in Section 3.1 to be somewhat confusingly written. Possibly it will be implemented correctly because people generally know how to code version negotiation -- but I don't think the text here makes it clear. First, you seem to be using "EAP peer" and "TEAP peer" interchangably. Please make sure you're consistent in your usage, and if there really is a difference then make that clear and explain it. You similarly say "EAP server" and "TEAP server" -- again, are they the same, or different enities? Second, I'm confused by "server" and "peer". Peers talk with peers; when there's a server, there's a client. What does it mean to have a server and a peer (in the document in general, and in this negotiation in particular)? Now, I think you're trying to say this: 1. The server gives the highest version it supports. 2. The client does one of three things: 2a. Sends a response that echos the server's version. 2b. Sends a response that offers a lower version. 2c. Sends a Nak, and we're done here (perhaps we continue with something else). 3. For 2b, the server does one of two things: 3a. Accepts the client's version and continues. 3b. [Does something else; see Spencer's comment.] Now, I like this approach, in that both the client and server can refuse an earlier version (which perhaps has security flaws), so that's nice. But I think the wording of the negotiation process ought to be fixed to make it clearer, and that what happens in case 3b, especially, needs to be clearer. I also think that numbering the list(s) will help, though you don't have to use my numbering (and if you can make it clear without numbers, that's fine).
I note that the shepherd writeup included key information about reviews from outside the working group. Thanks for that; it's very useful. In Section 3.3.2, it might be useful to (briefly) note *why* one SHOULD NOT use EAP-FAST-GTC.
I considered balloting Discuss, but I'm assuming that either I'm missing
something really obvious, or this will be an easy fix ...
In 3.1. Version Negotiation
If the TEAP server does not support the version number proposed by
the TEAP peer, it MAY terminate the conversation with EAP-Failure
or negotiate for another EAP type. Otherwise the TEAP
conversation continues.
I'm wondering if "MAY terminate the conversation" is what you mean when the
TEAP peer doesn't propose a version number that the TEAP server supports.
I'm reading "otherwise the TEAP conversation continues" as saying that the two
alternatives given are the only choices when the TEAP server doesn't support a
proposed version number. Did I get that right?
If you're expecting the TEAP server to do one of those two things, something
like "MUST terminate the conversation unless the TEAP server negotiates for a
different version number" might be clearer.
If there are more than two alternatives, it would be helpful to rephrase this
text so it's clear that the TEAP server isn't limited to those two alternatives.
(I should have mentioned that I agree with Martin's Discuss, but one Discuss on
those topics is enough)
draft-ietf-mpls-retire-ach-tlv
Brevity is the soul of wit.
draft-eastlake-rfc5342bis
What's the point of Appendix B? If it's to have a restricted list of only IETF allocations, should the IANA be maintaining this list, since what's in this document is doomed to become out of date? I don't find a list like this on the IANA web site. I don't specifically object to Appendix B; I just think that if these lists are useful, they ought to be maintained. Give that Joe's draft has passed IETF last call, I think my DISCUSS is moot, so I'm dropping it. Former DISCUSS: Based on Donald's response to the below point, I realize that I should have entered this as a DISCUSS, so I am correcting that mistake. Here't the original text of the comment: What is the purpose of section 5.2? It seems out of place with respect to the rest of this document. I can't really object to it, since what it says is true, but it seems inappropriate to mention IANA RRTYPE assignments in a document about 802 code points. Here's my further explanation of the problem: The use of these RRtypes is not documented in any IETF publication, so documenting it in this one is precedent-setting. Given that there has been substantial controversy about these RRtypes on the IETF mailing list (although it seems to be in a lull at the moment), publishing a reference to them in a completely unrelated document seems inappropriate. This document is an individual submission with a clear focus on documenting IEEE 802 code points. Knowing the authors, I think it is reasonable to assume that it has gotten sufficient review from experts on IEEE 802 code points, and that the consensus of the IETF on those points is valid. That it additionally documents a DNS RRTYPE code point suggests to me that this section likely slipped under the radar and got no expert review from DNS experts, and that in fact this particular text does not represent any meaningful IETF consensus. This DISCUSS can be cleared either by removing the text that documents these two RRtypes, or by doing a new last call on the IETF mailing list that specifically points out that this draft documents these two RRtypes. It may be that there is a similar problem relating to the AFN allocation. It seems similarly unrelated, but probably isn't controversial, so it may be that this part of section 5.2 is not problematic. I will not object if this part of section 5.2 is kept, even if no new consensus call is done.
Thank you for including section 1.1 which helped my review considerably.
---
Maybe reversing the order of sections 1.1 and 1.2 would make 1.1 easier
to read.
---
<pedant alert>
([RFC5342] had a requirement for parallel unicast and multicast
assignments under some circumstances even when both types were not
applied for. That requirement has proven impractical and is
eliminated in this document.)
s/both types were/one of the types was/
---
<double pedant alert>
IANA always sends the Template to an appointed Expert. If the
Expert recuses themselves or is non-responsive, IANA may choose
an alternative appointed Expert or, if none are available, will
contact the IESG.
s/none are/none is/
---
I am unwarrantedly bothered by the presence of Appendix B. I struggle to
see that it serves any purpose except to provide a secondary and
potentially conflicting source of information compared to the
registries.
Would the authors consider removing it and leaving the pointers to the
registries as the only source of information?
minor adjustment due to feedback provided by ieee rac is needed.
since this doesn't not impact IETF assignments I think it's fine. imho I
reviewed and I do not belive that it impacts the consensus we already have.
from donald.
From -04 to -05
Re-cast informational material about relevant IEEE assignment
policies to take into account the planned changes by the IEEE
Registraion Authority as per [RAC-OUIdraft].
Add a sentence forshadowing the future possibility of EUI-128 MAC
addresses.
Add InfiniBand as example of EUI-64 use.
Minor editorial changes.
draft-ietf-websec-x-frame-options
The introduction of the concept of origins in 2.1 is a bit clumsy—the term is
used under the SAMEORIGIN heading without being defined, and is later defined
as a constraint specific only to ALLOW-FROM. Text about browser
implementations for SAMEORIGIN and ALLOW-FROM is repeated here and in later
sections. It would be better to simply refer to the later section. If I
were to clean up this section, I would do something like the following:
DENY
A browser receiving content with this header MUST NOT display
this content in any frame.
SAMEORIGIN
A browser receiving content with this header field MUST NOT
display this content in any frame from a page of different
origin than the content itself.
If a browser or plugin can not reliably determine whether the
origin of the content and the frame have the same origin, this
MUST be treated as "DENY". Section 2.3.2.2 documents
variations in the handling of this header field by different
browsers.
ALLOW-FROM (followed by a URI [RFC3986] of a trusted origin)
A browser receiving content with this header MUST NOT display
this content in a frame from any page with a top-level browsing
context of different origin than the specified origin. While
this can expose the page to risks by the trusted origin, in
some cases it may be necessary to allow the framing by content
from other domains.
The meaning of the term "origin" is given in [RFC6454].
If the ALLOW-FROM value is used, it MUST be followed by a valid URI.
Any data beyond the domain address (i.e. any data after the "/"
separator) is to be ignored. And the algorithm to compare origins
from [RFC6454] SHOULD be used to verify that a referring page is of
the same origin as the content or that the referring page's origin is
identical with the ALLOW-FROM URI. Though in conflict with
[RFC6454], current implementations do not consider the port as a
defining component of the origin.
I also noticed that in another exchange about this document, someone said that
this document is not intended to give advice to browser vendors. If that's
the case, what is the above SHOULD doing in the text? Is there uncertainty as
to what implementations do? If so, it would be better to express that
uncertainty, if indeed you are documenting browser behavior.
Also, with respect to this text:
Though in conflict with
[RFC6454], current implementations do not consider the port as a
defining component of the origin.
Does this mean that http://www.foo.com and http://www.foo.com:8080 are
considered equivalent, or that http://www.foo.com and http://www.foo.com:80 are
_not_ considered equivalent? What about http://www.foo.com and
https://www.foo.com?
The following text is incomprehensible to me as a non-domain-expert:
The criteria for the SAMEORIGIN option is not evaluated unanimously
either: one implementation may evaluate the SAMEORIGIN option based
on the origin of the framed page and the framing page, while another
may evaluate based on the framed page and the top-level browsing-
context.
What is the distinction between "top-level browsing context" and "origin of the
framing page?" A reference here would be helpful.
Thanks for documenting this.
(D1) The privacy considerations make no sense to me. To whom is data being leaked? To the browser? To random people who send a request to a URI? Do you mean that X-Frame-Options leaks information about who the site authorizes? That's true, but also true of things like CORS. If this is the concern, you should recommend a mitigation that's basically the same as what CORS does, namely varying the value of X-Frame-Options based on the Referer or Origin header. (D2) It seems like this is a value that browsers might cache, to avoid unnecessary requests if the same page is framed in the future. If this is something browsers do today, please say so. (D3) Shouldn't ALLOW-FROM be followed by an origin, not a URI? In other words, what does it mean to send "X-Frame-Options: ALLOW-FROM https://example.com/this/is/a/path?query#fragment"? (D3) In the ALLOW-FROM: what does "top level context" mean? Do you really mean the top level here, as opposed to the next one up? For example, suppose A loads B in an iframe, and B loads C, and then C sends an X-Frame-Options header with ALLOW-FROM. Is the ALLOW-FROM origin compared to B or A? In either case, you should also note the attacks that remain. For example, if the answer is B, then B needs to use X-Frame-Options as well, or else, A can maliciously frame A within B. Or if the answer is A, then C is trusting A not to load any malicious intermediate frames B.
(C1) In the Introduction, the phrase "secure web page" would seem to imply that this mechanism only applies to pages delivered over HTTPS, which I'm pretty sure isn't true. Suggest just deleting "secure". (C2) In Section 2.1, the sentence starting "And the algorithm" seems to imply that ALLOW-FROM allows SAMEORIGIN requests as well, which I think you actually mean something like: """ And the algorithm to compare origins from [RFC6454] SHOULD be used to verify that a referring page is of the same origin as the content (in the case of SAMEORIGIN) or that the referring page's origin is identical with the ALLOW-FROM URI (in the case of ALLOW-FROM). """
(Personal opinion only, no change requested unless it resonates with folks.) I would prefer that this not say that NoScript impairs broswer utility. I find it fine. Other than that, this is a fine draft, thanks.
Why is this document not on the standards track?
I really like this specification, and I appreciate the working group producing it. Documenting "in the wild" behavior is a good thing. I have one fairly fundamental comment, which I think can be easily addressed, and a few nits. My comment: This specification starts out like a normal header field specification until you get to 1. Introduction This specification provides informational documentation about the current use and definition of the X-Frame-Options HTTP header field. Given that the "X-" construction is deprecated [RFC6648], the X -Frame-Options header field will in the future be replaced by the Frame-Options directive in the Content Security Policy Version 1.1 [CSP-1-1]. That's still KIND of OK (no indication that anything is wrong with X-FRAME-OPTIONS functionality, just a heads-up that implementations that include X-FRAME-OPTIONS will have work to do in the future), but when we get to 2.3.2.2. Variation in current browser behaviour There are currently variations in the implementation of the X-FRAME- OPTIONS header. we discover unambiguously that current implmentations don't all work the same way, so your ability to rely on X-FRAME-OPTIONS is not entirely clear. I wonder if the set of technical details are asperational, saying "this is what X-FRAME-OPTIONS could have been, and what the next header field in this space should be". I think it's fine to publish this specification, especially as Informational, even if it's not clear to me that *any* of the functionality described in this specification is implemented the same way in all major browsers. I would be more comfortable with a clear statement in the Introduction that the biggest problem with X-FRAME-OPTIONS is *not* the leading "X-", but that today's implementations don't all provide the same options with the same behaviors, so relying on this specification as a predictor of what will happen to your frames is not a good idea. One sentence that puts the reader on notice would be sufficient. My nits, just so editors don't have to find them again: Is there a reason why sometimes X-FRAME-OPTIONS is in all caps, and other times not? I'm not an APP guy, so I'm asking. In Section 2.3.2.2. Variation in current browser behaviour These variations in the evaluation of the header by different implementations impair the useage and reliability of this http header. A revised version of x-frame-options in the form of a frame- options directive in the CSP 1.1[CSP-1-1] will unify the behaviour and it is expected that newer implementations will use it rather than the mechanisms documented here" The trailing quote mark should be a period, I suppose? 5.1. Privacy Considreations should be "Considerations". In B.2. Online Shop Confirm Purchase Page The "Confirm Purchase"" The doubled trailing quote marks should be one quote mark, perhaps?
It's interesting to note that this draft says there's a problem with folks not checking the origins of the entire ancestor tree of names of the framing resource - but then doesn't say that sounds like a good idea do it. I can see the argument that might be made that this draft is just documenting what's done now, but shouldn't we take the opportunity to do more and recommend something along the lines of "The entire ancestor tree of names of the framing resource SHOULD be checked to mitigate the risk of attacks in multiple-nested scenarios" or something like that?
I'd ask about how RFC 6648 applies to this, but I bet this header was out long before the drafts that lead to RFC 6648. s1 (penultimate paragraph): r/script/Javascript ? s4.1: Is Figure 1 missing or is that the registration template? ;) s5: r/all kinds of these attack vectors/these kind of attack vectors r/, ...)/) Appendix A: Is this a guarantee that x-frame-options/frame-options will be supported henceforth until the end of time in those browsers? Basically, I'm not sure Appendix A is needed.
support richards discussion, the security/privacy considerations could use some wordsmithing.
draft-ietf-emu-crypto-bind
3.2.3: this confused me "First, the server and peer prove to each other knowledge of the inner MSK. Then, the inner MSK is combined into some outer key material to form the tunnel's keys." Reading that, the implication would be that I form a tunnel, then inside the tunnel do EAP resulting in the inner MSK, and after that I "form the tunnel's keys" which seems impossible as I've used the tunnel already so how can I "form" its keys? Do you mean "confirm" instead? (And a nit: "combined into" seems odd, "combined with" would be clearer for me.)
Is there a response to the Gen-ART review by Francis Dupont?
Very well written; thanks.
draft-ietf-lwig-terminology
Maybe the term is best read as "Low-Power Wireless Area Networks" (LoWPANs) [WEI]. This doesn't actually make sense—why does "area" belong in this sentence, given that no statement as to the size of the area is given? I would suggest deleting this sentence. In Table 1, are the column's or'd or anded? That is, for example, is a C0 device a device that either has <<10k of RAM or <<100k of code? Or a device that has both <<10k or RAM _and_ <<100k of code? Is a device with 10k of RAM and 10k of code a C0 or a C1 device? In Table 3, "mains powered" is a regional name, which likely will not be understood by all readers. I notice that "mains power" is used elsewhere in the document; it might be good to define it somewhere. I realize that this may sound very nit-picky, but you never know who is going to be reading the document. I think it would be obvious to me in context, even if I hadn't heard the term before, what the term means, but I am unsure enough that it would be obvious to any reader that I think it's worth defining the term. Other than that, the document looks good. I think a lot of IETFers could benefit from reading this document, because these terms have been coming up in conversation quite a bit recently. For example, I heard "LLN" a lot long before I learned what it stood for, and I have since used it on people who responded by saying "what's an LLN." :)
I have struggled hard in my review of this document, and Brian
Habermann has helped me a lot with understanding the value and
purpose of the work. In my Discuss, below, I have tried to list
actionable work that I feel is necessary for the publication of
this document as a definition of terminology, and I have pushed
out to my Comment other issues that I think would be good to fix
but which are not blocking.
Before reading and attempting to resolve the Discuss issues, the
authors might like to consider whether this document could be re-
positioned as "A Discussion of Some Concept in Constrained Networks".
I believe that this re-branding complete with a few minor tweaks to
the text to be consistent would pretty much defuse most of my
Discuss comments (except, perhaps some on the Abstract and Section
2.3.1).
---
The Abstract is confusing in that it introduces a "small device with
severe constraints" and uses it to define a "constrained node network",
but never says what a "constraint" is. It then goes on to use the term
"constrained environment" without explaining what this means.
I think that the Abstract could give several examples of constraint for
a node (memory, CPU, power). It could also replace "constrained
environment" (which is not used in the rest of the document - except in
a similar paragraph in the Introduction) with "constrained network"
together with a mention that links may also be constrained, and some
examples of link constraints.
---
Section 2.1
I agree that the definition of Constrained Node "is less than
satisfying." Indeed, I think that the definition you provide is useless
as a definition.
I find it odd that the definition includes the reasons why the node is
different, but not a list of the ways it might be different.
some of the characteristics that are
otherwise pretty much taken for granted for Internet nodes in 2013
...is so vague and unscoped. Of course, the text that follows does
list some of the constraints and these are helpful to an understanding
of the definition.
Probably the best way to handle this is to turn the whole section into
prose and dispense with the formal definition that isn't.
The same problem exists in Section 2.2.
[These concerns are consistent with my suggestion to back away from
providing definitions, and to offer a discussion of concepts instead.]
---
Section 2.3.1 is full of issues.
In common usage, LLN often stands for "the network characteristics
that RPL has been designed for".
Asides from being cryptic (or possibly sarcastic), that definition is so
clearly circular as to be of no value. You could, instead stop after the
quote from draft-ietf-roll-terminology.
Also, please expand RPL and give a reference.
LLNs do appear to have significant loss at the
physical layer
How do you mean "appear"? Do they or don't they?
Actual "low power" does not seem to be
required for an LLN [I-D.hui-vasseur-roll-rpl-deployment], and the
positions on scaling of LLNs appear to vary widely
[I-D.clausen-lln-rpl-experiences].
Again "seem to be". If you cannot provide a definition in this document
then probably best to not try.
The reference to [I-D.clausen-lln-rpl-experiences] in the discussion of
scaling LLNs is curious. That document talks about experiences trying
to scale RPL. It does not, as far as I can tell, discuss the size or
scalability of a LLN.
The ROLL terminology document states that LLNs typically are composed
of constrained nodes; this is also supported by the design of
operation modes such as RPL's "non-storing mode". So, in the
terminology of the present document, an LLN seems to be a constrained
node network with certain network characteristics, which include
constraints on the network as well.
What do you mean "is also supported by"? Are you saying that the
composition of a network is defined by the widgits built into a protocol
that runs over it?
What do you mean "an LLN seems to be..." Can you not write a clear
definition?
---
Section 2.3.2
I don't see a definition in this section of either LoWPAN or 6LoWPAN. I
only find a discussion of the expansion of the acronym.
[Again, if the document is not seeking or claiming to provide
definitions this is not a problem.]
---
In Section 3, the description of a Class 0 node seems to be prejudging
the work of LWIG. It is mixing what the physical capabilities of the
node are (memory, CPU, power) with what the node will be capable of
doing (using security). That is surely interesting and equally surely
not part of the definition of the node class.
Similar issues apply to the discussion of Class 1 and Class 2 nodes.
[Yet again, if you are not defining but only discussing then this
issue is much less pronounced.]
---
Section 5 is missing some thoughts about the availability of security
mechanisms in constrained devices. Since these are mentioned in Section
3, you can't duck them in Section 5.
In pulling terms and ideas from non-consensus documents, this document assigns the terms more weight than they actually have. For example, in 2.3.2... Originally focused on IEEE 802.15.4, "LoWPAN" (or when used for IPv6, "6LoWPAN") is now also being used for networks built from similarly constrained link layer technologies [I-D.ietf-6lowpan-btle] [I-D.mariager-6lowpan-v6over-dect-ule] [I-D.brandt-6man-lowpanz]. ...is undoubtedly correct, but implies that there is acceptance of this use of the term. I don't believe this document is supposed to be a survey of the way terms are used in works in progress, but is supposed to be a set of definitions to help future work. This can be handled by a small change in wording so that "is now also being used for" is replaced with "also refers to". --- Section 1 Small devices with limited CPU, memory, and power resources, so called constrained devices (also known as sensor, smart object, or smart device) can constitute a network, becoming "constrained nodes" in that network. Such a network may itself exhibit constraints, e.g. with unreliable or lossy channels, limited and unpredictable bandwidth, and a highly dynamic topology. I question "also known as..." A sensor, smart object, or smart device does not need to be constrained. A constrained device does not need to be a sensor, smart object, or smart device. It might be reasonable to say that "...many sensors, smart objects, and smart devices are constrained devices..." I think "constitute a network" is wrong. These constrained nodes may be included in a network, but do they constitute the network? Are the elements of constrained connectivity between nodes (nodes which may or may not themselves be constrained nodes) relevant to the work of LWIG? It is possible that the behavior of the data channels has an impact on the code and buffering needed in a node. If so, perhaps this could be drawn out more in the Introduction. --- Section 2 might be better named "Core Terminology" otherwise we wonder why other sections are not just subsections of section 2. --- I don't like "this field of work" (which field?) and "appears to be" (appears to whom?) in Section 2. Maybe you could give: There are two important aspects to scaling within the IoT: BTW, is underbar _really_ necessary? --- Section 4.1 Instead of defining classes or clusters, we propose simply stating, in SI units, an approximate value for one or both of the quantities listed in Table 2: You "propose"? You have moved beyond that. Now you "do". --- I am surprised that Ps is a useful measure. In my experience devices often operate power availability on a curve (usually a series of steps) as a function of remaining energy in the store. Thus devices that are running short of energy reduce the available power to try to eke out what is left. That would, of course, make the average an ambiguous measure. --- Section 4.3 I was amused by he term "Always Off". "Always" as in "except for the exceptions"? :-) --- In section 4.3 it would be useful to align with (or at least mention) the terms "sleepy node" and "non-sleepy node" as presented in draft-ietf-roll-terminology.
I have one discuss point, that I'll probably quickly clear when told the wg could rather not, and then I'll move to abstain. My discuss is: I think we're missing an opportunity here to do much better than this and could do so if this document were re-worked with the goal of making the text be such that it would likely still be useful in 5 years time. Would the WG like to do that? Assuming the answer will be "no, thanks" then I'll move to an abstain since I think that's unfortunate, and very little, but some, harm will ensue, in terms of confusion when these terms are used in the not too distant future. I'm happy discuss my comments of course, in any case, but really handling many of them would only make sense if the wg wanted to re-do this, so if I do end up abstaining, it'll be entirely fine to pretty much ignore my comments:-)
write-up: I slightly dislike being told that "experts from
companies x, y & z" think something. Much better would be
to have been told that "Fred Bloggs, Joe Blow and
A.N.Other" read it and said on the list that they were ok
with it. I've worked for large companies and some of our
company "experts" were not. And even if they were, they
were sometimes more intersted in achieving company goals
and not in objectively applying their expertise. (And just
in case, for a protocol spec, it would be fine to say that
company x have implemented since that's something one could
in principle check. So I'm not saying that write-ups ought
never mention comapanies.)
abstract: Devices years ago were arguably far more
constrained in some ways than the ones you mean here. The
tendency to forget what happened a decade or more ago is a
real one, and it'd be good if some lwig document reflected
that. That's not really actionable, but if you wanted, you
could remove the first sentence of the abstract and still
be ok.
intro: all devices have limited CPU etc. (Except maybe some
in THHGTTG:-) That's not entirely a nit - all the
terminology here needs to be relative, and relative to what
we consider today's "standard candle" which could be a
typical laptop. If you re-cast the discussion here in to
only use relative terms, (except for examples) then perhaps
this terminology could be current for far longer?
intro: sigh. The Internet has always been made of things.
The IoT is of course a new marketing term, but doesn't
reflect any new reality really. And "becomes a reality" is
just pure marketing which'd be better omitted.
section 2: why is 5x10^10 an interesting number? That's
just 7 devices per person.
section 2: I don't understand the 2nd bullet at all. What
is it meant to say?
section 2: I disagree with the last sentence - there will
always be "constrained" nodes (relative to some standard
candle) and both the practical definition of constrained
and standard will move as technology develops. I don't see
how that *has to* to relate to scaling at all. (There are
relationships, but I don't think "scaling down" is
causitive.)
2.1: I assert that mentioning 2013 in the definition is a
mistake.
2.1: A definition that does not consider a smartphone a
constrained node seems wrong. Those are differently
constrained compared to a tension sensor, but both should
be considered constrained IMO. ("My problems are worse than
your problems" doesn't seem like a good basis for
terminology.)
2.1, bullet list: I would argue that you ought include
"constrained user interfaces" here. (A LED is a user
interface as is a factory-reset button, or even a
replacable battery arguably.)
2.1: bullet list: I think you're again making the mistake
of not being relative, e.g. "maximum node complexity" isn't
even really understandable (why's it a max? can't I just
add more? yes, I can! but of course then its a different
device). Again the right approach (I claim:-) would be to
cast all this in relative terms.
2.1: batterys vs. harvesting is not a real dichotomy, afaik
almost all harvesting nodes have a battery or charge up a
capacitor. There are vanishingly few nodes with no energy
storage or accumulation mechanism and if they did become
popular I suspect they ought be a class of their own. Or am
I wrong there?
2.2: again 2013 in the definition is an error IMO.
2.2: constrained n/w definition also seems wrong in that
there are networks today that are high speed that fit this
definition e.g. fibre based networks doing quantum key
distribution.
2.2.1: I don't think this is really a useful section at
all, unless the goal is simply to say that DTN protocols
are out of scope, which they are, since all protocols are
out of scope. I'd say just delete this section (if you fix
the definitions).
2.3: Just to note that this defintion is fine!
2.3.x: again you seem to be just dealing with territory
here but I guess this could be useful
3 - I bet you some beers you live to regret using absolute
numbers here. I don't find this table that useful. The text
definitions saying what the nodes in various classes can
and cannot do however is good and should be used in the
definitions.
4.1 says you're not defining classes, but then 4.2 seems to
do exactly that, which I find confusing.
4.2: I'd suggest s/E3/Einf/ so you could introduce new
classes when you find out that E0..2 aren't sufficiently
descriptive of interesting classes of device. For example,
this section doesn't seem to consider duty-cycles which IMO
can siginifcantly influence designs and which also provide
a handy way to talk about device power requirements and
capabilities in a n/w.
- table 4: Sn as classes is a terrible choice since it
conflicts with existing sleep state terminology for ACPI.
- I agree with the secdir reviewer's suggestion [1] that
it'd be good to note the security characteristics of the
various classes defined (even if the current classes are
kept). A table could usefully do that. (The exercise of
generating that table might also help to see if the current
class definitions are meaningful.)
[1] http://www.ietf.org/mail-archive/web/secdir/current/msg03964.html
Thanks for writing this useful document. A couple of comments that you may consider: 1) In my experience, power/memory/cpu are important considerations, but equally often user interface and deployment considerations are the cause of even more constraints or challenges. E.g., ability to set keys, update software, etc. Perhaps these kinds of limitations could be listed as well. 2) I agree with other ADs that tying the definitions to 2013 state of the world may not be useful. 3) I found the below comments from Suresh Krishnan's Gen-ART review useful. In particular, I'd not limit constrained devices to sensors. --- I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-lwig-terminology-05.txt Reviewer: Suresh Krishnan Review Date: 2013/08/12 IESG Telechat date: 2013/08/15 Summary: This draft is ready for publication as an Informational RFC but I do have a few comments that the authors may wish to consider. Minor ===== * Section 1 Aren't actuators also one class of constrained devices? The section talks about gathering information but does not talk about constrained devices acting on information. * Section 2.1 When speaking about the multiple facets of constraints on the nodes shouldn't processing power be included as well? There is an item for power but it is unclear if that means energy/power or processing power. In either case one of them probably needs to be added. * Section 2.2 Would it be worth mentioning the asymmetric nature of some of these link as a constraint? * Section 2.3.1 This sentence does not read right. Suggest rewording. OLD: In its terminology document, the ROLL working group is saying [I-D.ietf-roll-terminology]: NEW: The ROLL terminology document [I-D.ietf-roll-terminology] defines LLNs as follows: * Section 3 Please add a reference to the CoAP draft at first use of CoAP. * Section 4.3 Should this section also talk a bit about the term "duty cycle" since this term is used frequently in the constrained device context? Thanks Suresh
Do we really want to tie the general definitions of "constrained [thing]" (in Sections 2.1 and 2.2) to 2013? I wouldn't think so. It makes sense to say that the numbers in Table 1 represent constraint levels in 2013, but whether something is a constrained node or not should be relative to when the evaluation is being made, not relative to 2013, no?
I'm a Yes, and think this document is in good shape and worth publishing at version -05. That said, I am sensitive to Barry's point about "constrained" not being the same as "constrained in 2013". If I wasn't looking at this document for the first time at the end of the process, I probably would have asked how useful Table 1 really is, because what matters isn't whether you have 100 KiB of flash memory, it's what you have enough flash memory to do. So, not based on physical characteristics, but on functional characteristics - and the distinctions based on functional characteristics are well-described in the paragraphs that follow Table 1. What I was thinking, was more like "there are three classes of devices, and you know you have a Class 0 device when it's too constrained to communicate directly with the Internet ..." But unless people think that's helpful ... ship it.
mostly this is an observation, I am however curious how this is addressed? I have a lot of trouble with section 2 discussion of scaling... imho there are no problems associated with scaling the internet to 50 billion devices that are actually addressed or described in this document. As a network operator I don't see the considerations for hosts to be dramatically different with merely an order of magnitude more devices then we have at present. another observation section 2.2 network technologies associated associated with limited resource devices exist today, whether these are cdma schemes running on rs485, 802.15.4, ongoing work in 802.11ah, bluetooth 4.0 low energy and so on. while these technologies will be more present in the future then they are today some aren't that rare (zigbee in particular) and that seems like an odd thing to omit from that particular dicussion, only to be mentioned later in other places.
draft-ietf-trill-directory-framework
I am surprised that the WG is willing to request the publication of documents where there is known IPR, but the license terms have not been disclosed. There are multiple interpretations of this including the WG not considering that the IPR applies, the WG not believing that the IPR is enforceable, the WG not having the issue properly exposed by the chairs. or the WG being happy to consider paying a license for their implementations. Given that one of the chairs is the IPR holder, the issue needs to be treated with a high degree of caution if for no other reason than to protect the chair against claims of abuse. The Shepherd write-up points to a fumble during WG last call, but suggests the issue was handled with an additional call for comments within the WG. The write-up also points at a slide from IETF-86. I found this at http://www.ietf.org/proceedings/86/slides/slides-86-trill-10.pdf The disclosure (which was initially made against the -05 version of the individual I-D, and later against the -04 version of the WG I-D) has never included licensing terms. Given that "IETF working groups prefer technologies with no known IPR claims or, for technologies with claims against them, an offer of royalty-free licensing" [RFC3979] I would like to understand the WG process that led to this document being sent for publication. I am sceptical that I am raising an issue that meets the IESG's Discuss criteria, but I would like to discuss the point (at least with the responsible AD) to understand that IETF process was followed sufficiently to warrant deviating from the general case described in RFC 3979. Then I will be able to move to No Objection with a clear conscience.
- Why is there no definition of directory service in section 2? For this reader that term means an X.500 or LDAP like service, but I'm not at all clear if that's what's envisaged. - If an LDAP-like service is what is envisaged then I don't see how a push model can work. Perhaps if you delve deep enough into X.500 history there is a matching model with DSA replication though, not sure. That'd be very complex though. - If what's envisaged is for the TRILL WG to develop an entirely new directory service, then I think that should be seriously discussed with the applications area. I'm sure our apps ADs would take a keen interest were that to be the case. - Section 6 should IMO note the possibility that it may not be possible to follow this recommendation, that is, failure is a possible outcome. - The security considerations should note that any directory service would be a fine target to attack and could constitute a single point of failure. The current text all seems to be saying how good all this would be, which I don't think is right. - Managing access control in directories is always hard and that should be noted here.
-- Section 10.1 -- As an Informational document, this draft has no Normative References. I don't believe the general sentiment behind this (that Informational documents don't have normative references) is true. I think normative references are those that must be understood in order to understand the document at hand, and that applies to documents of any status. I think it would be helpful if the authors should sort the references with that in mind. That said, this is a non-blocking comment. Please consider doing that sort, but there's no need to respond to this comment.
Donald proposed the following text to clear my Discuss, and it works for me: > I suspect it would be good to add two sentences to the paragraph at > the beginning of Section 5. Something like: > "It is optional whether or not an RBridge uses Push Directory > services, Pull Directory services, or some combination. It is optional > whether a Directory offers Push services, Pull services, or both." Thank you for the quick response! Donald also responded to my comment about collecting the text that compares and contrasts the Push and Pull models into one section, by saying that the working group hasn't agreed on what advice to give on when to Push and when to Pull, and that this is more appropriate for more detailed protocol specifications anyway. That makes sense to me. Perhaps it's worth pulling the partial description of advantages and disadvantages out of the framework doc now and including a more complete description as the working group consenses, but as before, this is not a blocking comment.
Updated... Given some additional discussions I have had on this document, I am strongly leaning more towards Joel J.'s view of this document. It is not a framework, but it is also not a strong problem statement document. I am unclear what purpose this document will serve and I am not sure how it could be changed to make it worth publishing. I am curious about the sub-sections in section 5. There is discussion of how RBridges can learn the mappings via either a Push or Pull model (and the corresponding requirements) and what information should be in the directory. Was there discussion of adding a section discussing how the information gets placed in the directory (and the corresponding requirements)? Something to consider, but is more a curiosity on my part and definitely non-blocking.
IMHO this isn't a framework at all. it's a problem, requirements, and two operational models and some non-specific recommendations for more work. a framework is the structure that holds up the specification. I am unclear what actions the working group is planning on doing on the basis of section 6. 6. Recommendation TRILL should provide a directory assisted approach. This document describes a basic framework for directory assistance to RBridge edge nodes. More detailed mechanisms will be described in a separate document or documents. The document appears to suggest implementing both mechanisms that it proposes, which is great I guess but normally I'd expect a document like this from a working group to arrive at a consensus solution instead of two of them.
draft-ietf-multimob-pmipv6-ropt
I am balloting Yes on this document on the strength of reviews by the PIM WG. I would be glad if you looked at my comments below. ==== Thank you for recognising that this work is best brought forward as Experimental. I should like it if the Abstract made the point that this is intended as an Experiment. I think it important to add some text to the Introduction to: - state that this work is Experimental - describe the scope of the experiment and how it is contained - explain what happens if any of this experiment interacts with the wider Internet - indicate what people should experiment with, what they should report back, how the experiment will be judged, and what the next steps might be. --- The RFC Editor will ask you to remove the citation from the Abstract. --- Section 2 In this draft we refine such definition from the point of view of the s/draft/document/ --- Section 5.1.2 Maybe the explanatory text should be ordered the same as in the message option? --- Section 5.1.2 The description of "Dynamic IP Multicast Selector Mode Flag" uses "SHOULD" for behaviors of 1 and 0. That implies that there is an option to do something different. Can you describe the circumstances where an implementation MAY do something else. --- Section 9 should really identify the registry from which the allocation is to be made per Barry's comment.
Apologies, I didn't have time to really review this but I don't get how you can change the multicast anchor and routing and yet introduce no new security considerations. The secdir review [1] raised some similar questions to which the authors responded with some suggested changes that I assume will be made in -08. [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04128.html One note: in the answer to the secdir review, the author said: "The addition of the new option does not address any security issue as long as the signaling is properly secured reusing Proxy Mobile IPv6 mechanisms." That could be a misinterpretation of what this section is meant to contain. If so, I'd suggest taking a read of BCP 72 [2] which says that you should document the security considerations of this protocol and not just the new security features it introduces. Or maybe the quoted text is just a slightly loose email, which is quite understandable. [2] http://tools.ietf.org/html/bcp72 Lastly, that's a lot of complicated IPR declarations. I'd not be surprised if those disincentivise implementers. It'd put me off for example. But I guess the wg had consensus that it's ok with that.
I've just one quibble with the document: the IANA Considerations do not properly specify what needs to be done -- the registry isn't mentioned at all. This is *not* a DISCUSS, because IANA have figured out what to do. That said, it wouldn't hurt to make it clear in the document, so that others reading it will know what registry is involved: OLD This document defines a new mobility option, the Dynamic IP Multicast Selector, which has been assigned the type TBD by IANA. NEW This document defines a new mobility option, the Dynamic IP Multicast Selector (see Section 5.1). IANA has assigned this option the type TBD and has registered it in the Mobility Options subregistry of the Mobile IPv6 Parameters registry. [RFC Editor: Please replace "TBD" above with the value assigned by IANA.] END Oh, and I think our custom is to name Section 11 as "Contributors", not "Authors". The RFC Editor will sort that out, I suppose.
draft-jabley-dnsext-eui48-eui64-rrtypes
As I've said in the past, I think this is a bad idea, because it encourages the use of private identifiers in the DNS, which I expect will result in leakage despite the document's admonition against publishing these records in public zones. But the IETF appears to disagree, at least according to the results of the IETF last call, so I will just abstain rather than arguing about it further.
I'm abstaining because I think this is standardising a very dubious practice that is not really needed except (it seems) for compliance with a really silly regulation in one country. But I agree with Ted that the IETF seems to have rough consensus to publish this, which is a pity IMO. - Where is there a definition of a private DNS namespace? If that is not defined, how can an implementer or deployment know whether or not its ok to publish these records in their DNS? I *think* I know that is meant, but not very precisely and absent such a definition isn't there a real danger that the (weak) privacy mitigation suggested will be mythical? (If a good definition exists, all that'd be needed is a reference, and I'm not saying that I think that has to be an RFC, just good and easily accessible.) - abstract and intro: I think you should s/where/if/ in: "This document specifies an interoperable encoding of these address types for use in private DNS namespaces, where the privacy concerns can be constrained and mitigated." The current text suggests that all you need is a "private DNS namespace" and you're done, which is not the case. - Section 5: It was my impression that the IETF LC demonstrated a consensus that the Canadian regulation was crappy. I think to properly reflect the quite rough consensus this should say something about that here, so that its clear that these RRs are not what the IETF would do, were it to design a solution for this use-case. - Section 8: was any consideration given to putting ciphertext forms of these values into RRs? Surely that'd be a better mitigation than depending on access control for DNS queries? For example, in the cited use-case the EUI value could be encrypted with a public-key before being placed into the DNS. (Yes, that's also a crappy solution, but perhaps less crappy than this.)
I do not see that any type of hardware identifier should be stored in the DNS at all. I also find the use case odd, though I do understand that there is a regulatory requirement to implement this. However, I do not want to block this draft and I'm balloting abstain for that reason.
I happen to agree with what Martin says in his "Abstain", but I'm tipping to "No Objection" because the specification documents existing RR assignments (EUI48 and EUI64 are already in http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4), describes the privacy considerations of including this information in the public DNS, and recommends that "EUI-48 or EUI-64 addresses SHOULD NOT be published in the public DNS".
from the secdir reviewer: Should this draft mention that publication of the EUI's could facilitate MAC cloning?
In s9 (from secdir reviewer): Can we replace the term "Global bit" with a term more consistant with RFC5342 or RFC4291? RFC 5342 calls this bit the "Local bit" and the "Local/Global bit". RFC4291 calls this the "universal/local" bit. The IEEE 802 standard talks about "universal" and "local" without actually naming the bit, but lots of online documentation says "universal/local" and "U/L". The privacy concern arises not just from the uniqueness of the EUI but from the fact that it is a more permanent identifier than the IP address associated with the subscriber (as the next paragraph notes). So maybe in the first paragraph: r/in the form of unique trackable/in the form of unique, permanent trackable identities likewise maybe: r/typically change over time/provide a unique permanent identifier
draft-merkle-tls-brainpool
Sigh... More knobs to turn for TLS. Personally I really hope TLS1.3 dramatically cuts down this ciphersuite parameter explosion, but in the meantime this is only making the status quo very marginally worse and the specific ciphers seem ok. For the authors: that's not actionable, and not a dig at you, but more at how we (the IETF as a whole) have allowed this situation to develop over the last decade. I do understand that your use-case is as real as many others. Nit: I'd suggest using BSI on the title page for Manfred's affiliation.
draft-housley-ltans-oids
This is strictly for the shepherding AD... Will we have a management item on the same telechat to approve the expert reviewers?
status-change-2050-to-historic
conflict-review-steffann-tunnels
I agree with the proposed conflict review.
I have no objection to the publication of this survey, but think that it would have been better taken through the IETF process where it would have received a more complete technical review.
conflict-review-irtf-dtnrg-dgram-clayer
conflict-review-pfaff-ovsdb-proto