Subject: Re: [Trans] [trans] #77 (rfc6962-bis): normative client behavior specified in Section 5

From: "trans issue tracker" <[email-masked]>
Date: Mon, 06 Jul 2015 12:39:54 -0000

#77: normative client behavior specified in Section 5

Changes (by [email-masked]):

 * milestone:   => review

Comment:

 What has been ruled out of scope is what action clients take, not how they
 conform to the protocol.

 Suggest close wontfix.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-trans-
  [email-masked]           |  [email-masked]
     Type:  defect       |      Status:  new
 Priority:  major        |   Milestone:  review
Component:  rfc6962-bis  |     Version:
 Severity:  -            |  Resolution:
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/77#comment:2>
trans <http://tools.ietf.org/trans/>

---

From: Stephen Kent <[email-masked]>
Date: Mon, 06 Jul 2015 14:33:44 -0400

I see your point. 6269-bis is mostly a document specifying the
operation and interface to the log. Other parts of the document attempt to
describe how clients interact with the log, but they do so only 
superficially.
That's why I believe we need additional document specifying the behavior
of the other elements of the CT system.

You refer to "the protocol" but don't indicate which protocol you have 
in mind.
I might agree that specs for TLS client behavior in the context of TLS 
exchanges
are in scope. If so, 6269-bis needs to state that it updates TLS.

Your interpretation of the WG's agreement to expunge client behavior 
from 6269-bis
seems to encompass only the issue of whether a client rejects or accept 
a cert
accompanied by a (valid) SCT. That strikes me as rather narrow.

If a client that claims CT compliance MUST perform a series of checks to 
verify
CT compliance of a cert, what does the client do if any of these tests 
fail? It's
not useful to require a set of checks to be performed and yet not 
indicate what
happens if they fail. If no action is required, then why bother 
performing the checks?
If some action is required, or even recommended, then a spec needs to 
state what that
behavior is.

Steve

> Changes ([email-masked]):
>
>   * milestone:   => review
>
>
> Comment:
>

---

From: Ben Laurie <[email-masked]>
Date: Tue, 7 Jul 2015 14:45:09 +0100

On 6 July 2015 at 19:33, Stephen Kent <[email-masked]> wrote:
> You refer to "the protocol" but don't indicate which protocol you have in
> mind.
> Your interpretation of the WG's agreement to expunge client behavior from
> 6269-bis
> seems to encompass only the issue of whether a client rejects or accept a
> cert
> CT compliance of a cert, what does the client do if any of these tests fail?
> It's
> not useful to require a set of checks to be performed and yet not indicate
> what
> happens if they fail. If no action is required, then why bother performing
> the checks?
> If some action is required, or even recommended, then a spec needs to state
> what that
> behavior is.

To restate our position on this: we don't know what clients will do in
response to failure to comply with CT, and nor are we in a position to
mandate it. We feel it is helpful to provide a mechanism by which the
issuance of certificates can be made open to public scrutiny. Clearly
adoption of this mechanism does ultimately require that clients behave
somehow differently for certificates that do not conform, but we can't
dictate what that behaviour is.

For example, right now, the only client I know of that reacts to CT is
Chrome/Chromium, and the behaviour it (at least for Chrome - Chromium
comes in multiple flavours) currently exhibits is that text in some
dialogues is changed depending on whether CT is present and meets
Chrome's policies or not, and in the display/non-display of the EV
indicators for EV certificates. This behaviour has already been
through several versions and policy changes, and will continue to
evolve - and is not arrived at by IETF consensus, nor will it ever be.
So, I don't see how it can be a part of the I-D.

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

---

From: Stephen Kent <[email-masked]>
Date: Fri, 10 Jul 2015 10:23:59 -0400

Ben,

> ...
> To restate our position
first issue: does "our" = Google or just the authors of this document?
> on this: we don't know what clients will do in
> mandate it.
I agree with the last part of this statement, irrespective of the identity
of the "our" above.
> We feel it is helpful to provide a mechanism by which the
> issuance of certificates can be made open to public scrutiny.
that is clearly the premise of CT, yet absent a detailed analysis of how
transparency improves security, the premise is unsubstantiated.
>   Clearly
maybe, maybe not. I'll await your comments on the new intro for the
attack model. In that text I make some observations about the importance of
browser behavior in the CT system.
> evolve - and is not arrived at by IETF consensus, nor will it ever be.
nice of you to reaffirm that Google doesn't care about IETF standards
in this context.
> So, I don't see how it can be a part of the I-D.
I agree that client responses to the presence or absence of an SCT
ought not be part of your document. Your document is really a spec for
CT log behavior and it should be retitled as such.

