Re: [websec] #60: Well Known URIs vs Response Headers

<no hats>

On 30/07/13 21:17, Trevor Perrin wrote:
> On Mon, Jul 29, 2013 at 1:38 PM, websec issue tracker
> <trac+websec@trac.tools.ietf.org> wrote:
>> #60: Well Known URIs vs Response Headers
>>
>>  This is about a suggestion to replace the HPKP header with an RFC 5785
>>  well-known URI.  This would allow lower bandwidth, as this resource would
>>  be read at most once per connection, rather than with each request.
> To me this seems related to a couple other issues:
>  - can a client pin CAs by name, or will the client have to list
> potentially dozens of hashes in the header?
>  - is the header sent on every response from the pinned host, or is it
> only returned infrequently or to a client who asks for it?
>
> If CAs can be pinned by name, or if response headers are only returned
> to a client who asks for them, then large headers don't matter much.
>
> But the current draft seems inefficient / inelegant, since an HPKP
> header may contain dozens of hashes.  The header must be sent on
> *every* response from a pinned site (draft-08, section 2.2.1), so the
> client must process the header on every response.

actually the client does not have to process the hash for every
response. A simple compare with the previous cached hash(es) is
sufficient. So less processing effort.

Best regards, Tobias

>
>>  However, the same is true for HSTS, CSP, and any other policy-conveying
>>  header.
> It's not exactly the same - HSTS does not interpret an absent response
> header as max-age=0, so the headers doesn't need to be sent on every
> response.  HSTS headers are also smaller.
>
>
> Trevor
> _______________________________________________
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec