Subject: Re: [pkix] draft-pala-rea-ocsp-over-dns

From: Erwann Abalea <[email-masked]>
Date: Fri, 3 Aug 2012 12:08:11 +0200

[Sending this to pkix@ietf too, as others might have ideas. I mentionned
the fact that nothing permitted to specify parameters along with the hash
function, and I'm seeing GOST-hashed OCSP requests in our responders since
mid july]

Bonjour,

I'm not sure that DNSSEC is useful here. After all, OCSP is usually
requested and sent in clear, the response is already signed. I don't know
what could DNSSEC add in here that we're missing.

GOST (and not Ghost) R 34.11-94 is a hash algorithm based on the GOST
28147-89 block cipher. The former needs an initial value, the latter needs
some S-Boxes. CryptoPro defined 2 sets of parameters (test and production)
in RFC4357, and a NULL parameter designates the "production" parameters (if
I correctly read the ASN.1 module, I'm not sure it's valid). There's no
"DEFAULT" in the DigestAlgorithm definition, the parameters element is only
declared "OPTIONAL", so no value is not a synonym of a NULL value.

2012/8/2 Massimiliano Pala <[email-masked]>

> Hello,
>
> thanks for the clarification. I agree that an update for RFC4501 is not
> the best idea (although it does not give
> the possibility to even specify dns vs dnssec, AFAIK).
>
> For the Ghost.. I see your point. I thought that the ghost hash did not
> need parameters to be specified (is there
> a default or you have to explicitly specify them all the time ?). That is
> an issue as specifying those types of
> parameters might be unfeasible in a URI... for that, we might need to
> specify an additional extension to cover
> that case. It might be the only possibility.. although I am sure people on
> the PKIX will just say "no" to another
> extension..
>
> Thanks again for  the input.
>
> Cheers,
> Max
>
>
>
> On 08/02/2012 05:44 PM, Erwann Abalea wrote:
>
>>
>> Bonsoir,
>>
>> Updating RFC4501 to add non-DNS information such as a hash algorithm is
>> not a good idea, IMO. Unfortunately, accessLocation in the AIA extension is
>> only a GeneralNames type, which leaves no place for a hash algorithm
>> either. Some magic trick is necessary.
>>
>> Regarding GOST, you've added some crypto-agility by allowing the CA to
>> specify the hash algorithm to use when hashing the certificate. What is
>> proposed is sufficient for classical algorithms (such as the SHA1/2
>> family), because these don't need any parameter. Russia is pushing for its
>> set of GOST defined algorithms (block cipher, hash, signature), and these
>> algorithms are mandatory in Russia (and maybe neighbours). Support for them
>> have been added in DNSSEC, for example.
>> The fact is that the GOST block cipher and hash algo (built on top of
>> block cipher) need some parameters. For the block cipher, the S-boxes; for
>> the hash, the underlying block cipher S-boxes and an IV (initial internal
>> state of the hash function). When used in a certificate, these parameters
>> find their place in the AlgorithmIdentifier structure (with the SHA*
>> families, parameters is set to NULL).
>> In your scheme, there's no place for parameters. So crypto-agility is not
>> complete.
>> I agree that GOST crypto stuff sucks, but we have to deal with real world
>> constraints :(
>> Anyways, who knows how will the soon-to-be-announced SHA3 be used? Maybe
>> it'll also need parameters too?
>>
>
-- 
Erwann.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 3 Aug 2012 06:45:48 -0400

> what could DNSSEC add in here that we're missing.

I don't fully understand the way the mechanism is supposed to work,
and I don't really know very much about OCSP, so I'm speaking from
almost total ignorance.  But DNSSEC will provide you with assurances
that the answer you get is in fact unmolested along the path.  This
could be important for ensuring you don't get fake answers.  For
instance, without DNSSEC, an attacker could insert an Name Error
response and thereby leave the client needing to fall back to some
other mechanism.  In the presence of DNSSEC, that attack would be
detected.  (You'd still be unable to use the mechanism, so I can see
an argument that there's no real gain here.)

>From the draft, however, I have no idea how the response is signed
when it comes through the DNS.  Am I just overlooking something in the
draft?  Since there's no RRTYPE definition, it's kinda hard to know
what the fields in the response will contain.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Erwann Abalea <[email-masked]>
Date: Fri, 3 Aug 2012 15:01:38 +0200

2012/8/3 Andrew Sullivan <[email-masked]>

> that the answer you get is in fact unmolested along the path.

This is already guaranteed with OCSP, which are signed objects.

>  This

That's the point. DNSSEC offers nothing more.

Today's mechanism:
 - attacker exchanges the response with a one unrelated to the request: RP
can detect it
 - attacker exchanges the response with a previous one: RP can detect if
the response has expired, responses usually have a max 10 days validity
period, some CAs have 4 hours validity responses
 - attacker exchanges the response with an unsigned error message: RP can
detect it
 - attacker blocks the response: RP can detect it

When the RP detects something wrong, it either falls back to another
validation mechanism (other OCSP URL, or CRL) or declares the certificate
as not trusted.

With the proposed mechanism (DNS), DNSSEC could have some value on the
second example, but then the attacker could simply block the response and
let the RP rely on a CRL and the attack still applies.

> what the fields in the response will contain.

What I understand is that the returned object is the requested OCSP token,
not a different beast.

-- 
Erwann.

---

From: Francis Dupont <[email-masked]>
Date: Fri, 03 Aug 2012 18:15:12 +0200

>  That's the point. DNSSEC offers nothing more.

=> not formally 100% true: DNSSEC offers secured proof of not existence.
Now IMHO it doesn't change things for this intented (mis)use of DNS,
so DNSSEC should only increase the size of responses...

Regards

[email-masked]

PS: my reasoning is to get a such name or RR doesn't exist response *or*
no response won't really make a difference.