Subject: [anonsec] Contributing to BTNS

From: rajiv_das at msn.com (rajiv Das)
Date: Fri, 5 Aug 2005 09:48:50 +0530

Hi,
I read your slides and will read the draft over the weekend. I am interested
to know more about the problem you people are investigating, and possibly
would like to contribute in whatever way possible. Let me know how to go
about it.

Thanks,
Rajiv Das
http://thothzone.blogspot.com 

-----Original Message-----
From: anonsec-bounces at postel.org [mailto:anonsec-bounces at postel.org] On
Behalf Of anonsec-request at postel.org
Sent: Friday, August 05, 2005 12:30 AM
To: anonsec at postel.org
Subject: ANONSEC Digest, Vol 12, Issue 1

Send ANONSEC mailing list submissions to
	anonsec at postel.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://www.postel.org/mailman/listinfo/anonsec
or, via email, send a message with subject or body 'help' to
	anonsec-request at postel.org

You can reach the person managing the list at
	anonsec-owner at postel.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of ANONSEC digest..."

---

From: lha at kth.se (Love Hörnquist Åstrand)
Date: Sun, 07 Aug 2005 23:48:53 +0200

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 477 bytes
Desc: not available
Url : http://www.postel.org/pipermail/anonsec/attachments/20050807/885d4a49/attachment.bin

---

From: paul at xelerance.com (Paul Wouters)
Date: Mon, 8 Aug 2005 12:27:21 +0200 (CEST)

On Sun, 7 Aug 2005, Love H?rnquist ?strand wrote:

> A good starting point for what the group is going to do it the charter for
> the group [1] and the Problem and Applicability Statement draft. The draft
> needs some more revision and Joe Touch have recived some comments and have
> ideas on how to improve the document.
>
> I'm sure Joe will appreciate any comments you have on the draft.

I personally find the draft focuses far too much on TCP-RST issues. Really,
if that is the main reason for BTNS, then a completely different solution to
that specific problem should be designed. The current BTNS is rather overkill
to fix the TCP-RST problem.

Ofcourse, the real use of BTNS is to provide a better then nothing privacy
between two parties, but it seems that people are too afraid to mention this
political goal, and use the RST issue as a technical excuse for the unmentioned
political goal.

I have not read the draft carefully enough to give more specific technical
comments, but I do find anonymous IPsec connections with only inbound public
key exchange without any kind of third party verification too dangerous to
give to people and tell them it adds security. I know it adds prootection
against passive attacks, but I think it is far too easy to play man in the
middle if there is only inbound (ISAKMP/IKE) information exchange happening.

I'm also worried that transferring inbound X.509 certificates will hit many
UDP fragmentation issues as we see now in IKE v1.

Ofcourse I am somewhat biased to FreeS/WANs and Openswan's Opportunistic
Encryption draft that uses DNS (and preferably DNSSEC) as a trusted third
party.

Furthermore, one could think of a Rendezvous extension where two parties
meeting over Bluetooth (or any other non-internet connected connection) could
send DNSSEC signed keys from their machine upwards the hierarchy until it
meets a domain of which the other party has a signed trusted key as well.
I hope BTNS and/or IKE v2 would allow such an exchange.

Paul
Paul

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 09 Aug 2005 13:20:21 -0700

> to fix the TCP-RST problem.

That is historical, i.e., providing an example case that happened to
also be the motivator in reality. It's intended as an example, not the
only example. I had thought the doc gave that sense; can others speak up
if that isn't the case?

> middle if there is only inbound (ISAKMP/IKE) information exchange

In a sense. BTNS doesn't care about man-in-the-middle (MITM). MITM
substitutes one party for another, and BTNS doesn't care which party
it's talking with.

> Encryption draft that uses DNS (and preferably DNSSEC) as a trusted third

Yes - but that just replaces one infrastructure (CAs) with another
(DNS). It doesn't solve the problem of how to secure communications with
a party that hasn't already got (or doesn't want to get) a third-party
to authenticate who it is.

> I hope BTNS and/or IKE v2 would allow such an exchange.

Perhaps, but that seems like yet another key distribution
infrastructure alnternative, rather than one that avoids the need for
such keys in the first place.

Joe

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Sat, 13 Aug 2005 18:52:45 -0400

>>>>> "Paul" == Paul Wouters <paul at xelerance.com> writes:

    Paul> Ofcourse, the real use of BTNS is to provide a better then
    Paul> nothing privacy between two parties, but it seems that
    Paul> people are too afraid to mention this political goal, and
    Paul> use the RST issue as a technical excuse for the unmentioned
    Paul> political goal.

There were three camps that wanted BTNS in the BOF.  I think the
document actually represents all three mindsets.

    Paul> specific technical comments, but I do find anonymous IPsec
    Paul> connections with only inbound public key exchange without
    Paul> any kind of third party verification too dangerous to give
    Paul> to people and tell them it adds security. I know it adds
    Paul> prootection against passive attacks, but I think it is far
    Paul> too easy to play man in the middle if there is only inbound
    Paul> (ISAKMP/IKE) information exchange happening.

so, that would have been a valuable comment to make before the BTNS
working group was charetered.  However I don't think that there is any
way of meeting the goals of the charter without providing IPsec SAs
that are vulnerable to man-in-the-middle attacks.

If you don't want to work on the problems described in the charter
then this is not the working group for you.  If you do, then we'd be
happy to have your input.

---

From: jari.arkko at piuha.net (Jari Arkko)
Date: Sun, 14 Aug 2005 10:30:27 +0300

Sam Hartman wrote:

>However I don't think that there is any
>that are vulnerable to man-in-the-middle attacks
>  
>
Agreed.

--Jari

---

From: kivinen at iki.fi (Tero Kivinen)
Date: Sun, 14 Aug 2005 16:02:00 +0300

> to fix the TCP-RST problem.

BTW, one idea I had earlier is that if we are really concerned about
TCP-RST issues, and we do not have enough CPU power to
encrypt/authenticate all traffic, we would need new traffic selectors
for the IPsec that would allow us to encrypt/authenticate only TCP
control traffic packets (i.e. packets having SYN, FIN, RST etc bits
on).

That could also be used on the protocols having internal
authentication inside, but which cannot protect against TCP-RSTs (ssl,
ssh).

This would be tradeoff between security and CPU power needed (yes,
there would be still lots of different attack which can be used to
break connections, but this could protect against SYN-flooding, blind
TCP-RSTs etc).
-- 
kivinen at safenet-inc.com

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 23 Aug 2005 08:48:38 -0700

> control traffic packets (i.e. packets having SYN, FIN, RST etc bits

That is one of many possible solutions, including using multiple levels
of algorithms with varying computational loads. It would be useful to
take this discussion over to the triage at postel.org mailing list
(www.postel.org/triage), since it is orthogonal to the solutions being
developed here (IMO).

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20050823/1c485f9b/signature.bin