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

[Tony Finch <[e-mail]>]

SM <[e-mail]> wrote:
>

Thanks very much for your helpful comments!

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

Thanks.

> 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.

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 :-)

> In Section 2:
>
>    "ADMD:  An ADministrative Management Domain, as described in the
>     Internet Mail Architecture [RFC5598]."
>
> The reference to RFC 5598 should be normative.

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

> In Section 3.1:
>
>   "o  A CNAME or DNAME pointing to a successful result."
>
> 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.

> 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).

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.

> 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.

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  <[e-mail]>  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.