On Sun, Aug 2, 2015 at 11:14 PM, John-Mark Gurney <[email protected]> wrote:
> Eric Rescorla wrote this message on Sun, Aug 02, 2015 at 13:29 -0700: > > On Sun, Aug 2, 2015 at 1:16 PM, John-Mark Gurney <[email protected]> > wrote: > > > > > > > > o Implement just the TCP-TLS negotiation option in the operating > > > system kernel with an interface to tell the application that TCP- > > > TLS has been negotiated and therefore that the application must > > > negotiate TLS. > > > > > > So, if TCP-ENO is adopted, and ths TLS-use-TCP draft is adopted, they > > > just have to do TCP-ENO, and no other work, and they've fully > > > implemented the TCPINC WG recommendations, but we have made very little > > > headway to encrypting the internet traffic. > > > > You've made this point several times and I have to say I don't really > > understand > > it. Vendors need not ship TCPINC now and won't have to regardless of what > > Then why even have this option? If you don't think vendors will > implement this option? I didn't say that vendors wouldn't implement this option. As I said, I think it would be good if vendors implemented *both* an automatic option that required no application intervention *and* an option which allowed the application to do out-of-band negotiation. What I don't think vendors will do. > 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 implementations to be required to encrypt traffic that is already TLS encrypted. So, regardless of implementation technique, it's not going to the case that implementations of this specification offer encryption on every single TCP connection. My sense is that that reflects the general feeling of the WG as well. > 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 describe produces identical wire format behavior, and I think there is a useful space for an implementation such as I describe, for a number of reasons, not just implementation convenience. Specifically: - 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. > [0] It's worth noting that yet another way to implement TCP-use-TLS is > with > > the split indicated here but with the TLS implementation in userspace via > > libc modifications shims. This seems like a valid implementation > technique > > and I'm > > not sure what the objection would be to a vendor doing this. > > If they ship w/ it in libc, and fully on by default, and applications > run w/o modifications, then and conforms to the specification, then > that's a valid implementation.. > Great. -Ekr
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
