On Mon, Aug 3, 2015 at 12:38 PM, John-Mark Gurney <[email protected]> wrote:
> Eric Rescorla wrote this message on Mon, Aug 03, 2015 at 04:07 -0700 > > > we standardize. So, yes, they could do as you suggest, but if their > > > > intention > > > > is not to provide automatic encryption to their users, it would be > far > > > > easier > > > > to simply not implement TCPINC at all, rather than just implement an > > > > in-kernel flag. > > > > > > You forget that vendors play the standards game... You must adhere > > > to standard X, or your product must follow an open standard... But > > > at various levels, they just say, oh, supports automatic encryption, > > > must be good, but fail to understand that it required application > > > modification, or that though they support RFCxyz that does automatic > > > encryption, it isn't... > > > > OK, I now see what you're saying. I've never found this argument to be > > particularly persuasive as an argument for 2119-level MUST requirements. > > That may be true in some cases where, for instance, the customer > generally > > wants some functionality (e.g., SIP) and then they have a list of the > > RFCs that constitute conformance, but I don't generally think it's going > > to be that useful a strategy for vendors to nominally implement some RFC > and > > then have it not encrypt anything. > > > > If two vendors have conforming implementations of the output of this > > > WG, and they do not encryption all the TCP connections between them, > > > then I consider that a failure on this WG to do it's charter... > > > > Well, I definitely don't agree with this. For instance, I don't want > > You don't agree that if two implementations should always result in an > encryption connection of some kind? I specificly left out how the TCP > connection was encrypted, be it userland TLS because both sides signaled > it could do that, or the always on, anonymous encryption put forth by > this WG... I think it's completely legitimate and should be conformant for implementations to be configurable so they only offer tcpinc on some TCP connections. They might do that to allow for space for application-level encryption or for other reasons. I don't see anything in the charter that prohibits this. > > With that said, I think that the mode you mention above *is* of value to > > > > users > > > > because it allows out of band negotiation of TLS, so I would hope > that > > > > vendors would > > > > implement both a version that upgraded all applications and one that > just > > > > allowed applications to upgrade themselves [0]. > > > > > > I'm not saying that it shouldn't be an option, but it isn't this WG's > > > charter to do this... If you feel that strongly about this option, > > > then bring it up as part of the TLS WG or another one... But this WG > > > is about enabling always on encryption... > > > > Yeah, I think this is unduly focusing on the implementation. This WG is > > about > > defining *protocol* and the protocol the implementation technique that I > > I can't parse: "and the protocol the implementation technique" s/and the protocol// > - It's much safer for vendors to ship and users to turn on because it > > puts the responsibility for potential breakage on the application, > which > > is better able to bear it (this is a real problem with any new protocol > > rollout at this point, which is why people implement fallback). > > > > - It allows applications to gradually shim their way up to > non-opportunistic > > security as Christian indicates. > > > > However, if you're worried about people gaming the system, then I sugges > > that something like the proposed ENO draft provides a good mechanism for > > meeting > > both our requirements. Simply have two RFCs, one of which defines > > the protocol and one of which defines the "on-by-default" behavior you're > > concerned with. This allows us to define flexible mechanisms while > > allowing for a seal of approval that defines a specific behavior. > > I disagree w/ this. There should be the protocl that requires > "on-by-default" behavior, and the TCP-ENO draft that allows the > negotiation of your idea, userland shim or the "on-by-default" > behavior... > > It could be that I'm misunderstanding what you call the protocol... > I'm calling the protocol, either the TLS-use-TCP or tcpcrypt the > protocol, and then ENO is just a signalling mechnism which is different.. Well, I'm more than happy to have some RFC that says "you must have this on by default for every connection unless someone turns it off by some mechanism and then people can be conformant to that RFC or not. I'm not happy to have the mechanism that this WG defines for signaling require that policy, since I think it's unduly restrictive. And since the wire protocol is the same regardless, I don't really see the issue. -Ekr
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
