Loading ...
Sorry, an error occurred while loading the content.

Re: Digest mess

Expand Messages
  • John Franks
    ... I think the reason for including dates and expires in a digest is to prevent replay attacks. There are many cases where not only is the information
    Message 1 of 185 , Dec 18, 1997
    • 0 Attachment
      On Thu, 18 Dec 1997, Scott Lawrence wrote:

      >
      >
      > 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).
      >

      I think the reason for including dates and expires in a digest
      is to prevent replay attacks. There are many cases where not
      only is the information important but the date it was sent is
      important (think of a stock quote, for example). The motivation
      for including the response status value in the digest is to
      have the response from a PUT essentially certify that the
      PUT succeeded. For this to be meaningful it also needs a date.

      There are ways to achieve the same thing, like putting duplicates
      of the headers in the message body, but if there is no standard
      way to do that then clients can't automatical
    • Larry Masinter
      I believe there is rough consensus for moving forward with digest limited to its role as a replacement for basic that doesn t provide for message integrity.
      Message 185 of 185 , Jan 8, 1998
      • 0 Attachment
        I believe there is rough consensus for moving forward with
        digest limited to its role as a replacement for 'basic' that
        doesn't provide for message integrity. John Franks will work
        with Jim Gettys on replacement text. We need not discuss
        the matter further until there's a revised draft to consider.

        Let's move on.

        Larry (as WG chair)
      Your message has been successfully submitted and would be delivered to recipients shortly.