Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft

From: Gervase Markham <[email-masked]>
Date: Wed, 04 Jun 2014 20:54:07 +0100

Hi Ben,

On 27/05/14 22:12, Ben Wilson wrote:
> Here is another draft with suggested changes from Santosh accepted, and
> the addition of “Security Considerations” subsections, based on our
> discussions of May 13^th .

Sorry if I'm missing context here, but the intro to the document
suggests that it's documentation of observed browser behaviour (i.e. a
record of reality), but then as early as section 1.4 it starts by saying
browsers "should" do X or Y. E.g.:

"A browser should only use its trust anchor store to determine the trust
anchor for a Server’s certification path."

Taking this particular statement as an example: what happens if the
browser wants to use the OS store? Or both its own and the OSes? Or a
remote store with auto-download such as Windows uses?

To take another example from 1.4: "Specifically, the browser should be
able to use unsecure HTTP and unsecure LDAP method." I can confidently
say that we have no plans to reintroduce LDAP fetching to Firefox, and
the publication of an RFC would be unlikely (British understatement) to
change that. (We are also pretty unlikely to do caIssuers chasing, but I
am 0.1% less adamant about that.)

As more constructive input: many of the behaviours you note are features
of the underlying SSL implementation rather than the browser. This is, I
believe, why Chrome and Safari on OS X don't do name constraints (they
use the system SSL library) but Firefox does (which uses NSS). I agree
it's difficult because the exact user experience _is_ defined by the
individual browsers. But the document might be easier to understand and
follow if you acknowledged the connection with the library being used.

Gerv

---

From: Tim Moses <[email-masked]>
Date: Thu, 5 Jun 2014 13:37:27 +0000

Hi Ben.  We want to move this document to WG draft status.  Do you want to address Gerv's comments before we hold a ballot?  I suggest we do that.

All  the best.  Tim.

-----Original Message-----
From: wpkops [mailto:[email-masked]] On Behalf Of Gervase Markham
Sent: Wednesday, June 04, 2014 3:54 PM
To: [email-masked]; [email-masked]
Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft

Hi Ben,

On 27/05/14 22:12, Ben Wilson wrote:
> Here is another draft with suggested changes from Santosh accepted, 
> and the addition of “Security Considerations” subsections, based on 
> our discussions of May 13^th .

Sorry if I'm missing context here, but the intro to the document suggests that it's documentation of observed browser behaviour (i.e. a record of reality), but then as early as section 1.4 it starts by saying browsers "should" do X or Y. E.g.:

"A browser should only use its trust anchor store to determine the trust anchor for a Server’s certification path."

Taking this particular statement as an example: what happens if the browser wants to use the OS store? Or both its own and the OSes? Or a remote store with auto-download such as Windows uses?

To take another example from 1.4: "Specifically, the browser should be able to use unsecure HTTP and unsecure LDAP method." I can confidently say that we have no plans to reintroduce LDAP fetching to Firefox, and the publication of an RFC would be unlikely (British understatement) to change that. (We are also pretty unlikely to do caIssuers chasing, but I am 0.1% less adamant about that.)

As more constructive input: many of the behaviours you note are features of the underlying SSL implementation rather than the browser. This is, I believe, why Chrome and Safari on OS X don't do name constraints (they use the system SSL library) but Firefox does (which uses NSS). I agree it's difficult because the exact user experience _is_ defined by the individual browsers. But the document might be easier to understand and follow if you acknowledged the connection with the library being used.

Gerv

_______________________________________________
wpkops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/wpkops

---

From: Gervase Markham <[email-masked]>
Date: Thu, 05 Jun 2014 15:10:20 +0100

On 05/06/14 14:37, Tim Moses wrote:
> Hi Ben.  We want to move this document to WG draft status.  Do you
> want to address Gerv's comments before we hold a ballot?  I suggest
> we do that.

Again, apologies for lack of knowledge of the process, but: the doc is
full of "to be expanded", "we plan to..." etc. So there will be lots of
further change. Is that what "Draft" means?

My two examples were two of many; they were actually given to try and
get clarity on the purpose and goals of the document. If that's written
up somewhere, do point me to it. :-)

Gerv

---

From: Tim Moses <[email-masked]>
Date: Thu, 5 Jun 2014 14:19:10 +0000

