Subject: [dane] Review of DANE SMTP draft

From: Alexey Melnikov <[email-masked]>
Date: Thu, 6 Mar 2014 13:44:17 +0000

Hi,
I have a possibly slightly cryptic review notes. Feel free to ask for clarifications.

In the terminology section: what about no MX record case (A or AAAA only)?

In 1.3.1: why mention SMTP URIs? How would introduction of such URIs help with securing SMTP? I suggest you just mention that there is no signalling of "secure" SMTP.

In 2.2: Network address instead of MX hostname - I think this deserves an example.

In 2.2.3 (page 17, 3rd from the last para): and possibly other places: TLS server certificate matching rules should be fully specified. Use RFC 6125 (for example look at draft-melnikov-email-tls-certs-01) or specify the rules directly.

Page 22, 3rd para: please add reference for the SNI TLS extension (a Normative reference, because you use normative language when referencing the extension) and various versions of TLS.

In 2.3.3: it is not clear whether the client needs to check that for every record covered by the WORSE hash there is a corresponding record covered by the BETTER hash.

In Section 3, last para: add "or bounced", as this can be more serious than just being delayed.

In 4.2, last para: did you mean "SHOULD"?

I've heard Not checking expiration dates in certificate - I don't think this was mentioned in the document.

Best Regards,
Alexey

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 14 Mar 2014 05:23:42 +0000

> In the terminology section: what about no MX record case (A or AAAA only)?

Thanks.  This was a global replace error.  The term used to define
"MX Host".  All of its occurrences got replaced with "SMTP server",
no longer specific to MX hosts of domains, but the terminology is
now wrong.  I am going to just delete this dangling definition.

> In 1.3.1: why mention SMTP URIs? How would introduction of such
> URIs help with securing SMTP? I suggest you just mention that there
> is no signalling of "secure" SMTP.

There are no URIs and none are desired.  This is an attempt at a
contrast with HTTP, and yes the point is that there is no signalling
of HOP by hop security policy in the envelope address (which is
more of a feature than a bug).  I'm tweaking the text to talk about
signalling more explicitly, rather than a hypothetical URI scheme.

> In 2.2: Network address instead of MX hostname - I think this

[ Second-last paragraph of 2.2 ]

Is it not obvious that this means the misguided:

	example.com. IN MX 0 192.0.2.1.

I am not adding this yet, do others feel this really warrants more
text?

> In 2.2.3 (page 17, 3rd from the last para): and possibly other places:
> TLS server certificate matching rules should be fully specified. Use RFC
> 6125 (for example look at draft-melnikov-email-tls-certs-01) or specify
> the rules directly.

In 6125 (where the exceptions dominate the rules) there are no
provisions for matching one of a set of candidate names.  So, I
guess, we should be more explicit about the wildcard matching
(perhaps generically in the SRV draft) and otherwise defer to
6125 for international domain names, Subject commonName vs.
subjectAltName:DNS, etc.

FWIW Postfix by default (Postini work-around) supports wildcard certificates
that match multiple DNS labels:

    http://www.postfix.org/postconf.5.html#tls_wildcard_matches_multiple_labels

The folks at Postini have a wildcard cert for "*.psmtp.com" and clients
publish MX records of the form:

    verisign.com.           IN      MX      100 verisign.com.s6a1.psmtp.com.
    verisign.com.           IN      MX      200 verisign.com.s6a2.psmtp.com.
    verisign.com.           IN      MX      300 verisign.com.s6b1.psmtp.com.
    verisign.com.           IN      MX      400 verisign.com.s6b2.psmtp.com.

I have not given much thought to writing DANE-specific rules for
SMTP TLS with respect to the mechanics of matching of any particular
candidate name against the certificate.  (To be honest, I did not
need to write any new code for this, since name matching is handled
in Postfix TLS policy generically for DANE and PKIX.  The existing
PKIX code was already flexible enough to do all the work, so this
did not cross my radar).  In

    https://tools.ietf.org/html/rfc6125#appendix-B.4

