Eran,
#145: Section 9.2 (TLS clients) needs more guidance for browsers
Comment ([email protected]):
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?
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.
If so, we can remedy these particular points. However,my understanding is
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.
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.
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.
For this reason I think that the proposed text in comment 1 about browsers
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?
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?
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
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
