Subject: [anonsec] my comments on the documents

From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Sun, 06 Nov 2005 06:57:56 -0800

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 306 bytes
Desc: not available
Url : http://www.postel.org/pipermail/anonsec/attachments/20051106/3d1f556b/attachment.bin

---

From: dbernard at ozonline.com.au (Dan Bernardo)
Date: Mon, 7 Nov 2005 07:50:44 +1100

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
>

---

From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Sun, 06 Nov 2005 13:43:19 -0800

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

---

From: touch at ISI.EDU (Joe Touch)
Date: Sun, 06 Nov 2005 14:15:37 -0800

Michael Richardson wrote:
>>>>>> "Michael" == Michael Richardson <mcr at sandelman.ottawa.on.ca> writes:
>     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

---

From: touch at ISI.EDU (Joe Touch)
Date: Sun, 06 Nov 2005 14:05:39 -0800

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

-------------- 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

---

From: touch at ISI.EDU (Joe Touch)
Date: Sun, 06 Nov 2005 23:21:40 -0800

Michael Richardson wrote:
> 
>>>>>>> "Joe" == Joe Touch <touch at ISI.EDU> writes:
>     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

---

From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Mon, 07 Nov 2005 18:58:55 -0800

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 306 bytes
Desc: not available
Url : http://www.postel.org/pipermail/anonsec/attachments/20051107/759f30cd/attachment.bin

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 07 Nov 2005 21:22:18 -0800

Michael Richardson wrote:
>     >> 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

---

From: paul at xelerance.com (Paul Wouters)
Date: Tue, 8 Nov 2005 18:07:09 +0100 (CET)

> infrastructure or to start with IKE and go to the infrastructure only if

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

> 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)

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 08 Nov 2005 10:07:58 -0800

> against all local active attacks.

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

> 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

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 8 Nov 2005 12:30:18 -0600

> with the cert of the other side without checking its CA.

Er, even if you have a good cert your BTNS-capable peers may not or your
cert may not be good enough to them -- you might still be happy to do
BTNS.

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 09 Nov 2005 09:43:27 -0800

Michael Richardson wrote:
>     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

---

From: paul at xelerance.com (Paul Wouters)
Date: Wed, 9 Nov 2005 21:40:35 +0100 (CET)

> 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.

> 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)

> NXdomain won't - and shouldn't - be generated by the delegating server.

Correct, a quick ServFail should be generated.

> 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.

> 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

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 09 Nov 2005 13:43:19 -0800

> registry) that are not there, then the machine has a much more generic problem,

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

> and adding any kind of encryption is not going to help it It won't be able to

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

> I guess if it is broken it will return a ServFail. If the local
> machine you are trying to connect to and should be fixed.

Agreed; just pointing out the delays there.

> If you would be

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.

> 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.

> your resolver is not working, you're spending most of your time drinking

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

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 10 Nov 2005 10:46:29 -0600

> such as ftp or http, will fail in the same bad time range of your supposed 10

But other nameservers could be down too  :(