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

[Stephen Farrell <[e-mail]>]

Hiya,

On 16/04/15 18:37, Viktor Dukhovni wrote:
> On Thu, Apr 16, 2015 at 04:27:33PM +0100, Stephen Farrell wrote:
> 
>> (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;-)
> 
> 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.

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.

> 
>> (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?
> 
> 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. 

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.

> 
> 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
>> as IETF LC comments.
>>
> 
> Responding to a subset, leaving out mostly editorial fixes.
> 
>> - 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.
> 
> 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.

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).

> 
>> - 2.1.1, the term anchorless should probably 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.)
> 
> 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".

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

> 
>> - 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.

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.

> 
>> - 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?)
> 
> 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.

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

> 
>> - 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.
> 
> 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. ]

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.

> 
>> - 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
> 
> 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.

I'll chime in later.

> 
>> - 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).

Ditto.

> 
>> - 9.2, 2nd para: isn't that repetitive? That seems like a bad
>> idea.
> 
> Are we looking at the same draft version?  Perhaps your 8.2/9.2 is
> 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.

>