Re: Digest mess

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

Received on Monday, 22 December 1997 10:08:21 UTC