Subject: Re: [dane] WGLC: DANE-SRV & DANE-SMTP

From: Sean Turner <[email-masked]>
Date: Wed, 7 Jan 2015 12:25:05 -0500

Apologies for this being a bit late …

I read the DANE-SRV record, had some nits (Victor also caught ‘em), and support progressing the draft.

Still working on the SMTP draft it’s a big denser.

spt

On Nov 12, 2014, at 23:09, Olafur Gudmundsson <[email-masked]> wrote:

> Dear wg members
> 
> This email message starts a three week WGLC ending on December 4’th at 23:59 UTC. 
> 
> http://tools.ietf.org/wg/dane/draft-ietf-dane-srv
> and 
> https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-13
> 
> These two document are specifying related uses of DANE. 
> Please review the documents carefully, in particular we want to make sure the documents have no 
> contradictions. 
> 
> We need at least 5 members of the working group to state in public that they have read the documents and 
> state what is needed to fixed before the documents are advanced. 
> 
> I will act as document shepherd for these two documents. 
> 
> Olafur & Warren
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 8 Jan 2015 01:15:29 +0000

On Wed, Jan 07, 2015 at 12:25:05PM -0500, Sean Turner wrote:

> I read the DANE-SRV record, had some nits (Victor also caught
> 'em), and support progressing the draft.

I think you're saying that the associated revisions can be made as
part of moving into IETF LC, and don't need further WG review? Is
that right?  But being new around here, I am not quite sure.

> Still working on the SMTP draft it's a big denser.

Yeah, sorry about that.  The SMTP draft is a lot more detailed,
because it is applies DANE to a concrete protocol, and so can and
I think should be more specific in its prescriptions.

With RFC 7435 out the door, at least part of the basic premise need
no longer be debated.  We'll need to remember to update the references
from draft-dukhovni-opportunistic-security to RFC7435 at some
convenient point in time.

I did ask a question during LC:

    http://www.ietf.org/mail-archive/web/dane/current/msg07159.html

    ...

    One deployment pitfall discovered in recent interoperability tests
    is that some domains have cleartext-only anti-spam proxies in front
    of their MTA, with the proxies only allowing connections to the
    real MTA once the SMTP client passes a grey-listing check (this
    was observed with "spamd" as the proxy, but any "selective access"
    to TLS can be similarly problematic).

    If the receiving domain publishes TLSA records, this creates a
    catch-22 with DANE-aware client MTAs.  The DANE client never begins
    the first mail transaction, because the proxy does not offer
    STARTTLS, (the proxy is a receiving system deployed downgrade to
    cleartext MiTM in front of the real MTA).

    The short-term solution for such domains is to NOT publish TLSA
    RRs for port 25.  Longer-term the anti-spam proxy should be upgraded
    to support STARTTLS.  For example, the Postfix "postscreen" service,
    which has functionality similar to "spamd", supports STARTTLS so that
    grey-listing does not amount to a similar downgrade attack.

    I'd like to add some language about avoiding this problem in the
    operational considerations section of the smtp-with-dane draft.
    Any objections?  

    Additional operational considerations might include not forgetting
    to update TLSA RRs for *all* the names under which a server might
    be known when doing key rotation.  This is a problem particularly
    when a single wild-card certificate is deployed on all the MX hosts,
    and replaced concurrently on them all, creating an immediate outage
    for any domains that use variant MX host names (for flexibility of
    later hosting some domains separately).  With DANE one should
    strongly consider per-server certificates to avoid synchronized
    multi-MTA outages.

    And lastly, by far the most common problems are with DNSSEC.  A
    mixture of failure to perform timely re-signing and at present lots
    of domains with nameservers that have non-working Denial of Existence.
    I don't have a comprehensive list of software that is deficient in
    this manner, but it seems that some older versions of PowerDNS
    botch DoE in at least some configurations.  Similar issues reportedly
    with djbdns DNSSEC patches.  A few domains have firewalls that
    block TLSA queries, one blocked these only for IPv4 clients, with
    IPv6 clients not filtered, that can create difficult to diagnose
    problems.

    So I am looking for guidance on how much *current* operational
    experience to include in the draft that may ultimately become
    irrelevant as the infrastructure improves, but may be very useful
    to get us past the initial deployment hurdles.  If we don't get
    early adopters past the initial problems, the long-term obsolescence
    of the issues might remain forever in the future.

Any feedback on that would be appreciated, plus guidance on *when* to
make any such changes.

-- 
	Viktor.

P.S.

As for deployment stats, my curated list now has 794 domains, but
not all of that is recent growth, some is due to an additional data
source that contributed 241 domains.  The domain count for my
original sources grew from 463 to 553 over the last month.

The count of domains for which TLSA lookups break stands at 2561,
with 2352 of them attributable to 3 .nl and 1 .cz hosted DNS
providers:

    910 transip.nl
    852 forpsi.cz
    453 hostnet.nl	
    137 ns0.nl

I'm told that the above registrars, which account for the bulk of
the deployment barriers, are working on it, and I am still optimistic
that this will be addressed over the next few months.

Anyone reading this who is operating PowerDNS older than 3.3.1,
should upgrade, as older versions generally exhibit interoperability
issues (incorrect denial of existence).

---

From: Sean Turner <[email-masked]>
Date: Thu, 8 Jan 2015 17:23:30 -0500

> that right?  But being new around here, I am not quite sure.

Yes - let’s get this one out the door.

spt

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 08 Jan 2015 15:26:04 -0700

> Yes - let’s get this one out the door.

Truth be told I haven't had time to review Viktor's proposed edits yet 
and I thought he was going to be posting more feedback, but if he's done 
then the authors can have a chat about how to address his input.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 8 Jan 2015 22:31:10 +0000

On Thu, Jan 08, 2015 at 03:26:04PM -0700, Peter Saint-Andre - &yet wrote:

> Truth be told I haven't had time to review Viktor's proposed edits yet and I
> thought he was going to be posting more feedback, but if he's done then the
> authors can have a chat about how to address his input.

My last review message said I was done.  Sorry if it was not
sufficiently obvious.

-- 
	Viktor.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 08 Jan 2015 15:36:44 -0700

> My last review message said I was done.  Sorry if it was not

I've been so busy with day-job responsibilities that I haven't read any 
of your messages. :(

But Matt and I plan to meet in person late next week so we'll have a 
little authors' meeting and figure out next steps.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 15 Jan 2015 19:40:54 +0000

On Wed, Nov 12, 2014 at 06:09:41PM -1000, Olafur Gudmundsson wrote:

> This email message starts a three week WGLC ending on December 4th at 23:59 UTC. 
> 

On Thu, Jan 08, 2015 at 05:23:30PM -0500, Sean Turner wrote:

> Yes - let?s get this one out the door.

> authors can have a chat about how to address his input.

So where are we with the LC?  Are we waiting for Sean to finish
reading the SMTP draft?  For the SRV draft authors to mull over my
comments?  Or just stalled for lack of momentum?

-- 
	Viktor.

---

From: Sean Turner <[email-masked]>
Date: Thu, 22 Jan 2015 16:23:36 -0500

> Please review the documents carefully, in particular we want to make sure the documents have no 

Apologies again for being late.  Here are my comments on the DANE SMTP draft.  Though pretty dense, I think this is a well written document that does a good job explaining why you might want to deploy this as well as how to deploy it.  Got one major (procedural thing) but the rest are editorial:

This is procedural but I guess it’s major:

Am I right that this draft is using the new definition for DANE-EE that is documented in draft-ietf-dane-ops?  Don’t we have to wait for it to update RFC 6698 or does this specification have to indicate that it updates RFC 6698?

Nits:

0) s1.1, delayed delivery: r/When an MTA is unable forward/When an MTA is to unable forward

1) s1.1, delayed delivery: Might be good to have a forward reference to “mandatory DANE TLS” in the later section or add it as a definition in s1.1.