we have matching with just "*" as a wildcard (no "foo*.example.com"
or "*foo.example.com") and only for a single label.  While SMTP-AUTH
forbids chasing CNAMEs insecurely, it only works well for MSA hosts,
not MX hosts which already lose after insecure MX delegation.  With
DANE we have a secure TLSA base domain, so this does not apply.

I don't know whether the Postfix (on by default) Postini work-around
deserves IETF blessing.  Perhaps it would be better for Postini to
fix their certificates, or if they ever deploy DANE to publish only
DANE-EE(3) certs, which make the question moot.  I don't know
whether any other sites are attempting to use SMTP with wildcard
certs for multi-label sub-domains.  There is not enough authenticated
TLS happening for SMTP today to know what's out there in the wild.

> Page 22, 3rd para: please add reference for the SNI TLS extension (a
> Normative reference, because you use normative language when referencing
> the extension) and various versions of TLS.

RFC 6066 is referenced on page 6 (second last paragraph) and appears
in the References section.  Should the reference be repeated on
page 22?

> In 2.3.3: it is not clear whether the client needs to check that for every
> record covered by the WORSE hash there is a corresponding record covered
> by the BETTER hash.

This is not possible.  The records don't carry separate "instance"
identifiers that allow one to identify all the TLSA records of a
single certificate or public key.  The various digest algorithms
are not invertible!  All that the client can check is that the
number of records for the best algorithm is the same as that for
all other algorithms within each combination of usage and selector.

We may need a separate thread on pinning down algorithm agility
(unless it is good enough as-is, perhaps with clarifications if
the intent is not completely clear).

> In Section 3, last para: add "or bounced", as this can be more serious

Fine.

> In 4.2, last para: did you mean "SHOULD"?

Perhaps so, though this may hold up publication of the SMTP draft
until the "ops" draft is also done.  We could cut/paste the relevant
text, or move it to the more generic SRV draft.

Ultimately, there is a real need for DANEbis, but it looks like it
won't move forward until there are more published and deployed
protocols, so we'll all be parroting the "missing" text in multiple
drafts, or perhaps the normative text from "ops" can be published as
a standards track "clarifications" to 6698?  Any suggestions from
the chairs?

> this was mentioned in the document.

This is in the "ops" draft, but I'll add it to the description in
the SMTP draft, after we figure out exactly what should be ignored
in DANE-EE(3) certs (and possibly DANE-TA(2) SPKI(1) trust anchor
certs).  (Separate thread on this soon).

-- 
	Viktor.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 14 Mar 2014 17:15:37 +0000

> now wrong.  I am going to just delete this dangling definition.
Ok.
> signalling more explicitly, rather than a hypothetical URI scheme.
Ok.
> 	example.com. IN MX 0 192.0.2.1.
No, it is not obvious, otherwise I wouldn't have asked.
> provisions for matching one of a set of candidate names.
I am not sure I understand. If there are multiple subjectAltName values 
of the same type, any match works. Unless you mean something else.
> So, I
> fix their certificates,
I think so, yes.
> or if they ever deploy DANE to publish only
In general, I prefer when references are repeated.
> all other algorithms within each combination of usage and selector.
I think your current text can be misinterpreted that such validation is 
allowed. Use of normative language didn't help. I think I interpreted 
some of the requirements as applying to SMTP clients, where they applied 
to ISPs.
>> In Section 3, last para: add "or bounced", as this can be more serious
Thank you.
> certs).  (Separate thread on this soon).
Ok. If you are departing from RFC 5280, they you should state all new 
requirements.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 14 Mar 2014 17:41:02 +0000

> No, it is not obvious, otherwise I wouldn't have asked.

The original sentence reads:

    Similarly, when an MX RRset incorrectly lists a network address in
    lieu of an MX hostname, if the MTA chooses to connect to the network
    address, DANE TLSA does not apply for such a connection.

