Subject: RE: [lemonade] Re: URLAUTH and hash function agility

From: "Eric Burger" <[email-masked]>
Date: Thu, 29 Sep 2005 06:42:25 -0400

There is consensus.  Realizing:

Only the IMAP server needs to know the algorithm for generating the hash
for URLAUTH.  It is opaque to the client and submit server.  Moreover,
the URLAUTH is short-lived, *and* the URLAUTH mechanism explicitly
discusses server revocation of URLAUTH tokens.  Thus the server can
upgrade the hash at will.

For long-lived URLAUTH's, one would assume the server "knows" that it
has them outstanding, and can thus deal with them outside the protocol.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Mark Crispin
Sent: Tuesday, September 27, 2005 11:02 AM
To: Dave Cridland
Cc: [email-masked]; Chris Newman
Subject: Re: [lemonade] Re: URLAUTH and hash function agility

On Tue, 27 Sep 2005, Dave Cridland wrote:
>>> 1) Most URLAUTH signed URLs will have relatively short lifetimes,
and thus
>>> 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 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.

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

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

---

From: Mark Crispin <[email-masked]>
Date: Thu, 29 Sep 2005 12:42:38 -0700

I agree with all of this, so count me in as part of the concensus.

-- 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: Thu, 29 Sep 2005 14:31:32 -0700

I agree with this statement of consensus.

                - Chris