Re: [keyassure] Object Digest Reference

[Ilari Liusvaara <[e-mail]>]

On Mon, Dec 13, 2010 at 01:59:28PM -0500, Phillip Hallam-Baker wrote:
> On Mon, Dec 13, 2010 at 11:04 AM, Paul Hoffman <[e-mail]>wrote:
> 
> Some folk on this list doubted that a semantic substitution attack was an
> issue for the KEYASSURE/CERT proposal.

I can't find any way to perform semantic substution attack against 
draft-hoffman-keys-linkage-from-dns-03 even in the most pathological
situations (that don't involve much easier attacks anyway).

BTW: TLS itself can't defend against such attacks, it just relies that
attacker doesn't have such capabilites.

> Now absent some really clear indication to the contrary, using ASN.1 OIDs
> for identifying cryptographic algs and formats is pretty much a slam dunk. I
> can't see how anyone could say that it is not an acceptable way to go for
> any application layer design.

Programming complexity. Which is big deal when you are writting this stuff
in C or C++ for practical end applications.

And yes, I'm assuming prefixes are precomputed.

I looked at piece of code I have written that handles ASN.1-encoded hashes.
All I can say is "yuck". I'd much rather deal with small integers (even
if the set has gaps).

> They are bad within DNSSEC. But unavoidable at the upper layers. I would
> prefer not to have to support PGP and other key formats in this scheme, but
> they are going to be unavoidable politically.

I haven't seen any overly bad stuff with DNSSEC (granted, how many
implementations support GOST, but the problem). But I have seen _PLENTY_ of
bad stuff with X.509.

> I don't like having to deal with all that. But what I really, really want to
> avoid is having application layer crypto impact DNSSEC.

his is just about how to denote hash algorithms. And what about fairly
reasonable hash algorithms that seeming have no OID?

> OK, how about on a web page. Imagine that we have a web page that is
> downloaded from a TLS site but the images are stored on a separate image
> server that does not have TLS.
> 
> At the moment this is such a common use case that it is really difficult to
> get enforcement on because it is so common. And there is another variation
> where the data linked to is not even in the same domain.
> 
> Imagine we can create a link of the form:
> 
> <img src="http://images.example.com/1.gif"
>     odr="odr:woei2oqur02que0o2quefoiqwefouqwefoiu=="/>
> 
> Packaging it up as a URI is not strictly necessary but that is what it is
> functionally.
> 
> One could even have a cache of content referenced by ODR lookup. So if the
> content is not locatable, it can be pulled from cache.
> 
> <a href="http://tools.ietf.org/rfc6666.txt
>     odr="odr:woqi12o3o12hroiqhweoiqhwe==">RFC 6666</a>
 
What does that ODR encode about the semantics in both cases? That the file
is a GIF in above case (what's the OID of GIF?) and that it is text file
(what character set‽; what is say, OID of ASCII text file?).

-Ilari