[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [IPSECKEY] minutes from BOF



I believe that I made a number of comments on the issue of
DNS Key records and XKMS/SRV.

I can't remember the exact points I raised, however the argument
I have been advancing goes something like this:

1) Directory based and Directory linked PKI have failed because
	they are the wrong model and key off the wrong index.

	I differentiate Directory linked PKI and DNS linked PKI
here because I believe that the reasons why Directory linked PKI 
has failled do not apply to DNS linkage.

	The main problem with using an LDAP or X.500 directory as
the hub of an Internet PKI is that there is no X.500 infrastructure
at that scale and there never will be. The DNS is the naming
infrastructure of the Internet.

	The secondary problem is that the concept of the directory
as the authoritative name source was simply wrong. Common names are
not unique identifiers. RFC822 Email addresses are.

2) DNS is fragile, handle with care

	There have been numerous points raised about the straw that
broke the DNS back problem. While I believe that we can probably
make DNS work in whatever context we need to, the costs of doing
so might be more than people are willing to bear.

3) DNS is not deployed as trusted cryptographic infrastructure

	So be very careful when layering cryptographic functions
on top of it.

4) Real world PKI topologies are rarely hierarchies

	The DNS is an (the?) exception. However most application
PKIs in which there are issues of liability, risk etc are not
actually hierarchies, and if they are hierarchies the root is
not ICANN or the ISOC or IETF.

	Real world PKI topologies tend to look hierarchical at 
the base of the tree and get web of trust-ish at the top. See
the FBCA for an example.

5) Real world PKI at Internet scale requires separation of the 
	key discovery and key validation processes

	PGP and S/MIME both fail at internet scale because of the
problem of locating encryption keys. At present both PGP and
S/MIME resort to out of band configuration to hand configured
discovery mechanisms, often the users address book...

6) DNS Linked PKI is best model for most applications

	The model I have come to prefer for PKI is to make key
management a separate function that is linked to the DNS, either via
a SRV or NAPTR record.

	So if I have an email address fred@somewhere.com my email
client follows an SRV record in the DNS zone somewhere.com to find
a key discovery service for fred@somewhere.com.

	My overwhelming preference here is for the discovery service
interface to be of the form used in XKMS 'give me a key to talk
S/MIME to fred@somewhere.com'. 

	If people want to they can try to make key discovery through 
LDAP directories work, however I think that model is broken since
it is impossible to know what path to follow throught the Web of 
trust to locate the trust chain.

	Linking the PKI to DNS is preferable to merging PKI and DNS
for many reasons, not least the fact that DNS is not designed as a
PKI and DNSSEC is constantly having to work arround constraints due
to the deployed base.

7) IPSEC is an exception

	IPSEC is different because at that level there is a precise
alignment of the DNS hierarchy and the trust topology.

8) DNSSEC is needed to securely distribute policy

	The real value of DNSSEC is that it allows the secure
distribution
of the security policy for a zone to be communicated, either through
records in the DNS itself or (preferred) by means of a link to a
policy distribution mechanism. This allows downgrade attacks to be
prevented. Consider the following policy statements:

   a) All mail in this zone is signed
   b) The SMTP mail server in this zone offers SSL Upgrade
   c) This host offers IPSEC connectivity

	Obtaining this type of policy information from an authoritative
source is very powerful. For example a and b might be used to reject 
SPAM with a forged address from that zone - very powerful since much of
the spam sent has a bogus from address to evade filters, a lot is forged

as comming from the user meant to receive it.

9) Validation of keys is not an issue if the alternative is plaintext

	Most of the Internet mechanisms we use have become complex
because
we have got the problem of man in the middle wrapped arround the axles.
So because we can't solve the man in the middle without infrastructure 
we end up sending information plaintext instead.

	I don't see this so much as opportunistic encryption as simply a
low
threshold for key validation. We will accept the minimal validation
provided by an SRV record in non-authenticated DNS and a key returned by
XKMS locate followed by the 'accept everything' validation procedure.

	I like the idea of opportunistic encryption, but not if it means
that
we end up accepting an infrastructure that is only good for
opportunistic
encryption when we can have an infrastructure that will operate at any
policy level for the same price, perhaps less since DNS linked PKI does
not
have the baggage of legacy deployment of a critical infrastructure to
cope 
with.

	There is no reason why we could not get an XKMS locate service 
written and make a single distribution containing both that and BIND.

		Phill