Gerv:  You have to look for that in the charter ...

http://datatracker.ietf.org/wg/wpkops/charter/

The significance of WG Draft is that it identifies the single document (or sequence of documents) of the declared scope on which the group will focus its efforts.  It is not expected that the first WG Draft will be complete or internally consistent.

It is often stated that the experts in the community will not engage until a document achieves WG Draft status.  So, we are hoping for, and expecting, a more vigorous debate once the document advances to WG Draft status.

All the best.  Tim.

-----Original Message-----
From: Gervase Markham [mailto:[email-masked]] 
Sent: Thursday, June 05, 2014 10:10 AM
To: Tim Moses; [email-masked]
Cc: [email-masked]
Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft

On 05/06/14 14:37, Tim Moses wrote:
> want to address Gerv's comments before we hold a ballot?  I suggest we 
> do that.

Again, apologies for lack of knowledge of the process, but: the doc is full of "to be expanded", "we plan to..." etc. So there will be lots of further change. Is that what "Draft" means?

My two examples were two of many; they were actually given to try and get clarity on the purpose and goals of the document. If that's written up somewhere, do point me to it. :-)

Gerv

---

From: "Ben Wilson" <[email-masked]>
Date: Thu, 5 Jun 2014 08:22:22 -0600

Thanks.  I'll take a look and create another draft.

-----Original Message-----
From: wpkops [mailto:[email-masked]] On Behalf Of Tim Moses
Sent: Thursday, June 5, 2014 8:19 AM
To: Gervase Markham
Cc: [email-masked]; [email-masked]
Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft

The significance of WG Draft is that it identifies the single document (or
sequence of documents) of the declared scope on which the group will focus
its efforts.  It is not expected that the first WG Draft will be complete or
internally consistent.

It is often stated that the experts in the community will not engage until a
document achieves WG Draft status.  So, we are hoping for, and expecting, a
more vigorous debate once the document advances to WG Draft status.

All the best.  Tim.

-----Original Message-----
From: Gervase Markham [mailto:[email-masked]]
Sent: Thursday, June 05, 2014 10:10 AM
To: Tim Moses; [email-masked]
Cc: [email-masked]
Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft

> want to address Gerv's comments before we hold a ballot?  I suggest we 

Again, apologies for lack of knowledge of the process, but: the doc is full
of "to be expanded", "we plan to..." etc. So there will be lots of further
change. Is that what "Draft" means?

My two examples were two of many; they were actually given to try and get
clarity on the purpose and goals of the document. If that's written up
somewhere, do point me to it. :-)

Gerv

---

From: "Ben Wilson" <[email-masked]>
Date: Fri, 6 Jun 2014 12:47:49 -0600

Iñigo and Bruce,
Perhaps we should revise the Trust Model document to describe how browser,
root store, and cryptolibrary are related?  In addressing Gerv's comments, I
am thinking of starting with the following "This document reviews the
current processing behaviors of cryptolibraries, and the browsers they
support, with respect to SSL/TLS session establishment between a server and
a browser, ..." or something along those lines.
Thoughts?
Thanks,
Ben

>Sent: Thursday, June 5, 2014 8:10 AM
of "to be expanded",
> "we plan to..." etc. So there will be lots of further change. Is that what
"Draft" means?
>My two examples were two of many; they were actually given to try and get
clarity on the 
>purpose and goals of the document. If that's written up somewhere, do point
me to it. :-)

---

From: Tim Moses <[email-masked]>
Date: Fri, 6 Jun 2014 20:01:47 +0000

Bruce/Inigo - Do you think the Transparency section in the revocation doc from Phill and David belongs in the Trust Model doc?  

All the best. Tim. 

> On Jun 6, 2014, at 2:47 PM, "Ben Wilson" <[email-masked]> wrote:
> 
> Iñigo and Bruce,

---

From: [email-masked]
Date: Mon, 09 Jun 2014 10:29:01 +0200

Hi Ben,

The current text of the trust models document already identifies the way a browser and a root store provider work together but not the relation with the crypto libraries. I don´t understand your question exactly because I don´t see why these libraries are of interest for a trust model. Do you mean that a trust model can differ depending on which library is used?
The trust model document is more on a "functional" view than a technical one.
I need more clarification on what you think to be added

Regards

