Re: Digest mess

  In http://www.ics.uci.edu/pub/ietf/http/hypermail/1997q4/0481.html
  John Franks says:

JF> ... adding a field to the Authentication-Info
JF> header could solve the problem by duplicating the headers which
JF> a proxy might change.  I have in mind something like

JF>    dheaders = "date:content_len:L-M-date:expires"

JF> John Mallery points out that it would be good to have the response
JF> status code digested as well.  If it is included here that becomes
JF> possible (which it wasn't before since proxies change it from
JF> say 304 to 200).  This header would also eliminate problems of 
JF> proxies canonicalizing headers.

  This would work in terms of preserving the computability of the
  digest value.  The problem I see with it is that it doesn't really
  do anything for the security but prevent a denial of service attack
  (which is unstoppable if the attacker can modify any part of the
  message anyway).  

  Going back to Pauls rationale for including these header field
  values in the first place - the general principal that as much as
  possible should be protected by the integrity check because you
  never know what some clever attacker will be able to do by changing
  an unprotected field.  By sending the original values separatly, we
  would ensure that a proxy would not cause the digest calculation to
  fail by changing these headers, but we might not prevent the
  original attack from succeeding.  The headers in question are
  essentially cache control headers; if an attacker has figured out a
  way to get a cache to do something wrong by modifying these headers,
  then the cache will still do it - the proxy does not have the secret
  needed to check the authentication information anyway.

  If good nonces are used, attacks based on cache behaviour will fail
  anyway (and as I said before, the Security Considerations section
  probably needs some more text on this), so I'm not sure that adding
  the headers is justified.

  Removing the problematic field values from the calculation and
  adding the original values as attributes are both
  backward-incompatible changes; the question then becomes which will
  do more:
     1) to support authentication and integrity protection
     2) to encourage wider implementation and use of the feature.
  I think that with respect to (1) the two alternatives are
  equivalent; neither ends up really preventing attacks based on cache
  manipulation, and either is capable of detecting such attacks.  It
  seems clear to me that making the scheme simpler by removing
  elements from the calculation is more likely to encourage wider
  implementation.

Received on Saturday, 3 January 1998 09:46:44 UTC