Subject: Re: [TLS] Signature Hash Agility

From: Mike <[email-masked]>
Date: Sat, 30 Jun 2007 20:59:30 -0700

> You're kidding, right? The server is about to do a digital signature.
> The cost of searching through a list of probably < 5 entries to
> look through your preferred choice (when your list is probably <5
> entries) is totally trivial by comparison.

Well there have been suggestions to change from a list of hash
algorithms to a list of signature algorithms which means the
list will be longer, and then there was a suggestion to send
I believe it was DigestInfo ASN.1 structures which would need
to be processed.  But yes that is probably trivial compared to
doing the signature.

Mike

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 30 Jun 2007 22:10:54 -0700

At Sat, 30 Jun 2007 20:59:30 -0700,
> to be processed.  But yes that is probably trivial compared to

The DigestInfo ASN.1 structures need to be transmitted regardless
of what the ordering rules are. They are there to prevent 
substitution attacks on the signature.

-Ekr

---

From: "Whyte, William" <[email-masked]>
Date: Mon, 2 Jul 2007 09:52:14 -0400

> substitution attacks on the signature.

Burt Kaliski has a presentation about this approach, which he
calls "Hash Function Firewalls". You can download the presentation
in various formats from
http://grouper.ieee.org/groups/1363/Research/Presentations.html
(sorry no direct link -- bottom of the page).

There are various downsides to these firewalls and it's not clear
that they absolutely need to be included if a system's being
designed from scratch.

Cheers,

William

> -----Original Message-----
> From: Eric Rescorla [mailto:[email-masked]] 
> Sent: Sunday, July 01, 2007 6:11 AM
> To: Mike
> Cc: [email-masked]
> Subject: Re: [TLS] Signature Hash Agility
>

---

From: Vin McLellan <[email-masked]>
Date: Tue, 03 Jul 2007 01:55:16 -0400

Burt Kaliski also has a 2002 paper, "On Hash 
Function Firewalls in Signature Schemes," in 
which he concluded that the best way to separate 
different hash functions is in the infrastructure 
itself (e.g., in certificates), rather than 
within the signature scheme.  It was published in 
Topics in Cryptology  CT-RSA 2002, B. Preneel, 
editor. This was volume 2271 of Lecture Notes in 
Computer Science, Springer, 2002

RSA also offers the paper, and slides, at: 
<http://www.rsa.com/rsalabs/node.asp?id=2020>

It's encouraging to see TLS thinking in the infrastructure direction.

Suerte,
          _Vin

PS. Hi William!

===============

At 09:52 AM 7/2/2007, William Whyte <[email-masked]> replied:

>Burt Kaliski has a presentation about this 
>approach, which he calls "Hash Function 
>Firewalls". You can download the presentation in 
>various formats from 
>There are various downsides to these firewalls 
>and it's not clear that they absolutely need to 
>be included if a system's being designed from scratch.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 07 Jul 2007 16:26:20 -0700

At Fri, 29 Jun 2007 09:06:10 -0700,
Eric Rescorla wrote:
> 
> 4. DSA hash selection
> I claim it must be deterministic from the DSA SubjectPublicKeyInfo what hash
> algorithm it is to be used with. Otherwise you risk substitution attacks.

So, where this item is at is that I think that for the OID dsa
(1 2 840 10040 4 1), we need to require SHA-1 and that PKIX
needs to require a new OID for dsaWithSHAXXX to go in the
SPKI.

I have a note in the draft, but it's not finished.

-Ekr

---

From: <[email-masked]>
Date: Thu, 19 Jul 2007 15:22:56 +0300

Eric Rescorla wrote:

> 3. Communicating the signature/hash algorithm you're using So, I
> agree that trying to figure out the hash from the signature
> algorithm in the cert was a mistake. We clearly need to explicitly
> name the digest algorithm in the message. However, previewing point
> (4), DSA keys need to be bound to one specific digest algorithm.
> Accordingly I think the right structure is:

> 
>     struct {
>         select (SignatureAlgorithm) {
>             case anonymous: struct { };
>             case rsa:
>                 HashType digestAlgorithm;       // NEW
>                 digitally-signed struct {
>                     opaque hash[Hash.length];
>                 };
>             case dsa:
>                 digitally-signed struct {
>                     opaque sha_hash[20];
>                 };
>             };
>         };
>     } Signature;
> 
> 
> And note that we'll need DigestInfo encoding to protect against hash
> substitution.

I'd prefer a more uniform approach:

    struct {
        opaque signature_algorithm<0..2^16-1>;
        opaque signature_value<0..2^16-1>;
    } Signature;

where signature_algorithm is DER-encoded AlgorithmIdentifier
structure, and signature_value is the actual signature value 
(and for anonymous, both are just zero-length strings).

This would work even in the case of ANSI X9.62 encoded ECDSA 
public keys, where SPKI can list more than one acceptable hash 
algorithm. (If they're all secure, substitution may not be 
a problem; IMHO this is a CA policy issue, and we shouldn't
hardcode this in TLS.)

Best regards,
Pasi

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 21 Jul 2007 07:05:36 -0700

> a problem; IMHO this is a CA policy issue, and we shouldn't

I'm OK with a uniform type, but I think a HashType is what's
appropriate here. OIDs don't seem like the TLS way...

-Ekr

---

From: <[email-masked]>
Date: Sun, 22 Jul 2007 19:44:57 +0300

> appropriate here. OIDs don't seem like the TLS way...

I agree that OIDs are not really the TLS way... but 
AlgorithmIdentifier would also work for signature schemes (such 
as RSA PSS and randomized hashing) where the hash isn't the only 
parameter needed to verify the signature.

(And actual implementations for e.g. RSASSA-PKCS1-v1_5 wouldn't
really need any ASN.1/DER code, just hardcoded octet string.)

Best regards,
Pasi