A CT architecture doc is needed, consistent with what has been done for
many IETF security area systems of this scale. The attack model I've been
working on is also a common element of an RFC suite for a security system
with this many moving parts. Descriptions of how a Monitor works, including
its relationship to logs and to Subjects, is needed. The audit function 
needs
to be defined precisely if there is to be claim that CT can detect 
misbehavior
by logs. Finally, the behavior of clients, in terms of what checks they 
perform
on certs accompanied by SCTs, and whether they discriminate against 
certs w/o SCTs.
also seems to be  an essential element of a complete system description.

You argue that CT "... does ultimately require that clients behave 
somehow differently
for certificates that do not conform." Yet you note that Google has not 
yet figured
out what thus discriminatory behavior should be. Maybe this means that 
the CT design
is not yet adequately mature, and thus it ought not move from 
experimental, yet.

Steve

---

From: Ben Laurie <[email-masked]>
Date: Fri, 10 Jul 2015 15:38:19 +0100

> first issue: does "our" = Google or just the authors of this document?

Google.

> nice of you to reaffirm that Google doesn't care about IETF standards

Does _anyone_ care about IETF standards when it comes to UI?

> on certs accompanied by SCTs, and whether they discriminate against certs
> w/o SCTs.
> You argue that CT "... does ultimately require that clients behave somehow
> differently
> for certificates that do not conform." Yet you note that Google has not yet
> figured
> out what thus discriminatory behavior should be. Maybe this means that the
> CT design
> is not yet adequately mature, and thus it ought not move from experimental,
> yet.

If you believe that, then we should move all TLS documents to
experimental, since they are in exactly the same position.

---

From: Rob Stradling <[email-masked]>
Date: Fri, 10 Jul 2015 15:47:32 +0100

>> first issue: does "our" = Google or just the authors of this document?

FWIW, since I'm not a Googler but I am one of the authors of this 
document, let me just state that I also agree with this position.

<snip>
> Does _anyone_ care about IETF standards when it comes to UI?

Has IETF ever actually published any standards relating to web browser UI?

Let me just note that CABForum has no influence over Chrome's UI either, 
so please don't feel that IETF is being ignored any more than any other 
standards organization.  ;-)

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Melinda Shore <[email-masked]>
Date: Fri, 10 Jul 2015 07:50:27 -0800

> nice of you to reaffirm that Google doesn't care about IETF standards

Steve, this kind of commentary really needs to stop.

Melinda

---

From: Stephen Kent <[email-masked]>
Date: Tue, 14 Jul 2015 10:35:28 -0400

Melinda,

Or, conversely, you could chastise Ben for making offensive statements 
about
Google's "position" in his posting.

I observe that Ben's reply to my question about the "our" in his message 
is that
he was stating Google's position.

Since the IETF ethos calls for us to participate as individuals, and 
since Ben
appears to be trying use Google's stature in supporting a technical 
argument,
where is the criticism of his statement?

Also, I have never seen _any_ vendor make a statement on an IETF list in 
which they
openly say that their development plans are not influenced by whatever IETF
standards may arise.  I don't doubt that many vendors feel and act this
way, but they usually don't flaunt their intent. The issue here isn't 
whether
browser UI details are appropriate fodder for IETF standards, but rather 
whether
Google staff should make stark statements like this in the context of an 
IETF WG
discussion.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 14 Jul 2015 10:38:09 -0400

Rob,

> Has IETF ever actually published any standards relating to web browser 
rejecting a cert, as the doc in question has previously mandated (as 
recently as the -05 version),
is not  just a UI issue, IMHO. It's protocol behavior and, as I noted 
last year, it's
protocol behavior that requires a plan to deal with incremental deployment.

Less severe forms of discrimination against certs not accompanied by an 
SCT may fall
under the browser UI heading, and that they are not subject to IETF 
standardization.
> Let me just note that CABForum has no influence over Chrome's UI 
> either, so please don't feel that IETF is being ignored any more than 
> any other standards organization.  ;-)
I'm quite willing to believe that Google believes it decisions are not 
subject to
influence by any standards body, country, etc. ;-)

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 14 Jul 2015 10:38:29 -0400

Ben,

> On 10 July 2015 at 15:23, Stephen Kent<[email-masked]>  wrote:
>> Ben,
>>
>>> ...
>>> To restate our position
That's what I thought, but thanks for the clarification.
> Does _anyone_ care about IETF standards when it comes to UI?
Previous versions of your doc (as recent as the -05 version) have called 
for a TLS
client to reject a cert that was not accompanied by an SCT. Do we agree 
that such
an action is not just UI behavior, since it would cause a session to 
(hard) fail?
If a TCP spec dropped  a connection because of a newly-specified, not 
backward
compatible mandate would you assert that that too is a UI issue?
> experimental, since they are in exactly the same position.
I agree that most browser UI details are outside the scope of TLS 
standards.
However, TLS 1.2  requires that a session be closed and not resumed in
the face of fatal error alerts. Examples of fatal error alerts (Section 
7.2.2)
include certs of "unsupported type", any failure of cert validation 
processing,
revoked certs, unknown CA, etc. So, TLS does mandate some aspects of 
browser
behavior that will be visible to the user, and some of the triggers for 
mandated
hard session failure are consistent  with text previously proposed for 
missing SCT
info (as recent as the -05 version of 6952-bis).

