Joe Touch <[email protected]> writes: >> * Many of the uses concern APIs that implementations SHOULD provide. >> The reason for the SHOULD is that in some cases this may be impossible >> or inapplicable. For example, if you are implementing TCP-ENO inside >> a dedicated NAS server, there might not be the same notion of >> applications giving API commands. On the other hand, these points are >> pretty important to the success of TCP-ENO, and should be followed in >> the vast majority of cases. > The problem with SHOULD for APIs is that users then can't rely on any of > those features. So the real question is: > - what are the API features that are absolutely required > - why are you listing any that are optional? > > For APIs, the second set ought to be optimizations, not features or > capabilities IMO.
Because the very notion of an API is optional in some cases. An embedded single-purpose network device might not be implemented in terms of sockets or anything else, but rather might have the device functionality completely intermingled with the protocol implementation. Since TCP-ENO is above all a protocol, there's no reason to deem such implementations non-compliant. On the other hand, if this ships with the linux kernel and there's no API call to get the session ID out of the kernel, we have a problem. If this occurred only once in the document, I could add a sentence about the requirement applying only when there's a narrow interface to TCP such as a socket system call interface. Since there are multiple requirements about the API, it would get tedious to repeat such a sentence. >> * "TEP specifications SHOULD refer to hosts A and B to specify >> asymmetric behavior." Again, no explicit exemption, but the point is >> that there might be a TEP that is not asymmetric, or where some other >> optimization makes it better to specify hosts by the numeric order of >> their Diffie-Hellman parameters or something. I suppose I could >> change that to a MAY, but if TEPs talk about active/passive openers, >> that could mess up simultaneous open. > Are you saying it's better to be symmetric? If so, why? > > If not, are you saying that it's more typical that TEPs will be > symmetric? In that case, you shouldn't be using 2119 keywords. Okay, how about these lines: TEP specifications MUST NOT refer to the active and passive opener or the client and the server as a means of specifying asymmetric behavior, as such role assignments are ill-specified in the case of simultaneous open. Rather, asymmetric TEP behavior SHOULD be specified in terms of hosts A and B, unless a TEP contains its own symmetry-breaking mechanism. >> * Implementations SHOULD provide forward secrecy. The important point >> is that the TEPs MUST be amenable to forward secrecy. > That MUST turns the SHOULD into a MUST too. >> We didn't say >> MUST for the implementation because that may not always be >> possible--e.g., implementation considerations may someday require >> keying material to be shared across servers or with a load-balancer or >> something. We don't want to say you can't implement TCP-ENO under >> such circumstances, but we want people to think long and hard about >> the implications for confidentiality. > That consideration is too vague to weaken a MUST into a SHOULD, IMO. > > Why not "MUST provide forward secrecy" and indicate that any future > sharing is viable only when it preserves forward secrecy? The current phrasing was in response to feedback from Yoav Nir (message ID [email protected]): https://www.ietf.org/mail-archive/web/tcpinc/current/msg01026.html Specifically, he wrote: Section 4: o Specs MUST NOT allow the negotiation of encryption modes that do not provide forward secrecy some bounded, short time after the close of a TCP connection. That's not up to the specs. The best that specs can do is to *allow* forward secrecy by not requiring that session keys be derived from long-term keys and inputs sent in the clear. Nothing in any spec that mandates ECDHE, for example, prevents an implementation from hard-coding a key pair, or generating one just once. So the use of SHOULD is an attempt to make people doing some of the things Yoav talks about at least think through the implications. However, in retrospect, perhaps Yoav was objecting to the fact that Specs was the subject of the sentence, in which case it would be okay to say MUST for implementations providing forward secrecy. I would prefer that, because forward secrecy is important. >> * Applications SHOULD authenticate endpoints, SHOULD treat session IDs >> monolithically, SHOULD use the application aware bit. Again, these >> are all obviously very good things. But there are so many different >> things an application can do, and so many constraints applications can >> be subject to, that it seems inappropriate for a transport-layer >> document to use MUST in regards to applications. Anyway, we can't >> enforce what applications will do. > If you say SHOULD, you need to indicate the conditions under which apps > would do otherwise. > > Simply saying "we don't know what they want" isn't enough - you're > providing a framework and app choices have implications in the > capabilities provided. > > E.g., authenticating endpoints kills BTNS-style PKI-free use - but it's > very clear that if you drop authentication, you're allowing MITM attacks > but also raising the bar against off-path attacks. Okay, well I'll fiddle with the document in an attempt to change some SHOULDs to MUST or MAY. It could be that I can use a scoped MUST instead of a SHOULD in some places. > MUST serves to deprecate ExID use faster. IMO, you should say MUST > initiate using the new option and MAY continue to support the ExID for > compatibility with development implementations. > > If you change the protocol so those development variants aren't > something you want to continue to deal with, then just say MUST and move on. > > There's nothing technically wrong with the SHOULD text in RFC7413, but > it shot themselves in the foot IMO by requiring continued legacy support. Well, you seem to be the option enforcer, so if you are happy with MUST, I'll be glad to swap that out. >> * TEPs SHOULD compute session IDs using only well-studied and >> conservative hash functions. Here the problem is that the terms >> well-studied and conservative are subjective. So while I think it's >> an important point people need to worry about violating, the point is >> also nebulous enough that I don't see how to enforce it with a MUST. >> Put another way, the hash functions SHOULD be as conservative as >> practical, with an implicit exception where more conservative hash >> functions are not practical. > > If there is no objective definition of the requirement, then you really > have no business stating it. > > Just talk about what constitutes a good hash functions, even > subjectively. Leave requirements to objective conditions. So... lower-case should? I wish there were some way to specify important points to think about that just aren't specific enough to be requirements. This is what RFC6919 proposes be introduced by "OUGHT TO"... (Although I do note there's non-April-fools use of this term in RFC2616.) David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