2) s1.1: Couldn’t hurt to have informative references to DNS RR and RRSet.

3) s1.2: r/Certificate Authority/Certification Authority

4) s1.3.2: r/and requiring/and require

5) s1.3.3: What I think you’re trying to say here:

 Sending systems are in some cases explicitly configured to use TLS
 for mail sent to selected peer domains.   This requires sending MTAs
 to be configured with appropriate subject names or certificate
 content digests to expect in the presented server certificates.

is this:

 Sending systems are in some cases explicitly configured to use TLS
 for mail sent to selected peer domains, but this requires configuring
 sending MTAs with appropriate subject names or certificate
 content digests from their peer domains.

6) s2.1.3: I think if we’re going to have a “MUST NOT” for something it’s probably worth a pointer to the definition in RFC 4033 for "Security-Oblivious stub-resolvers” or add it to s1.1 and point to RFC 4033.

7) s2.2.1: The text about MAT delivery logs made me wonder where the rest of the normative behavior is for MTA delivery logs and whether this text is updating that text.

8) s3.1: Should this be "RECOMMEND":

  In summary, we recommend the use of either "DANE-EE(3) SPKI(1)
  SHA2-256(1)" or "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA records
  depending on site needs.

9) s3.1: Maybe reword:

 The mandatory to support digest algorithm in [RFC6698] is
 SHA2-256(1)

