[anonsec] my comments on the documents

Hi,

Can I get a copy of the doc or at least the link?
It looks interesting to me.

Thanks
Dan

----- Original Message -----
From: "Michael Richardson" <mcr at sandelman.ottawa.on.ca>
To: <anonsec at postel.org>
Sent: Monday, November 07, 2005 1:57 AM
Subject: [anonsec] my comments on the documents

_______________________________________________
_____________________________________________________
This mail has been virus scanned by Australia On Line
see http://www.australiaonline.net.au/mailscanning

Joe Touch

2005-11-06 22:05:39 UTC

See:
http://www.postel.org/rbridge

Post by Dan Bernardo
Hi,
Can I get a copy of the doc or at least the link?
It looks interesting to me.
Thanks
Dan
----- Original Message -----
From: "Michael Richardson" <mcr at sandelman.ottawa.on.ca>
To: <anonsec at postel.org>
Sent: Monday, November 07, 2005 1:57 AM
Subject: [anonsec] my comments on the documents

_______________________________________________

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

Michael Richardson

2005-11-06 21:43:19 UTC

Joe Touch

2005-11-06 22:15:37 UTC

Michael> Please change section 4.2: Opportunistic Encryption (OE) is a
Michael> system for automatic discovery of hosts willing to do a
Michael> BTNS-like encryption, with authentication being exchanged by
Michael> leveraging through existing use of the DNS.
Please change section 4.2: Opportunistic Encryption (OE) is a
system for automatic discovery of hosts willing to do a BTNS-like encryption,
with authentication being exchanged by leveraging existing use of the DNS

Sure, but the changes need to be a little more careful. In particular,
most of BTNS focuses on what your own side does. Finding another side
that is willing to do BTNS matters only if your own cert is not signed
by a well-known CA; it has nothing to do with your decision to proceed
with the cert of the other side without checking its CA.

How does this 'automatic discovery' work, and how is it a variant of OE?
(can you explain?)

Finally, there's no need to use the DNS to exchange authentication in
BTNS; that just inserts an extra intermediary to attack, and possibly a
worse delay.

Joe

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

Joe Touch

2005-11-07 07:21:40 UTC

Joe> Sure, but the changes need to be a little more careful. In
Joe> particular, most of BTNS focuses on what your own side
Joe> does. Finding another side that is willing to do BTNS matters
Joe> only if your own cert is not signed by a well-known CA; it has
Joe> nothing to do with your decision to proceed with the cert of
Joe> the other side without checking its CA.
Yes, I agree.
The section in question is relating to other work. I'm sending text,
because you have mis-stated what OE does.

The original text:
Opportunistic Encryption (OE) is a system for automating authentication
infrastructure by leveraging the existing use of the DNS

Your proposed text:
Opportunistic Encryption (OE) is a system for automatic discovery of
hosts willing to do a BTNS-like encryption, with authentication being
exchanged by leveraging existing use of the DNS

Agreed as to the text change.

The point is that BTNS doesn't do discovery, nor does it matter,
because of what you just said.
Joe> How does this 'automatic discovery' work, and how is it a
Joe> variant of OE? (can you explain?)
System about to send packet looks in reverse DNS for a specific kind
of RR (TXT RR in the current draft, to be changed to IPSECKEY soon in a
future revision of the specification).
If the key exists, it initiates. If the key doesn't exist, it fails,
and may fall-back to something else (pass or block).

Why would we want to depend on a predeployed infrastructure to detect
whether the other end was willing to do something? Wouldn't the success
of an IKE exchange with an un-CA'd certificate be proof, and wouldn't
that be more direct (and less dependent on infrastructure)?

This is described in draft-richardson-ipsec-opportunistic-17.txt
http://www.sandelman.ottawa.on.ca/SSW/freeswan/oeid/draft-richardson-ipsec-opportunistic.html
sections 2.3, 3.1, 3.2, 4.2, 4.4, 5.2, 10.1.
Joe> Finally, there's no need to use the DNS to exchange
Joe> authentication in BTNS; that just inserts an extra intermediary
Joe> to attack, and possibly a worse delay.
Nor was it suggested.

Yes, but even checking to see whether it exists introduces a delay,
doesn't it?

Joe

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

Michael Richardson

2005-11-08 02:58:55 UTC

Joe Touch

2005-11-08 05:22:18 UTC

