On 8/19/14, Hagen Paul Pfeifer <[email protected]> wrote: > On 19 August 2014 19:15, Jacob Appelbaum <[email protected]> wrote: > >> No. I want to protect my TLS service from implementation exploitation. >> You cannot probe my TLS service for the next heartbleed without a >> shared secret. > > C'mon Jacob, this smells fishy! Let's assume you protect *your* > service from one potential TLS bugs, this is (partly) possible with > the mechanism described in the ID. But what happens in the meantime > with your https:// browsing, openvpn, ... communications? If you > assume bugs in TLS you must stop all your communications! TLS and > strong cryptography is the fundamental building block - when it is > broken the whole communication system is b0rken.
No, it isn't. It isn't a zero sum game. We are trying to protect against people port scanning - that an authorized user may abuse a service is another issue - we do not protect against it, except that you may revoke that user's ability to exploit the service, of course. > > The other way, if you trust TLS you can also trust the TLS client > certificates mechanism as well. This is false. I use heartbleed as the example. > > I understand your objection but the "fix" feels wrong. We should do > everything we can to make TLS fast, clean and strong. But to repeat > myself: I see advantages and benefits and _if_ there are no major > disadvantages we can push things forward. Well, no need to answer > here, I got your point in detail and I want to make sure we discuss > all possibilities, using TLS client certificates is one alternative. > We should do both. It would be nice if TCP helped us with this realistic issue - services are exploitable, let us mitigate the problem with authentication for specific services at a different layer. We can authenticate the use of a service in a forward compatible manner and that is what the draft seeks to standardize. >> It isn't abuse - we're even trying to make it a standard to ensure >> that it is well documented non-abusive behavior - rather different >> than most other port knocking, I'd add. > > The ISN has 32 bits, reduce this space leads to problems in the past. > We must do everything to not open any other attack vectors regarding > TCP by mistake. If you *prove* that this will not lead to problems, I > will never ever mention the word "abuse" in an email to you! ;-) The ISN is still 32bits. We do not reduce the space and the entropy of the space does not change. There are corner cases where a passive observer may replay a packet as if it was normal TCP. Thus in the worst case, we're as bad as TCP is in every case, all the time. All the best, Jacob _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
