Kyle Rose <[email protected]> writes:
> This is a review of the latest TCP-ENO draft (02). I am acting as member,
> not chair.
Hi, Kyle. Thanks for the review. We've addressed most of your
comments, so I'll append a diff. Since we are probably going to upload
another draft when we get Jana's review, plus we have to fix IANA
considerations, I'm not going to upload this just yet, but figured the
easiest way so see if you are happy with changes is to send you our
proposed wording. I'll just address a few points that we didn't know
what to do with for discussion.
> [4] I feel like "spec" is being overloaded to mean algorithm, protocol, and
> functional specification. I also suspect everyone knows what you mean, so
> maybe clarifying it isn't worth the effort. I really only noticed it when I
> hit the line q( It uses a new TCP option kind to negotiate one among
> multiple possible encryption specs--separate documents describing how to do
> actual traffic encryption ), because you're not negotiating documents,
> you're negotiating either an algorithm or a protocol.
I agree that spec is a bit of a made up word, here, but we've failed to
come up with a better one. For what it's worth, you are kind of
negotiating a document and a protocol. But basically I think we would
need a more concrete suggestion to do something about this awkwardness.
> [4.1] I'm mostly going to leave this issue to David Black, but IMO all
> references to option 69 should just be removed from the document.
So from my limited experience, it seems like one is supposed to ask IANA
for a specific number to which they reply yes or no, rather than asking
them to choose the number. I was hoping that since we say you MUST NOT
implement 69, this would satisfy the objections to option kind
squatting. (Michael Scharf did at one point suggest he would be okay
with the statement, "This protocol specification MUST NOT be implemented
prior to assignment of a TCP option kind number.")
But if it's better to use a symbolic constant like ENO, we can do that,
too. We'll defer to people who know the process better.
> [4.4] The line q( A suboption preceded by a length byte MUST be a spec
> identifier ("cs >= 0x20") and MUST have "v = 1" ) precludes q( If the octet
> following a length byte has the high bit clear ).
Right, the idea here is that if v=0, then it's not a suboption preceded
by a length byte, but rather a length word. We've tried to clarify the
language.
> [4.4] It seems like a client conforming to a future revision of this spec
> would forever be unable to use zzzz != 0 and negotiate encryption with
> implementations based on this spec, which probably makes sense since it
> might be encoding length in a way an old implementation couldn't
> understand, rendering the rest of the suboptions unparseable. I'm guessing
> any attempt to use a non-zero zzzz in SYN-only segments would result in a
> new ENO option kind, so I wonder if it wouldn't be better just to list the
> 4 '0's explicitly.
>
> Alternatively, since a TCP option itself is limited to 255 bytes by virtue
> of the option format, maybe we should assume zzzz will never be part of the
> length but might encode some other suboption-specific information, and so
> mandate that any use of non-zero zzzz MUST result in successful
> backwards-compatible encryption negotiation if there exist other valid
> specs among the suboptions.
Obviously the issue here is what happens in the very distant future if
ever TCP SYN option space becomes huge, like more than 255 bytes. As
you point out, there is the separate limitation that each option only
has one byte of length.
In the previous draft, we figured that in case both problems are fixed
(total option space an individual option length), we might as well have
a 12-bit length word. Upon further reflection, we figured that isn't
super likely. Instead, it may become necessary to split TCP-ENO over
multiple options, or reference extension options, or something else we
haven't yet thought of, for which it's better to have completely
reserved the zzzz bits right now. It will already be a miracle if we
get >256 bytes of aggregate SYN option space, so there are just too many
unknowns about whether we'll ever get >256 bytes per individual option.
If ENO is adopted, we can always just standardize what to do with jumbo
options at the time those become available, in the hope that people will
implement both at the same time. For that, it is better to have
completely reserved bits that cause legacy applications to abort than to
have some weird thing where we mispredicted the future.
Now, why not hard-code 0's instead of having zzzz? Well, the initial
100 bits are how you recognize that you have a length byte/word; the
meaning of every other value of the high 3 bits is already fully
specified. However, if we just wrote 1000000, then we haven't addressed
the question of what 100zzzz means for values of zzzz other than 0000.
We used the zzzz variable to make sure every possible byte sequence was
defined (even if the definition for zzzz != 0000 is just abort). Does
that make sense?
> [5.1] q( The session ID MUST depend in a collision-resistant way on fresh
> data contributed by both sides of the connection. ). Is this clear enough
> to rule out specs that, for instance, take random data from each side and
> XOR it? I think it does if "collision-resistance" is interpreted as
> applying to the set of raw inputs to the session ID computation; it doesn't
> if a spec author interprets it as applying to the string used as the input
> to the collision-resistant compression function they employ to produce the
> final session ID, where that string is some function of the raw inputs.
XOR is not collision-resistant. I'm not sure I understand your second
interpretation well enough to craft language to rule it out. Do you
have any suggested language?
> [5.1] q( Unless and until applications disclose information about the
> session ID, all but the first byte MUST be computationally
> indistinguishable from random bytes to a network eavesdropper. ). For DH,
> this seems to imply that the session ID must be a function of the output of
> the key agreement, because all other input to the session ID is public. Is
> this actually necessary, however? I've been struggling with whether it even
> matters if an eavesdropper can compute the session ID from a public
> transcript: the two required properties seem to be that both ends of the
> connection can compute it, and that it be unique over all time with
> overwhelming probability.
This was discussed on the mailing list, and the feeling was that there
are cases where you might want to generate crypto keys from the session
ID (for example to authenticate that another connection belongs to the
same host as the first connection).
An alternative would be to require specs to provide an RFC5705-like
exporter facility. That's more complicated, but still open to
discussion if people feel strongly about it.
> [9] The first paragraph here *really* makes me want to figure out a way to
> conceal "a" from passive eavesdroppers because it means active attackers
> wouldn't know until it's too late that they can't safely MitM a connection.
> Not sure if there's any way to achieve this. It may be irrelevant because
> the application-aware bit can be set to 0 for applications that will not
> function without transport encryption. Maybe that's actually the answer:
> recommend that the application-aware bit be set to 1 only for application
> protocols that are willing to function without encryption, and 0 at all
> other times.
Well, if an eavesdropping ISP starts downgrading only connections with
a=0, then everyone can just start setting a=1... It could also be that
if connections are downgraded, an application falls back to some other
form of encryption...
But I see your point, I just don't know what to do about it, especially
because in the case of mandatory application-aware mode, you don't want
to go through the trouble of key exchange in the first place.
> [9] In the last paragraph, you might want to generalize this to all non-SYN
> ENO options, which as you've stated earlier in the document are perfectly
> cromulent. (You can imagine a spec that for some reason sends data in ENO
> options in both directions during the key exchange. It seems both unlikely
> and pointless, but if it's possible, according to the monkey-typewriter
> theorem someone will eventually do it.)
Other than the third leg of the handshake, any other non-SYN ENO options
will be after the key agreement, so can just be encrypted or MACed. But
to be honest, even that last paragraph seems a little weird to me, and
is there by request of someone else. I think the idea is that the first
ACK is part of the TCP handshake, so people might subconsciously think
it is part of the negotiation transcript. I'm happy to substitute
whatever wording you want to suggest.
Anyway, below are the diffs so far.
Thanks,
David
--- draft-ietf-tcpinc-tcpeno-02.md 2016-06-29 23:34:37.929943820 -0700
+++ draft-ietf-tcpinc-tcpeno-03.md 2016-07-01 22:11:48.696993934 -0700
@@ -196,15 +196,17 @@
: A TCP segment in which the SYN and ACK flags are both set
Active opener
-: A host that sends a SYN-only segment. With the BSD socket API,
-this occurs when an application calls `connect`. In client-server
-configurations, active openers are typically clients.
+: A host that initiates a connection by sending a SYN-only segment.
+ With the BSD socket API, this occurs when an application calls
+ `connect`. In client-server configurations, active openers are
+ typically clients.
Passive opener
-: A host that does not send a SYN-only segment (only a SYN-ACK
- segment). With the BSD socket API, this occurs following a call to
- `listen`. In client-server configurations, passive openers are
- typically servers.
+: A host that does not send a SYN-only segment, but responds to one
+ with a SYN-ACK segment. With the BSD socket API, passive openers
+ call `listen` and `accept`, rather than `connect`. In
+ client-server configurations, passive openers are typically
+ servers.
Simultaneous open
: The act of symmetrically establishing a TCP connection between two
@@ -242,8 +244,8 @@
identifier,
* A few extra bytes of suboption data from each host, if needed by the
spec,
-* A negotiation transcript that the negotiated spec must
- cryptograhpically authenticate,
+* A negotiation transcript with which to mitigate attacks on the
+ negotiation itself,
* Role assignments designating one endpoint "host A" and the other
endpoint "host B", and
* A few bits indicating whether or not the application at each end
@@ -415,12 +417,17 @@
`m`
: The middleware bit `m` functions similarly to the application-aware
-bit `a`. It is available for middleware such as shared libraries
-needing out-of-band signaling to improve the security of legacy
-applications. Implementations MUST set this bit to 0 by default and
+bit `a`, but is available to middleware shared by multiple
+applications, some of which might have an independent use for the `a`
+bit. When set, the bit indicates a desire to engage in some endpoint
+authentication protocol before turning the connection over to the
+application. Implementations MUST set this bit to 0 by default and
SHOULD provide an API through which software can change the value.
-Unlike the application-aware `a` bit, no mandatory mode is needed for
-the middleware bit.
+Unlike the application-aware bit `a`, no mandatory mode is needed for
+the middleware bit. Middleware using the `m` bit SHOULD employ length
+fields and unique authentication scheme identifiers so as to allow the
+`m` bit to be multiplexed by multiple schemes, but the mechanism for
+doing so is outside the scope of this document.
`zz`
: The `zz` bits are reserved for future revisions of TCP-ENO. They
@@ -504,11 +511,12 @@
Figure: Suboption with length byte
If the octet following a length byte has the high bit clear (meaning
-`v = 0`), then the length byte and following octet together are
-interpreted as a length word, as shown in (#fig:marker-word). The
-length word encodes an 8-bit value corresponding to one less than the
-suboption data length. As with length bytes, spec identifiers MUST
-have `v = 1`.
+`v = 0`), then it is not a suboption. Instead, the length byte and
+following octet together are interpreted as a length word, as shown in
+(#fig:marker-word). The length word encodes an 8-bit value
+corresponding to one less than the suboption data length. As with
+length bytes, the octet following a length word MUST be a spec
+identifier suboption and MUST have `v = 1`.
{#fig:marker-word}
bit 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
@@ -593,9 +601,12 @@
To defend against attacks on encryption negotiation itself, encryption
specs need a way to reference a transcript of TCP-ENO's negotiation.
-In particular, an encryption spec MUST fail with high probability if
-its selection resulted from tampering with or forging initial SYN
-segments.
+In particular, an encryption spec MUST with high probability fail to
+establish a connection between two honest endpoints if the spec's
+selection resulted from tampering with or forging initial SYN
+segments. (Of course, in the absence of endpoint authentication, two
+honest endpoints can still each end up talking to a man-in-the-middle
+attacker rather than each other.)
TCP-ENO defines its negotiation transcript as a packed data structure
consisting of two TCP-ENO options exactly as they appeared in the TCP
@@ -653,11 +664,12 @@
## Session IDs
Each spec MUST define a session ID that uniquely identifies each
-encrypted TCP connection. Implementations SHOULD expose the session
-ID to applications via an API extension. Applications that are aware
-of TCP-ENO SHOULD incorporate the session ID value and TCP-ENO role (A
-or B) into any authentication mechanisms layered over TCP encryption
-so as to authenticate actual TCP endpoints.
+encrypted TCP connection and that is computable by both endpoints of
+the connection. Implementations SHOULD expose the session ID to
+applications via an API extension. Applications that are aware of
+TCP-ENO SHOULD incorporate the session ID value and TCP-ENO role (A or
+B) into any authentication mechanisms layered over TCP encryption so
+as to authenticate actual TCP endpoints.
In order to avoid replay attacks and prevent authenticated session IDs
from being used out of context, session IDs MUST be unique over all
@@ -814,11 +826,15 @@
underlying TCP connection. Such an API enables the possibility of
authenticating servers transparently to the application, particularly
in conjunction with technologies such as DANE [@?RFC6394]. The
-middleware bit `m` in general suboptions enables a middleware library
-to indicate to the peer that it wishes to engage in an authentication
-protocol before turning the TCP connection over to the application.
-Different middleware authentication protocols can employ unique
-identifiers to multiplex the `m` bit.
+middleware bit `m` allows such authentication to be slipped underneath
+legacy applications--if both sides set the `m` bit, then before
+turning the socket over to the application, the two endpoints engage
+in a server authentication protocol. Over time, the consequences of
+failed or missing authentication can gradually be increased from
+issuing log messages to aborting the connection if some
+as yet unspecified DNS record indicates authentication is mandatory.
+Through shared library updates, such authentication can potentially be
+added transparently to legacy applications without recompilation.
TLS can currently only be added to legacy applications whose protocols
accommodate a STARTTLS command or equivalent. TCP-ENO, because it
@@ -831,7 +847,7 @@
devolving to unencrypted TCP rather than causing the entire TCP
connection to fail.
-Because some network paths drop ENO options in one direction only, a
+Because a network path may drop ENO options in one direction only, a
host must know not just that the peer supports encryption, but that
the peer has received an ENO option. To this end, ENO disables
encryption unless it receives an ACK segment bearing an ENO option.
@@ -922,10 +938,11 @@
kind of endpoint authentication. Opportunistic encryption protects
against undetectable large-scale eavesdropping. However, it does not
protect against detectable large-scale eavesdropping (for instance, if
-ISPs terminate and proxy TCP connections or simply downgrade them to
-unencrypted). Moreover, it emphatically does not protect against
-targeted attacks that employ trivial spoofing to redirect a specific
-high-value connection to a man-in-the-middle attacker.
+ISPs terminate TCP connections and proxy them, or simply downgrade
+connections to unencrypted). Moreover, opportunistic encryption
+emphatically does not protect against targeted attacks that employ
+trivial spoofing to redirect a specific high-value connection to a
+man-in-the-middle attacker.
Achieving stronger security with TCP-ENO requires verifying session
IDs. Any application relying on ENO for communications security MUST
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
