On Tue, Mar 26, 2013 at 09:48:11AM -0400, James Cloos wrote:
> >>>>> "VD" == Viktor Dukhovni <[email protected]> writes:
>
> VD> I take it you read the phrase "with any certificate matching the
> VD> TLSA record... " to mean that such a certificate must come from the
> VD> server in the server SSL HELO.
>
> Yes, but I should have written something more like "in the HELO or in
> the client's trust store"; any case where a type 0 can work also should
> work with a type 2 pointing at the same cert.
I must not be making my question clear enough. The "or in the
client's trust store case" is NOT an option for any of the "2 x y"
forms. The domain owner is not psychic, and must not be given the
freedom to divine what may or may not be in the trust stores of
every plausible client.
Yes, I have code that supports the DNS unfriendly "2 0 0" and I'll likely
keep it in place, although I am also considering disabling it by default.
The deeper problems are:
- "2 x [12]" are too fragile to support in any implementation that
commits *verify* the peer's certificate or else drop the connection.
If we're proceeding opportunistically without dropping the connection,
what's the point of DANE?
Unless the certificate in sure to be in hand, that is unless
it is REQUIRED (MUST, no excuses) to be provided in the
server's SSL HELO, I cannot make TLS certificate *verification*
mandatory for a connection to a "2 x [12]" endpoint". Since
usage "2" supports private CAs, there is NO presumption that
clients already have the TA cert, so the RFC has to mandate its
presence in the server SSL HELO chain.
If this is not clearly required by 6698, server operator
practices will vary on this point, and I must then treat all
"2 x [12]" TA associations as "unusable".
- In addition, "2 1 0" is also unusable if PKIX means "issued and
signed by the TA", and not just "signed by the TA". Which is it?
Is 6698 relaxing 5280 on this point? My reading of 5280 is that
they mean "issued", and TAs must have a subject name for that purpose.
If that's not what 5280 means, DANE should specify the "signed by is
sufficient" interpretation, or else MANDATE that the peer
present the TA certificate after the server SSL HELO reply.
- Without a MANDATE to include the TA in the server's configured
SSL trust chain, it turns out that the *only* "2 x y" case I can
implement robustly, but hesitantly, since I'm endorsing bad DNS
hygiene in doing so, is "2 0 0".
Since for SMTP I must also read "0 x y" as "2 x y", and I am guessing
that this group will not agree to language in 6698 or related
standards that also MANDATES the TA certificate in the server's
SSL certificate chain (sent by the server itself, not optionally
found by the client), I have to treat all "0 x y" associations
other than "0 0 0" as unusable. I am also inclined to treat "0 0
0" as unusable in order to promote "DNS hygiene".
I cannot encumber Postfix users with a feature that routinely makes
email sit in queues for spurious reasons. Can the group clarify the
RFC 6698 requirements with respect to the content of the SSL "server
certificate" message:
https://tools.ietf.org/html/rfc2246#section-7.4.2
Structure of this message:
opaque ASN.1Cert<1..2^24-1>;
struct {
ASN.1Cert certificate_list<0..2^24-1>;
} Certificate;
certificate_list
This is a sequence (chain) of X.509v3 certificates. The sender's
certificate must come first in the list. Each following
certificate must directly certify the one preceding it. Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate which specifies the
root certificate authority may optionally be omitted from the
chain, under the assumption that the remote end must already
possess it in order to validate it in any case.
The part starting with "Because certificate validation..." is clearly
cast in a new light by DANE with associations that specify TA digests.
Where/what is the normative language in 6698 that refines this requirement
for server operators (and domain owners) who choose to publish DANE
TLSA associations?
> VD> If I squint hard enough, I can read it the same way, but I could
> VD> also suppose that the PKIX validation path in question was in part
> VD> constructed by the verifier, and so no explicit requirement for the
> VD> server to provide the certificate.
>
> I did forget the other day, as I wrote above, the case where the type 2
> points at a cert in the client's store.
>
> Since you wrote that, after all, you wrote the code to handle the type 2
> case where the cert isn't in the local store or in the HELO, I have to
> say "working code beats word lawyering".
>
> I think it would have been OK to skip the extra code for those possibil-
> ities, using the language in the RFC as an excuse. But since you wrote
> it anyway, use it.
Yes, I have code that handles "2 0 0" and "0 0 0" out-of-band, but
I'd much rather not need it, it brings-in dependencies on low-level
primitives (X509 signature checks) from OpenSSL's libcrypto that
I'd rather not introduce.
For the same implementation complexity price, I also have code that
handles "2 1 0" and "0 1 0", but only if "issued by" is to be taken
to mean "signed by".
I have no code that can deal with "2 x 1" or "2 x 2" unless there
is clear language in 6698 that mandates the corresponding TA in the
server's "certificate_list" (https://tools.ietf.org/html/rfc2246#section-7.4.2)
My request to the group is as follows:
Please consider *mandating* that any TLSA association that
specifies a trust anchor (0, 2 and any additional ones in the
future) obligates the server to present the corresponding TA
certificate in its "certificate_list".
If that is done, I can support all "0 x y" and all "2 x y"
associations, and publish documentation for Postfix SMTP server
operators to be DNS-friendly and use "2 x 1" rather than "2 x 0".
If the group can only mandate on-the-wire TA certificates in
the "certificate_list" for "2 x y" associations and not for
"0 x y" associations, then I must drop support for all "0 x y"
associations other than "0 0 0", but it may be better to simply
not support "0 x y" at all for all "x y".
If there is no "certificate_list" mandate for any of the "usage"
values, then I can only implement "0 x 0" and "2 x 0", with x=1
meaning "signed by".
So my take on the standard from an implementation viewpoint is that
so far the *only* robust associations are "3 1 1" and "3 0 1".
- 3 0 0 and to a lesser extent 3 1 0 are not DNS-friendly.
- 3 1 2 alone is fragile because matching type 2 support is optional,
one must publish 3 1 1 along with it. So essentially nobody will
publish 3 1 2.
- "0 x y" and "1 x y" needlessly risk rejection by clients with an
incomplete public CA set that implement the spec as written and
implement these as "constraints" and not "assertions".
- "2 x [12]" is unusable without the "certificate_list" mandate.
- "2 1 0" is unusable unless "issued by" is read as "signed by",
it is also not very DNS-friendly, a 2048-bit RSA public key
is around 300 bytes of DER (an EC public key at ~90 bytes
may be sufficiently svelte, but we're not yet at broad support
for EC in SSL).
- "2 0 0" is not DNS-friendly.
With a "certificate_list" mandate for "2 x y", I get:
- Cleaner implementation support for "2 x 0" associations, no need
for signature checks in my code, the chain will be checked by
OpenSSL's built-in verification code.
- Support for "2 x [12]" associations, since I can expect to find the
TA in the server chain.
With a "certificate_list" mandate for "0 x y" (which I expect I won't
get, but it would be a shame not to ask) the above applies with "2"
replaced by "0".
With no "certificate_list" mandate, and without clarification of
"issued by" vs. "signed by", I may have to withdraw support for
everything other than "3 x y" and (after remapping constraint to
assertion) "1 x y".
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