Iñigo Barreira
Responsable del Área técnica
[email-masked]
945067705

ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ!
ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente.

-----Mensaje original-----
De: Ben Wilson [mailto:[email-masked]] 
Enviado el: viernes, 06 de junio de 2014 20:48
Para: Barreira Iglesias, Iñigo; [email-masked]
CC: [email-masked]; 'Gervase Markham'; 'Tim Moses'
Asunto: RE: [wpkops] Preliminary Next Version of Browser Behavior Draft

Iñigo and Bruce,

of "to be expanded",
"Draft" means?
clarity on the 
me to it. :-)

---

From: [email-masked]
Date: Mon, 09 Jun 2014 11:00:30 +0200

Hi Tim,

Well, I have my doubts. The trust model document is about the webPKI working as today and CT is not deployed at all. Google plans to incorporate by the beginning of 2015 officially and make it mandatory for Chrome (of course, CAs can use it today on a voluntary basis).
OTOH, CT is about issuing a certificate from a CA and how to let the others know that a certificate has not been issued properly but I think this is on the CA operations rather than on a trust model document but it also has implications on the trust you can have.
Google uses in Chrome, when running on windows, the MS root store so it relies on what MS has stated in his root store program independently of the CT.

But, in section 3.4 of the trust model document, it´s described how a browser can support public key pinning, so CT can be a new section 3.4.5, but again, it´s not yet deployed. The same can happen with CAA, there´s a RFC but none is using it at the moment and there´s a minimum of % to be considered.
Initially was also considered the EU Trusted List and were removed because not "widely" used and maintained by the browser, so the % was very low.

So, IMHO, right now, the CT is not part of the trust model document. We´ll see next year.

Iñigo Barreira

-----Mensaje original-----
De: Tim Moses [mailto:[email-masked]] 
Enviado el: viernes, 06 de junio de 2014 22:02
Para: Ben Wilson
CC: Barreira Iglesias, Iñigo; Bruce Morton; [email-masked]; Gervase Markham
Asunto: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft

All the best. Tim. 

> Perhaps we should revise the Trust Model document to describe how 
> browser, root store, and cryptolibrary are related?  In addressing 
> Gerv's comments, I am thinking of starting with the following "This 
> document reviews the current processing behaviors of cryptolibraries, 
> and the browsers they support, with respect to SSL/TLS session 
> establishment between a server and a browser, ..." or something along those lines.
> Thoughts?
> Thanks,
> Ben
> 
>> get

---

From: "Ben Wilson" <[email-masked]>
Date: Mon, 9 Jun 2014 10:24:25 -0600

Iñigo,
Yes, the cryptolibraries are functional subcomponents of browsers, so they
ought to be mentioned.  Providing the functional introduction will lay the
groundwork for technical background.  I'll send you (or post to the IETF
site) the next version of the working document on non-revocation behavior.
Cheers,
Ben 

-----Original Message-----
From: wpkops [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, June 9, 2014 2:29 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft

Hi Ben,

The current text of the trust models document already identifies the way a
browser and a root store provider work together but not the relation with
the crypto libraries. I don´t understand your question exactly because I
don´t see why these libraries are of interest for a trust model. Do you mean
that a trust model can differ depending on which library is used?
The trust model document is more on a "functional" view than a technical
one.
I need more clarification on what you think to be added

Regards

Iñigo Barreira

ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea.
Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki
idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna.
KONTUZ!
ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la
que solo tiene derecho a acceder el destinatario. Si usted lo recibe por
error le agradeceriamos que no hiciera uso de la informacion y que se
pusiese en contacto con el remitente.

-----Mensaje original-----
De: Ben Wilson [mailto:[email-masked]] Enviado el: viernes, 06 de junio de
2014 20:48
Para: Barreira Iglesias, Iñigo; [email-masked]
CC: [email-masked]; 'Gervase Markham'; 'Tim Moses'
Asunto: RE: [wpkops] Preliminary Next Version of Browser Behavior Draft

Iñigo and Bruce,

>full
of "to be expanded",
"Draft" means?
clarity on the 
me to it. :-)

---

From: [email-masked]
Date: Tue, 10 Jun 2014 10:23:20 +0200

Hi Ben,

