Subject: Re: [dane] I-D Action: draft-ietf-dane-srv-07.txt

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 19 Aug 2014 11:24:47 -0600

Hi Viktor, thanks for the continued feedback.

On 7/24/14, 6:57 AM, Viktor Dukhovni wrote:
> On Wed, Jul 23, 2014 at 10:28:59AM -0700, [email-masked] wrote:
>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-srv-07
>
> For now comments on the -07 changes, will review the whole draft
> later.
>
> Section 3.1 paragraph 3 (page 4 line 17):
>
>     If the the entire RRset is "insecure" or "indeterminate", this
>     protocol has not been correctly deployed.  The client SHOULD fall
>     back to its non-DNSSEC, non-DANE behavior (this corresponds to the AD
>     bit being unset).  If the entire RRset is "bogus", the client MUST
>     abort the attempt.
>
> delete [or "indeterminate"], per RFC 4035, from which "indeterminate"
> is reputedly taken, that status is essentially a lookup error
> (failure to determine whether the query zone is opted out or not),
> and so is not a case where the client simply falls back to non-DANE
> behaviour.

What would you suggest the client do in this case?

> Note the words "entire RRset" in paragraphs 3 and 4 are misleading.
> I believe that it is not possible for an RRset to be partially
> secure.  Unless I am mistaken, RRSIGs apply to an RRset, not an
> individual RR.

That comports with my reading of RFC 4035.

> Since we're ultimately looking at an SRV RRset

Correct.

> (possibly after CNAME expansion of the original domain),

Disallowed by RFC 2782, right? Or do you mean expansion of the SRV 
"Name" rather than the SRV "Target"?

> it is
> either secure in full or insecure in full.

That's what we were trying to capture by "entire". But it's just as easy 
to remove the word if it is causing confusion.

> More appropriately,
> "entire" applies not to RRset, but rather "entire chain" of aliases
> (CNAME or DNAME if any) leading to the ultimate SRV RRset.

I find the term "ultimate SRV RRset" to be a bit vague. Do you suggest 
that we spend time and energy in defining it for use in this specification?

> Not continuing with connections to the target service applies when
> the DNS lookup fails ("bogus", "indeterminate", "timeout", ...).

Are you referring to this text?

    o  If the response is "bogus" or "indeterminate", the client MUST NOT
       connect to this target server; instead it uses the next most
       appropriate SRV target.

And are you suggesting that we expand that text to mention additional 
DNS lookup errors (e.g., "timeout")?

> DNS lookup error handling is more comprehensively specified in the
> SMTP draft, and perhaps should be borrowed from that document in
> its entirety.

Yes, Section 2.1 of draft-ietf-dane-smtp-with-dane is indeed quite 
comprehensive. I am hesitant to copy it to draft-ietf-dane-srv primarily 
because copying introduces the possibility of divergence in text and 
secondarily because that text talks about SMTP. It seems safer to me if 
we point to that text from the dane-srv specification.

Peter

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 19 Aug 2014 18:07:17 +0000

On Tue, Aug 19, 2014 at 11:24:47AM -0600, Peter Saint-Andre wrote:

> Disallowed by RFC 2782, right? Or do you mean expansion of the SRV "Name"
> rather than the SRV "Target"?

Yes, the "Name".

> I find the term "ultimate SRV RRset" to be a bit vague. Do you suggest that
> we spend time and energy in defining it for use in this specification?

Just be clear that the text in question is talking about the security
if the sequence of CNAMEs leading to the result, (all the links in
the chain need to be "secure").  The RRset at the end of the chain
is "secure" or not, binary, thus "entire" does not apply to that.

>       connect to this target server; instead it uses the next most

Yes, "bogus" is not the only case in which you skip the target,
and "indeterminate" (as defined in 4035) is best viewed as an error
condition.  All error conditions in resolving the TLSA RRset lead
to skipping the target.

> And are you suggesting that we expand that text to mention additional DNS
> lookup errors (e.g., "timeout")?

All DNS lookup errors, with or without examples of specific ones.
Definitely not limited to just "bogus" and "indeterminate".

> secondarily because that text talks about SMTP. It seems safer to me if we
> point to that text from the dane-srv specification.

