On Tue, Jun 10, 2014 at 07:24:30PM -0600, Peter Saint-Andre wrote:
> Matt Miller and I submitted a new version of draft-ietf-dane-srv today.
Thanks. A few comments:
Section 2:
The reference to "secure", "insecure", "bogus", "indeterminate"
was changed to refer to RFC 4033, from 4035, but in fact it is 4035
that gives the intended definition of "indeterminate" (failure
to determine, a lookup error). See the SMTP draft, section 2.1.1
Section 3.1:
If a particular response is "bogus" or "indeterminate" according
to DNSSEC validation, the client MUST ignore that target server
host name.
This glosses over two distinct cases:
* The SRV RRset is "bogus", "indeterminate" (or some other
lookup error, feel free to borrow/steal section 2.1.1 from
the SMTP draft). In this case NONE of the SRV server names,
if any were actually obtained, can be used.
* The SRV RRset is secure, but downstream lookups for A or TLSA
records fail...
The quoted comment more properly applies to the second case, but
you've not yet reached that point in the discussion. The immediately
preceding text is about the initial SRV lookup, and if that fails,
ALL the SRV records are bad, and the service is unreachable.
So it seems that the original text was more appropriate:
Section 4.1:
This section is confusing because it is not clear that the opening
paragraph established preconditions for the rest of the section.
The first paragraph should say something like:
"In this section we consider the case that, ... The case with
TLSA usable/secure records is considered in the next section, ..."
> We have a few questions for the WG...
> 1. In Section 4.1, we discuss how to proceed if there are no TLSA records,
> only SRV records. This section assumes that the presented certificate is a
> "traditional" PKIX cert. Therefore we do not take into account raw public
> keys as specified in draft-ietf-tls-oob-pubkey. Do folks here think we need
> to address, or at least mention, the raw keys case?
Without TLSA records any out of band authentication of "RPK" material
is not via DANE, it is not clear whether anything generally useful
can be said about this. However, even without RPK, opportunistic
TLS clients may simply skip authenticating the server entirely (as
with SMTP), and so a general requirement to authenticate is too
strong.
Rather I think you should specify which reference identifiers to
use *IF* the client is using PKIX, without mandating the use of
PKIX.
> 2. Also in Section 4.1, we say:
>
> SRV is secure: The reference identifiers SHALL include both the
> service domain and the SRV target server host name (e.g., include
> both "im.example.com" and "xmpp23.hosting.example.net"). The
> target server host name is the preferred name for TLS SNI or its
> equivalent.
>
> In the latter case, the client will accept either identity to ensure
> compatibility with servers that support this specification as well as
> servers that do not support this specification.
>
> Remember that the reference identifiers are what the client uses when
> determining if the certificate is acceptable (cf. RFC 6125). The reasoning
> here is that if the client allows only the target server host name as a
> reference identifier then it won't be able to connect to older servers that
> don't yet support dane-srv, whereas if it allows only the source domain as a
> reference identifier then it won't be able to connect to newer servers that
> support only dane-srv. For the sake of interoperability, supporting both
> seems like the best approach. Does that justify the SHALL here? And is this
> the best place in the document for this information?
I think the requirement is justified, provided the client is doing
PKIX. I have no concrete opinion about document organization.
The document still feels a bit "raw" overall, if you have cycles to
re-read it with care, and polish it further, it would likely help.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
