I'd offered to review this version during the TLS session at IETF 78,
but I think I'm going to wait for the next version ;)
spt
Wes Hardaker wrote:
I've reviewed draft-saintandre-tls-server-id-check-09 and find it a good
document and support it's forward progress. I do have a few comments
though:
(*):
Applies to many of the comments below: some parts of the document
read like a BCP in the way it tries to rationalize things. A number
of these text sections really don't help the document, though, as it
adds unneeded ambiguity. Examples of this are marked below with (*).
Section 1.1: (*)
I don't think you should be spelling out the popularity of TLS vs
DTLS. While it may be true today, this is intended to be a proposed
standard and thus doesn't need to specify that one is potentially more
popular than the other. The document should be targeting the use of
both regardless of how well DTLS is used at the moment. Suggested:
OLD:
When a client connects to an
application services using Transport Layer Security [TLS] (or, less
commonly, Datagram Transport Layer Security [DTLS]), it references
some conception of the server's identity while attempting to
establish a secure connection (e.g., "the web site at example.com").
New:
When a client connects to an
application services using Transport Layer Security [TLS] or
Datagram Transport Layer Security [DTLS], it references some
conception of the server's identity while attempting to establish a
secure connection (e.g., "the web site at example.com").
Section 1.1 and the appendices:
You could now, if you wanted, add SNMP over (D)TLS: RFC5953. If
you're going to copy into the appendix as well, the text to copy is
from the snmpTlstmAddrTable object in that document.
Section 1.3.2: (*)
This section is full of text that is subjective and really isn't
needed in the first place. Nearly every paragraph contains text that
may be true today but might not be in the future or is subject to
interpretation. While I agree with most of the conclusions, I don't
think it's worth putting the text into the document; especially when
the text is simply defining what's out of scope. I don't think you
need to spend effort rationalizing what's out of scope.
Suggestion: keep the bullets, ditch the paragraphs.
Phrasing examples (IE, an incomplete list) that are questionable:
"service operators have less experience with client certificates"
"Most fundamentally, most users find DNS domain names much easier to
work with than IP addresses, which is why the domain name system was
designed in the first place.
"Furthermore, application technologies have less experience with
IPsec than with TLS, thus making it more difficult to gather
feedback on proposed best practices."
Section 1.4, "Target Domain"
It took me far too long into reading this document to remember what a
"target domain" really meant. IMHO, a better term that already
conveys the proper meaning to most readers would be a "derived
domain". Think about a global search and replace for target->derived?
Section 3, bullet 5:
Unfortunately, this is the one rule I think will be
broken the most often. Fortunately, checking from the client side
says to ignore the CN-ID if it can match on other things as well.
Because of this, the only thing this particular rule hurts is the
software that isn't going to conform to this document because the code
is already too old. It's basically a "should upgrade" statement. I
think an extra sentence here might be helpful, though I don't have a
suggestion at the moment.
Section 4.3, security note:
I actually think wording these things is tricky when the future is
unknown. I think it's generally safer to describe the only conditions
which are valid for checking a CN-ID instead of trying to list all the
"MUST NOT" cases, which is more likely to change with the addition of
future specs into the spec tree. I didn't have time to fully think
out replacement text, but I'd start it with "A client MUST only seek a
match for a reference identifier of a CN-ID if it is the only
available presented identifier." Or something like that.
Section 5, Security Considerations:
The interesting thing about this specification is that we're leaving a
fairly broad range of potential "success" matches. Not only that, but
future specifications may lead to future reference identity matches
that previously didn't work. Fortunately, I can't come up with an
example that works all that well to describe it but somehow I'm left
feeling nervous that a server cert could have a clause the clients
don't understand currently but might later after a software upgrade
and an admin that expects a failure may suddenly see a success. You
can ignore this paragraph if you fail to grasp what I'm trying to say,
as I'm not at all stating it well.
Section 5.1, Service Delegation:
You discuss interactive clients and how the the source domain name
MUST be provided by a human user. But the odd case that I couldn't
figure out what it mapped to was references from an original source.
EG, images or javascript elements in a web page aren't "provided by
the user", but a web-browser is certainly interactive. This sort of
"snow ball" domain list probably should be discussed at least in
brief.
Section 5.1, Service Delegation:
I read the last paragraph (which is one sentence) multiple times and I
only barely feel that I understand what it's saying. I'd suggest
rewording it for clarity and splitting it into multiple sentences.
I'd offer suggestive text, but then I'd prove that I really didn't
understand it.
General:
Some of the possible combinations and options that may exist could
really use an "examples" section or something that had example info
from a certificate combined with example list of expected reference
indenties. Though this would be nice, it's not at all critical.
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf