Subject: [dane] DANE and wilcdcard CNs (or DNS subjectAltNames)

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 11 Apr 2013 16:56:59 +0000

---------
Background:

    http://wiki.cacert.org/WildcardCertificates

Plus 3280/5280:

   Finally, the semantics of subject alternative names that include
   wildcard characters (e.g., as a placeholder for a set of names) are
   not addressed by this specification.  Applications with specific
   requirements MAY use such names, but they must define the semantics.
---------

Should DANE or draft-ietf-dane-{srv,smtp} say anything about the
semantics of the "*" in "*.example.com" CNs or DNS subjectAltNames?

There was never an explicit specification of certificate matching for
SMTP, and Postfix allows wildcards to match exactly one label in a nod
to RFC 2818 for lack of any other normative text:

	mail.example.com =~ *.example.com
    foo.mail.example.com !~ *.example.com

This has not been an issue since X509v3 certificates are almost
universally unverified in SMTP, and the exceptional cases where
site A does verify mail to site B use hand-tuned verification rules
that match site B's certs.

Since DANE enabled MTAs will require TLS verification between peers
without prior *mutual* arrangement, the semantics of "*.example.com"
for SMTP (and likely other protocols) need to be understood by all
parties.  I am concerned that receiving sites like Postini may be
tempted to publish TLSA RRs for their current wildcard certificate,
causing a major outage for senders, since Postini handles the MX
hosts for many client domains with MX hostnames of the form
"example.com.<id>.psmtp.com" which does not match "*.psmtp.com" in
the current Postfix implementation.

  Connected to postini.com.s8a1.psmtp.com[64.18.7.10]:25
  > STARTTLS
  < 220 Go ahead
  postini.com.s8a1.psmtp.com[64.18.7.10]:25: depth=1 matched=1 trust anchor certificate sha256 digest 25:0D:A2:69:1B:E9:7C:9A:33:CE:EF:7E:31:1C:14:FB:01:84:6E:05:8A:99:CE:A9:BD:11:25:BD:25:A0:CA:D5
  postini.com.s8a1.psmtp.com[64.18.7.10]:25: subjectAltName: *.psmtp.com
  postini.com.s8a1.psmtp.com[64.18.7.10]:25 CommonName *.psmtp.com
  postini.com.s8a1.psmtp.com[64.18.7.10]:25: subject_CN=*.psmtp.com, issuer_CN=Google Internet Authority, fingerprint=B7:3B:6F:25:EB:A7:FD:AA:77:80:EB:30:DD:82:AC:D7:52:CA:64:FE, pkey_fingerprint=25:F3:B4:77:4F:9E:0B:FA:FD:96:4E:70:87:77:B3:CA:F9:F5:1E:44
  Trusted TLS connection established to postini.com.s8a1.psmtp.com[64.18.7.10]:25: TLSv1 with cipher AES256-SHA (256/256 bits)
  > QUIT
  < 221 Catch you later

Above "Trusted" means the certificate trust chain is valid, but
only "Verified" would indicate that it matches the expected peer,
so a TLS verified delivery to Postini would fail to match the
expected "postini.com.s8a1.psmtp.com" certificate peername.

Should Postfix be more liberal in its treatment of "*", or are
Postini clueless about wildcard certificates?

-- 
	Viktor.

---

From: Tony Finch <[email-masked]>
Date: Thu, 11 Apr 2013 20:32:00 +0100

> semantics of the "*" in "*.example.com" CNs or DNS subjectAltNames?

No. That is RFC 6125's job. But I see that dependent specs have to
explicitly say it is OK. Sigh.

> I am concerned that receiving sites like Postini may be tempted to
> publish TLSA RRs for their current wildcard certificate, causing a major
> outage for senders, since Postini handles the MX hosts for many client
> domains with MX hostnames of the form "example.com.<id>.psmtp.com" which
> does not match "*.psmtp.com" in the current Postfix implementation.

Postfix is right: a wildcard in a certificate only matches within a
label. (One of the "fun" differences between X.509 and DNS wildcards.)
Postini will have to fix that. Most of the SMTP certificates out there
will have to be replaced before they can be validated, so Postini are in
good company.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.