Anyone else feel this deserves an example?  There are some poor
sods who attempt to stuff IPv4 addresses into MX hostname RRDATA,
and some MTAs may do them a favour and handle this broken syntax.
In that case DANE is clearly out of scope.

> I am not sure I understand. If there are multiple subjectAltName
> values of the same type, any match works. Unless you mean something
> else.

No, the SMTP and SRV drafts specify that the client has multiple
names it is willing to accept, any one of which may match one of
the many SAN names in the peer certificate.  There can be up to
three names.  The original name before redirection by MX or SRV,
the securely CNAME expanded version of that if different, and
finally the TLSA base domain of the server.

> >deserves IETF blessing.  Perhaps it would be better for Postini to

That is Postini fix their mess?  Or SMTP support multi-label
wildcards?

> In general, I prefer when references are repeated.

We can do that.  There is clearly sufficient distance between page
6, and page 22, for the reference not to appear repetitive.

> I think your current text can be misinterpreted that such validation
> is allowed. Use of normative language didn't help. I think I
> interpreted some of the requirements as applying to SMTP clients,
> where they applied to ISPs.

What do you mean by "such validation is allowed"?  Would you mind
starting a new thread with questions specifically about the digest
agility part of the SMTP draft?  This mechanism is not intended to
be SMTP-specific, and should some day make it into DANEbis via the
SRV draft as a first hop perhaps (unless it should be its own
stand-alone draft on just digest agility for DANE).

> Ok. If you are departing from RFC 5280, they you should state all
> new requirements.

Yes.

-- 
	Viktor.

---

From: Lawrence Conroy <[email-masked]>
Date: Fri, 14 Mar 2014 19:34:42 +0000

Hi Viktor, Alexey, folks,

Please, please, please do NOT give invalid/incorrect examples (even as examples of what NOT to do).

Viktor: The text you have seems pretty obvious to me on reading.
To nail it in with a hammer, maybe c/when an MX RRset incorrectly lists a network address in lieu of an MX hostname, if the MTA chooses/Even though this form is invalid, some MX RRsets may be encountered that list a network address in lieu of an MX hostname. If the MTA nevertheless chooses/
(but that really is smashing the point home).

Now back to lurking.

all the best,
  Lawrence

On 14 Mar 2014, at 17:41, Viktor Dukhovni wrote:
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 14 Mar 2014 21:42:12 +0000

> examples of what NOT to do).

No worries, I did not want to spend too much ink on this case.  It
was just a "throw-away" comment, while specifying that DANE is not
applicable to address literal destinations when sending email to
legal, but rare, constructs such as postmaster@[192.0.2.1] (also no
example).

-- 
	Viktor.

---

From: James Cloos <[email-masked]>
Date: Fri, 14 Mar 2014 21:01:48 -0400

>>>>> "VD" == Viktor Dukhovni <[email-masked]> writes:

VD> FWIW Postfix by default (Postini work-around) supports wildcard
VD> certificates that match multiple DNS labels:

VD>     http://www.postfix.org/postconf.5.html#tls_wildcard_matches_multiple_labels

VD> The folks at Postini have a wildcard cert for "*.psmtp.com" and
VD> clients publish MX records of the form:

VD>     verisign.com.           IN      MX      100 verisign.com.s6a1.psmtp.com.
VD>     verisign.com.           IN      MX      200 verisign.com.s6a2.psmtp.com.
VD>     verisign.com.           IN      MX      300 verisign.com.s6b1.psmtp.com.
VD>     verisign.com.           IN      MX      400 verisign.com.s6b2.psmtp.com.

For some historical context, mozilla's original wildcarded ssl implement-
ation also allowed an *. to match any number of labels.

Several sites were broken by the change to limit a wildcard to a single label.

-JimC
--
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 15 Mar 2014 02:42:03 +0000

On Fri, Mar 14, 2014 at 09:01:48PM -0400, James Cloos wrote:

