The time to vote on this question is approaching. Forced to vote, I
chose #1 (keep both drafts going for now). But I think we must
appropriately modify the instructions to authors going forward so as to
avoid wasting four months.
Keeping the bigger goal in mind, we should vote for the option that
results in the highest fraction of TCP connections carrying encrypted
traffic. The reason I think waiting four months (with the right actions
July 20) could further that goal is that TCPINC is really solving *two*
problems:
1. Let application authors adopt encryption even when protocols do not
contain room for negotiation (i.e., can't squeeze in a STARTTLS).
In this case, it is okay to have source code changes.
2. Let systems deploy encryption without modifying existing programs
or in cases where for whatever reason TLS does not fit.
Having the AD just pick a winner tomorrow would be good for goal #1,
because both proposals provide the necessary out-of-band negotiation for
encryption, and an earlier decision would lead to earlier deployment.
However, I believe this would not be good for goal #2, particularly if
we go with TCP-use-TLS, which to my mind is tailor-made for a library
implementation. In fact, I'd go so far as to say that TCP-use-TLS could
actually be *improved* if it weren't hamstrung by the need to maintain
API compatibility with TCP. For instance, without such a restriction,
TCP-use-TLS applications could express information about domain names to
the protocol and benefit from TLS's certificate machinery.
Tcpcrypt, by virtue of being designed to be implemented in TCP or as a
packet rewriter, is going to be easier to make work in case #2. There's
a reason that so far only tcpcrypt has provided an implementation that
works with unmodified binaries.
All of this makes me wonder if there might not actually be room for both
protocols on the Internet. With that in mind, if we go forward with
both protocols, rather than charge the two groups with identical
instructions, we should task them with different requirements in the
hopes of getting out a pair of protocols that truly maximizes encryption
of TCP traffic.
Specifically, suppose we instructed authors of the two drafts as
follows:
* Tcpcrypt should be modified to provide application-level signaling
for TCP-use-TLS. It already has support for application-aware bits,
which means the draft must evolve to add support for an
"application-prefers-TLS" option and an
"application-declines-tcpcrypt-but-wants-TLS" option. We would
probably rework things so this mode negotiation is cleaner (a byte
with various option bits).
* TCP-use-TLS should be freed from the notion that it someday needs to
live in the TCP stack, and should therefore be optimized for a
library implementation. It's goal should be to achieve the best
design possible *with API changes*.
These goals can be furthered without making the two protocols dependent
on each other's success. The tcpcrypt protocol can make support for
TCP-layer encryption a SHOULD rather than a MUST, so that if TCP-use-TLS
end up far more popular, people don't have to stick the rest of tcpcrypt
into their kernels. Likewise, if tcpcrypt turns out to be preferable in
practice, people don't have to link their applications with the
TCP-use-TLS library.
David
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
