Subject: Re: [Trans] [trans] #145 (rfc6962-bis): Section 9.2 (TLS clients) needs more guidance for browsers

From: "trans issue tracker" <[email-masked]>
Date: Mon, 07 Mar 2016 12:15:24 -0000

#145: Section 9.2 (TLS clients) needs more guidance for browsers

Comment (by [email-masked]):

 My understanding of the original problem raised in the ticket is that the
 section on TLS clients is vague/confusing because it prescribes some
 actions but not the results of these actions, is that right?
 For example that TLS clients MUST reject an SCT whose timestamp is in the
 future, but not what it implies for a client to have rejected this SCT. Is
 this understanding accurate?

 If so, we can remedy these particular points. However,my understanding is
 that prescribing client behaviour is outside the scope of 6962-bis.

 Regarding the focus on browsers, I disagree: A significant portion of
 traffic nowadays is from native mobile applications which rely on SSL+PKI
 for securing their connections, but are not browsers. Such an application
 can decide to hard-fail a connection if no valid SCTs are present, for
 example, because that particular application communicates with a small set
 of servers, all of which are expected to serve SCTs.

 For this reason I think that the proposed text in comment 1 about browsers
 and incremental deployment is not applicable.

 I have proposed re-wording of the example provided, of SCTs with timestamp
 in the future, here:
 https://github.com/eranmes/certificate-transparency-
 rfcs/commit/c643193aeea93afe57baf7a63589fa5ec4cf5d6e

 Does that address at least that case?

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

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

---

From: Stephen Kent <[email-masked]>
Date: Thu, 10 Mar 2016 18:08:27 -0500

Eran,

> Comment ([email-masked]):
>
That's a pretty good summary. Another way to look at this issue is that
the way the text reads, a black box analysis of a TLS client cannot
determine if the client complies with the spec. In general, it's a bad
idea to state requirements that cannot be verified.
>   that prescribing client behaviour is outside the scope of 6962-bis.
unfortunately, the text tries to have it both ways, i.e., it specifies
some level of client behavior using the term "compliant" yet it avoids
requiring any specific behavior by the client. That's not helpful.
>   of servers, all of which are expected to serve SCTs.
I agree that non-browser TLS clients are becoming more important. But, they
need not rely on the Web PKI model that browsers use. You postulated a
scenario in which a TLS client communicates with a small set of servers
and is configured to know that all of them are expected to provide SCTs.
You are describing something that is not, AFAIK, described in any extant
RFC. Thus its questionable to make CT TLS client specs vague by citing
such client scenarios. I believe almost all of the discussions in TRANS
have focused on browsers. Certainly the Auditor proposal seesm to be 
very-much
focused on browsers interacting with web servers. Thus I don't agree 
with the
suggestion that the TLS client discussion should be considered generic, 
e.g.,
in order to make statements about non-proscriptive behavior less specific.
>   and incremental deployment is not applicable.
I recall the meeting in London where I raised the issue about incremental
deployment, in response to the text in the (then current) version of 
6962-bis.
That text called for a TLS client to reject certs not accompanied by SCTs.
Ben's response was to declare that this aspect of client behavior was out
of scope for 6962-bis. So, now there's a new, different reason for sort-of
specifying client behavior without really specifying it?
>   Does that address at least that case?
I don't read github posts of proposed text. I read I-Ds when they are 
posted,
or text sent to the list, the common methods for IETF WG discussions of
suggested text for I-Ds.

Steve

---

From: Rob Stradling <[email-masked]>
Date: Fri, 11 Mar 2016 10:27:43 +0000

On 10/03/16 23:08, Stephen Kent wrote:
<snip>
> posted, or text sent to the list, the common methods for IETF WG
> discussions of suggested text for I-Ds.

Hi Steve.  FWIW, I would classify GitHub as a "common method" these days...

https://www.ietf.org/mailman/listinfo/ietf-and-github

"About Ietf-and-github	
GitHub is being used by more IETF Working Groups for proposing and 
tracking changes to WG Internet-Drafts. Using GitHub for normal WG 
processes requires some training, and edge cases in its usage abound. 
This list will be used for answering questions of individual WG 
participants and for creating IETF-wide documentation on how to use 
GitHub effectively in WG processes."

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