to: 

 As specified in [RFC6698], the mandatory to implement digest
 algorithm is SHA2-256(1).

10) s3.2.3: r/must be entire/must be the entire

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 22 Jan 2015 22:08:56 +0000

On Thu, Jan 22, 2015 at 04:23:36PM -0500, Sean Turner wrote:

> This is procedural but I guess it's major:
> 
> Am I right that this draft is using the new definition for DANE-EE
> that is documented in draft-ietf-dane-ops?  Don't we have to wait
> for it to update RFC 6698 or does this specification have to indicate
> that it updates RFC 6698?

Indeed the semantics of DANE-EE(3) are the same in both the ops
and smtp-with-dane drafts.

The ops draft ammends the semantics for all use-cases of the TLSA
record by updating 6698.  The smtp-with-dane draft makes the same
change only for opportunistic DANE TLS used in MTA to MTA SMTP.

The history is that the decision to turn the ops draft into a 6698
update happened rather late, and until that time, only the smtp
draft had the requisite normative language.

I don't know to best deal with this procedurally.  One might say
that both drafts update 6698, or that only the ops draft does that,
and the smtp draft applies just narrowly to the protocol at hand.

I don't have any views on the logistics.

> 0) s1.1, delayed delivery: r/When an MTA is unable forward/When an MTA is to unable forward

    Muphry bites, but I know what you mean thanks.

> 1) s1.1, delayed delivery: Might be good to have a forward
> reference to "mandatory DANE TLS" in the later section or add it
> as a definition in s1.1.

I'll add a forward reference, unless there is good reason to extend
the terminology.

> 2) s1.1: Couldn?t hurt to have informative references to DNS RR and RRSet.

Sure.

> 3) s1.2: r/Certificate Authority/Certification Authority

Indeed, I thought I fixed all of those...

> 4) s1.3.2: r/and requiring/and require

This is a rather long sentence, but its high level
structure is:

    One might try to ... by using ... and requiring ...

So I think that "requiring" agrees better with the
preceding parts.  It might be clearer with an
extra "by":

    One might try to ... by using ... and by requiring ...

Or a rewrite of the whole sentence.

> 5) s1.3.3: What I think you're trying to say here:
> 

These looks largely the same to me, your version is fine too.

> 6) s2.1.3: I think if we're going to have a "MUST NOT" for
> something it's probably worth a pointer to the definition in RFC
> 4033 for "Security-Oblivious stub-resolvers? or add it to s1.1 and
> point to RFC 4033.

Makese sense.  The larger question is whether this is really the
right place for a MUST NOT.  If the client gets this wrong it is
insecure (never sees any "secure" domains and never uses DANE),
but it is still interoperable.  What's the right way to tell clients
that they don't get any security if their recursor is oblivious?

> 7) s2.2.1: The text about MTA delivery logs made me wonder where
> the rest of the normative behavior is for MTA delivery logs and
> whether this text is updating that text.

I don't think there is any such text anywhere else.  The closest
you'll find is "no misrepresentation of security" in RFC 7435
(opportunistic security) of which this is an instance.

>   SHA2-256(1)" or "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA records

Sure, if there are no objections.

>  algorithm is SHA2-256(1).

