Subject: [dane] draft-fanf-dane-smtp-04

From: James Cloos <[email-masked]>
Date: Thu, 17 Jan 2013 19:55:59 -0500

Some comments:

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

It does seem useful; I'm indifferent to in this document or in a
document of its own.

,----
| Is the description of DNSSEC validation over-done?  Can it be trimmed
| down so it relies more on the core DNSSEC specs?
`----

Given the desire to ensure that partial tlsa provisioning doesn't block
mail delivery, it seems squarely to have hit the as simple as needed but
no simpler nail.

,----
| o  If there is no TLSA record or its DNSSEC validation state is
|    insecure or indeterminate, this protocol has not been fully
|    deployed.  The client SHOULD deliver to this server insecurely
|    (which might be over unauthenticated TLS).
`----

In that case the target mta might offer a cert which the client mta can
authenticate by some means other than dane (eg a pool in CApath or the
like).  So 'insecurely' is not the right adverb.

I haven't come up with an alternative wording, though.

,----
| A <Transmitted-line> SHALL include:
|
| o  A <To-domain> clause describing the SMTP server.  The <Domain>
|    part of a <To-domain> SHALL be the same as the SMTP server host
|    name.
`----

When would/could/should the To-domain not in its entirety match the string
used for the A/AAAA and TLSA lookups?

,----
| 6.1.  "with" protocol types
`----

It seems odd that with is used for some auth but not all.  Perhaps there
should be a with keyword for tlsa, too?

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

---

From: Tony Finch <[email-masked]>
Date: Fri, 18 Jan 2013 11:28:11 +0000

> Some comments:

Thanks!

> like).  So 'insecurely' is not the right adverb.

The reason it says "insecurely" here is explained in the first couple of
paragraphs in the introduction. Perhaps I should add a back-reference.

> used for the A/AAAA and TLSA lookups?

They always match - that is what the text you quoted is supposed to mean.

> should be a with keyword for tlsa, too?

Isn't that covered by RFC 3848? ESMTPSA and so forth.

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: James Cloos <[email-masked]>
Date: Fri, 18 Jan 2013 19:18:36 -0500

>>>>> "TF" == Tony Finch <[email-masked]> writes:

>> like).  So 'insecurely' is not the right adverb.

TF> The reason it says "insecurely" here is explained in the first couple of
TF> paragraphs in the introduction. Perhaps I should add a back-reference.

I must have forgotten the earlier note by the time I got down to that
section.  Perahps because I had to take some breaks while reading
through it.  A back-reference probably is a good idea.

>> used for the A/AAAA and TLSA lookups?

TF> They always match - that is what the text you quoted is supposed to mean.

I always tend to read domain name more like dns zone than like host name.

Even after all these years.

You remind me that I should read it more akin to fully-qualified-domain-name.

>> should be a with keyword for tlsa, too?

TF> Isn't that covered by RFC 3848? ESMTPSA and so forth.

So ESMTPT is for any kind of TLS authentication of the starttls creds?
Either tlsa rr or set of out-of-band-maintained trusted root certs?

My instinct is that it would be useful to know *how* the starttls was
authenticated, not just whether.

(And, yes, by the time I got down that far I see that I did glaze over a
bit.  "when the client successfully authenticated the server." didn't
click as intended, though it is obvious today.  Modulus the above q.)

-JimC