Subject: [dane] AD review of draft-ietf-dane-smtp-with-dane

From: Stephen Farrell <[email-masked]>
Date: Thu, 16 Apr 2015 16:27:33 +0100

Hiya,

Sorry for being slow with this but I've finally gotten
my AD review for this done. (See below.)

A couple of things to check before starting IETF LC:

(1) What is the behaviour when all RRs required for this are
published except for no DNSSEC RRs? I have heard tell of some
people who would like to experiment in that way, and would
like to know if the WG have a clear answer for them as to
what ought happen. Is that answer here? (If so, it's fairly
well hidden;-)

(2) Doesn't this need to be consistent with other recent IETF
documents, in particular the generic UTA BCP and deprecating
SSL 3.0? I don't believe it current is entirely consistent
with either. (See minor comments below for details.) Why is
that ok?

The rest (below) are more minor comments, please treat these
as IETF LC comments.

Cheers,
S.

- intro: end of 1st para could reference rfc7435, just to be
sure that the opportunistic term is well defined in this
context

- 1.2, 2nd para: s/trusted public keys/public keys/

- 1.2, 2nd para: s/a new/the/

- 1.2, 3rd para: s/directly delegated/delegated/

- 1.2, 3rd para: s/data integrity/data origin authentication/
TLS provides data integrity for application PDUs in all cases

- 1.3, 2nd para: s/traditional PKI/traditional Web PKI/

- 1.3.1, s/such as the use of PKIX// I don't think that says
anything really and I've no clue what "use of PKIX" might
mean exactly - better left out I'd say

- 1.3.2, s/A PKIX TLS client/A TLS client/

- 1.3.2, The MX lookup is vulnerable as stated but isn't the
A/AAAA similarly vulnerable? I think you ought note that too,
but also that this specification can mean that DNSSEC for
that lookup is not needed based on the name in the MX
response being bound (via x.509 or tlsa) to the TLS server
private key. (Well, that assumes I've gotten that correct:-)
Without DNSSEC for the MX name->address mapping a bad actor
could however, insert themselves into the path and gain
whatever can be gained via traffic analysis of the SMTP/TLS
session.

- 2.1.1, 2nd para: s/must be used/MUST be used/? Not sure
myself, but I'd make it uppercase for emphasis. (Other people
will disagree from all points of view though, no matter what
you do or don't do here;-)

- 2.1.1, the term anchorless should probbaly get a mention in
1.1 with a forward pointer to 2.1.1. Or maybe you can avoid
the term since it's not used much. (Just in 2 adjacent
paragraphs.)

- 2.1.1, what does "securely opted out" mean?

- 2.2, I'd re-phrase "A connection to the MTA MUST be made
using authenticated and encrypted TLS" as "Any connection to
the MTA MUST be made using authenticated and encrypted TLS"
The current text could be read to say that the client MUST
make the connection, whereas I think you just mean if you
do make a connection it MUST use TLS.