---

From: Robin Wilton <[email-masked]>
Date: Fri, 11 Mar 2016 12:44:46 +0000

>> discussions of suggested text for I-Ds.

Hmm. As someone who has just sent a revision-marked draft to an IETF mailing list (in proprietary file format, too, I’m ashamed to say), I was somewhat worried about the potential for confusion if someone else happened to be editing another copy of it at the time.

If Github offers ways to help with version control on collaborative docs, I think that is to be encouraged.

R

> GitHub is being used by more IETF Working Groups for proposing and tracking changes to WG Internet-Drafts. Using GitHub for normal WG processes requires some training, and edge cases in its usage abound. This list will be used for answering questions of individual WG participants and for creating IETF-wide documentation on how to use GitHub effectively in WG processes."
> 
> --
> Rob Stradling
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans

---

From: Rob Stradling <[email-masked]>
Date: Fri, 11 Mar 2016 15:02:25 +0000

On 11/03/16 12:44, Robin Wilton wrote:
<snip>
> If Github offers ways to help with version control on collaborative docs, I think that is to be encouraged.

Yes!

---

From: Melinda Shore <[email-masked]>
Date: Fri, 11 Mar 2016 08:24:40 -0900

> discussions of suggested text for I-Ds.

That's certainly your prerogative, but git is a very
widely used tool, Github is free, Github requires no
knowledge of git (it's a point-and-click interface),
and using a publicly-hosted versioning system provides
more transparency, not less.

Because of this we will tend to discount objections
you've raised based on your unwillingness to look at
revised text for which the link has been posted.

Melinda

---

From: "trans issue tracker" <[email-masked]>
Date: Mon, 14 Mar 2016 12:15:14 -0000

Steve Kent replied on the list, attempting to summarize his response:
 - It should be possible to do a black-box analysis of a TLS client to
 determine if it's CT compliant. So prescribing requirements that can't be
 verified is a bad idea.
 - He does not agree that with the suggestion that the TLS client
 discussion should be considered generic (i.e. not specific to browsers).
 - He claims that "now there's a new, different reason for sort-of
 specifying client behavior without really specifying it?". (I don't fully
 understand why this argument is made).

 Based on his reply I will push the change mentioned in comment #2 for
 review, which will address the first issue.

 As for the other issues they are broader and I will leave them for
 discussion on the mailing list.
 My opinion is that any browser-specific guidance provided in this RFC
 should be non-normative, since there are real-world scenarios where
 6962-bis could be applied to non-browser TLS clients. But I really don't
 see the point of suggesting any behaivour to browsers - they're perfectly
 capable of figuring out themselves what to do once CT compliance/non-
 compliance has been established.

Ticket URL: <https://trac.tools.ietf.org/wg/trans/trac/ticket/145#comment:3>
trans <https://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Mon, 14 Mar 2016 12:16:17 -0000

Out for review in https://github.com/google/certificate-transparency-
 rfcs/pull/134.

Ticket URL: <https://trac.tools.ietf.org/wg/trans/trac/ticket/145#comment:4>
trans <https://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Mon, 14 Mar 2016 12:16:33 -0000

Changes (by [email-masked]):

 * owner:  [email-masked] => [email-masked]

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

Ticket URL: <https://trac.tools.ietf.org/wg/trans/trac/ticket/145#comment:5>
trans <https://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Wed, 16 Mar 2016 15:21:16 -0000

* milestone:   => review

Comment:

 Merged as https://github.com/google/certificate-transparency-
 rfcs/commit/0dfa4a4f30fbfedd259eceae5a067f60904fae65
 Please review.

 Priority:  major         |   Milestone:  review

Ticket URL: <https://trac.tools.ietf.org/wg/trans/trac/ticket/145#comment:6>
trans <https://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Wed, 16 Mar 2016 15:30:11 -0000

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => fixed

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

Ticket URL: <https://trac.tools.ietf.org/wg/trans/trac/ticket/145#comment:7>
trans <https://tools.ietf.org/trans/>