Re: Digest mess
Dave Kristol (dmk@bell-labs.com)
Mon, 22 Dec 1997 10:07:58 -0500
John Franks wrote:
>
> On Fri, 19 Dec 1997, Scott Lawrence wrote:
>
> >
> >
> > Ok; that makes sense, but I don't think that we need the dates - they
> > are not essential to detecting response replays and they are many more
> > bytes.
> >
>
> Let me suggest a compromise here that might meet everyone's needs.
>
> To the Authentication-info header we add a "digested-headers"
> field with the form
>
> dheaders="status_code:entity_length:date:L-M-date:expires"
>
> but we add the proviso that a server MAY omit any or all of the
> dates. Here are the advantages I see:
>
> 1. Proxies may now muck with date headers, content length, or status
> code as much as they wish with no ill effect on digest. This is the
> most important plus since making sure all proxies don't change or even
> canonicalize headers was looking hopeless.
>
> 2. This provides the security of digested status code and when
> necessary the three dates. Clockless servers or reponses with no
> expires or L-M-date are dealt with cleanly and insulated from
> rogue proxies. Servers can decide (on a per response basis if they
> wish) whether including the dates is worthwhile.
>
> Just to clean things up a little I would then change the definition
> of entity-digest to
>
> -----------------------------------------------------------
> entity-digest =
> <"> KD (H(A1), unquoted nonce-value ":"
> transaction-info ":" H(entity-body)) <">
> ; format is <"> *LHEX <">
>
> transaction-info =
> H(
> Method ":"
> digest-uri-value ":"
> media-type ":" ; Content-Type, see section 3.7 of [2]
> content-coding ":" ; Content-Encoding, see 3.5 of [2]
> *DIGIT ":" ; HTTP response status code
> *DIGIT ":" ; entity-length, see ??
> date ":" ; contents of origin HTTP date header
> last-modified ":" ; last modified date, see 10.25 of [2]
> expires ; expiration date; see 10.19 of [2]
> )
>
> date = rfc1123-date ; see section 3.3.1 of[2]
> last-modified = rfc1123-date ; see section 3.3.1 of [2]
> expires = rfc1123-date
> -----------------------------------------------------------
>
> Then the last five parts of the pre-digested transaction-info is precisely
> the content of dheaders.
I like the stated idea, but I don't see it reflected in the
specification fragment above. What am I missing? The date-related
pieces are still embedded in transaction-info, which is part of
entity-digest. So it hasn't been separated out, and is therefore
subject to the vagaries of proxies. OTOH, if it's made exclusively part
of a separate attribute, dheaders, then there's the possibility of its
being stripped by a MITM.
Dave Kristol