- 2.2, Could "authenticated" here mean mutually authenticated
with TLS client certs? If not, maybe say so. (And for the
last sentence before 2.2.1, what about the client cert names
- what's done with those?)

- 2.2, 3rd bullet: Is it a good idea to mix the insecure TLSA
RRSet and validated non-existence in one bullet? I find it
confusing. Maybe it'd be better to have two bullets even if
the new one says "do as above."

- 2.2.1, last para: What is the other, to which the
"Otherwise" at the start of the para applies? That confused
me.

- 2.2.2: bullet 1 - what's that mean? (In this context) This
section generally has a bunch of paragraphs that start with a
conditional, and it's not clear how they all fit.  Could you
add some more structure (e.g. pseudo-code) to clarify?

- 3.1: All but the first and last two paras of this seem to
be repetitive of 6698 and 7218. I don't see that it's a good
idea to do that. (In what is already an over-long document.)

- 3.1.2 - does the MUST include TA in the TLS handshake
conflict with common implementations of 5246?  5246 section
7.4.2, says that the TA MAY be omitted, but I wonder if we
might be causing ourselves trouble (some) with running code.

- 3.1.3, last sentence: is that needed? It seems to
invalidate the sentence before. (And it's vague.)

- 3.2.2, various places: "MUST be included" where?

- 8.1, para 1: We've (the IETF) just deprecated SSL 3.0, [1]
so don't you need to reference that and say to not do that?
At least the MAY at the end of that paragraph seems not to
conform with the BCP. I think a ref to [1] is needed.

   [1] https://tools.ietf.org/html/draft-ietf-tls-sslv3-diediedie

- 8.2: This is alrady handled by the generic UTA BCP. Why is
it needed here?

- 9.2, 2nd para: isn't that repetitive? That seems like a bad
idea.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 16 Apr 2015 17:37:23 +0000

> what ought happen. Is that answer here? (If so, it's fairly

The specified and implemented (Postfix and Exim) behaviour is that
the records are ignored when not "secure".  Thus DNSSEC is a
prerequisite.  Opportunistic TLS happens anyway (even without TLSA
record validation), so it is not clear why one would bother with
incomplete (easily defeated) attempts at protecting against active
attacks.

> with either. (See minor comments below for details.) Why is

This is an opportunistic protocol, hence some security is better
than none.  If all that the server has is SSL 3.0, it can still
publish TLSA RRs, and POODLE et. al, are primary attacks on HTTPS
not SMTP.

In any case this draft was ready (and has been largely unchanged)
for about a year now, *before* all the fuss about SSL 3.0.  Clients
MUST support at least TLS 1.0 (to use SNI).  Servers MAY support
SSL 3.0 (allowing them to publish TLSA RRs with whatever they're
running today).  At this point we can set the floor at TLS 1.0 if
that's better "optics", the number of servers doing just SSL 3.0,
whose admins might be tempted to publish DANE TLSA RRs is likely
zero.

There is no reason to require anything beyond SSL 3.0 (server-side)
in this protocol, and it does not preclude other documents from
setting a higher bar.

> The rest (below) are more minor comments, please treat these

Responding to a subset, leaving out mostly editorial fixes.

> whatever can be gained via traffic analysis of the SMTP/TLS

The address records are not security relevant.  MX is because
authenticating the origin domain does not work, and the MX,
absent DNSSEC, is insecure (but widely done anyway).

While, the A records don't a-priori need to be secured, we skip
TLSA records for MX hosts whose A/AAAA records are "insecure" in
order to avoid interop problems with (Microsoft's and similar)
domains whose non-DNSSEC nameservers are allergic to unsupported
RRtypes (the "mail.protection.outlook.com" nameservers botch
TLSA queries).

Traffic hijacking can be done with BGP (this is far more common,
and is more difficult to observe) even without changing the addresses.
Or by tapping into the cables.

> - 2.1.1, the term anchorless should probably get a mention in

Yeah, that's a bit tricky, just need some way to avoid local
repetition and to make it clear when we're describing the "4034"
type of "indeterminate" once the definition of the term is aligned
with "4035".  Specific suggestions welcome, if this is important
to "fix".

> - 2.1.1, what does "securely opted out" mean?

That's about a parent domain providing proof of non-existence of
DS records, possibly with NSEC or NSEC3 for the domain itself, or
perhaps via NSEC3 for neighbour domains with the opt-out bit set.
Thus the domain is an "insecure" sub-domain of a "secure" parent
domain.  I'm open to better language if the current is confusing.

> - what's done with those?)

There is no protocol for specifying mutual authentication until
someone (I volunteered) writes the DANE draft for locating client
TLSA RRs and how that works for SMTP.  Some of the signaling
(client -> server: please check for my TLSA records) will be
application protocol specific.

> might be causing ourselves trouble (some) with running code.

No, this is not a conflict.  5246 allows a shorter chain,
but does not require it.  With DANE the "optimization"
is not available.

Since verification without the TA cert is impossible, there is no
choice.  The requirement is a statement of logical fact, not a
design choice.

Running code is working just fine.  The only real consequence is
that some Microsoft (surprise?) Exchange servers reportedly can't
actually add self-signed certs to their chain, so if they use a
DANE-TA(2) trust anchor, it needs to be an intermediate.  [ Either
the admin tooling, Schannel, or something else in the stack does
not make it possible to specify a server chain that includes a root
CA. ]

>    [1] https://tools.ietf.org/html/draft-ietf-tls-sslv3-diediedie

See above.  The BCP does not claim applicability to opportunistic
TLS.  This protocol is (still) opportunistic TLS, but with
authentication not just unauthenticated encryption.  However, at
this point SSL 3.0 has largely been phased out, so raising the bar
to TLS 1.0 would have little practical effect.  Server operators
will ignore whatever we say here anyway and will support whatever
they support.  So whatever you want for "optics" is fine, though
I still don't like erecting needless hurdles as a matter of principle.

> - 8.2: This is already handled by the generic UTA BCP. Why is
> it needed here?

I don't see any discussion of anon-DH in the UTA BCP (which in any
case disclaims applicability to opportunistic TLS).

> - 9.2, 2nd para: isn't that repetitive? That seems like a bad

Are we looking at the same draft version?  Perhaps your 8.2/9.2 is
not what I'm looking at (version 15).

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 16 Apr 2015 13:50:42 -0400 (EDT)

> whose admins might be tempted to publish DANE TLSA RRs is likely

DANE should not say which TLS version to use. Leave that up to the TLS
working group ?

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 16 Apr 2015 17:59:37 +0000

> DANE should not say which TLS version to use. Leave that up to the TLS

Well, since the client MUST SNI, it must support at least TLS 1.0
and send an SSL 3.0 compatible HELLO (so SSL 2.0 is definitely
out).  Therefore, the server logically needs to support at least
SSL 3.0, which is what I said, but perhaps as you note silence may
suffice.

So, should we not mention TLS versions at all, and just mention
SNI, with the reader making the "obvious" conclusions?  I prefer
to make things explicit so that implementations don't make silly
mistakes.

-- 
	Viktor.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 16 Apr 2015 19:28:58 +0100

Hiya,

> incomplete (easily defeated) attempts at protecting against active

My understanding is that some people wanted to experiment with TLSA
without having to have had DNSSEC deployed. But I take your answer
to be that no such behaviour is defined here, which is fine. So
consider this one answered.

> whose admins might be tempted to publish DANE TLSA RRs is likely

I see Paul has replied so I'll see how the discussion develops
and join in later.

A few bits more below on the non-blocking things.

> Or by tapping into the cables.

So I think the threat is that someone who fakes the A record
can do traffic analysis as they can direct the SMTP and STARTTLS
traffic through their chosen host. I think that's work noting,
in and of itself. If we had more to say (that's well founded)
about traffic analysis if SMTP/TLS that'd be interesting but I'm
not familiar with any work in the space (though I've not looked).

> with "4035".  Specific suggestions welcome, if this is important

I'm fine if you just take a peek again and decide what to do.

> domain.  I'm open to better language if the current is confusing.

I think that's needed, or perhaps a reference. In my reading I
never even considered DS RR's. Now that might be my relative
ignorance of DNSSEC terminology, but that's a new one on me so
please either define it if it's a neologism or else just add a
reference if it's a know term of art.

> application protocol specific.

Could be worth saying that mutually authenticated TLS is out
of scope so servers SHOULD (or MUST) NOT send a certificate
request.

> not make it possible to specify a server chain that includes a root

Ok, it's that latter I was after. If someone maintains that those
specific server deployments are significant they can make that
case during last call I guess. Ta.

> I still don't like erecting needless hurdles as a matter of principle.

I'll chime in later.

> case disclaims applicability to opportunistic TLS).

Ditto.

> not what I'm looking at (version 15).

Sorry, I meant that lots of 9.2 repeats things said earlier in
this document.

Cheers,
S.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 16 Apr 2015 18:45:18 +0000

> not familiar with any work in the space (though I've not looked).

Note that for this protocol, both the address records and the TLSA
records of the MX host are DNSSEC-validated, since when the address
records are not, we don't even ask for the TLSA RRs.  So I am not
sure what you have in mind...

When the MX host's DNS zone is signed, both the address and the
TLSA records are signed, and off-path attackers don't get to use
DNS to redirect the traffic to addresses that are on-path.  They
are of course still free to attempt to mess with the routing layer
to whatever extent possible.

> of scope so servers SHOULD (or MUST) NOT send a certificate

Some SMTP servers send certificate requests anyway, most don't.
Sending MTAs, most of which are not configured with client certs,
just ignore the requests.  Receiving MTAs complete the handshake
even if no client certificats are sent, but don't grant whatever
additional access rights one may get with some particular client
cert (or simply can't, when absent, record any client cert details
in "Received" headers or mail logs).

So there's nothing really to say here, we're not changing the status
quo in any way (yet).  Once there's a protocol for client TLSA RRs,
then there'll be something to say.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 16 Apr 2015 15:10:33 -0400 (EDT)

> consider this one answered.

I go back and forth with this one. It seems there is no good reason
not to use an insecure trust anchor over no trust anchor, but the UI
would have to be clearly different, which is where the real problem is
I think. We could easilly use unsigned TLSA over completely unverified
TLSA, but it would not be a good test because you cannot accept it as
equal security in the UI without it becoming a downgrade attack.

Those who want to test could add their zone to the DLV, at least for
now - or configure a local trust anchor, if they are okay with a
signed zone without DS record.

Paul

---

From: Jeremy Harris <[email-masked]>
Date: Thu, 16 Apr 2015 20:36:51 +0100

> of scope so servers SHOULD (or MUST) NOT send a certificate

This seems excessive; one could not then use both DANE/SMTP
and some future specification for authenticating the client.
Surely "out of scope" is sufficient?
-- 
Jeremy

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 17 Apr 2015 13:17:45 +0100

> signed zone without DS record.

I still think I've been answered but just to clarify. The context
here has no UI at all given it's between MTAs. And the people who
wanted to experiment I believe wanted to play about with no DNSSEC
at all, rather than with local trust anchors for DNS.

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 17 Apr 2015 13:18:15 +0100

> Surely "out of scope" is sufficient?

Fair enough. That'd be fine by me. (And bear in mind this was
just offered as a LC comment, not blocking in any way.)

Cheers,
S.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 17 Apr 2015 08:24:40 -0400 (EDT)

On Fri, 17 Apr 2015, Stephen Farrell wrote:

> here has no UI at all given it's between MTAs.

That's not entirely true, surely the people testing will check
the Received: headers for feedback on how the encryption went.

> And the people who

That does raise the question of what you are testing? While you might
be able to test whether a transport was encrypted between two mail
servers based on a TLSA key from DNS, you won't be testing whether a
forged or bad DNS entry will cause the email to be queued up for later
to protect it from being sent cleartext or encrypted via a forged key.

Paul

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 17 Apr 2015 13:58:34 +0100

Hiya,

> sure what you have in mind...

Yep - this could be me being confused. If there's no way in which
the MX and TLSA can be properly signed but where the A is not, then
I agree my comment is moot and no change is needed.

Cheers,
S.

PS: The rest below is fine.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 17 Apr 2015 16:39:42 +0000

> I agree my comment is moot and no change is needed.

Well, though I don't know why we'd care protecting about the address
records also (given routing layer attacks), ...  There is (full
disclosure) a corner case where the address records are not secure,
but the TLSA records are.

The case in question is a CNAME alias chain whose starting point
(the "owner" name of the initial CNAME) is in a signed zone, but
whose end-point is not secure:

    ; CNAME from signed zone into unsigned zone
    ; with TLSA records at start of CNAME chain.
    ;
    example.com. CNAME example.net.
    example.com. RRSIG CNAME ...
    _25._tcp.example.com. TLSA 3 1 1 ...
    _25._tcp.example.com. RRSIG TLSA ...

    ; Address records are in an unsigned zone
    ;
    example.net. IN A 192.0.2.1

In this case, mail to example.com is sent to the "insecure" IP
address of example.net, with "secure" TLSA RRs coming from example.com.

This case is rather rare, because most domains have MX records
(rather than just receiving email at their A/AAAA records), and MX
hostnames are supposed to not be aliases (and rarely are).  Rare
violators of the MX hostname is not a CNAME are however tolerated
by most MTAs, and so Postfix will occasionally deliver mail to an
authenticated peer via unauthenticated A records.

Of course the administrator of the receiving domain willingly
aliased their signed zone's hosts into an unsigned namespace.

-- 
	Viktor.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 17 Apr 2015 12:47:45 -0400

> On Apr 16, 2015, at 2:28 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 

Stephen, I want to remind you of the conversations we had before and after the IETF meeting in 
Tapei, when this topic was going in circles. 
Conclusion of discussion: DANE REQUIRES DNSSEC <full stop> 

if someone wants to publish TLSA records w/o DNSSEC that can work in their environment but it is not
going to be globally visible. 
This and other WG document should not be in conflict with the principle above. 

Olafur

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 17 Apr 2015 17:01:03 +0000

On Fri, Apr 17, 2015 at 12:47:45PM -0400, Olafur Gudmundsson wrote:

> If someone wants to publish TLSA records w/o DNSSEC that can work in their environment but it is not

I don't disagree, but to be fair, the original DANE discussions
were likely not about opportunistic protocols.  With opportunistic
uses of DANE, one can argue that if "insecure" TLSA records are
published, one might as well use them.

Thus, for example, when address records are reported "insecure",
instead of bypassing TLSA lookups, to avoid the potential interop
issues, one could simply make "TLSA" lookup failure non-critical
and then use "insecure" TLSA records when available, without claiming
any security.  Just log authentication failures, but deliver anyway.

Such a mode of operation is not specified in the draft.  I don't
know whether there would be much demand/adoption of such an
"variant" of the protocol.

The present draft is a defense against active attacks, the variant
would be some sort of tamper-evidence, though it is not clear
exactly what "sort" unless the TLSA records observed are recorded,
and regularly analyzed for "anomalies".

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Fri, 17 Apr 2015 15:26:17 -0500

On Fri, Apr 17, 2015 at 12:47:45PM -0400, Olafur Gudmundsson wrote:
> Stephen, I want to remind you of the conversations we had before and
> after the IETF meeting in Tapei, when this topic was going in circles. 

+1

> if someone wants to publish TLSA records w/o DNSSEC that can work in
> their environment but it is not going to be globally visible. 

There's nothing wrong when unsigned TLSA RRSets being publicly visible.

What's wrong is shipping code that uses unsigned TLSA RRSets.

To test, I'd use a recursive, validating server, and prime its cache (or
the stub resolver's).  Done.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 17 Apr 2015 15:31:56 -0500

> whose end-point is not secure:

This sort of thing is fine in general: get the TLSA RRSet for the
original name, chase aliasing regardless of whether aliasing RRs are
signed, then insist on the server using certificates that validate
per-the TLSA RRSet found in the beginning.  Though preferably we should
sign everything -- it's easier to think about this.  Changing the origin
is a different -but related- topic, about which see the threads from the
URI RR's IETF LC.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 17 Apr 2015 15:41:56 -0500

> at all, rather than with local trust anchors for DNS.

As Paul says, there is a UI here: logs for sysadmins, Received headers
for users and sysadmins.

For testing, just prime a cache at the validating resolver.

Incidentally, testing with DNS is hard.  The biggest problem, of course,
is hardwiring the port number, which means that automated tests can't
simply spin up a server on some other port, which then means that VMs
with virtualized networking are needed in order to automate tests, which
then completely changes how tests run (i.e., "make check" won't do,
and/or it will be slow).  Of course, the fact that DNS is always on port
53 has its benefits, but an option to put NSs on a different port would
sure help.  Stub resolvers can help by having an option for priming a
cache (including pretending that the records in the cache were signed,
and the signatures validated).

Nico
--

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 18 Apr 2015 00:10:55 +0100

> but the TLSA records are.

Right, that's what I was wondering about.

I think the question for the WG is whether or not to
note that that allows for potential traffic re-direction
and traffic analysis of the TLS protected data.

You are also correct that this could be done via BGP (and
is perhaps more likely to be done) but if one was worried
about this, then the error could also be done at this level
(as shown by your example) which is an argument to call
this out but not get into BGP issues.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 18 Apr 2015 00:13:17 +0100

> As Paul says, there is a UI here: logs for sysadmins, Received headers

Paul's initial mail on this referred to UI and downgrade
attack possibilities. I don't believe there is any such UI
related downgrade attack in this case, but if there is, I'd
be interested.

S.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 18 Apr 2015 02:25:47 +0000

> Right, that's what I was wondering about.

Almost no domains lie in this corner case.

> and traffic analysis of the TLS protected data.

I don't see why opportunistic DANE TLS for SMTP should attempt to
protect against this "attack", which even mandatory TLS for HTTPS
ignores.  The folks interested in traffic analysis will learn what
they need whether the IP addresses are forged or not.  In fact I
rather doubt they'd want to be that visible just for traffic
analysis.

> this out but not get into BGP issues.

I'd prefer to not discuss this side-track in the draft.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 17 Apr 2015 23:21:04 -0400 (EDT)

> related downgrade attack in this case, but if there is, I'd

In case of this email of yours, my UI has elements like:

Authentication-Results: bofh.nohats.ca; dkim=pass
     reason="1024-bit key; unprotected key"
     header.d=ietf.org header.i=@ietf.org header.b=x912mqog;
     dkim-adsp=none (unprotected policy)

It might not be a fancy colourful padlock, but it's a UI :)

Paul

---

From: [email-masked]
Date: Sat, 18 Apr 2015 09:50:48 +0000

On Sat Apr 18 03:25:47 2015 GMT+0100, Viktor Dukhovni wrote:
> protect against this "attack",

I wasn't arguing to protect against this but to document the security consideration. Sorry if that wasn't clear. And it's still ok if the wg prefer to not mention it.

S.

> which even mandatory TLS for HTTPS
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 20 Apr 2015 16:01:25 +0000

Should I cut another version with editorial changes based on your
review prior to IETF LC?

-- 
	Viktor.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 20 Apr 2015 17:08:45 +0100

> Should I cut another version with editorial changes based on your

I guess that's one for the WG chairs.

But I don't think we bottomed out on the TLS versioning thing and
the relationship with recent related BCPs did we?

Thanks,
S.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 20 Apr 2015 16:34:49 +0000

> I guess that's one for the WG chairs.

OK.  Any word from the chairs then?

> the relationship with recent related BCPs did we?

I don't expect much/any further discussion.  I am ready to replace
all mention of SSL 3.0 with TLS 1.0.  Given that the protocol is
opportunistic, requiring anything stronger is I think counter-productive.

Can we move forward with s/SSL 3.0/TLS 1.0/g?  This modifies just
the first paragraph of 8.1 and is not a big deal.

I don't recall seeing any other recent BCPs at issue in this thread.

-- 
	Viktor.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 20 Apr 2015 12:51:59 -0400

> On Apr 20, 2015, at 12:34 PM, Viktor Dukhovni <[email-masked]> wrote:
> 

Update,

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 20 Apr 2015 20:36:39 +0100

> I don't recall seeing any other recent BCPs at issue in this thread.

One could encourage adhering to the generic UTA BCP though
as well right?

If the WG don't pushback at me (and please do if I'm wrong),
I think s/SSL 3.0/TLS 1.0/g and adding a recommendation to
follow the UTA BCP would be just fine to move forward. (I'm
ok if the UTA BCP is a SHOULD or RECOMMENDED and could live
with a non-2119 type recommendation either.)

S.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 20 Apr 2015 21:03:05 +0000

> One could encourage adhering to the generic UTA BCP though

There is AFAIK no UTA BCP for opportunistic TLS.

Even though once usable TLSA records are found (DANE) authenticated
TLS becomes mandatory, the client is (a-priori) opportunistic and
was willing to send cleartext.

The client is honouring the server's preference for authenticated
TLS, but should not be unduly strict with respect to the server's
TLS protocol capabilities, which are not advertised as part of the
TLSA records which the client uses to "commit" to using TLS.

Opportunistic DANE TLS will be disabled by users if it enforces
TLS settings with which more a negligible fraction of servers cannot
comply.  This protocol needs to have conservatively low expectations
of server TLS capabilities.  What that means will vary over time.

What Postfix does when TLS is mandatory is to disable low-grade
ciphersuites and obsolete TLS protocol versions.

    http://www.postfix.org/postconf.5.html#smtp_tls_mandatory_ciphers
    http://www.postfix.org/postconf.5.html#smtp_tls_mandatory_protocols

Are you looking for something that elaborates on the text below
from Section 3 of RFC 7435?

   With unauthenticated, encrypted communication, OS protocols may
   employ more liberal settings than would be best practice when
   security is mandated by policy.  Some legacy systems support
   encryption, but implement only outdated algorithms or protocol
   versions.  Compatibility with these systems avoids the need to resort
   to cleartext fallback.

   For greater assurance of channel security, an OS protocol may enforce
   more stringent cryptographic parameters when the session is
   authenticated.  For example, the set of enabled Transport Layer
   Security (TLS) [RFC5246] cipher suites might exclude deprecated
   algorithms that would be tolerated with unauthenticated, encrypted
   communication.

In particular the second quoted paragraph hints at the possibility
of being a bit more strict when authentication is mandatory and
active attack protection is expected.

What specifically in the UTA BCP should be referenced in this draft?
 
-- 
	Viktor.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 20 Apr 2015 22:12:56 +0100

> There is AFAIK no UTA BCP for opportunistic TLS.

Agreed.

> Opportunistic DANE TLS will be disabled by users if it enforces

Did I mention "enforcing"? If so that wasn't what I meant.

But in any case, the UTA BCP is designed not to require things
that aren't commonly available.

>    algorithms that would be tolerated with unauthenticated, encrypted

No, not that I think.

> What specifically in the UTA BCP should be referenced in this draft?

How about:

"BCPxxx [draft-ietf-uta-tls-bcp] documents current best practice
recommendations for TLS, e.g. which ciphersuites are best to adopt
etc. Implementations and deployments are encouraged to adopt those
practices."

Cheers,
S.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 22 Apr 2015 06:13:27 +0000

On Thu, Apr 16, 2015 at 04:27:33PM +0100, Stephen Farrell wrote:

>        using authenticated and encrypted TLS" as "Any connection to the
>        MTA MUST be made using authenticated and encrypted TLS" The current
>        text could be read to say that the client MUST make the connection,
>        whereas I think you just mean if you do make a connection it MUST
>        use TLS.

Adopted in -16, please check.

> 	   the term since it's not used much. (Just in 2 adjacent

Rewritten (improved I think, thanks) in -16 to avoid "anchorless".

> - 2.1.1, what does "securely opted out" mean?

Rewritten in -16 to clarify.

> - what's done with those?)

Per the list discussion, no client authentication.  Definition
rephrased in -16 to make the meaning more clear.

> "Otherwise" at the start of the para applies? That confused

Rewritten in -16 to clarify this as 'When not "insecure"'.

> add some more structure (e.g. pseudo-code) to clarify?

Reworked the bullets and paragraph above to make this clearer
in -16.

> idea to do that. (In what is already an over-long document.)

Fat trimmed in -16, leaving just the meat and bones.

> invalidate the sentence before. (And it's vague.)

NEW (in -16):

    SMTP client treatment of TLSA RRs with certificate usages
    PKIX-TA(0) or PKIX-EE(1) is undefined.  As with any other
    unsuppored certificate usage, SMTP clients MAY treat such
    records as "unusable"

> - 3.2.2, various places: "MUST be included" where?

Reworded in -16.

> conform with the BCP. I think a ref to [1] is needed.

Simplified text in -16 omits all mention of SSL 3.0.  Just reminds
the reader that use of SNI precludes SSL 2.0 HELLO.

> - 9.2, 2nd para: isn't that repetitive? That seems like a bad

In -16 dropped the repetition of non-support for usage 0/1.

> whatever can be gained via traffic analysis of the SMTP/TLS

Declined.

> the new one says "do as above."

Any guidance from the WG on this?  I neither see this change as a
compelling improvement, nor am I strongly opposed to it.  Deferred
for now.

> might be causing ourselves trouble (some) with running code.

As discussed on the list, this is not a conflict nor a problem with
running code.

Section 9.2 mentioned the the Microsoft Exchange issue where servers
are unable to send self-signed trust-anchors, and therefore must
not use them in DANE-TA(2) records, employing intermediate TAs
instead.  In -16, shortened and moved that text to 3.1.2.

> - 8.2: This is alrady handled by the generic UTA BCP. Why is

This discusses use anonymous cipher suites in SMTP opportunistic
TLS, which is not covered in the UTA BCP.  Section retained.

-- 
	Viktor.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 22 Apr 2015 07:59:21 +0100

Thanks, will get back to this later on today, by Friday
worst case.

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 23 Apr 2015 17:43:24 +0100

> Thanks, will get back to this later on today, by Friday

Sorry, I didn't get a chance to look that over in detail
and now probably won't tomorrow either, so I've requested
IETF LC start and I'll take a peek at it again during
the LC.

Thanks,
S.