Subject: Re: Install DNS mappings based on TLS/IPsec?

From: Joe Touch <[email-masked]>
Date: Mon, 02 Aug 2004 06:45:53 -0700

Iljitsch van Beijnum wrote:

> On 4-jul-04, at 10:43, Brian E Carpenter wrote:
> 
>> Are you suggesting that the multi6 solution should have a strict
>> dependency on using TLS or IPSEC?
> 
> 
> Certainly not. I'm saying two things:
> 
> - if the DNS doesn't work, discover information that would normally be 
> in the DNS through the TLS or IKE negotiation, and

Sorry for the late addition to the thread, but the use of the DNS for 
forward and reverse lookups is often to provide confirmation of identity.

To that end, DNSSEC is useful, by removing the assumption of trust with 
true trust. The presumption in either case is that if the DNS tree 
verifies fwd/rev, then things are reasonable.

IKE relies either on X.509 keys (a different hierarchy) or preshared 
secrets. At best, all this does is move the problem (DNSSEC certificate 
hierarchy -> X.509 certificate hierarchy); at worst, it exposes the 
endpoint to assuming identity when the pre-shared key could be open 
(compromised, or deliberate).

I.e., it would be necessary (IMO) to limit this to identities exchanged 
by IKE/TLS based on CAs, not based on preshared keys. That may not be 
feasible.

> - the DNS is often insecure, so let the TLS or IKE derived information 
> override it to increase security

The more independent trust mechanisms there are the less trust that 
results, IMO.

Joe

> But if TLS/IPsec aren't used, the information is taken from the DNS.
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 3 Aug 2004 00:07:13 +0200

On 2-aug-04, at 15:45, Joe Touch wrote:

> the use of the DNS for forward and reverse lookups is often to provide 
> confirmation of identity.

Yes.

> To that end, DNSSEC is useful,

Sure, but that's not the point. The point is that requiring the 
presence of a working DNS is dangerous. Obviously the set of working 
DNSSEC implementations is smaller than the set of working DNS 
implementations so adding DNSSEC only makes this part worse.

> secrets. At best, all this does is move the problem (DNSSEC 
> certificate hierarchy -> X.509 certificate hierarchy);

This is an improvement as the X.509 hierarchy doesn't have to be 
traversed in real time (barring caching).

> at worst, it exposes the endpoint to assuming identity when the 
> pre-shared key could be open (compromised, or deliberate).

> I.e., it would be necessary (IMO) to limit this to identities 
> exchanged by IKE/TLS based on CAs, not based on preshared keys. That 
> may not be feasible.

I disagree. The ability to configure trust manually is very useful. 
Obviously when trust is configured using a preshared key this means 
only the configured identity must be injected into what the application 
thinks is the DNS, not any arbitrary value the remote side comes up 
with.

>> - the DNS is often insecure, so let the TLS or IKE derived 
>> information override it to increase security

> The more independent trust mechanisms there are the less trust that 

That depends on whether you do "or" or "and". Unfortunately, if you 
want to optimize for avalability you need to do "or" rather than "and".

---

From: Joe Touch <[email-masked]>
Date: Mon, 02 Aug 2004 16:37:46 -0700

Iljitsch van Beijnum wrote:

> Sure, but that's not the point. The point is that requiring the presence 
> of a working DNS is dangerous. Obviously the set of working DNSSEC 
> implementations is smaller than the set of working DNS implementations 
> so adding DNSSEC only makes this part worse.

OK.

> traversed in real time (barring caching).

How so? If the CA Certs aren't already imported, IKE won't accept them 
until they're verified. If they are, that's equivalent to DNS caching 
its keys, isn't it?

> Obviously when trust is configured using a preshared key this means only 
> the configured identity must be injected into what the application 
> thinks is the DNS, not any arbitrary value the remote side comes up with.

I don't know how we could control where the identities get used based on 
the kind of trust that is provided - that's the concern.

> That depends on whether you do "or" or "and". Unfortunately, if you want 
> to optimize for avalability you need to do "or" rather than "and".

"or" usually decreases trust, in the sense that you can only assume the 
lowest common denomenator.

Joe

---

From: Jeff Williams <[email-masked]>
Date: Mon, 02 Aug 2004 22:20:46 -0700

Joe and all,

  It would seem that following what is more and and more recognized
in the commercial world that a need to do better with Bind and the
latest version being more broadly implemented would be more helpful.
See:

    0. http://www.defcon.org/html/defcon-12/dc-12-index.html
    1. http://www.defcon.org/html/defcon-12/dc-12-speakers.html#kaminsky
    2. http://news.com.com/2100-1002_3-5291874.html?tag=nefd.top

Joe Touch wrote:

>   ------------------------------------------------------------------------
>
>                           Name: signature.asc
>    signature.asc          Type: application/pgp-signature
>                    Description: OpenPGP digital signature

Regards,
--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail [email-masked]
 Registered Email addr with the USPS
Contact Number: 214-244-4827