Eric Rescorla wrote this message on Mon, Aug 03, 2015 at 04:07 -0700:
> 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
You did say: "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."
So, that's how I read that either a vendor will implement the full
version of TCPINC, or not at all...
> 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.
I agree that it would be good if they did both...
> > 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...
> implementations to be required to encrypt traffic that is already TLS
> encrypted. So, regardless of implementation technique, it's not going
If it's encrypted by TLS, then I consider that a encrypted TCP
connection..
> 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.
If a connection signals that it does not want encryption (are we even
going to provide this option), then that is exempt from my argument,
but the whole point of this WG is to encrypt all TCP connections... Do
I need to quote the charter again?
> > 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"
> 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:
I agree that there is useful space for your described behavior, I just
don't think that this WG is the correct place for protocol that will
not ensure as many connections as possible are encrypted...
> - 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..
> > [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.
I forgot to include that the connections are always encrypted unless
otherwise controled (via application or system admin)...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