I´ll wait for your proposal but still don´t see it as a part of the trust model. The cryptolibraries are "something" the browsers use to perform their activities regarding the web PKI but IMHO are not related on how the browsers (or the OS) accept a CA in their root stores or how a CA adopt different options.
In any case, if this is important for the browser behavior document, as said, will wait for the proposal and see where this can be added to the trust model doc.

Iñigo Barreira

-----Mensaje original-----
De: Ben Wilson [mailto:[email-masked]] 
Enviado el: lunes, 09 de junio de 2014 18:24
Para: Barreira Iglesias, Iñigo; [email-masked]
CC: [email-masked]; [email-masked]; [email-masked]
Asunto: RE: [wpkops] Preliminary Next Version of Browser Behavior Draft

Iñigo,

-----Original Message-----

Hi Ben,

Regards

Iñigo Barreira

-----Mensaje original-----

Iñigo and Bruce,

of "to be expanded",
"Draft" means?
clarity on the 
me to it. :-)

---

From: "Ben Wilson" <[email-masked]>
Date: Tue, 10 Jun 2014 09:52:53 -0600

It's now posted here -
https://tools.ietf.org/html/draft-wilson-wpkops-browser-processing-01 

-----Original Message-----
Sent: Tuesday, June 10, 2014 2:23 AM

Hi Ben,

I´ll wait for your proposal but still don´t see it as a part of the trust
model. The cryptolibraries are "something" the browsers use to perform their
activities regarding the web PKI but IMHO are not related on how the
browsers (or the OS) accept a CA in their root stores or how a CA adopt
different options.
In any case, if this is important for the browser behavior document, as
said, will wait for the proposal and see where this can be added to the
trust model doc.

Iñigo Barreira

-----Mensaje original-----
De: Ben Wilson [mailto:[email-masked]] Enviado el: lunes, 09 de junio de
2014 18:24
Para: Barreira Iglesias, Iñigo; [email-masked]
CC: [email-masked]; [email-masked]; [email-masked]
Asunto: RE: [wpkops] Preliminary Next Version of Browser Behavior Draft

Iñigo,

-----Original Message-----

Hi Ben,

Regards

Iñigo Barreira

-----Mensaje original-----

Iñigo and Bruce,

of "to be expanded",
"Draft" means?
clarity on the 
me to it. :-)

---

From: Rick Andrews <[email-masked]>
Date: Tue, 10 Jun 2014 17:03:58 -0700

Ben,

I reviewed what I think is the latest draft at https://tools.ietf.org/html/draft-wilson-wpkops-browser-processing-01, not the Word doc attached to the previous message.

Section 2.1: Is it worth pointing out that root stores are not fixed? Not only can they be extended via automatic download (as you pointed out), but enterprises can add and remove roots (as often happens in Windows environments) and browser users can manually add or remove roots or modify trust bits. Document readers may not be aware of those other possibilities.

Section 2.2: It might be helpful to readers to explain here why Firefox does not do "AIA chasing". In other words, they don't see it as a missing feature; they choose to fail on incomplete chains, and a case can be made as to why this behavior is preferable to the behavior of other browsers. Or do we just want to point out differences among browsers without trying to explain why those differences exist (where we understand why)?

Section 3.1 The introduction says "This document reviews the current processing behaviors...", but this Section is full of "should"s. I suggest it needs to be rewritten to factually describe current behavior.

Section 3.4 seems speculative and not descriptive of current browser behavior.

Section 3.5 Header is not in bold.

Section 4.3 Shouldn't say "browsers should" ;^)

-Rick

From: wpkops [mailto:[email-masked]] On Behalf Of Ben Wilson
Sent: Tuesday, May 27, 2014 2:13 PM
To: [email-masked]
Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft

Here is another draft with suggested changes from Santosh accepted, and the addition of "Security Considerations" subsections, based on our discussions of May 13th.

From: wpkops [mailto:[email-masked]] On Behalf Of Ben Wilson
Sent: Tuesday, May 13, 2014 9:44 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [wpkops] Preliminary Next Version of Browser Behavior Draft

Here is a first pass through the browser behavior document that I sent to Robin and Santosh yesterday.

---

From: "Ben Wilson" <[email-masked]>
Date: Tue, 10 Jun 2014 20:41:42 -0600

Thanks, Rick.  

I can add more about the dynamic nature of some root stores to Section 2.1.

