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

[SM <[e-mail]>]

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