Ben,
I agree that the phrase "client behavior" is too broad. But, I also
think that not all of what
a client does in the lack of valid CT info is strictly a UI issue.
For example, Eran noted that the architecture doc distinguishes
between what a client does in the absence of an SCT vs. what
it does if there is an SCT but the sig fails. This, IMHO, is a
legitimate protocol issue that the
WG has not addressed. David took a position on this in his
browser spec, but that's just an
initial proposal that needs to be reviewed and discussed by the
WG. However, at least the issue is
clearly stated in that doc and thus provides a basis for discussion.
Other client behaviour, such as following the protocol, is _not_
out of scope for 6962-bis. Indeed, it seems counter-productive to
remove it, since that's the document implementers have to
actually read in order to implement CT. It makes no sense to
define one side of a protocol in one document and the other in
another.
If 6962-bis were a complete spec for CT, then I would agree that it
should specify all
protocol aspects of behavior for clients, CAs, Web Servers, Monitors,
and Auditors. But, the
architecture document and the companion requirement specs for the
CA/Subject, Monitor/Auditor
and Browser/vendor illustrate that 6962-bis is far from a comprehensive
requirements spec.
...
Well, the reason this whole conversation started is because I don't
believe the IETF is in a position to say what clients should do, which
is why the language above is not normative (and appears in the
introduction, so it seems pretty obvious to me it is explanatory in
nature), and why I have very little interest in a client spec that
says more than how to process CT information and what it means - which
should be specified in 6962-bis.
I have a problem deciding what is in and out of scope when you use
phrases like "what clients should do."
I believe an well-written spec for CT should make clear exactly what is
mandated and what is a local
policy decision for a TLS client (as well as for other CT system
elements). I find the text in 6962-bis
to be inadequate in this regard. If you read
draft-dseomn-trans-browsers-00.txt you'd see what I view
as an appropriate level of specification for an IETF standard. The
example I cited about differences
in how a browser should react to a missing SCT vs. an invalid SCT is a
good example of what I view
as within scope when specifying a protocol. Note that I have not said
anything about the ability
of a browser to discriminate against a cert with no accompanying SCT in
terms of the UI. The browser
spec I mentioned specifically says that is a local matter.
Similarly vague text appears elsewhere, e.g.,
Since certificates may not be accepted by TLS clients unless
logged, ...
How could that be less vague? That is the reality of the situation...
This is a good example of where we seem to disagree about what
constitutes appropriate language for a standards track RFC. I have long
argued that it is unacceptable for browsers to reject a cert because
it is not accompanied by an SCT, until there is a backwards compatible
transition mechanism codified
in an RFC. Your stance appears to be that what a browser does in this
regard (which I consider a
basic protocol issue that should be in scope) is not subject to IETF
standardization, and hence it's
OK to use deliberately vague phrases. We have a fundamental disagreement
here.
...
Whether you need an STH depends on what you are trying to do. TLS
clients may or may not need STHs, depending whether they care about
verifying proofs... the I-D does explain when STHs are needed...
I still view the text as needlessly ambiguous. Again, please look at the
requirements specs we posted
in late December as examples of how to be clear in this regard.
Since the next sentence refers to "marking clients" a reader may
infer that TLS clients
are required to acquire STHs. This is a more subtle issue than
suggested by this text.
A reader would be wrong to infer that, the point is that STHs could be
used to mark individual clients, TLS or otherwise. Which is what the
text says.
The text also strikes me as needlessly vague.
I have authored about 25 RFCs, 18 of which are standards track, and 3 or
4 of which are BCPs.
I think my experience in this regard makes me a good judge of what
constitutes a well-written,
standards track security area RFC. I'm sorry to say that 6962-bis (v-11)
is not.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
