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?
> 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...
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... With
that option, this can happen...
> 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...
> [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..
I don't understand your resistance to having all conforming
implementations of the specification support automatic encryption?
--
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