System about to send packet looks in reverse DNS for a specific kind
of RR (TXT RR in the current draft, to be changed to IPSECKEY soon in
a future revision of the specification). If the key exists, it
initiates. If the key doesn't exist, it fails, and may fall-back to
something else (pass or block).

Joe> Why would we want to depend on a predeployed infrastructure to
Joe> detect whether the other end was willing to do something? Wouldn't
Joe> the success of an IKE exchange with an un-CA'd certificate be proof,
Joe> and wouldn't that be more direct (and less dependent on
Joe> infrastructure)?
Okay, so consider the case where the IKE exchange is not successful.
- how can you tell that it failed? (it could take a long time)
- how can you tell that you aren't in a bid-down attack?
Joe> Yes, but even checking to see whether it exists introduces a delay,
Joe> doesn't it?
Yes, it does. But, a gratuitous DH, plus 3 IKE Main Mode messages is a
longer delay, assuming that it works.

The primary difference is whether to start by contacting an
infrastructure or to start with IKE and go to the infrastructure only if
required.

The gratuitous DH + IKE is a lot faster than a DNS timeout when no DNS
is available (DNS timeouts are in the tens of seconds).

Joe

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

Paul Wouters

2005-11-08 17:07:09 UTC

Post by Joe Touch
The primary difference is whether to start by contacting an
infrastructure or to start with IKE and go to the infrastructure only if
required.

Start with infrastructure might give you trusted third party data, protecting
against all local active attacks.

Post by Joe Touch
The gratuitous DH + IKE is a lot faster than a DNS timeout when no DNS
is available (DNS timeouts are in the tens of seconds).

If you have no DNS you will have those delays in browsing and emailing too.
However, normally, you would get a NXDOMAIN, which only takes about 1 second.

Paul

--
"Happiness is never grand"

--- Mustapha Mond, World Controller (Brave New World)

Joe Touch

2005-11-08 18:07:58 UTC

Post by Joe Touch
The primary difference is whether to start by contacting an
infrastructure or to start with IKE and go to the infrastructure only if
required.

Start with infrastructure might give you trusted third party data, protecting
against all local active attacks.

Agreed. That is not the focus of this draft, however.

Post by Joe Touch
The gratuitous DH + IKE is a lot faster than a DNS timeout when no DNS
is available (DNS timeouts are in the tens of seconds).

If you have no DNS you will have those delays in browsing and emailing too.
However, normally, you would get a NXDOMAIN, which only takes about 1 second.

I won't have a delay if I don't use DNS names.

NXDOMAIN is a DNS reply; I don't get that if there is _no_ DNS.

Joe

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

Joe Touch

2005-11-09 17:43:27 UTC

Joe> Yes, but even checking to see whether it exists introduces a
Joe> delay, doesn't it?

Yes, it does. But, a gratuitous DH, plus 3 IKE Main Mode messages
is a longer delay, assuming that it works.

Joe> The primary difference is whether to start by contacting an
Joe> infrastructure or to start with IKE and go to the
Joe> infrastructure only if required.
Joe> The gratuitous DH + IKE is a lot faster than a DNS timeout when
Joe> no DNS is available (DNS timeouts are in the tens of seconds).
Yes, DNS timeouts can be a serious problem, but we know who to ask,
and we have some expectation of an NXdomain (or NSEC) to tell us that
there is no record.

You're still assuming there's a DNS to ask. What if there is NONE?

Alternately (different case), what if there IS a record but it's not
available? NXdomain won't - and shouldn't - be generated by the
delegating server.

But, what are the right IKE timeouts? What if there is an attacker?
How do you know if the recipient is not interested?

IKE timeouts are always local to the two parties; DNS timeouts are
harder to preempt on a per-connection basis (they can be buried in the
net, and only the origin resolver can control the timeout).

ICMP port unreachable's may get filtered out. (They could also get forged!)
How do you think random firewall admin is going to respond when they
start getting unsolicited messages to port 500?
So, the problem with trying IKE is that it may in fact take far longer
than "tens of seconds" to establish that the peer is not
interested.
Next, you need to build a cache as well, since you don't want to
repeat this for each web page. What is the TTL of the cache?
DNS already does all of that for us.

DNS is infrastructure. What happens when it's _not_ there?

Joe

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

Paul Wouters

2005-11-09 20:40:35 UTC

Yes, DNS timeouts can be a serious problem, but we know who to ask,
and we have some expectation of an NXdomain (or NSEC) to tell us that
there is no record.

