tcpinc is probably another candiate to discuss this ID.
On 18 August 2014 15:49, Christian Grothoff <[email protected]> wrote: > On 08/18/2014 03:15 PM, Stephane Bortzmeyer wrote: >> [The I-D does not indicate, apparently, a mailing list for discussion >> of the idea. Trying on perpass. Suggestions of a better venue are >> welcome.] >> >> On Thu, Aug 14, 2014 at 11:41:06PM -0700, >> [email protected] <[email protected]> wrote >> a message of 49 lines which said: >> >>> Title : TCP Stealth >>> Authors : Julian Kirsch >>> Christian Grothoff >>> Jacob Appelbaum >>> Holger Kenn >>> Filename : draft-kirsch-ietf-tcp-stealth-00.txt >> >> IMHO, very good idea for an important problem. I would like this >> work to move forward (an independant RFC with status Experimental, may >> be?) >> >> A few suggestions/remarks: >> >> * May be a remark about the fact that it is intended for small groups >> (the use of a shared secret limits the scalability). > > That is of course correct. > >> * "If the token is incorrect, the operating system pretends that the >> port is closed." If the port is closed, the server will reply with a >> RST. Not very stealth. You meant "If the token is incorrect, the >> operating system won't reply at all"? > > We intend the OS to react in the same way as it does for all other ports > where no service is listening. If the OS policy is to send a RST, it > should also send a RST if the authentication fails If the OS policy is > to drop, it should also drop if the authentication fails. Stealth here > is about being as indistinguishable as possible from an "ordinary" > closed port. > >> * May be a security analysis comparing it to port knocking? > > Eh, this is a port knocking scheme. > >> If I'm >> correct, TCP stealth provides min(32, N) bits of secret (32 being the >> size of the ISN and N the number of bits in the shared secret) while >> port knocking provides 16*N bits (N being the number of ports to >> knock). > > That depends on the type of port knocking scheme deployed. You could in > theory implement a knock with a 512 byte UDP packet and have a huge > shared secret. Naturally, if you talk about a knock where just the > destination port is derived from the knock secret, then your analysis is > correct. But again, there are many ways to implement knocking in general. > >> * May be a mention of SPA <http://www.cipherdyne.org/fwknop/>, which >> is closer from TCP Stealth than port-knocking? (The biggest difference >> is that SPA is not stealth, Eve knows you're using SPA.) > > There are other differences; for a more detailed analysis I would > suggest you use Julian's Master's thesis, not the RFC. The MS thesis is > freely available at https://gnunet.org/kirsch2014knock > >> * Why MD5? I assume that TCP Stealth has no cryptographic agility >> since there is no room to indicate the crypto algorithm (while staying >> stealth) but why MD5, despite RFC 6151? > > As (I hope) the thesis explains, MD5 is used for ISN calculations > already, from ISN to SYN flooding protections. And once reduced to 32 > bits, there is no real security advantage of other hash functions, but > there is a speed (and maybe indistinguishability advantage) for MD5. > >> * "6. Integraton with Applications" should be Integration > > Ack. Fixed in Git, thanks! > > -Christian > > > _______________________________________________ > perpass mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/perpass > _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
