On Thu, Mar 07, 2013 at 05:41:48PM +0000, Tony Finch wrote:
> > - If insecure, do opportunistic TLSA with this host
>
> I think you meant TLS here.
Yes, TLS, and on closer reading of draft-ietf-dane-srv, it is
"mandatory TLS" not "opportunistic TLS", but contrary to that spec,
the practicalities of email mean: *without PKIX* validation.
> > One quick comment on Section 7.3 of the above. This section is
> > broken. Certificate name checks are *only* appropriate with
> > certificate usage 0 and 2, and are *never* appropriate with usage
> > 1 and 3.
>
> If you have a certificate with a mismatched name it will fail validation
> with non-DANE clients. So the another reason for keeping the name checks
> in all cases (which I should add to the spec) is for more consistent
> behaviour between old and new clients.
The long thread on the DANE list boils down to "no name checks for
certificate usage 3". Therefore, also not "name checks in all cases".
> > Multiple servers that do not share a single name can be reasonably
> > expected to share a single replicated key-certificate pair, bound
> > to the service by fingerprint alone. One should not need to re-issue
> > the certificate every time a new server is added to the cluster.
>
> Maybe in current SMTP deployments, because SMTP certificate validation is
> broken, but that isn't true for other protocols.
Actually, for all protocols with certificate usage 3. So with any
luck the spec will be revised accordingly.
Postfix will map usage 0 to 2, and usage 1 to 3, and Postfix DANE
documentation will strongly encourage administrators to only ever
generate "TLSA 3 1 1" records. These are least likely to break due
to incomplete trust-anchor lists on the sender side, or other common
barriers to PKIX validation that browser users can click-through,
but MTAs cannot.
--
Viktor.