You're still assuming there's a DNS to ask. What if there is NONE?

If there is none configured (eg through resolv.conf), then failure is instantly.
If there are nameservers configured in resolv.conf (or on windows in the
registry) that are not there, then the machine has a much more generic problem,
and adding any kind of encryption is not going to help it. It won't be able to
do anything that requires dns, and anything it attemps to do that requires dns,
such as ftp or http, will fail in the same bad time range of your supposed 10
seconds.

Post by Joe Touch
Alternately (different case), what if there IS a record but it's not
available?

I do not understand this case. The record IS available (in DNS?) but it is not
available? I guess if it is broken it will return a ServFail. If the local
resolver is working, but the remote DNS that is authorative is not, then yes
there will be a delay, and again it is the fault of the administrator of the
machine you are trying to connect to and should be fixed. If you would be
trying to connect to that machine (by dns name?) and that is what triggered
BTNS, then you've already spend 10 seconds waiting (and I guess failed to
resolve it)

Post by Joe Touch
NXdomain won't - and shouldn't - be generated by the delegating server.

Correct, a quick ServFail should be generated.

But, what are the right IKE timeouts? What if there is an attacker?
How do you know if the recipient is not interested?

IKE timeouts are always local to the two parties; DNS timeouts are
harder to preempt on a per-connection basis (they can be buried in the
net, and only the origin resolver can control the timeout).

A machine running a Windows Firewall and dropping IKE would also cause you
to wait a number of seconds before you give up on BTNS IKE.

Post by Joe Touch
DNS is infrastructure. What happens when it's _not_ there?

ServFails. And they get cacahed too if your resolver is still working. If
your resolver is not working, you're spending most of your time drinking
coffee anyway.

Paul

Joe Touch

2005-11-09 21:43:19 UTC

Yes, DNS timeouts can be a serious problem, but we know who to ask,
and we have some expectation of an NXdomain (or NSEC) to tell us that
there is no record.

You're still assuming there's a DNS to ask. What if there is NONE?

FWIW - that's the case I was thinking of.

Post by Paul Wouters
and adding any kind of encryption is not going to help it It won't be able to
do anything that requires dns, and anything it attemps to do that requires dns,
such as ftp or http, will fail in the same bad time range of your supposed 10
seconds.

Post by Joe Touch
Alternately (different case), what if there IS a record but it's not
available?

I do not understand this case. The record IS available (in DNS?) but it is not
available?

The parent knows a delegation exists, but the child is unavailable. Just
trying to cover bases.

Post by Paul Wouters
I guess if it is broken it will return a ServFail. If the local
resolver is working, but the remote DNS that is authorative is not, then yes
there will be a delay, and again it is the fault of the administrator of the
machine you are trying to connect to and should be fixed.

Agreed; just pointing out the delays there.

Post by Paul Wouters
If you would be
trying to connect to that machine (by dns name?) and that is what triggered
BTNS, then you've already spend 10 seconds waiting (and I guess failed to
resolve it)

Yes; you might not use DNS to get to a BTNS peer, though - that's the
case I'm considering where OE would induce delays.

Post by Joe Touch
NXdomain won't - and shouldn't - be generated by the delegating server.

Correct, a quick ServFail should be generated.

But, what are the right IKE timeouts? What if there is an attacker?
How do you know if the recipient is not interested?

IKE timeouts are always local to the two parties; DNS timeouts are
harder to preempt on a per-connection basis (they can be buried in the
net, and only the origin resolver can control the timeout).

A machine running a Windows Firewall and dropping IKE would also cause you
to wait a number of seconds before you give up on BTNS IKE.

Yes - but if you give up on BTNS IKE, you've done all you can in the
most direct way.

Post by Joe Touch
DNS is infrastructure. What happens when it's _not_ there?

ServFails. And they get cacahed too if your resolver is still working. If
your resolver is not working, you're spending most of your time drinking
coffee anyway.

Only if you use names ;-)

Joe

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

Nicolas Williams

2005-11-10 16:46:29 UTC

Yes, DNS timeouts can be a serious problem, but we know who to ask,
and we have some expectation of an NXdomain (or NSEC) to tell us that
there is no record.

You're still assuming there's a DNS to ask. What if there is NONE?

But other nameservers could be down too :(

Nicolas Williams

2005-11-08 18:30:18 UTC