RE: Do we need to authenticate error status and nonce information in TSA responses?

[Robert Zuccherato <robert.zuccherato@xxxxxxxxxxx>]

Sarbari;

> ----------
> From: 	Sarbari Gupta[SMTP:sgupta@cygnacom.com]
> Sent: 	Wednesday, June 02, 1999 12:42 PM
> To: 	'Robert Zuccherato'
> Cc: 	PKIX (E-mail)
> Subject: 	RE: Do we need to authenticate error status and nonce
> information in  TSA responses?
> 
> The OCSP case is absolutely relevant to this discussion. It also returns
> a signed token when successful and an (unsigned) error message when
> unsuccessful. The OCSP token is also long-lived exactly like the
> TSAToken. The OCSP document, just like the TSA document, is an Intenet
> Draft and is undergoing review.
> 
> As a group, PKIX should be able to justify design decisions it has made
> in various I-Ds that are currently being reviewed. Decisions made should
> be consistent for documents that are in parallel paths (at the very
> least). I don't see how or why OCSP should be treated differently with
> respect to error messages being signed or unsigned. The fundamental
> characteristics are identical! 
> 
No, they are not.  In OCSP the basic protocol does not link the request and
response.  This allows caching of responses.  Therefore, a signed error
message could be returned by an attacker in response to any request and thus
signed error messages are of no more value than unsigned error messages in
the OCSP case.  In this protocol, requests are always linked with responses,
and thus signed error messages are of value.  Since the underlying
assumptions and protocol characteristics are different, the OCSP case is not
relevant.  Could we now stick to discussing this protocol?

> > > If an attacker were changing the error type, what could
> > > the attacker gain from that action that they couldn't 
> > achieve by simply
> > > deleting the entire (signed or unsigned) error response?
> > > 
> > They could change "time not available for the next week" with 
> > "malformed
> > request" which would cause me to repeatedly try and fix my 
> > request for a
> > week.  Or, they could change "malformed request" with "time 
> > not available"
> > which may cause me not to get the document timestamped until 
> > next week.  
> 
> All of the above scenarios are examples of denial-of-service attacks,
> whereby the attacker is preventing the client from obtaining a valid
> TSAToken. 
> 
Yes, they are examples of denial-of-service attacks.  However, they are
preventable by using signed error messages.  Also, because of these kinds of
attacks, I cannot trust any unsigned error message and every unsigned error
message is indistinguishable from a "no response".  As I said earlier, when
you receive a "no response" you probably want to contact your server by some
other method to find out what is going on.  Do we really want to design a
protocol that forces users to contact the server every time an error is
produced?

> > Or,
> > they could change any error with "TSA XXX down, please try 
> > TSA YYY" where
> > TSA YYY is a competitor.  There are many possibilities.
> 
> This is not a valid example. The TSA client trusts the TSA for
> timestamping. A TSA is not supposed to offer referral services, and even
> if it does, the TSA client is under no obligation to use that referral
> unless it has reason to trust TSA YYY through a valid certificate chain.
> In that case, the referral is immaterial, the TSA client trusts TSA YYY
> anyway, and would probably have used TSA YYY if TSA XXX were not
> responding. 
> 
Of course, these are just three examples that came into my head as I was
writing the email.  I'm sure we could all think of other, similar attacks.

	Robert.