Re: [Hipsec] Spencer Dawkins' No Objection on draft-ietf-hip-native-nat-traversal-28: (with COMMENT)
On Wed, Feb 26, 2020 at 12:20:16PM -0600, Spencer Dawkins at IETF wrote: > > I see that Adam has asked the question about why XOR is not required, which > is close enough to my question that I should DEFINITELY continue to defer > to the current ADs! I believe that was already answered somewhere in the thread of messages. XOR is not used as it is superfluous, since the messages in question are encrypted. Hence middleboxes still can't see the addresses. DF ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal
On Mon, Mar 07, 2016 at 02:35:07pm +0200, Gonzalo Camarillo wrote: > First he will look into adding clarifications to the existing draft > while still referencing the old RFC. If the group is not happy with the > readability after the editorial pass (or our AD does not finally let us > downref the old RFC), we can consider bringing material from the old RFC > directly into the new one. Sorry, that I'm quite late in looking at these, but have been doing so recently... I have to say that I find the it difficult to decode simply because of having to refer to 3 (the draft, 5770, 5245) plus possibly the STUN/TURN docs at once. I'd certainly find it easier to comprehend if the text from 5770 was incorporated (suitably modified to account for not doing STUN/TURN) within the draft. That way the references to the significant pieces of 5245 text would be easier to nail down. As it is, I currently find it a bit like reading an Act of Parliament! e.g. $3.8 Connectivity Checks refers to $4.6 of 5770 with some exceptions, $4.6 of 5770 refers to $5.7 of 5245 and $7 of 5245, where the exceptions (use of UPDATE instead of STUN) have to be applied to that $7 referencing 5389, so possibly I don't have to read 5389, since hopefully it would just be packet formats. > I would also like the group to comment on the following two proposals: > > 1) the draft will allow implementers to use HIP native relays only. In > addition, the use of STUN and TURN relays will be optional. I'd suggest the draft be native only, but say with an appendix referencing 5770 for use of STUN/TURN, maybe indicating which bits of the 5770 to take heed of. > 2) in addition to covering the base exchange, the draft will also cover > the mobility readdressing exchange. Not having read that recently, I can't really comment. DF ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
Re: [Hipsec] IPCOMP support in HIP
On Thu, Mar 10, 2016 at 02:18:51pm -0500, Robert Moskowitz wrote: > Fair point. I really cannot convert TLS specifications to packet > content. I suspect there are things exposed? [snip] > I do suspect that TLS is different in how it does compression, and if it > is being abandoned, so sad. quite possibly. > But can you point me to a paper on the TLS compression attack? I'm afraid not, I just recall reading up on some of the TLS attacks when they were publicised, and seeing that some of them were related to compression. A bit of poking around though yielded: http://www.iacr.org/cryptodb/archive/2002/FSE/3091/3091.pdf I also spotted this, but it doesn't add much: https://www.cosic.esat.kuleuven.be/ecrypt/provpriv2012/abstracts/barghavan.pdf I did avail myself of google before my prior email, it suggested CRIME and BREACH. Where the latter seems to be HTTP specific, and a chosen plain text attack. So all I'm suggesting is to be careful, and do appropriate comparisions, to see if one can ensure enabling compression does not enable an attack mode similar to those seen with TLS. Since I'm not sure if the lack of attacks against ESP+IPCOMP is due to inherent robustness, or simply a lack of trying. DF ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