Yes.

> 10) s3.2.3: r/must be entire/must be the entire 

Yes.

When should the suggested changes be made?

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 23 Jan 2015 04:19:31 +0000

> When should the suggested changes be made?

Whether the requested changes need a -14 version as part of WG LC
or will be reviewed as part of IETF LC, they are available for
review at:

    https://github.com/vdukhovni/ietf/commit/287ca65902e0085648f126bb6d8f59124dcf463d

Nothing has been changed in relation to the DANE-EE(3) redefinition
procedural question.

-- 
	Viktor.

---

From: Sean Turner <[email-masked]>
Date: Thu, 29 Jan 2015 10:43:42 -0500

> I don't have any views on the logistics.

Multiple drafts can update one draft so if you want to save time you can just add
"Updates: 6698 (once approved)" to the header of both drafts and you’d be procedurally covered.  Well I guess technically, you need to also say “This draft updates RFC 6698” or something like that in the abstract of the nits checker will complain.

> I'll add a forward reference, unless there is good reason to extend

Nope that’ll work.

> Indeed, I thought I fixed all of those…

> Or a rewrite of the whole sentence.

I re-read it leave it as is.

> These looks largely the same to me, your version is fine too.

Yeah just moving some words.

> that they don't get any security if their recursor is oblivious?

I think doing it here is fine.  There might be other places we’d also do it, but here I think is a fine place to start.

> (opportunistic security) of which this is an instance.

This is good to know and personally I’m fine with it.  I wonder if the mail folks won’t come unglued about this though because it’s imposing some kind of requirements on the MTA.  But, let’s see what they say before we try to second guess what might make it through.

> Sure, if there are no objections.

I guess we’ll see ;)

> When should the suggested changes be made?

Since we’re changing at least one 2119 keyword, I guess I’d go ahead and spin a new version before IETF LC - but that’s really up to the chairs.

spt

---

From: Warren Kumari <[email-masked]>
Date: Thu, 29 Jan 2015 12:06:41 -0500

> Since we’re changing at least one 2119 keyword, I guess I’d go ahead and spin a new version before IETF LC - but that’s really up to the chairs.

... and I'd like to apologize for us not having actually called this /
answered any of the requests for guidance / actually done anything.

We have been stupidly busy recently (in related news:
https://blog.cloudflare.com/help-us-test-our-dnssec-implementation/) ,
and I've been owing Olafur a call back for a few weeks now. We (the
chairs and our AD) are planning a call in the next few days to discuss
how to make sure we keep things moving...

Y'all (DANE) deserve better and we are working on making that happen...
W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 29 Jan 2015 11:48:44 -0700

On 1/29/15 10:06 AM, Warren Kumari wrote:

> We (the

BTW, Matt Miller and I plan to meet in person next week to work through 
Viktor's feedback on DANE-SRV, too.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 30 Jan 2015 00:07:48 +0000

> Viktor's feedback on DANE-SRV, too.

Thanks.  Once concern beyond the SRV draft itself, is that in UTA
I see an XMPP draft, that delegates all the DANE bits to the SRV
draft, but the SRV draft is not XMPP-specific, and in particular
does not fully lay out requirements for opportunistic clients (as
in server-to-server XMPP where even if TLS may be required,
authentication is IIRC optional and opportunistic).

So there seems to be a specification gap between the generic SRV
document and the actual requirements of XMPP.  It seems to me that
DANE for XMPP is under-specified.  Many of the detailed issues
addressed by the SMTP draft might reasonably apply also to (server
to server) XMPP if the spec were more complete.

Who's doing the XMPP server DANE implementation?  Perhaps the
problem is that either the implementations are not mature and have
tackled all the issues yet, or the implementors have not raised them
to the spec writers...

Or perhaps I my SMTP draft is unnecessarily detailed, and people
should be able to figure all the messy bits out for themselves?

This is again about XMPP, not the SRV draft, but if the SRV draft
is to serve as a complete spec for XMPP with DANE there may be more
than needs to be said (opportunistic authentication use-case, DANE
vs. PKIX usages, ...).

Perhaps the UTA XMPP draft is the place to fill any residual gaps.

-- 
	Viktor.