Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01
On 25/08/15 17:54, David Mazieres wrote: > TCP-ENO is an > effort A) to make progress on common elements of TCP-use-TLS and > tcpcrypt, The above is reasonable. ... > Well, in order to make the choice between tcpcrypt and TCP-use-TLS the > most salient, it seems worth maximizing the advantages of the two > protocols. I think your goal (A) and "maximising the advantages" of tcpcrypt (or of TLS) are incompatible goals at this point in time. If/when the WG adopt tcpcrypt optimisations relating to algorithm agility will inevitably be explored. If/when the WG adopt TLS that kind of change wouldn't make sense. In the meantime trying to squeeze discussion of loads of different things into discussion about TCP-ENO seems mostly a distraction. S. ___ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01
Watson, On Tue, Aug 25, 2015 at 7:06 AM, Stephen Kent wrote: Watson, On 8/24/15 4:37 PM, Watson Ladd wrote: On Mon, Aug 24, 2015 at 1:08 PM, Stephen Kent wrote: Watson, based on many years of experience dealin wit this sort of issue I suggest that the relative merits (strength, etc.) of cipher suites form a lattice, not a total order. Every lattice has a compatible total order more properly, a total order can be imposed on a lattice. I don't see the difference between these two statements, and I don't see the relevance. pity, I tried. Earlier people raised examples of ciphersuites with no comparison between them. Why does what you are saying matter more? What's the connection between being a lattice, and picking just one ranking not a good idea. they're equivalent, but since you seem to bring an academic perspective to the discussion I thought you might like a more math-oriented response ;-). into the reality of comparing ciphersuites justifies exposing all possible ciphersuites, and permitting specifying arbitrary preferences among them? The preferences of others are "arbitrary" but yours are not? Of course it's an arbitrary choice! My question is why is it not a good idea to pick a single nothing-else-is better suite. and have a mechanism designed to support migration if weaknesses are discovered? So far as I can tell the argument has been that people have different orderings, and should be allowed to express them. But this doesn't actually get to the fundamental issue: how much more secure are people if they will use X instead of Y if the other side wants it, then if they prefer Y instead of X? protocol design is a complex process where there often is not a single "right" answer. preserving the ability of different sets of folks to do what they perceive as the "right thing" has often been a critical element of successful standards. Yes, this can lead to bad outcomes, but trying to dictate one answer is also likely to lead to a bad outcome, i.e., nobody adopts the standard. Steve ___ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01
> A->B: SYN "Hey, I support tcpcrypt and TLS" > B->A: SYN "Hey, I support tcpcrypt" > A->B: ACK(+) "Great, let's use tcpcrypt with cipher suite X or Y" > B->A: ACK(+) "Great, let's use tcpcrypt with cipher suite Z" > A->B: ACK(*) DH parameter, etc. One way to resolve this for TLS is to just make TLS one of the cipher suites: A->B: SYN "Hey, I support (TLS, tcpcryptX, tcpcryptY)" B->A: SYN "Hey, I support (TLS)" A->B: ACK "Great, let's use TLS" B->A: ACK "Great, let's use TLS" And then switch to straight-up TLS, whether in userspace or in the kernel. In userspace this is a little tricky in that a software or administrative change to the cipher suite preference list should be made when TCP-ENO is activated by default in the kernel: as long as one of the two endpoints is properly configured, tcpcrypt-unaware endpoints will do the right thing, but if both endpoints are improperly configured you'll get two key exchanges and connections will be doubly-encrypted. (An HTTPS server implementor might just choose to turn off TCP-ENO for port 443, which would have the desired effect.) For passive/active, the same basic logic applies: A->B: SYN "Hey, I support (TLS, tcpcryptX, tcpcryptY)" B->A: SYN-ACK "Great, let's use TLS" B->A: ACK "Ok, let's use TLS" Kyle ___ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01
Stephen Farrell writes: >> What is eminently deployable is using TCP-ENO to negotiate a >> ciphersuite. E.g., you can agree to use curve25519 for ECDHE by the end >> of the SYN exchange, and include a DH parameter in the first data >> segment of a connection, after only one round trip. > > So yes one could. But that assumes that the WG have not chosen > to do TLS I think, doesn't it? If the WG did choose TLS then > ciphersuite selection has to happen in the TLS h/s or else we > will not get the security guarantees that TLS is supposed to > give us. Right. So my working assumption is that the WG has not killed tcpcrypt yet, and is still deciding on tcpcrypt vs. TCP-use-TLS. TCP-ENO is an effort A) to make progress on common elements of TCP-use-TLS and tcpcrypt, B) to satisfy people from tcpm who believe (correctly, IMO) that TCPINC would benefit from future TCP enhancements, and C) to enable a fixed target API for application writers so that any application-level efforts to leverage TCPINC will continue to apply even across significant revisions of TCPINC. > Even without the large options, whacking in ciphersuite specific > values in TCP-ENO now is a bad plan as it (for me anyway) further > muddies the already muddy waters within which we've been fishing > for consensus in this WG. (Apologies for the strained analogy and > even more for the pun in the apology:-) Well, in order to make the choice between tcpcrypt and TCP-use-TLS the most salient, it seems worth maximizing the advantages of the two protocols. The big advantage of TCP-use-TLS is compatibility with TLS. Hence, the obvious way to fit TCP-use-TLS onto tcpcrypt is to use a single ENO suboption to trigger it, and then use as much TLS as possible for everything else. The big advantage of tcpcrypt is simplicity (and hence easier analysis) as well as its tight fit with TCP, for which it was specifically designed. So for that our thinking was that TCP-ENO already specifies a suitable negotiation mechanism, let's not have two different negotiation mechanisms when we only need one. It doesn't feel particularly "whacked in"--in fact there's a very straight-forward fit. It's basically about as simple as you can get: A->B: SYN "Hey, I support tcpcrypt suite X and tcpcrypt suite Y" B->A: SYN-ACK "Great, let's use X" A->B: ACK "Agreed, here's my DH parameter" B->A: ACK "Here my DH parameter, ciphertext from here on out" ... The alternative (more like the previous draft of tcpcrypt) would be: A->B: SYN "Hey, I support tcpcrypt and TLS" B->A: SYN-ACK "Great, let's tcpcrypt with cipher suite X or Y" A->B: ACK(*) "I choose X and here's my DH parameter" B->A: ACK(*) "Here my DH parameter, ciphertext from here on out" ... (*)These segments use TCP data for TCPINC messages, not application data. That's also pretty simple, and works perfectly well with the existing TCP-ENO. I'd be delighted to do it if we didn't support simultaneous open. But simultaneous open risks scenarios like this: A->B: SYN "Hey, I support tcpcrypt and TLS" B->A: SYN "Hey, I support tcpcrypt" A->B: ACK(+) "Great, let's use tcpcrypt with cipher suite X or Y" B->A: ACK(+) "Great, let's use tcpcrypt with cipher suite Z" A->B: ACK(*) DH parameter, etc. (*)TCP payload includes TCPINC message. Now this gets messy if either of the segments market (+) is dropped, because those segments don't consume sequence numbers, and so wouldn't ordinarily get ACKed. > *If* the WG selected tcpcrypt then it might make sense to see > if algorithm agility could be sufficiently well supported in the TCP > handshake. I'm not sure if it could or not myself. But if the WG > selects TLS or decide to pursue both (ick) then that'd not make > any sense that I can see. So there are multiple issues being discussed in this thread: 1. Should IETF set a global total order on ENO suboption preference, or should hosts be able to configure this? 2. Should simultaneous open enable encryption with no application involvement, or is it okay to require a socket option? 3. Should tcpcrypt leverage TCP-ENO suboptions for ciphersuite negotiation? Questions 1-2 affect the TCP-ENO draft. Question 3 does not affect the TCP-ENO draft. The discussion touched on both because answering YES to question 1 forces us to answer NO to question 3. However, my sense is that the working group mostly believes the answer to #1 is YES. In that case, does it not make sense to answer question 3 (which affects only the next tcpcrypt draft) under the assumption that the WG will select tcpcrypt? This is not being presumptuous, it's being realistic that if the WG does not adopt tcpcrypt, we will have to chuck the document. So why not optimize the document for the case in which it actually gets used, no? That's not to say the answer to #3 is automatically YES. We are leaning towards YES because, a posteriori, having fiddled with the tc
Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01
On Sun, Aug 23, 2015 at 9:26 AM, David Mazieres < dm-list-tcpcr...@scs.stanford.edu> wrote: > Eric Rescorla writes: > > > But, as I note, at the cost of a byte if you *ever* want to have >1. My > > experience > > is that things get more complicated, rather than less. > > Well, I'd say TCP's experience is that option space gets more precious, > not less. I think the most common case is going to be that the SYN > proposes a bunch of one-byte suboptions and the SYN-ACK contains a > single suboption that is either one byte or variable length. That's > what TCP-ENO is optimized for. > > The "things get more complicated" argument is valid because software > doesn't typically have weight-and-balance-style restrictions like > aircraft. Yet the 40-byte option limit is just such a hard limit. > > Anyway, I'm not sure we can usefully debate this point without more > data, so maybe this question should be deferred until later in the > process? The usual way to handle this is with an [[OPEN ISSUE]] marker. > > That said, if you can provide an explicit example of why you might want > >> multiple variable-length suboptions, you could possibly convince us to > >> optimize for that case. > > > > > > I think it's a general issue of protocol hygiene, but with that said, > this > > would allow you to have an optional long tiebreaker for NAT penetration. > > That's too general to convince me. A totally reasonable standard for an individual submission. Less so for a WG document, which I understand you would like this to be. > > bit to 1 at the endpoint with the lowest (public-IP-address, > >> public-port-number) pair. > > > > > > As you say elsewhere, this is common in cases of NAT penetration and > > generally in NAT penetration cases you don't know your IP address > > with certainty. For instance, say we have two devices with apparent > > addresses: > > > > A: 10.0.0.1 (host), 198.51.100.1 (srflx) > > B: 10.0.0.2 (host), 192.0.2.1 (srflx). > > > > Which one has the lower IP address? > > Well, assuming the RFC5737 addresses are publicly routable, obviously B > has a lower IP address. > OK, that was what I was expecting you to say, but unfortunately the situation isn't always so simple. Consider what happens from A's perspective if he is doing trickle ICE and assume for simplicity that B is non-NATed so he just has the 192.0.2.1 address. ASignalingBSTUN STUN Check -> Host Cand > Host Cand --> <-- Candidate <--- Candidate SYN > X <-- STUN Response At the point when A sends his first SYN (labelled X) he knows his host address (10.0.0.2) and B's srflx (192.0.2.1) so he thinks his address is lower. However, after he gets the STUN response from the server, he learns his srflx and that it's higher than B's (note: in ICE you do only one check from both the srflx and the host candidates). There may be some way to resolve this, but it's not clear to me that in general it will be possible, and it's not clear to me in any case how the "b" bit helps. If the simultaneous open is happening in any kind of application, the > two sides will need to use STUN or some other service to figure out > their public IP addresses and determine that they are behind the > appropriate kind of NAT. ICE actually does the combinatoric explosion of all the IP address pairs, not NAT characterization. > > In the case where that was worked out most carefully at IETF (RFC 5245), > > a much larger tiebreaker is used. > > RFC5245 uses an 8-byte tie-breaker. So to put our options in a table: > >+--+--+-+ >| | application- | option| >| works ever | transparent | space | > +--+--+--+-+ > |drop simultaneous | no | no | 0 | > |open support | | | | > +--+--+--+-+ > |TCP-ENO draft | yes | no* | 0 / 1 bit | > +--+--+--+-+ > |TCP-use-TLS | yes | no* | 0 / 48 bits | > +--+--+--+-+ > |always-on RFC5245 | yes | yes | 48 bits** | > +--+--+--+-+ > > *TCP-ENO requires applications to break the tie, while TCP-use-TLS only > requires applications to set a single bit indicating they are about to > engage in a simultaneous open. > > **RFC5245 uses 64 bits, but TCP-use-TLS shows you can do the same thing > with only 48 bits. > Well, 48 versus 64 is just a matter of statistics. I.e., how many failures are you willing to accept with simultaneous open? To be honest, 32 bits is probably enough. > > As it i
Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01
Scharf, Michael (Michael) wrote: > To: David Mazieres ... > >> In fact, it's possible to fit a 32-byte ECDH parameter into a SYN-ACK >> segment today. It's always possible to fit _one_ thing in -- what's hard is fitting all the things folks consider "necessary". We've come late to this dance. :^( We should expect a lot of pushback putting that much in SYN-ACK until there is a Proposed Standard for expanding the SYN-ACK option space. >> That means even without large SYN options, we can imagine making TCPINC >> zero latency. "Zero latency" isn't the right target, IMHO. We should be advocating for low latency by alieviating buffer-bloat latency overall; and designing a default-case where we're not negotiating in the originating SYN: merely allowing for negotiation later. Until TCPM gets a "round tuit" and increases option space at least for the SYN-ACK, we're facing an almost insurmountable obstacle to deployment. >> Realistically, doing so will require a gross hack in which TCP-ENO >> compactly encodes timestamp and SACK availability, window scaling, >> etc., in lieu of larger options. I strongly advise against going there. Deployment would take forever! >> I don't expect people would be very happy with something like that from >> day one. But we don't want to shut the door to such an optimization >> either, in case TCPINC becomes a runaway success. Ah! Youthful optimism! It's refreshing to see it! >> (We've been careful to leave a bunch of reserved suboptions in the >> TCP-> ENO spec just in case we need extra bits for such optimizations.) > > I've not followed this thread. But this discussion about long options in > SYN, modifying existing TCP options, etc. really scares me. I've always > thought TCPINC's objective is to provide *payload* encryption, and > negotiating this should IMHO not require any complex option. I wonder if we _have_ a shared goal there... > I am also confused about the actual technical details in this > discussion. In my understanding, the SYN-ACK for any modern high-speed > TCP stack has to carry MSS (4 bytes), windows scale (3 bytes), and > SACK permitted (2 bytes). (In _many_ cases, timestamp is automatically included, in order to disambiguate over-large bandwidth-delay-product and error-correction algorithms trying to avoid packet loss. This _is_ of course a terrible design; but we seem to be stuck with it for at least five more years.) > This means that at most 31 bytes are left (in theory, we have plenty of > other TCP extensions consuming parts of it). +1 > Also, I believe some middleboxes/firewalls may act upon those options > in the SYN-ACK, i.e., they cannot easily be replaced or encoded in a > more compact way. As a result, I somehow don't understand how to get a > 32 byte value into SYN-ACK without EDO (draft-ietf-tcpm-tcp-edo). That really _is_ a non-starter. If we want negotiation in the SYN-ACK, we need to push the TCPM group to publish _some_ Proposed Standard. (Myself, I'd rather avoid the need for negotiatting in our first Proposed Standard: deployment of draft-ietf-tcpm-tcp-edo is going to be too slow for what I thought our target deployment to be. :^( > And for EDO there are deployment challenges with using it in the SYN-ACK, see > the discussion in TCPM. Seriously, we SHOULD follow (and participate in) the TCPM discussion. > In any case, this sort of discussion on SYN option space IMHO should be > taken to the TCPM list. I suspect we need to continue the discussion here; but recognize that multi-byte TCP options simply won't be available without TCPM action. :^( -- John Leslie ___ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01
Hiya, On 25/08/15 15:27, David Mazieres wrote: > Stephen Farrell writes: > It is not at all clear to me that that'd be a good plan. I think the gross-hack that it may one-day open up is unlikely to be worth it, and negotiating once is bad enough so it'd seem like a bad plan to do it twice, which I think would be the inevitable outcome. >>> >>> Sorry, I can't reconcile the first and last sentence of that paragraph. >> >> If a mechanism defined in the TCP-ENO document "supported" ckiphersuite >> negotiation, but was not deployable (which seems like it'd be the case >> given attempts to squeeze in 32 bytes of DH public) then you'd end up >> having to support algorithm agility in-band anyway. Hence bad-plan + >> doing it twice. > > I wish I hadn't conflated things. Conflating often does that - but none of us are perfect, certainly not me;-) > What's not deployable today is > putting a DH key exchange into SYN segments. The downside (in terms of > ruling out timestamp, MSS, etc.) is simply not realistic. Of course, > that's the long-term dream, so I discussed it, but realistically it > cannot happen without large options, so let's just forget I ever > mentioned it. Good. > > What is eminently deployable is using TCP-ENO to negotiate a > ciphersuite. E.g., you can agree to use curve25519 for ECDHE by the end > of the SYN exchange, and include a DH parameter in the first data > segment of a connection, after only one round trip. So yes one could. But that assumes that the WG have not chosen to do TLS I think, doesn't it? If the WG did choose TLS then ciphersuite selection has to happen in the TLS h/s or else we will not get the security guarantees that TLS is supposed to give us. Even without the large options, whacking in ciphersuite specific values in TCP-ENO now is a bad plan as it (for me anyway) further muddies the already muddy waters within which we've been fishing for consensus in this WG. (Apologies for the strained analogy and even more for the pun in the apology:-) *If* the WG selected tcpcrypt then it might make sense to see if algorithm agility could be sufficiently well supported in the TCP handshake. I'm not sure if it could or not myself. But if the WG selects TLS or decide to pursue both (ick) then that'd not make any sense that I can see. So trying to figure out now if or how algorithm agility can be handled via TCP options is IMO a bad plan that may move us further away from rather than towards consensus. If TCP-ENO is proposed as a meta-negotiation of the security protocol to use that is arguably different. I still don't like it (as I don't want us to continue processing both TLS and tcpcrypt, though it seems like Martin T. disagrees with me on that) but at least that meta-negotiation wouldn't repeat stuff done within TLS or tcypcypt so isn't nearly as bad as putting ciphersuite stuff into TCP options (now). Cheers, S. > > As you say, we probably only need two or three ciphersuites in play at a > time, a primary and one in case the primary starts looking weak, and > maybe third to satisfy diversity of algorithm designers. So there's no > reason ENO can't chose between these three. > >>> We are currently rewriting tcpcrypt to consume three ENO suboptions, one >>> for P-256+AES-128, one for P-512+AES-256, and one for >>> Curve25519+Chacha/Poly1305. Compared to the existing draft, this lets >>> us ditch PKCONF and pretty much everything except the DH parameters in >>> INIT1 and INIT2 messages. We are also ditching RSA (which at this point >>> was there "just in case," because tcpcrypt had to be future compatible >>> with things other than DH, but now ENO frees us from worrying about >>> future compatibility). The result is a much simpler document. >> >> I'll just repeat that I think that's a bad plan and you'd be >> better off not making such changes. > > If you can elaborate on this, we would certainly appreciate it. We > certainly can leave a second level of negotiation in tcpcrypt--that > would even be easier for us--but it will add pages to the RFC, so it > would help to understand why. > > David > > ___ > Tcpinc mailing list > Tcpinc@ietf.org > https://www.ietf.org/mailman/listinfo/tcpinc > > ___ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
Re: [tcpinc] Simultaneous open tie breaking
Kyle Rose writes: >> If we are going to add another round of exchanges anyway, though, why >> not do the tie-breaking there? We could keep the single b bit as is >> (for applications that want to work it out), and then add a >> variable-length tie-breaking phase. E.g., >> >> A->B: SYN ENO >> B->A: SYN ENO >> A->B: ACK ENO >> B->A: ACK ENO > > Why not dump b entirely and just always require an extra round trip > for simultaneous open? It seems to be enough of an edge case that, > given the options, I'd rather not optimize for it (and also not spend > a disproportionate amount of time debating optimization of something > that is such a long-tail, and practically degenerate, use case). There is one reason this isn't ideal (though I think it might still be workable), and that is that the first ACK packet might need to contain spec-specific information (like cipher suite preferences). If that information is in options only, then it doesn't consume sequence number space and now you have the problem of potentially needing to retransmit two ACKs for the other side's ISN. > IMHO, all applications should be able to benefit from TCPINC's > protection against passive eavesdropping without any changes. That's a perfectly valid position, and we can make it work. It will cost some complexity, though, so it would be nice to get clarity on whether this is also the preference of the whole working group. I wouldn't want to jump through hoops to make simultaneous open always work, then run into objections that it's too complicated or consumes too much option space. Note that yet another possibility is to delegate the choice of roles to the individual encryption specs. In the case of ECDHE, that's actually easy to do. But now the complexity of a fringe use case is bleeding into multiple documents. David ___ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01
On Tue, Aug 25, 2015 at 7:06 AM, Stephen Kent wrote: > Watson, > > On 8/24/15 4:37 PM, Watson Ladd wrote: > > On Mon, Aug 24, 2015 at 1:08 PM, Stephen Kent wrote: > > Watson, > > based on many years of experience dealin wit this sort of issue > I suggest that the relative merits (strength, etc.) of cipher suites > form a lattice, not a total order. > > Every lattice has a compatible total order > > more properly, a total order can be imposed on a lattice. I don't see the difference between these two statements, and I don't see the relevance. > > , and preferences are > expressed as total orders. > > The issue here is that reasonable people can disagree about > the total order imposed on the lattice. > > Could you explain how your supposed insight > > "supposed insight" seems rather pejorative; better watch out for the > IETF mail list PC police Earlier people raised examples of ciphersuites with no comparison between them. Why does what you are saying matter more? What's the connection between being a lattice, and picking just one ranking not a good idea. > > into the reality of comparing ciphersuites justifies exposing all > possible ciphersuites, and permitting specifying arbitrary preferences > among them? > > The preferences of others are "arbitrary" but yours are not? Of course it's an arbitrary choice! My question is why is it not a good idea to pick a single nothing-else-is better suite. and have a mechanism designed to support migration if weaknesses are discovered? So far as I can tell the argument has been that people have different orderings, and should be allowed to express them. But this doesn't actually get to the fundamental issue: how much more secure are people if they will use X instead of Y if the other side wants it, then if they prefer Y instead of X? What happens in practice is that we end up with copypasta in config files. And then when we do need to have a migration, instead of the next version of the software automatically prefering the new thing, configurations need to be changed. Of course you can always wash your hands of this by saying software could have expressed the preferences differently. But if software is going to do that, then we might as well chop down on what the mechanism needs to express. There are real benefits from shrinking code and reducing the complexity of the versioning mechanism. Downthread David Menzies is saying we only need three ciphersuites, with one explicitly as a backup for the other. So what's gained from being able to reverse that ordering? I do think we can't actually specify a backup until the primary is weak: remember when RC4 was the solution for Bard's attack on TLS 1.0? Sincerely, Watson Ladd > > Steve > > ___ > Tcpinc mailing list > Tcpinc@ietf.org > https://www.ietf.org/mailman/listinfo/tcpinc -- "Man is born free, but everywhere he is in chains". --Rousseau. ___ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01
Stephen Farrell writes: >>> It is not at all clear to me that that'd be a good plan. I think >>> the gross-hack that it may one-day open up is unlikely to be worth >>> it, and negotiating once is bad enough so it'd seem like a bad >>> plan to do it twice, which I think would be the inevitable outcome. >> >> Sorry, I can't reconcile the first and last sentence of that paragraph. > > If a mechanism defined in the TCP-ENO document "supported" ckiphersuite > negotiation, but was not deployable (which seems like it'd be the case > given attempts to squeeze in 32 bytes of DH public) then you'd end up > having to support algorithm agility in-band anyway. Hence bad-plan + > doing it twice. I wish I hadn't conflated things. What's not deployable today is putting a DH key exchange into SYN segments. The downside (in terms of ruling out timestamp, MSS, etc.) is simply not realistic. Of course, that's the long-term dream, so I discussed it, but realistically it cannot happen without large options, so let's just forget I ever mentioned it. What is eminently deployable is using TCP-ENO to negotiate a ciphersuite. E.g., you can agree to use curve25519 for ECDHE by the end of the SYN exchange, and include a DH parameter in the first data segment of a connection, after only one round trip. As you say, we probably only need two or three ciphersuites in play at a time, a primary and one in case the primary starts looking weak, and maybe third to satisfy diversity of algorithm designers. So there's no reason ENO can't chose between these three. >> We are currently rewriting tcpcrypt to consume three ENO suboptions, one >> for P-256+AES-128, one for P-512+AES-256, and one for >> Curve25519+Chacha/Poly1305. Compared to the existing draft, this lets >> us ditch PKCONF and pretty much everything except the DH parameters in >> INIT1 and INIT2 messages. We are also ditching RSA (which at this point >> was there "just in case," because tcpcrypt had to be future compatible >> with things other than DH, but now ENO frees us from worrying about >> future compatibility). The result is a much simpler document. > > I'll just repeat that I think that's a bad plan and you'd be > better off not making such changes. If you can elaborate on this, we would certainly appreciate it. We certainly can leave a second level of negotiation in tcpcrypt--that would even be easier for us--but it will add pages to the RFC, so it would help to understand why. David ___ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
Re: [tcpinc] Simultaneous open tie breaking
> If we are going to add another round of exchanges anyway, though, why > not do the tie-breaking there? We could keep the single b bit as is > (for applications that want to work it out), and then add a > variable-length tie-breaking phase. E.g., > > A->B: SYN ENO > B->A: SYN ENO > A->B: ACK ENO > B->A: ACK ENO Why not dump b entirely and just always require an extra round trip for simultaneous open? It seems to be enough of an edge case that, given the options, I'd rather not optimize for it (and also not spend a disproportionate amount of time debating optimization of something that is such a long-tail, and practically degenerate, use case). > Before settling on something, I'd like to get a sense of whether people > think it's okay to ask applications to signal their intent to use > simultaneous open, or whether it's important for TCP-ENO to enable > encryption for existing, unmodified applications that use simultaneous > open. Those two options put us down different paths. IMHO, all applications should be able to benefit from TCPINC's protection against passive eavesdropping without any changes. Kyle ___ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
Re: [tcpinc] Simultaneous open tie breaking
Tero Kivinen writes: > I do not think the b bit is really going to work, and I agree with > others that we need proper tie-breaker to solve this issue. > > On the other hand I do not think we need to add large tie breaker to > the frame, we can most likely use something like very small tie > breaker and sequence numbers for tie-breaker. I.e. whoever has smaller > 8-bit (or 6-bit) tie breaker is winner, This is doable, though adds complexity to implementations. Should this tie-breaker be sent by every active opener (and therefore consume option space), or do you imagine that applications intending to use simultaneous open set an option to include the tie breaker? > if the tie breakers are same, then we compare initial sequence > numbers, and whoever has smaller initial sequence number is the > initiator and other end responder. I'm very uncomfortable using sequence numbers. In our initial tests for tcpcrypt we found sequence numbers got modulated. If I recall OpenBSD does this by default when operating as a NAT, and I'm not even sure there's a way to disable it. Same for timestamp. > After that we just need to have rules specifying how we pick up the > protocol from two ordered list. The most simple solution would be to > just say we take initiators list, remove all of the protocols not in > the responders list, and then take first item from initiators list > that is also supported by responder. ENO currently does the mirror of this, letting the responder's list determine priority. The logic was that passive openers tend to need to support higher numbers of connections per second, and so may need to steer choices towards options with better hardware acceleration, etc. Is your choice of the initiator's list just arbitrary, because you think we should just settle on one of the two lists and happened to say initiator? Or is there an argument to favor the initiator's list over the responder's? > I.e. the negotiation would be (with same tie breaker selected randomly > in both ends): > > A->B(0x9453f454) SYN: Tie breaker=33; I can speak Z, Y > B->A(0x434945e5) SYN: Tie breaker=33; I can speak X, Y, Z > > As tie breaker is same, we will check sequence numbers, and as B has > smaller he is the winner, and both ends know this. Following the rules > above, the protocol to be used is Y. > > There are of course some middleboxes who do mess up with sequence > numrbers. To detect this we want to tell the result of the exchange to > both ends: > > A->B(0x9453f455) ACK: We are using protocol Y > B->A(0x434945e6) ACK: We are using protocol Y, I am initiator This is going to add significant complexity to the protocol, including some cold code paths that are likely to be weakly tested in some OS distributions. If we are going to add another round of exchanges anyway, though, why not do the tie-breaking there? We could keep the single b bit as is (for applications that want to work it out), and then add a variable-length tie-breaking phase. E.g., A->B: SYN ENO B->A: SYN ENO A->B: ACK ENO B->A: ACK ENO Here B is chosen as virtual responder because it has a higher tie-breaker, and at this point the protocol proceeds as usual. Yet another possibility is hashing the options list and comparing. Before settling on something, I'd like to get a sense of whether people think it's okay to ask applications to signal their intent to use simultaneous open, or whether it's important for TCP-ENO to enable encryption for existing, unmodified applications that use simultaneous open. Those two options put us down different paths. > Also if application will know it will NEVER do simulatenous opens > (like web server, or web client), it can do setsockopt that will > disable the Tie breaker option from the option list, saving byte or > two. Obviously a passive opener never needs to include the tie-breaker. But this sounds like you want active openers to include a tie-breaker by default, but want to enable them to opt out of it to save option space. My personal feeling is that it's unfortunate to waste option space and add all this complexity to deal with such a fringe case. But it's not a strong feeling and I'm happy to modify ENO to suit the option of the working group. But... I might have an idea for how to make this work that isn't so bad. Let me try something based on sorting the option lists and adding a variable-length tie-breaker option. I think that might allow simultaneous open to work out of the box without adding too much complexity, and would allow people trade-offs in terms of option space consumed vs. failure probability. David ___ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01
> into the reality of comparing ciphersuites justifies exposing all > possible ciphersuites, and permitting specifying arbitrary preferences > among them? > > The preferences of others are "arbitrary" but yours are not? Touché. I don't hear a lot of opposition to maintaining agility in ciphersuite preference. I am personally in favor of keeping some mechanism (whether this one or a different one) in place for that purpose, because it provides much more flexibility than it requires complexity. Kyle ___ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01
Stephen, On 24/08/15 21:08, Stephen Kent wrote: Watson, based on many years of experience dealin wit this sort of issue I suggest that the relative merits (strength, etc.) of cipher suites form a lattice, not a total order. Folks - Steve is I think correct here but I'm quite confused as to why we're having this discussion about this draft. TLS (if we go there) has a way of negotiating ciphersuites. So does tcycrypt (or it will before we're done). Discussion of AES vs. ChaCha shouldn't be popping up to this level should it? agreed, yet it did, so ... Steve ___ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01
Watson, On 8/24/15 4:37 PM, Watson Ladd wrote: On Mon, Aug 24, 2015 at 1:08 PM, Stephen Kent wrote: Watson, based on many years of experience dealin wit this sort of issue I suggest that the relative merits (strength, etc.) of cipher suites form a lattice, not a total order. Every lattice has a compatible total order more properly, a total order can be _imposed_ on a lattice. , and preferences are expressed as total orders. The issue here is that reasonable people can disagree about the total order imposed on the lattice. Could you explain how your supposed insight "supposed insight" seems rather pejorative; better watch out for the IETF mail list PC police into the reality of comparing ciphersuites justifies exposing all possible ciphersuites, and permitting specifying arbitrary preferences among them? The preferences of others are "arbitrary" but yours are not? Steve ___ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
[tcpinc] Simultaneous open tie breaking
[I changed the subject to make the discussion easier to follow.] Watson Ladd writes: > On Sun, Aug 23, 2015 at 9:38 AM, David Mazieres > wrote: > > No, encryption fails 100% of the time, because the b bit defaults to 0. > > As currently written, TCP-ENO requires application involvement to enable > > encryption under simultaneous open. > > Ok, I got confused about what b was doing. I thought it was > disambiguating and picked randomly. I do not think the b bit is really going to work, and I agree with others that we need proper tie-breaker to solve this issue. On the other hand I do not think we need to add large tie breaker to the frame, we can most likely use something like very small tie breaker and sequence numbers for tie-breaker. I.e. whoever has smaller 8-bit (or 6-bit) tie breaker is winner, if the tie breakers are same, then we compare initial sequence numbers, and whoever has smaller initial sequence number is the initiator and other end responder. After that we just need to have rules specifying how we pick up the protocol from two ordered list. The most simple solution would be to just say we take initiators list, remove all of the protocols not in the responders list, and then take first item from initiators list that is also supported by responder. I.e. the negotiation would be (with same tie breaker selected randomly in both ends): A->B(0x9453f454) SYN: Tie breaker=33; I can speak Z, Y B->A(0x434945e5) SYN: Tie breaker=33; I can speak X, Y, Z As tie breaker is same, we will check sequence numbers, and as B has smaller he is the winner, and both ends know this. Following the rules above, the protocol to be used is Y. There are of course some middleboxes who do mess up with sequence numrbers. To detect this we want to tell the result of the exchange to both ends: A->B(0x9453f455) ACK: We are using protocol Y B->A(0x434945e6) ACK: We are using protocol Y, I am initiator If both ends claim to be initiator, or neither end claims to be initiator, both ends will know that immediately when they get receive ACK, and will know that someone messed up the sequence numbers (provided they didn't happen to be exactly same initially :-). In that case we need to do something more complicated, or we could simply say we drop the connection and try again. This is such rare happening, that wasting extra round trips is much more preferred to having more complicated protocol solving the tie (simultaneous opens are rare, both ends happening to select same 8-bit (or 6-bit or whatever) tie breaker is not very common, having exactly same initial sequence number is rare, or even if we have middle box messing up sequence numbers, there is 50% them being in right order anyways). On the next try both ends will pick new random tie breaker, and this time they most likely will not be same, and then the simulatenous open will succeed (or there might even be timing differences, causing one of them be bit faster, and one of the ends might receive SYN before it has time to send his SYN out, in which case this will not be simultaneous open anymore). Also if application will know it will NEVER do simulatenous opens (like web server, or web client), it can do setsockopt that will disable the Tie breaker option from the option list, saving byte or two. Normal open would be: A->B(0x9453f454) SYN: Tie breaker=33; I can speak Z, Y B->A(0x434945e5) SYN-ACK: We are using protocol Y A->B(0x9453f455) ACK: We are using protocol Y, I am initiator "We are using protocol Y" could also include the initial key exchange messages for protocol Y, if they fit in option space. -- kivi...@iki.fi ___ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01
Hiya, On 24/08/15 23:48, David Mazieres wrote: > Stephen Farrell writes: > >>> The issue relates to ciphers because TCP-ENO can be used to negotiate >>> cipher suites. >> >> It is not at all clear to me that that'd be a good plan. I think >> the gross-hack that it may one-day open up is unlikely to be worth >> it, and negotiating once is bad enough so it'd seem like a bad >> plan to do it twice, which I think would be the inevitable outcome. > > Sorry, I can't reconcile the first and last sentence of that paragraph. If a mechanism defined in the TCP-ENO document "supported" ckiphersuite negotiation, but was not deployable (which seems like it'd be the case given attempts to squeeze in 32 bytes of DH public) then you'd end up having to support algorithm agility in-band anyway. Hence bad-plan + doing it twice. > If negotiated TCP-ENO spec implies a specific cipher suite, then you > only negotiate once. If TCP-ENO specs have multiple cipher suites, then > you have two negotiations, first the ENO-level meta-negotiation on how > to negotiate, then a second cipher suite within the particular > encryption spec. > > Your first sentence reads like a recommendation *not* to tie a single > cipher suite to a single TCP-ENO suboption, in which case you'd need a > separate cipher suite negotiation mechanism. Your second sentence > implies you consider two rounds of negotiation a bad idea, in which case > why wouldn't you want ENO to negotiate the cipher suite. We value your > opinion on this question, so please clarify! > >> But so long as tcpcrypt is not a WG document that's your call I guess. > > We are currently rewriting tcpcrypt to consume three ENO suboptions, one > for P-256+AES-128, one for P-512+AES-256, and one for > Curve25519+Chacha/Poly1305. Compared to the existing draft, this lets > us ditch PKCONF and pretty much everything except the DH parameters in > INIT1 and INIT2 messages. We are also ditching RSA (which at this point > was there "just in case," because tcpcrypt had to be future compatible > with things other than DH, but now ENO frees us from worrying about > future compatibility). The result is a much simpler document. I'll just repeat that I think that's a bad plan and you'd be better off not making such changes. S. > > But this is all easy to change until we've updated the code to match the > forthcoming document, so high-level feedback now would be appreciated. > >> My take fwiw would be that a TCP option should really only signal >> turning on TCPINC full stop. And that TCPINC initially ought only >> have two ciphersuites defined, one for use now and a backup. But >> TPCINC will have to support some form of algorithm agility so that >> that pair of ciphersuites can be changed over time. So yes some >> form of agility is needed but it's not clear to me that a TLS-like >> scheme is best. > > Given that latency is critical, at a minimum we have to start the > public-key cipher negotiation in the SYN-ACK of a three-way handshake. > So why not have the TCP-ENO suboption just specify the ciphersuite? > >> If/when practical deployment of DH values becomes feasible then >> it'd be time to discuss how to use that. But not now when that is >> not, if I understand correctly, possible to do that. > > Well, it is possible today. What's not not possible is to do that and > enable TCP timestamp for the same connection. > > David > > ___ > Tcpinc mailing list > Tcpinc@ietf.org > https://www.ietf.org/mailman/listinfo/tcpinc > > ___ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01
> In fact, it's possible to fit a 32-byte ECDH parameter into a SYN-ACK segment > today. That means even without large SYN options, we can imagine making > TCPINC zero latency. Realistically, doing so will > require a gross hack in > which TCP-ENO compactly encodes timestamp and SACK availability, window > scaling, etc., in lieu of larger options. I don't expect people would be > very happy with something like > that from day one. But we don't want to > shut the door to such an optimization either, in case TCPINC becomes a > runaway success. (We've been careful to leave a bunch of reserved suboptions > in the TCP-> ENO spec just in case we need extra bits for such optimizations.) I've not followed this thread. But this discussion about long options in SYN, modifying existing TCP options, etc. really scares me. I've always thought TCPINC's objective is to provide *payload* encryption, and negotiating this should IMHO not require any complex option. I am also confused about the actual technical details in this discussion. In my understanding, the SYN-ACK for any modern high-speed TCP stack has to carry MSS (4 bytes), windows scale (3 bytes), and SACK permitted (2 bytes). This means that at most 31 bytes are left (in theory, we have plenty of other TCP extensions consuming parts of it). Also, I believe some middleboxes/firewalls may act upon those options in the SYN-ACK, i.e., they cannot easily be replaced or encoded in a more compact way. As a result, I somehow don't understand how to get a 32 byte value into SYN-ACK without EDO (draft-ietf-tcpm-tcp-edo). And for EDO there are deployment challenges with using it in the SYN-ACK, see the discussion in TCPM. In any case, this sort of discussion on SYN option space IMHO should be taken to the TCPM list. Michael ___ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