Steve

---

From: Paul Wouters <[email-masked]>
Date: Tue, 14 Jul 2015 10:57:12 -0400 (EDT)

On Tue, 14 Jul 2015, Stephen Kent wrote:

Steve,

> Or, conversely, you could chastise Ben for making offensive statements about
> I observe that Ben's reply to my question about the "our" in his message is that
> Since the IETF ethos calls for us to participate as individuals, and since Ben
> appears to be trying use Google's stature in supporting a technical argument,

While Ben could have made it clearer that he was speaking without his RFC
document author hat on, he did clarify that later on. It is perfectly
reasonable for any participant to explain why their current $dayjob
would or would not be happy or violate/not violate certain protocol bits
under discussion. In fact, such information is useful and can lead to
participants opening up to further discussion and reaching new compromises.
In the end, we would end up with more interoperable implementations from
different vendors.

In my view, Ben's remark were not "offensive", "flaunting" or "stark".

> Also, I have never seen any vendor make a statement on an IETF list in which they
> way, but they usually don't flaunt their intent.

This is a very subjective view on your end. It is fine if Ben wants to
clarify the position of his $dayjob vendor.

> The issue here isn't whether
> browser UI details are appropriate fodder for IETF standards, but rather whether
> Google staff should make stark statements like this in the context of an IETF WG
> discussion.

I hope that Ben continues to explain the views of Google on various
protocol bits. I am also confident that Ben can keep his document author
hat and $dayjob hat apart. If the working group feels that Ben can no
longer do this, we can think about adding another author/editor to this
document, provided we can find a volunteer.

> Steve, this kind of commentary really needs to stop.

I concur.

Paul

---

From: Robin Wilton <[email-masked]>
Date: Tue, 14 Jul 2015 15:14:14 +0000

<top-posting intentional>

I hadn’t meant to comment on this further, after Melinda intervened. However, since the issue has come up again, I offer the following observation:

The number of people who follow/lurk on this list is, I am sure, much larger than the number who are active on it.

Those who are active should, I suggest, be conscious of the effect the tone of the discussion can have on the wider audience. I would not be at all surprised if there were potential contributors who have been discouraged from taking part, because the to-and-fro can appear adversarial beyond what is needed to express and test technical hypotheses.

Respectfully,
Robin

Robin Wilton
Technical Outreach Director - Identity and Privacy
Internet Society

email: [email-masked]
Phone: +44 705 005 2931
Twitter: @futureidentity

---

From: Rob Stradling <[email-masked]>
Date: Tue, 14 Jul 2015 17:27:03 +0100

On 14/07/15 15:57, Paul Wouters wrote:
<snip>
> hat and $dayjob hat apart.

+1

> If the working group feels that Ben can no

Is there an upper limit on the number of authors/editors that an I-D/RFC 
can have?

6962-bis currently has 5 authors/editors.  I've heard it said that 
there's a rule (which is unofficial but which is enforced) that 5 is the 
maximum.

---

From: Rob Stradling <[email-masked]>
Date: Tue, 14 Jul 2015 23:03:12 +0100

On 14/07/15 15:38, Stephen Kent wrote:
> recently as the -05 version), is not  just a UI issue, IMHO. It's protocol
> behavior and, as I noted last year, it's protocol behavior that requires a
> plan to deal with incremental deployment.
>
> SCT may fall under the browser UI heading, and that they are not subject to
> IETF standardization.

I agree that rejecting a cert is protocol behaviour.

However, I'm expecting that the "incremental deployment" will only 
involve "less severe forms of discrimination".  Only once the 
"incremental deployment" is complete are we likely to see web browsers 
starting to reject certs that are not accompanied by SCT(s), IMHO.

And clearly there's no need for a plan that would only be needed once 
there's no longer any need for a plan.  ;-)

---

From: Stephen Kent <[email-masked]>
Date: Mon, 20 Jul 2015 16:20:53 +0200

Rob,

I'm glad we agree that rejecting a cert is protocol behavior, not just a 
UI issue.

We can't assume that incremental deployment will ever be "complete."  
I've been
told by one major browser vendor that they like the logging and Monitor 
aspects
of CT, but do not see browser behavior as a critical element. Thus they do
not plan to make their browsers reject certs (maybe not even 
discriminate) based
on the lack of an SCT.

Given the history of browser behavior wrt cert revocation status 
checking, this
is not a surprising perspective.

Steve