> -----Original Message-----
> From: Michael Richardson [mailto:mcr@sandelman.ottawa.on.ca]
> Sent: Monday, December 16, 2002 11:24 AM
> To: ipseckey@lox.sandelman.ottawa.on.ca
> Subject: [IPSECKEY] minutes from BOF
> 
> 
> 
> Date: Sat, 14 Dec 2002 09:34:51 -0500 (EST)
> From: Sam Weiler <weiler@watson.org>
> 
> IPSECKEY BOF at IETF-55 Atlanta
> 19 November 2002
> Reported by Samuel Weiler
> 
> Mailing list: ipseckey@sandelman.ottawa.on.ca
> To subscribe, put "subscribe ipseckey" in the body of a message to
> majordomo@sandleman.ottawa.on.ca
> 
> Draft: draft-richardson-ipsec-rr-00.txt
> 
> 
> This is an effort to specify an RR to be used to distribute public
> keys and gateway addresses for opportunistic IPSEC, to replace the
> current use of both a TXT RR and a KEY RR.  In years past, the DNS
> working groups were seen as being stingy with new RR type codes, so
> KEY was subtyped and used for both DNSSEC keys and application keys.
> A recent draft prohibits applications from using KEY.  This is
> primarily an effort to replace the existing functionality, which
> requires a remote system's public RSA key and a IP address of it's
> gateway, both indexed by IP address.
> 
> Scott Rose presented a synopsis of
> draft-ietf-dnsext-restrict-key-for-dnssec-04.txt, which prohibits
> applications from using the KEY RR to avoid large keysets at a zone
> apex, to avoid subtyping, and to separate administration of DNSSEC and
> application keys.  He emphasized that the DNSSEC spec rewrite
> currently in progress does not forbid the use of DNS for storing
> application key material.
> 
> There was some discussion of whether the problems the restrict-key
> draft purports to address are real.  Subtyping is architecturally
> flawed -- DNS lookups are based on class/name/type, and there seemed
> to be widespread support for the idea that subtyping should be
> avoided.  There was not consensus as to whether overflow to TCP,
> which is almost certain when you have application KEY RRs sharing a
> zone apex with DNSSEC KEYs, is _really_ problematic: application use
> of KEYs was not experimented with at previous workshops.
> 
> Hugh Daniel expressed substantial frustration that the restrict-key
> draft seems to be going through before a replacement for use of the
> KEY RR is in place, especially given that there's deployed code using
> KEY for IPSEC.  Steve Bellovin expressed great reluctance to hold up
> the DNSSEC spec to wait for this and pointed out that there isn't a
> protocol police -- no one is going to forcibly stop the use of KEY for
> IPSEC.
> 
> There was much discussion of whether to focus on IPSEC keys or
> something more general.  A more general BOF (SIKED) was held
> Minneapolis (March 2002), and the feedback from there was not to try
> to do everything at once and instead go for one protocol at a time.
> Furthermore, the trust model of each application (ie. S/MIME) may not
> match that of DNSSEC -- there are decisions that will have to be made
> per application.  And the same logic that applied for evicting IPSEC
> from using KEY applies to reuse of an APPKEY RR type by multiple
> applications that will presumably need different additional/support
> data: subtyping is evil.
> 
> Micheal presented an initial proposal for an IPSECKEY RR.  It contains
> an extensible series of type-length-value tuples.  Specific fields
> types would be: priority, v4/v6 addresses of gateway, FQDN of gateway,
> RSA key of gateway.  There was some discussion of whether a hostname
> to key mapping (in the forward tree) would be more appropriate.  The
> BOF chairs intend this effort to replace the existing functionality,
> which uses the reverse tree, and in order to have the naming model of
> this mapping match the IPSEC naming model, it's appropriate to use the
> reverse tree.  A gateway needs to be specified because you may have
> boxes sitting behind an IPSEC gateway that need to delegate authority
> to make the IPSEC connections.  The desired case is that nodes are
> their own gateways, in which case they list themselves or nothing as
> gateway.
> 
> What if DNSSEC weren't available?  You'd still be protected from some
> passive attacks, which has value.  It is very easy to poison DNS
> caches, and while an active attack, it's not as difficult as a
> man-in-the-middle.
> 
> A sample charter was presented with a single deliverable draft to
> published as soon as the queue opens with a final version in Jan/Feb
> and submission to the IESG in March.  There was a noticeable hum in
> favor of requesting a WG with an IPSEC-specific charter and a timeline
> of six months.  There was no noticeable hum when the room was asked if
> the effort was worthless.
> 
> 
> -
> This is the IPSECKEY@sandelman.ca list.
> Email to ipseckey-request@sandelman.ca to be removed.
> 

smime.p7s