> > The folks at Postini have a wildcard cert for "*.psmtp.com" and
> > clients publish MX records of the form:
> >

I take it you're suggesting to not perpetuate Postini's abuse of
wildcard certs?  Implementations might choose to be more liberal,
but servers can't expect multi-label wildcard support.  Right?

-- 
	Viktor.

---

From: James Cloos <[email-masked]>
Date: Sat, 15 Mar 2014 13:59:43 -0400

>>>>> "VD" == Viktor Dukhovni <[email-masked]> writes:

VD> I take it you're suggesting to not perpetuate Postini's abuse of
VD> wildcard certs?

Not really; I'm ambivalent.  And most tls usage lacks uri bars, so it is
less of an issue than it might be for browsers.

VD> Implementations might choose to be more liberal,
VD> but servers can't expect multi-label wildcard support.  Right?

True.

-JimC

---

From: [email-masked] (Martin Rex)
Date: Mon, 17 Mar 2014 23:34:07 +0100 (CET)

> but servers can't expect multi-label wildcard support.  Right?

See:

 http://tools.ietf.org/html/rfc6125#section-6.4.3

   6.4.3.  Checking of Wildcard Certificates

   A client employing this specification's rules MAY match the reference
   identifier against a presented identifier whose DNS domain name
   portion contains the wildcard character '*' as part or all of a label
   (following the description of labels and domain names in
   [DNS-CONCEPTS]).

   For information regarding the security characteristics of wildcard
   certificates, see Section 7.2.

   If a client matches the reference identifier against a presented
   identifier whose DNS domain name portion contains the wildcard
   character '*', the following rules apply:

   1.  The client SHOULD NOT attempt to match a presented identifier in
       which the wildcard character comprises a label other than the
       left-most label (e.g., do not match bar.*.example.net).

   2.  If the wildcard character is the only character of the left-most
       label in the presented identifier, the client SHOULD NOT compare
       against anything but the left-most label of the reference
       identifier (e.g., *.example.com would match foo.example.com but
       not bar.foo.example.com or example.com).

   3.  The client MAY match a presented identifier in which the wildcard
       character is not the only character of the label (e.g.,
       baz*.example.net and *baz.example.net and b*z.example.net would
       be taken to match baz1.example.net and foobaz.example.net and
       buzz.example.net, respectively).  However, the client SHOULD NOT
       attempt to match a presented identifier where the wildcard
       character is embedded within an A-label or U-label [IDNA-DEFS] of
       an internationalized domain name [IDNA-PROTO].

-Martin

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 17 Mar 2014 23:06:46 +0000

>        not bar.foo.example.com or example.com).

I am aware of this SHOULD NOT.  The question is whether this is
the right behaviour for opportunistic DANE TLS.  There is no user
to "click OK", and if Postini-style wildcard certs are likely to
be employed or need to be employed, then perhaps the right choice
for SMTP is to tolerate multi-label wildcards.

I am not insisting one way or the other, just wondering whether
there is consensus.  Fortunately, there is a UTA draft on name
checks for SMTP, and its authors have invited me to pitch in.

Their draft defines wildcards to match a single label, and this
question is perhaps best dealt with on the UTA list (where I may
again run into Martin and the rest of our fine DANE crew, but it
seems to be a more natural forum for what is I think more of an
application question).

So most likely SMTP name checks will not specifically endorse
multi-label wildcards, but if it is OK with this group, I'd like
to move this specific issue to that forum.

-- 
	Viktor.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 18 Mar 2014 21:13:59 +0000

Hi Victor,

> On 14 Mar 2014, at 17:41, Viktor Dukhovni <[email-masked]> wrote:
> 

Ok, after thinking more about this, your current text looks Ok as is.
> finally the TLSA base domain of the server.

RFC 6125 allows for that, so I see no conflict.
> That is Postini fix their mess?

Yes.

> Or SMTP support multi-label wildcards?

I suppose this might be another reasonable outcome, if we can get IETF consensus on this.