Re: [keyassure] Object Digest Reference

On Dec 13, 2010, at 4:01 PM, Ilari Liusvaara wrote:

> 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 <paul.hoffman@vpnc.org>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).

+ a really large number.

ASN.1 handling is notoriously bad and horribly broken -- we should be aiming for simplicity wherever possible, both so that this actually get implemented, and because overly complex code leads to bugs and security issues...

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

Yes (and, some would say that the lack of GOST support is a feature, not a bug :-))

w

> 
>> 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
> _______________________________________________
> keyassure mailing list
> keyassure@ietf.org
> https://www.ietf.org/mailman/listinfo/keyassure