On Wed, Apr 10, 2013 at 08:54:01AM -0400, James Cloos wrote:
[ Thanks to James for his off-line response (at my request), it shows
that perhaps my question is not quite clear enough, so I am taking
the liberty of posting my response to the list. Separately, any
comments from the larger group on the CNAME question would also
be much appreciated. ]
> tlsa 0 [01] [12] by definition expect a root preknown to the client and
> that the tls server send any required intermediates with the EE cert.
> Whereever tlsa 0 would work, an identical tlsa 2 also should.
>
> But that is really from a browsers-type point of view, where a large set
> of roots is typical. In PF terms, it expects something like:
>
> smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
>
> Also, 0 and 2 needn't associate to the root cert, they can associate to
> an intermediate cert.
I know that 0 and 2 can and will associate to a cert anywhere in the chain
(Postfix aka PF will even support depth 0) not just the root.
I am trying to decide whether to treat "2 [01] [12]" as usable or
not. For this I need guidance from the spec on the obligations of
the server. I strongly urge the WG to explicitly require the
presence of "2 [01] [12]" certificates in the peer chain, otherwise
the verifier is left to verify the servers chain by employing a
psychic to divine the server's (often privately generated) issuing CA.
So my question is different. With "2 [01] [12]" is the server operator
obligated to provide the "associated" CA certificate (be it a root
or an intermediate) on the wire in the server's "certificate_list"
TLS handshake message. In practice this means something along the lines
of:
# More generally some MTA's configuration settings:
main.cf:
# Some way of specifying the server certificate chain file:
smtpd_tls_cert_file = /etc/postfix/smtpd.pem
# The configured certificate and chain: /etc/postfix/smtpd.pem:
-----BEGIN PRIVATE KEY-----
... server ee private key ...
-----END PRIVATE KEY----- -----BEGIN CERTIFICATE-----
... server ee cert ...
-----END CERTIFICATE----- -----BEGIN CERTIFICATE-----
... server cert issuer CA1
-----END CERTIFICATE----- -----BEGIN CERTIFICATE-----
... CA1 cert issuer CA2
-----END CERTIFICATE----- -----BEGIN CERTIFICATE-----
... CA<N-1> cert issuer CA<N>
-----END CERTIFICATE-----
Must the CA certificate in the TLSA RR (specified only as a digest,
not in full) be one of CA1 .. CA<N>, or is it allowed to be some
CA<N+1>: an omitted issuer of CA<N>.
Should the language clarifying this be in 6698, or in draft-ietf-dane-srv?
> So, for some applications, it is not unreasonable to expect that some
> admins will find it reasonable to publish a tlsa 2 [01] [12]. Should
> pf run into one, and the associated cert is not available in CAfile
> or the chain sent during TLS nego, my gut reaction is that pf should
> proceed as if there were no tlsa at all. Ie unverified tls.
There is then no point in verification if, when verification fails,
we proceed anyway! This is not how I read draft-ietf-dane-srv-02:
It SHALL verify the identity asserted by the server's certificate
according to [RFC6125] section 6, using a list of reference
identifiers constructed as follows.
Per the draft, in order to make DANE TLSA records be more than just
bloated HASTLS records, Postfix will a priori (before connecting
to the server) either commit to verification, or decide that all
RRs are unusable.
I really don't understand why anyone would bother with DANE if the
associations in the TLSA RRs are just a way to add DNS lookup
latency and CPU cost, but don't actually enforce any constraints
that yield greater connection security.
The Postfix implementation of DANE TLSA RRs is that when usable
RRs are found, either the peer is verified or mail stays in the
queue (if delivery fails for this or another reason on all MX hosts).
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
