Subject: [lemonade] URLAUTH and hash function agility

From: Chris Newman <[email-masked]>
Date: Fri, 23 Sep 2005 18:52:42 -0700

One of the substantive IESG comments on URLAUTH is in relation to hash function 
agility.  There was a good presentation on the topic at the "hash" BOF at the 
last IETF which I attended.

Basically the problem is that cryptographic hash functions can eventually cease 
to provide the collision resistance required.  And both MD5 and SHA-1 have 
recently shown weaknesses.  When this happens, it is desirable to have a 
graceful upgrade where a new hash function is gradually deployed while the old 
one continues to work.  Unfortunately, the security community didn't think to 
design their protocols with this feature until it was too late :-(

As an example, suppose MD5 is widely deployed and we want to upgrade to SHA256. 
A protocol with hash function agility needs a label which states the algorithms 
used (e.g. "md5,sha256"), that label needs to be signed by both algorithms (to 
reduce downgrade attacks), and the output from both algorithms needs to be 
included.  An MD5-only client will need the ability to ignore the ",sha256" in 
the label as well as the extra SHA 256 data.  A SHA256-aware client will ignore 
the MD5 data when both are present (as well as ignoring labels and data for 
other unknown mechanisms).

This impacts IMAP URLAUTH as follows:

1. A good implementation of the INTERNAL mechanism needs hash function agility
   internally.  Since we don't have an RFC explaining hash function agility to
   reference yet, we'll need to include text describing hash function agility
   in the security considerations.  So a good internal mechanism would have
   one or two bytes to numerically identify two hash functions which would be
   included in the calculation and would ignore unknown hash functions and
   the extra data associated with them.

2. To permit future extensibility to non-internal mechanisms, the URLAUTH
   mechanism field needs to support at least 2 comma-separated mechanisms and
   the rump URL (used to compute the output of each mechanism) has to include
   the mechanism list.  Implementations MUST have the capability to ignore
   unknown mechanisms.

I suggest changing:

iurlauth        = [expire] ";URLAUTH=" access ":" mechanism ":"
                   enc-urlauth

to:

iurlauth        = [expire] ";URLAUTH=" access ":" mechanism *("," mechanism)
                  ":" enc-urlauth *("," enc-urlauth)
                  ; Each mechanism must have exactly one matching enc-urlauth

3. The algorithm to determine the rump URL needs to be changed so it includes
   the mechanism list.

                - Chris

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

---

From: Mark Crispin <[email-masked]>
Date: Mon, 26 Sep 2005 17:08:27 -0700 (Pacific Daylight Time)

Thank you Chris for your analysis and suggestions in this regard.

I wonder if this is really a problem that requires us to do anything, or 
at least anything to the URLAUTH specification as opposed to an 
implementation recommendation.  In particular, I see no particular need 
for a URLAUTH signed URL to carry multiple hash function hashes.

Here's my thinking in this regard:

1) Most URLAUTH signed URLs will have relatively short lifetimes, and thus 
are highly unlikely to outlive a transition.

2) In the case of INTERNAL, it may be appropriate to recommend a means by 
which the hash function can be changed but older function hashes can still 
be validated for some transition period.  Thus, although some means of 
identifying "new" vs. "old" hash is needed, only the server (which both 
generates and validates the hash) needs to know about any of these 
mechanics.

3) The case of a non-INTERNAL mechanism where the client uses GENURLAUTH 
is essentially the same as INTERNAL.  In fact, I'm not certain that I 
fully understand the use/purpose of GENURLAUTH with a non-INTERNAL 
mechanism; it seems to me that the value of a non-INTERNAL mechanism is 
for client-generated hashes.  Perhaps we could/should simplify GENURLAUTH 
so that it only does INTERNAL?

4) In the case of non-INTERNAL mechanisms generated by the client, both 
client (generating the hash) and server (validating the hash) need to 
implement the hash.  There is no point to generating a URL with a hash 
that the server can not use, or has already been obsoleted by a better 
hash that the server can use.

I guess that the supposition in the (4) case is that the client knows that 
the server will implement the better hash in the near future; but it's not 
clear to me that much of anything is gained with a dual-hash URLAUTH.  If 
the old hash is weak enough to get rid of, then a URLAUTH with that hash 
is bad news and a dual-hash URLAUTH might even compromise the new hash??

I'm thinking out loud here; and I'll be the first to admit that these 
arguments may be full of male bovine manure.  If they are, please debunk 
them and help me understand where manure starts...  Thanks.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

---

From: Chris Newman <[email-masked]>
Date: Mon, 26 Sep 2005 18:02:24 -0700

Mark Crispin wrote on 9/26/05 17:08 -0700:
> I wonder if this is really a problem that requires us to do anything, or at
> least anything to the URLAUTH specification as opposed to an implementation
> recommendation.

Since URLAUTH doesn't define non-INTERNAL mechanisms, I'll agree the primary 
impact is to the implementation recommendation.

> which the hash function can be changed but older function hashes can still be
> validated for some transition period.  Thus, although some means of
> generates and validates the hash) needs to know about any of these mechanics.

Agreed.

> 3) The case of a non-INTERNAL mechanism where the client uses GENURLAUTH is
> essentially the same as INTERNAL.  In fact, I'm not certain that I fully
> understand the use/purpose of GENURLAUTH with a non-INTERNAL mechanism; it
> seems to me that the value of a non-INTERNAL mechanism is for
> client-generated hashes.  Perhaps we could/should simplify GENURLAUTH so that
> it only does INTERNAL?

That does sound like a good simplification.

