Mozilla's position on HPKP-RO storage

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Mozilla's position on HPKP-RO storage

Camilo Viecco-2

TLDR; I have been asked for Mozilla's position regarding a portion of
the HPKP spec.


Background:
HPKP is proposal for an http header that will instruct user agents about
ssl pinning preferences for sites. The spec contains two headers: a PKP
(MUST) which stores and enforces the pins and PKP-RO (SHOULD) which
would only report the failures to a url specified in the header.
The goal is to have reporting similar to CSP.

There has been a recent discussion on the websec mailing group about
storing the PKP-RO headers or just using them for the current session

http://www.ietf.org/mail-archive/web/websec/current/msg02204.html

I was asked offlist about Mozilla's position, so here I am going to post
my position:

1. The PKP-RO header is not really useful, it might help on initial
deployment of PKP but it cannot really be tested when it really matters
most when you are actually changing certificates.
2. Storing more data for websites for no benefit for the user seems like
a no-go (specially given concerns on mobile) therefore until proved
wrong the pkp-ro will be done for session only.
3. To simplify development we will initially limit PKP-RO only to the
current connection. (no initial storage of PKP-RO)

Waiting to hear arguments

Camilo
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Mozilla's position on HPKP-RO storage

Gervase Markham
On 28/08/14 17:20, Camilo Viecco wrote:
> 1. The PKP-RO header is not really useful, it might help on initial
> deployment of PKP but it cannot really be tested when it really matters
> most when you are actually changing certificates.

Why not? Why would it not be possible to deploy a PKP-RO and then change
your certificates?

> 2. Storing more data for websites for no benefit for the user seems like
> a no-go (specially given concerns on mobile) therefore until proved
> wrong the pkp-ro will be done for session only.

Is the amount of data involved expected to be significant in size?

> 3. To simplify development we will initially limit PKP-RO only to the
> current connection. (no initial storage of PKP-RO)

Isn't it simpler for development to treat the headers as identical apart
from in the actual display of the error?

Gerv

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Mozilla's position on HPKP-RO storage

Ryan Sleevi
On Fri, August 29, 2014 8:43 am, Gervase Markham wrote:

>  On 28/08/14 17:20, Camilo Viecco wrote:
> > 1. The PKP-RO header is not really useful, it might help on initial
> > deployment of PKP but it cannot really be tested when it really matters
> > most when you are actually changing certificates.
>
>  Why not? Why would it not be possible to deploy a PKP-RO and then change
>  your certificates?
>
> > 2. Storing more data for websites for no benefit for the user seems like
> > a no-go (specially given concerns on mobile) therefore until proved
> > wrong the pkp-ro will be done for session only.
>
>  Is the amount of data involved expected to be significant in size?
>
> > 3. To simplify development we will initially limit PKP-RO only to the
> > current connection. (no initial storage of PKP-RO)
>
>  Isn't it simpler for development to treat the headers as identical apart
>  from in the actual display of the error?
>
>  Gerv
>

Not what the current (post-LC) spec says. If Mozilla has strong feelings,
it would be useful to continue the discussion in the IETF WebSec group,
and the broader question of "Should the spec be withdrawn from the queue
to accommodate this" be answered.

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto