On Fri, Apr 25, 2014 at 05:57:24PM -0400, Tom Ritter wrote:
> -------------------
>
> These paragraphs are spread around, but say the same thing.
>
> The SMTP client SHOULD NOT deliver
> mail via the corresponding host unless a TLS session is negotiated
> via STARTTLS. This is required to avoid MITM STARTTLS downgrade
> attacks.
>
> ...
>
> When at least one usable "secure" TLSA record is found, the SMTP
> client SHOULD use TLSA records to authenticate the SMTP server.
> Messages SHOULD NOT be delivered via the SMTP server if
> authentication fails, otherwise the SMTP client is vulnerable to MITM
> attacks.
These cover different protocol stages, the first STARTTLS downgrade,
the second certificate verification.
> It also seems to contradict the later paragraph in 6.1:
>
> Unless
> local policy specifies "audit only" or that opportunistic DANE TLS is
> not to be used for a particular destination, an SMTP client MUST NOT
> deliver mail via a server whose certificate chain fails to match at
> least one TLSA record when usable TLSA records are found for that
> server.
Thanks, here, there is indeed a MUST/SHOULD inconsistency. I will
change 6.1 to SHOULD. Explicit local policy always wins.
> -------------------
>
> It took me a good long time, but I finally found a typo (missing
> period). This was the only typo I found.
>
> name is based entirely on the TLSA record association The server MUST
Fixed, staged for next update.
> -------------------
>
> Section 2.3.1.3
>
> Strong disagree with this paragraph:
>
> SMTP client treatment of TLSA RRs with certificate usages "PKIX-
> TA(0)" or "PKIX-EE(1)" is undefined. For example, clients MAY (will
> likely) treat such TLSA records as unusable.
In that case you need to re-read sections 1.3, and 1.3.1--1.3.4,
which explain why PKIX *cannot* work for SMTP. Wishing it otherwise
does not make it true.
> First off, I think it's inappropriate to use capital MAY in an example
> about how clients might behave, immediately after saying it's
> undefined. Lowercase 'may', sure, but capital implies something else.
I don't have a strong opinion about MAY vs. may in this context.
Anyone else care to comment?
> Second off, I think it's inappropriate to suggest that clients ignore
> these settings. I agree with the sentiment that it has no increase in
> security.
No, the real problem is that these cannot be implemented interoperably.
Honouring such records will break email deliverability and nobody
will use opportunistic DANE TLS with SMTP. An opportunistic protocol
has to be interoperable first, and secure second.
We're working on a definition of "opportunistic security" on the
"saag" mailing list. And while some of the discussion has been a
bit heated, naturally over rather small issues, there is little
contorversy with respect to the idea that "opportunistic security"
is first and foremost highly interoperable, it is expected to just
work at whatever security level is possible with each peer.
Now "opportunistic DANE TLS" is an attempt to provide stronger
security for peers that publish DANE TLSA records, but not to the
point of supporting parameters that lead to widespread breakage.
Since PKIX & SMTP are oil and water, the opportunistic DANE TLS
protocol has to define PKIX out of scope, because PKIX only works
for sites that coordinate their settings, while opportunistic DANE
TLS kicks-in automatically on the fly.
> I also bet you some large corporation or government agency
> somewhere has some requirement to publish CA-validated certs only, and
> thus would need to publish these usages anyway.
That's nice, and yet they too send unecrypted email to most of the world,
and unauthenticated email to sites with self-signed certs, ...
Their hypothetical policies don't match the reality of SMTP. They
can cut off their nose to spite their face, and refuse to do DANE
because DANE does not support PKIX, but they get no authentication
at all.
They can still do PKIX by hand with specific peers, just like
they've been doing (and I did for a decade at Morgan Stanley).
DANE does not trump local policy. However SMTP TLS at Internet
scale cannot tolerate PKIX. That's a fact I cannot legislate away.
> I think it is better said that clients SHOULD process these TLSA
> records and MAY treat them as the corresponding PKIX-less variants.
> (And leaving it stated that servers SHOULD NOT publish these
> variants.)
No, clients SHOULD NOT process these records, as they will lead to
widespread email outages and much disappointment for publishers of
such records.
> -------------------
>
> Is it really necessary to include the Reference Identifier Matching in
> 2.3.2.3? It can't be referenced in another document? The behavior
> seems different from what is actually valid in other contexts, and
> omits some restricts as I understand them.
Yes, it is necessary to describe RFC 6125-style semantics for this
new SMTP with TLS protocol. And yes it needs to be different from
prior documents which only ever covered MUA to MTA submission at
best.
> Suppose that a DANE TLS client authenticating a TLS server considers
> digest algorithm BETTER stronger than digest algorithm WORSE.
>
> I would suggest renaming these algorithms to something like
> "AlgoBetter" and rephasing it "considers a digest algorithm named
> AlgoBetter to be stronger than...". This avoids the backtracking
> needed to realize that BETTER is a name, and not an emphasized
> adjective.
Sure, makes sense, staging for next update.
> -------------------
>
> If the client sends no SNI extension,
> or sends an SNI extension for an unsupported domain, the server MUST
> simply send its default certificate chain.
>
> To me it seems it would be more appropriate to say that the server
> MUST send some certificate chain, and the choice of which certificate
> chain to send is left undefined.
I guess that makes sense, staging for next update.
> I can submit github PRs for these sometime next week if desired.
I'll take of it. Thanks.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