> implement the hash.  There is no point to generating a URL with a hash that
> the server can not use, or has already been obsoleted by a better hash that
> the server can use.
>
> clear to me that much of anything is gained with a dual-hash URLAUTH.  If the
> old hash is weak enough to get rid of, then a URLAUTH with that hash is bad
> news and a dual-hash URLAUTH might even compromise the new hash??

The other concern with case (4) is downgrade attacks.  If the attacker can 
trick the client into thinking the server doesn't understand the stronger hash 
and the client only generates with the weaker hash which the attacker can 
break, then that might be a problem.  If the client always uses the stronger 
hash in addition to optionally using the weaker hash, then when the server gets 
the string, it can validate the stronger hash even if a downgrade attack was 
attempted which foils the attack.

On the flip side, one could argue that a downgrade attack isn't feasible to the 
extent we're always using TLS/SSL protection for the IMAP connection.  One 
could also argue that this sort of downgrade attack is sufficiently complex and 
provides sufficiently little benefit to the attacker as to not be worth 
worrying about.  Given the tradeoff between those arguments and the cost of two 
algorithms, I'm thinking my analysis was over-eager in this case and you're 
correct.  I guess I should have re-read my analysis with my security geek hat 
off and my simplicity hat on prior to sending it...

                - Chris

---

From: Dave Cridland <[email-masked]>
Date: Tue, 27 Sep 2005 10:17:31 +0100

>> are highly unlikely to outlive a transition.
True, but that implies we should always be using EXPIRES, which isn't 
mentioned in the Security Considerations. Should it be?

> That does sound like a good simplification.
I wonder about this.

Supposing that, at a later date, we decide to define a similar 
mechanism to INTERNAL, in that it involves the server signing the 
URL, but that has different properties. Perhaps it's one-time only, 
or perhaps the URLAUTH URL can be generated by, and validated by, 
either client or server.

For the "simplification" of saving 9 octets, we seem to be preventing 
that.

On the other hand, we could reasonably state that the syntax has an 
optional mechanism name, which, when absent, defaults to INTERNAL. 
But that's a very cumbersome way of saving 9 octets.

FWIW, in the more general debate, I suspect that hash agility isn't 
important for URLAUTH because they're relatively shortlived. Just 
defining a new mechanism, and phasing out the old one, is probably 
enough. We always have INTERNAL as a "hash agile" fallback, simply 
because it's entirely opaque, so we can't lose interoperability with 
older clients.

Dave.

---

From: Mark Crispin <[email-masked]>
Date: Tue, 27 Sep 2005 08:02:00 -0700 (PDT)

> mentioned in the Security Considerations. Should it be?

That would preclude the possibility of long-lived "public" URLAUTH URLs.

It seems obvious to me that you would want any URL with a finite useful 
lifetime should have an EXPIRES to kill it after that lifetime, but I 
guess we could have something to that effect in the Security 
Considerations.  If there's concensus to do that, I would like some help 
in wordsmithing; since it's obvious to me, I don't know how to state it so 
that it explains what others may find non-obvious.

> Supposing that, at a later date, we decide to define a similar mechanism to 
> INTERNAL, in that it involves the server signing the URL, but that has 
> different properties. Perhaps it's one-time only, or perhaps the URLAUTH URL 
> can be generated by, and validated by, either client or server.

That's why GENURLAUTH takes a mechanism argument.  The question is whether 
the gain in potential protocol complexity is worth the additional protocol 
complexity.  It isn't about saving 9 octets; it's about slicing unneeded 
fat from the protocol.

> FWIW, in the more general debate, I suspect that hash agility isn't important 
> for URLAUTH because they're relatively shortlived. Just defining a new 
> mechanism, and phasing out the old one, is probably enough. We always have 
> INTERNAL as a "hash agile" fallback, simply because it's entirely opaque, so 
> we can't lose interoperability with older clients.

Yes, this is my thought as well.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

---

From: Mark Crispin <[email-masked]>
Date: Tue, 27 Sep 2005 15:45:52 -0700 (Pacific Daylight Time)

On Mon, 26 Sep 2005, Chris Newman wrote:
> trick the client into thinking the server doesn't understand the stronger 
> hash and the client only generates with the weaker hash which the attacker 
> can break, then that might be a problem.  If the client always uses the 
> stronger hash in addition to optionally using the weaker hash, then when the 
> server gets the string, it can validate the stronger hash even if a downgrade 
> attack was attempted which foils the attack.

Thank you for pointing this out.  I never thought about attacks using the 
vector of tricking the client into generating a weak hash.

This suggests another attack vector.  I wonder if an attacker can somehow 
convince the client to generate a hash using a cracked mechanism (that the 
server has removed), and use knowledge of the cracked mechanism hash to 
enable the attacker to generate a hash in a "safe" mechanism.

I wonder if we should require in the Security Considerations that 
mechanisms must not share mechanism-specific data, since (although the 
URLAUTH document does not explicitly state it) this data would be used by 
any client-generated URLAUTH hashes.

> On the flip side, one could argue that a downgrade attack isn't feasible to 
> the extent we're always using TLS/SSL protection for the IMAP connection. 
> One could also argue that this sort of downgrade attack is sufficiently 
> complex and provides sufficiently little benefit to the attacker as to not be 
> worth worrying about.

I think so; nevertheless, the fact that we considered these things (and 
this consideration is in the record) may be good for us in the future.

I *think* that these only become issues when mechanisms other than 
INTERNAL are defined.  I'm not certain about how much we can/should say, 
as opposed to deferring it to future work that defines non-INTERNAL 
mechanisms.  I think that future work would certainly write a new Security 
Considerations that completely supercedes the one in the current URLAUTH 
document; thus, I'm less concerned about preventing problems that are 
currently not possible than I am with saying something now that hinders 
future work later.

-- Mark --