Subject: [dane] Comments on draft-ietf-dane-smtp-00

From: SM <[email-masked]>
Date: Fri, 01 Feb 2013 23:54:26 -0800

Hi Tony,

I have a few quick comments on draft-ietf-dane-smtp-00.

In Section 1:

   "This memo does not cover message submission [RFC4409] [RFC5068]
    [RFC6186], nor does it cover LMTP [RFC2033], since they use the DNS
    in a different way than MTA-to-MTA SMTP."

The reference to RFC 4409 should be updated to RFC 6409.

In Section 1.1:

   "Is the Transmitted: header useful enough to include in this spec?
    Should it be dropped, or perhaps moved to another document?"

I suggest sticking to a SMTP versus Message Format split and dropping 
the Transmitted: header field.

In Section 2:

    "ADMD:  An ADministrative Management Domain, as described in the
     Internet Mail Architecture [RFC5598]."

The reference to RFC 5598 should be normative.

In Section 3.1:

   "o  A CNAME or DNAME pointing to a successful result."

RFC 5321 does not say anything about DNAME.

In Section 3.2:

   "It then proceeds with TLS negotiation [RFC5246].  If the
    client uses the Server Name Indication TLS extension ([RFC6066]
    section 3) it MUST use the SMTP server host name as the value for the
    ServerName field."

I am not sure whether to hand-wave by not getting in RFC 6125 details 
(see Section 7.4 too).

In Section 8:

   "If any of the DNS queries are for an internationalized domain name,
    then they need to use the A-label form [RFC5890]."

I suggest using RFC 6531 as any future clarification for 
internationalized email (SMTP) would go in there.

BTW, why go into intra-domain SMTP?  The proposal could take a SMTP 
client to SMTP server approach and anything not using Section 5 of 
RFC 5321 is left unspecified (what Section 3.1 refers to as "insecure 
delivery").

Regards,
-sm

---

From: Tony Finch <[email-masked]>
Date: Sat, 2 Feb 2013 21:28:09 +0000

SM <[email-masked]> wrote:

Thanks very much for your helpful comments!

> The reference to RFC 4409 should be updated to RFC 6409.

Thanks.

> I suggest sticking to a SMTP versus Message Format split and dropping the
> Transmitted: header field.

Note that the details of the Received: header are specified as part of
SMTP - RFC 5321 section 4.4. So although I am inclined to agree with your
conclusion, your reasoning is flawed :-)

> The reference to RFC 5598 should be normative.

Wouldn't that be a downref (since RFC 5598 is informational) and therefore
wrong?

> RFC 5321 does not say anything about DNAME.

Would you be happier if I change this text to "A CNAME record (which might
be synthesized from a DNAME record) pointing to a successful result"?

In fact when I split this document into a generic DANE+SRV/MX document
plus a DANE+SMTP document, I plan to describe alias handling better, so
the above text will be revised more thoroughly than that.

> I am not sure whether to hand-wave by not getting in RFC 6125 details (see
> Section 7.4 too).

No, I think it's really important to get this right and pin down the
details, which is why section 7.4 exists. This is not such a problem for
SMTP because its certificate name checking does not currently exist; but
other SRV-based protocols (such as XMPP and RFC 6186 for MUAs) follow RFC
6125 rules where without DNSSEC they have to check the certificate subject
name against the service domain. With DNSSEC they can instead check the
certificate against the server host name, since DNSSEC has authenticated
the link from service domain to server host name. This is desirable for
multi-tenant services since it avoids the need for lots of certificates or
large certificates, and it is important for applications like SMTP where a
message can relate to multiple service domains. I covered the forwards /
backwards compatibility aspects of this a bit better in
draft-fanf-dane-mua and I'll fold the relevant parts into the generic
DNAE+SRV draft.

> I suggest using RFC 6531 as any future clarification for internationalized
> email (SMTP) would go in there.

I'm going to keep the protocol-independent version for the generic spec. I
will have a look at RFC 6531 to see if the slimmed-down DANE+SMTP shim
needs to say anything more. Thanks for the pointer.

> BTW, why go into intra-domain SMTP?  The proposal could take a SMTP client to
> SMTP server approach and anything not using Section 5 of RFC 5321 is left
> unspecified (what Section 3.1 refers to as "insecure delivery").

Because we need to make sure that cross-vendor interop works for private
links as well as public ones.

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.

---

From: SM <[email-masked]>
Date: Sat, 02 Feb 2013 22:56:43 -0800

Hi Tony,
>conclusion, your reasoning is flawed :-)

:-)

>Wouldn't that be a downref (since RFC 5598 is informational) and therefore

Yes.  It can be called out during the Last Call.  RFC 5598 is already 
in the Downref registry.  There shouldn't be any process issue if the 
reference is normative.

>be synthesized from a DNAME record) pointing to a successful result"?

It's better to leave DNAME to 5321bis.

The issue the draft tries to tackle is similar to what is in Section 
3.7.2 of RFC 6531, i.e. in this case DNSSEC support.  The text in 
Section 3.1 of the draft discussing about CNAME RRs can be 
interpreted in different ways.  Although I read Section 5.1 of RFC 
5321 again I cannot come up with suggested text for now.  You already 
have the main idea in the draft.  It's a matter of word-smithing it.

Typo in Section 3.1: "successful".

>the above text will be revised more thoroughly than that.

Alias handling was an issue for SMTP due to an incorrect 
interpretation of the specification.  The discussion was previously 
controversial.

>draft-fanf-dane-mua and I'll fold the relevant parts into the generic

It may end up being more work if the draft attempts to address all 
the details.  Sorry for not being able to provide a clear answer.  I 
will have to review some of the STARTTLS discussions and some other 
discussions before commenting further about the SMTP angle.  I read 
draft-fanf-dane-mua previously.  XMPP should be easier as there is 
draft-miller-xmpp-dnssec-prooftype-03.

In Section 1:

   "We use DNSSEC to secure the association between a mail domain and its
    SMTP server host names, and between the host names and their
    certificates.  Connections to servers are authenticated by their TLS
    certificates."

Thinking about this, I would take a SMTP client to SMTP server 
approach instead of mail domain to SMTP server.  The problem 
description is to secure the client to server connection.  This means 
figuring out the secure delegation part (DNSSEC) and after that the 
TLS part.  I can cover the Smarthost case by reusing some of the 
logic from secure delegation part.  I better stop thinking. :-)

Regards,
-sm