In 2.2, I wasn't sure what to say because I didn't think I should speak for
Mozilla, even though it's been explained to me that those responsible for
NSS/Firefox prefer a click through failure because it may tend to alert the
server administrator that there is a problem and they need to install a
chain properly.  In order to say that, I think someone needs to point me to
an official statement of that rationale so that I can reference it
officially.

In 3.1 and beyond, I'll make those replacements of "should" like I did above
in Section 2.   

In Section 3.4, I can tone down the security concerns a bit, but the problem
is that the statements are true in a generic sense.  Basically, I am trying
to take advice from the last telephone call we had and hit the security
concerns, e.g., "why do we care?" or, in other words, what is significant
about each particular category of behavior, and why did PKIX frame the
security design as such?  Are you saying that because I do not reveal a
specific zero-day threat that I've observed, I'm therefore precluded from
mentioning how that latent vulnerability might be exploited?  I can make it
more clear that we're addressing the generic issues and not the specifics,
if that helps.

Thanks again for your review and comments-they do help - significantly.

Cheers,

Ben

From: wpkops [mailto:[email-masked]] On Behalf Of Rick Andrews
Sent: Tuesday, June 10, 2014 6:04 PM
To: [email-masked]; [email-masked]
Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft

Ben,

I reviewed what I think is the latest draft at
https://tools.ietf.org/html/draft-wilson-wpkops-browser-processing-01, not
the Word doc attached to the previous message.

Section 2.1: Is it worth pointing out that root stores are not fixed? Not
only can they be extended via automatic download (as you pointed out), but
enterprises can add and remove roots (as often happens in Windows
environments) and browser users can manually add or remove roots or modify
trust bits. Document readers may not be aware of those other possibilities.

Section 2.2: It might be helpful to readers to explain here why Firefox does
not do "AIA chasing". In other words, they don't see it as a missing
feature; they choose to fail on incomplete chains, and a case can be made as
to why this behavior is preferable to the behavior of other browsers. Or do
we just want to point out differences among browsers without trying to
explain why those differences exist (where we understand why)?

Section 3.1 The introduction says "This document reviews the current
processing behaviors...", but this Section is full of "should"s. I suggest
it needs to be rewritten to factually describe current behavior.

Section 3.4 seems speculative and not descriptive of current browser
behavior.

-Rick

Here is another draft with suggested changes from Santosh accepted, and the
addition of "Security Considerations" subsections, based on our discussions
of May 13th. 

Here is a first pass through the browser behavior document that I sent to
Robin and Santosh yesterday.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 11 Jun 2014 10:27:11 -0400

+1

As some other have already said, the charter of the WG calls for 
documenting current
Web PKI practices, not describing what one might wish were true.

Steve
> https://tools.ietf.org/html/draft-wilson-wpkops-browser-processing-01, 
> not the Word doc attached to the previous message.
>
> Section 2.1: Is it worth pointing out that root stores are not fixed? 
> Not only can they be extended via automatic download (as you pointed 
> out), but enterprises can add and remove roots (as often happens in 
> Windows environments) and browser users can manually add or remove 
> roots or modify trust bits. Document readers may not be aware of those 
> other possibilities.
>
> Section 2.2: It might be helpful to readers to explain here why 
> Firefox does not do "AIA chasing". In other words, they don't see it 
> as a missing feature; they choose to fail on incomplete chains, and a 
> case can be made as to why this behavior is preferable to the behavior 
> of other browsers. Or do we just want to point out differences among 
> browsers without trying to explain why those differences exist (where 
> we understand why)?
>
> processing behaviors...", but this Section is full of "should"s. I 
> suggest it needs to be rewritten to factually describe current behavior.
>
> *From:*wpkops [mailto:[email-masked]] *On Behalf Of *Ben Wilson
> *Sent:* Tuesday, May 27, 2014 2:13 PM
> *To:* [email-masked]
> *Subject:* Re: [wpkops] Preliminary Next Version of Browser Behavior Draft
>
> and the addition of "Security Considerations" subsections, based on 
> *From:*wpkops [mailto:[email-masked]] *On Behalf Of *Ben Wilson
> *Sent:* Tuesday, May 13, 2014 9:44 AM
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* [wpkops] Preliminary Next Version of Browser Behavior Draft
>