Whatever works for you.  There is also a possibility of migrating
that text to the OPS draft, if the WG consensus is that such text
would be better placed there, and used by reference in both SMTP
and SRV.  This of course means that OPS must be published at least
concurrently with SMTP (and SRV) or even before.

-- 
	Viktor.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 19 Aug 2014 13:42:38 -0600

>> rather than the SRV "Target"?

OK. Yes, we might need to account for expansion there. I'm sure you will 
tell me that the SMTP draft addresses this issue, right? ;-)

(I'm not being sarcastic, just in awe of your thoroughness!)

> is "secure" or not, binary, thus "entire" does not apply to that.

Yes, that makes sense.

> Definitely not limited to just "bogus" and "indeterminate".

OK.

> concurrently with SMTP (and SRV) or even before.

Let's see what our WG chairs think about how to proceed.

Peter

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 19 Aug 2014 19:49:49 +0000

> tell me that the SMTP draft addresses this issue, right? ;-)

Yes. :-)

> (I'm not being sarcastic, just in awe of your thoroughness!)

Thanks.  That's how the SMTP draft got to 33 pages...

The thoroughness is a result of writing both the draft and an
implementation of that draft.

-- 
	Viktor.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 25 Aug 2014 19:07:20 -0600

I've been reading the dane-smtp draft and have a further thought...

> we point to that text from the dane-srv specification.

Upon reading the dane-smtp document again, I am thinking more strongly 
that the text in Section 2.1 applies to most application protocols, not 
only SMTP; thus I wonder if we can move it to a more general document.

Chairs & WG, what do you think?

Peter

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 26 Aug 2014 15:35:41 +0000

On Mon, Aug 25, 2014 at 07:07:20PM -0600, Peter Saint-Andre wrote:

> Upon reading the dane-smtp document again, I am thinking more strongly that
> the text in Section 2.1 applies to most application protocols, not only
> SMTP; thus I wonder if we can move it to a more general document.
> 

At the time that was written, the OPS draft was informational, but
this section necessarily contains normative text.  So for lack of
a better place, it was in the SMTP draft.

I'm not sure that section 2.1 is a good fit for the OPS draft,
which is already somewhat of a chimera as a result of a change of
mission from an informational implementation/ops guide to a 6698
update.

What is perhaps missing is a generic document describing DANE
implementation guidelines for opportunistic protocols that use DANE
for "discovery", and implement DANE-based authentication only when
keys are found (this is the use-case addressed by 2.1, though some
or most of it[ might also apply with non-opportunistic scenarios).

There could be a separate document with implementation guidelines
for using DANE for mandatory security (application must use
authentication by local policy, with TLSA RRs for key lookup).

[ Any volunteers?  I need a break from IETF activity after all the
  sturm und drang over the opportunistic security definition draft. ]

Another option may be to move 2.1 into the SRV draft, and use it
by reference from SMTP.  Tony's original documents had most of the
meat in the SRV draft, and SMTP was a thin variant.  The main
difficulty is that SRV does not have an explicit opportunistic or
mandatory mode of operation.  It leaves that question unaddressed.

So moving 2.1 into the SRV document might require at least some
text about differences between opportunistic DANE and mandatory
DANE.

We have a record format in 6698, but we don't yet have a document
that presents a model of how DANE should be used.  And there are
in fact at least two high-level models to describe.

The SRV document is basically DANE with Service Specification
records (http://www.ietf.org/archive/id/draft-ogud-dane-vocabulary-02.txt).

Perhaps the SRV draft should become primarily "Opportunistic
DANE with SSR" (some of the content already makes more sense
in that light), with a section at the end that briefly touches
on how the mandatory SRV use-case might differ?

If so, 2.1 moves to the SRV draft, and the SMTP draft imports it
by reference.  Other bits could move over also (the sections on
the various Certificate usages for example).

This is a difficult question, and another option is to focus and
specify DANE for XMPP (which is looking to use the SRV draft as
its DANE specification) leaving generic SRV for a time when we have
more clarity.  Are there other major application protocols with
SRV records that are gearing up to use DANE?

Here, I think there needs to a vision of how all the pieces fit
together, and somebody to drive it.  At this time, per protocol
documents may be easier to pin down, and SRV is arguably too general.

-- 
	Viktor.