John-Mark Gurney <[email protected]> writes:
> Is the goal of this draft to get down to one spec? or to allow both
> specs to become standards?
Well, the working group charter is to produce three documents
(framework, protocol, and API). Hence, unless we re-charter, we would
have to reorganize the documents. Part of TCP-ENO (like the normative
requirements for a Session ID) might move into the framework document,
which would then have to be classified as experimental rather than
informational. (The charter doesn't specify the status of the framework
document.) Then other parts of TCP-ENO would be merged with tcpcrypt or
TCP-use-TLS to produce a protocol document.
> From what I see, this allows both specs to become standard, which is
> a bad idea... The WG charter specifically says: "to provide reasonable
> security for the majority of connections.", but if we adopt this, it
> will allow vendors to pick only one of two (or more), claim that they
> support always on encryption, and then a majority of connections will
> not be encrypted because there will be a protocol mismatch.
I think this is absolutely a valid concern. The working group should
not standardize two transport-layer protocols and use TCP-ENO to switch
between them. At the same time, I think we should be highly mindful of
future developments and needs. So that means that while we could have
written TCP-ENO as just a simple cipher-suite negotiation mechanism, we
also wanted to account for the possibility that TCPINC may need to
evolve in much more radical ways than just cipher suites.
A good example is what happens if someday we get large options in SYN
segments? Well, this would potentially allow us to shave round-trip
times from TCPINC, which is not the kind of performance win we'd want to
leave on the table. But the resulting changes would be different enough
from anything we have that we'd want to negotiate it straightaway in the
SYN using variable-length suboptions.
Another issue is that TCPINC should be the transport-layer encryption
mechanism for the Internet. But TCP-ENO can potentially be used to
negotiate application-layer encryption as well. There's a plausible
scenario in which TLS can hugely benefit from just one out-of-band bit
to negotiate library-level use of TLS in a backwards compatible way.
Looking back to Andrea's tcpcrypt slides from IETF89:
http://www.ietf.org/proceedings/89/slides/slides-89-tcpm-9.pdf
The goal he laid out was to attack the problem of unencrypted traffic on
two fronts--increase TLS adoption at the application layer as much as
possible, and then enable transport-level encryption for the remaining
cases. So while increasing TLS is not strictly within the TCPINC
charter, if there's room in TCPINC to reserve "one bit" for the TLS
working group, it might be prudent to do so.
> Expecting OS vendors to implement all protocols again is not a good
> idea... They will want to put their eggs in one basket, and watch that
> basket closely, pay for security audit, etc.
Again, I think this is absolutely a valid concern. To illustrate this
with some completely made up numbers, we could find ourselves in a
situation where giving one bit to the TLS working group allows people to
go from 50% to 70% adoption of TLS overnight, and that's enough of an
improvement that people lose interest in TCPINC. But if TCPINC had been
the only backwards compatible solution, then everyone would have
implemented it in their kernels and gotten us to 90% encryption. But
also if everyone implemented TCPINC and we gave TLS the extra bit, then
maybe we could get to 95% encryption.
This is a question I'm a little ambivalent about because it requires
predicting the future. But with something like TCP-ENO, we have the
groundwork to go in whichever direction the working group decides, and
also more leeway to change our minds down the road.
David
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
