Hi Tony,
At 13:28 02-02-2013, Tony Finch wrote:
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 :-)
:-)
Wouldn't that be a downref (since RFC 5598 is informational) and therefore
wrong?
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.
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"?
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".
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.
Alias handling was an issue for SMTP due to an incorrect
interpretation of the specification. The discussion was previously
controversial.
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.
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
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
