Ben,
On 10 July 2015 at 15:23, Stephen Kent<[email protected]> wrote:
Ben,
...
To restate our position
first issue: does "our" = Google or just the authors of this document?
Google.
That's what I thought, but thanks for the clarification.
...
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.
nice of you to reaffirm that Google doesn't care about IETF standards
in this context.
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?
...
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.
If you believe that, then we should move all TLS documents to
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
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
