Subject: [dane] Review of draft-ietf-dane-protocol-16

From: Andrew Sullivan <[email-masked]>
Date: Thu, 16 Feb 2012 16:09:25 -0500

Dear colleagues,

I note the WGLC of draft-ietf-dane-protocol-16.  I have read that
document.  I have some comments.

Before beginning, I want to note that the document is, in my opinion,
mostly a model of clarity.  I did not find it terribly hard to read.
I should note also that I am not any sort of authority on TLS or PKIX
(some might say I'm not any sort of authority on anything, but the
point is that I know even less about TLS and PKIX).  Finally, I'm
returning to this document after several weeks in which I've been too
busy to follow the WG's discussion on list in any sort of detail.
This review raises topics as they are first encountered, but then
jumps forward in the draft to discuss other relevant parts of it when
necessary.

Section 2.1.1 has a forward reference to section 4 to describe what
each of the Usage cases does.  Even section 4, however, is not
completely clear to me -- probably because I don't really understand
PKIX.  I think we can safely imagine that some implementers or,
especially, deployers will have a shaky grasp of PKIX, however, and
that the subtleties of each case will be lost on them.  I think that
putting the explanatory text with the definitions would be more useful
-- it was certainly a little confusing to me why they're separated --
but I appreciate that it might be a little late for that sort of major
editorial change.  In any case, a little more explanation of what the
use cases are would really help.  I'm sure there's some reason, for
instance, but I can't figure out why usage 1 and usage 3 aren't in
operation going to be the same.  Usage 2, if I am reading it
correctly, looks a foot-gun loaded for bear.  I saw a message from one
of the editors suggesting removing it; I have no objection.  If it
stays, further expansion of the security considerations discussion
(and a special note forward from usage 2 saying that there's important
implications, see the S.C.) might be nice.

Section 3 starts with a mystifying proviso: "Unless there is a
protocol-specific specification that is different than this one. . ."
This sounds like it's saying, "Unless someone is using a different
protocol. . ."  I don't think the proviso does any harm, but it
strikes me as pretty odd.

In Section 5, there's this: 

     The
   matching or chaining MUST be done within the life of the TTL on the
   TLSA record; using a TLSA record past the lifetime specified in the
   TTL can expose the the TLS client to many types of attacks.

I think this is fine, but I wonder whether it's useful to suggest what
to do if the lifetime ends during the TLS set up.  It seems to me that
could happen on a slow link, for instance, when one got the TLSA out
of the DNS cache and there wasn't much time left on it.  It's a corner
case, and probably not too important.  I just wonder what the
connection initiator ought to do: re-query for TLSA, mark the record
unusable and move on, throw an error?

I seem to recall a previous controversy about this item in section 5:

   o  A TLSA RRset whose DNSSEC validation state is secure MUST be used
      as a certificate association for TLS unless a local policy would
      prohibit the use of the specific certificate association in the
      secure TLSA RRset.

I don't have really strong opinions about it, although it does seem
odd to me that TLSA hereby becomes a way of forcing the application
off the more traditional validation chain absolutely.  If I read this
correctly, if the wrong TLSA record is in the DNS, TLS doesn't work
period.  This makes it hard to test the move to TLSA or to do a
seamless changeover, I think: as soon as you publish your TLSA record,
the existing, working infrastructure you have is broken to any client
that knows how to use TLSA.  Right?  I notice A.4 discusses rolling
once you have TLSA, but there doesn't seem to be anything about moving
from no-TLSA based TLS to TLSA-based TLS.

8.1 notes that the RRTYPE code assignment is going to go through the
expert review process.  I'd suggest someone put the application in
now.  That process has not worked properly in recent cases, and has
been the source of annoying delays.

Section 9 starts with, "The security of the protocols described in
this document relies on the security of DNSSEC as used by the client
requesting A/AAAA and TLSA records."  Is there some special reason why
A/AAAA is called out there?  Presumably it's just the security of
DNSSEC as used by the client requesting any DNS records secured by
DNSSEC, no?  (For instance, if I can change the NS records for your
zone, I can do some clever things too.)

I suspect the sentence (again in 9), "A better design for
authenticating DNS would be to have the same level of authentication
used for all DNS additions and changes for a particular host," ought
to end with, "changes for a particular owner name."  Or something like
that, right?  That is, the host involved in accepting the changes
isn't the issue; the issue is how changes in a zone or for a given
owner name are authenticated.

In the same section, "Thus, such proxies might choose to aggressively
block TLSA requests and/or responses, even though this is not a
recommended practice."  Is the idea here that a proxy notices a TLSA
query going out, and just sinks it so that no response ever returns?
I guess an ANY query might get around this, although I'm not sure.
I'm not sure I get the risk here: is the risk that the client can't
get the TLSA record, or is the risk to the proxy vendors who are about
to get bad news?

I don't understand this paragraph:

   Client treatment of any information included in the trust anchor is a
   matter of local policy.  This specification does not mandate that
   such information be inspected or validated by the domain name
   administrator.

Which trust anchor?  Given that we have a DNSSEC context in here, I'm
worried this might be confusing.  Also, which domain name
administrator?  Is the point that the person operating the
authoritative zone isn't necessarily responsible for the data in the
RDATA of the TLSA record?  This is sort of true and sort of false
(i.e. it's about as true as that a DNS operator isn't responsible if
you hand them the wrong IP address for your host).

I don't know what A.2.2 would mean, and I haven't thought about it.
If someone wants to point me to the archives where the idea was
described (yes, I'm too lazy to look it up) then I might offer text.
Otherwise, I say remove this.

The Pseudocode in B.2 sets class=IN but the text says that TLSA is
class-independent.  I know, I know.  Just a nit.

I think I understood the rest of the pseudocode, but I didn't try to
build anything on it nor to construct a proof.

Those are all my comments.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 16 Feb 2012 13:52:39 -0800

> unusable and move on, throw an error?

Pick one so we can discuss it here. :-)

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 16 Feb 2012 13:55:21 -0800

> from no-TLSA based TLS to TLSA-based TLS.

What do you see as a secure alternative? There was a lot of gnashing of teeth when we went to this, but no one came up with something that both provided a transition to TLSA and was secure against downgrades. I ask this given your DNSSEC history; I assume it was discussed there as well.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 16 Feb 2012 13:57:59 -0800

> zone, I can do some clever things too.)

The logic is "if you are going to trust an address record to go to a host, you can use the same mechanism to trust this certificate". Is there a better way to say that?

--Paul Hoffman

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 16 Feb 2012 16:58:21 -0500

> Pick one so we can discuss it here. :-)

Ok, I'd say, "If the TTL expires during TLS negotiation, the side
initiating the connection MAY query for the TLSA record again, but
SHOULD NOT re-query more than [n, n{2..5}] times.  If the TLSA RRset
cannot be used after multiple fetches, it should be marked as
unusable."

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 16 Feb 2012 17:11:39 -0500

> What do you see as a secure alternative? There was a lot of gnashing of teeth when we went to this, but no one came up with something that both provided a transition to TLSA and was secure against…

I don't think there's an analogue in DNSSEC, really.  And yeah, I
guess there isn't really a secure alternative.  Maybe simply pointing
out that this can't be done would be good though.  "It should be noted
that the presence of a DNSSEC-valid TLSA record can block a TLS
connection completely if the certificate association in the TLSA
record cannot be used."  That's pretty awkward, so there's probably a
nicer way to say it.  But I think this issue should be highlighted.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 16 Feb 2012 17:18:21 -0500

> The logic is "if you are going to trust an address record to go to a host, you can use the same mechanism to trust this certificate". Is there a better way to say that?

Because TLS is a mechanism for securing connections, and because that
connection can rely on information retrieved from the DNS, this
document works from the assumption that the same mechanism can be used
to retrieve the certificate for TLS.  The security of the protocols
described in this document relies on the security of DNSSEC as used by
the client to retrieve any resource record from the DNS.  (and so
on).  Howzzat?

A

-- 
Andrew Sullivan
[email-masked]

---

From: James Cloos <[email-masked]>
Date: Thu, 16 Feb 2012 17:31:21 -0500

AS>> This makes it hard to test the move to TLSA or to do a seamless
AS>> changeover, I think: as soon as you publish your TLSA record, the
AS>> existing, working infrastructure you have is broken to any client
AS>> that knows how to use TLSA.  Right?

Wrong.

The important note is that ANY of the TLSA RRs which apply can be used,
and any one of them might be current.  Just like with DNSSEC ZSKs.

When transitioning from non-TLSA to TLSA, first publish an RR which
matches the current, existing TLS cert chain.  Then, if you want to
use a new cert chain, first publish the new TLSA RR, wait out the TTLs,
restart the TLS server with the new key/cert info, wait out the TTLs
again, and then you can removed any outdated TLSA RR(s).

Since TLSA mandates DNSSEC, anyone doing this already should be familiar
with the concept, as they need it for rolling ZSKs and KSKs.

For sites who currently use well-known CAs to certify their EE certs,
want to continue doing so and want to add TLSA -- ie those for whome
usage types 0 and 1 are intended -- they only need to deploy dnssec
and add TLSA RRs matching their current cert chains.  For 0 and 1 the
TLSA RR is just a further confirmation that the TLS server sends the
actual intended certs and not some MITM-generated cert chain.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 16 Feb 2012 18:13:58 -0500

On Thu, Feb 16, 2012 at 05:31:21PM -0500, James Cloos wrote:
> matches the current, existing TLS cert chain. 

And at that moment, any TLSA-aware client that sees it has to use it,
and nothing else.  If you bollocks this step, those clients cannot
connect at all.  That's how I read the text, anyway, so if I'm wrong
either I just didn't understand the text, or else the text needs
improving.  Maybe this is just my crummy PKIX understanding kicking
in?

> with the concept, as they need it for rolling ZSKs and KSKs.

When you roll a key, they can use _any_ of the keys that work.  When
you're using no-TLSA and you add TLSA, the people who are TLSA-aware
can no longer use the no-TLSA mechanism.  If I've understood correctly
(and I am prepared to accept I haven't) this is considerably more
fragile.

A

-- 
Andrew Sullivan
[email-masked]

---

From: James Cloos <[email-masked]>
Date: Thu, 16 Feb 2012 19:59:54 -0500

>>>>> "AS" == Andrew Sullivan <[email-masked]> writes:

JC>> When transitioning from non-TLSA to TLSA, first publish an RR which
JC>> matches the current, existing TLS cert chain. 

AS> And at that moment, any TLSA-aware client that sees it has to use it,
AS> and nothing else.  If you bollocks this step, those clients cannot
AS> connect at all.

I didn't see an "If you bollocks this step" in the previous post.

Sure, an error in the TLSA RRs will block the site.  But so will an
error in the A, AAAA, DSK, ZSK, RRSIG or DS RRs.  Or a secondary which
stops updating.  (I just got hit by that; the stale secondary had, by
virtue of being stale, expired RRSIGs.  That blocked everything which
validated dnssec and happened to hit that secondary.).

AS> When you roll a key, they can use _any_ of the keys that work.  When
AS> you're using no-TLSA and you add TLSA, the people who are TLSA-aware
AS> can no longer use the no-TLSA mechanism.  If I've understood correctly
AS> (and I am prepared to accept I haven't) this is considerably more
AS> fragile.

But only if the addition has wrong RRs.  I don't see how it could be a
problem otherwise.  But perhaps I'm wrong on that front??

-JimC

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 16 Feb 2012 23:03:14 -0500

> I didn't see an "If you bollocks this step" in the previous post.

If it makes you happier, I'm willing to stipulate that I suck, and so
did my review of the draft.  But this is what you quoted:

The point of those "move to TLSA" and "existing, working
infrastructure" words was -- however they failed to communicate the
point -- to note that there's a startup issue for operators.  It seems
to me that's worth taking into account, even if the answer is, "Can't
fix that."  If I put on the hat of the operator who pays my mortgage
today, I have to say that a deployment that involves a hard cutover
point is considerably more anxiety-producing, and therefore less
likely.  If I take off that hat and think about my own, stupid
sysadmin mistake this morning, where I messed up a line in my own mail
server config file and created a mail loop for exactly long enough
that my test caught it and that an IETF list got a pointless bounce
from me, I _also_ have to say that a hard cutover point is more
anxiety-producing.  In deployment terms, given that we have an
existing infrastructure that has wide deployment, a transition issue
doesn't seem to be to be a totally needless worry.

None of that is to say that, "Yep.  Suck it up," is the wrong answer.
It's rather to say that, if that's our answer, we need to point it out
explicitly, because it seems to me like an important deployability
issue.  If the idea of IETF standards is interoperability, this is a
place where two strategies fail to interoperate.

> error in the A, AAAA, DSK, ZSK, RRSIG or DS RRs.

Yes.  The first two of those you list are well-understood DNS
operational mistakes for which people are prepared and -- at least in
the case of A records -- with which we gradually built up operational
experience that taught us how to do things carefully.  But the
introduction of DNSSEC (with its different kinds of keys, signing
across the zone cuts, funny key lifetime approach, and so on) has been
in some cases a good example of disruption to operational habits.
It's that collective experience that makes me nervous for this case.

Long after the US OMB mandate kicked in, for instance, many US federal
.gov sites are either not signed or else so badly maintained that the
sites go off the air to validators sometimes.  I'm not sure which of
these states is a less-happy omen, but in any case I think they
illustrate the difficulties of just deploying, correctly, something
that changes operational assumptions or involves different operational
departments becoming involved with one another.  In the case of TLSA,
the "web department" and the "DNS department" in some organizations
will need to co-ordinate their activities more tightly than perhaps
they always have.  I don't see how it is a disservice to point that
out. 

Yes, this is "only if you screw up".  That's the point, though, in a
new deployment: it's precisely at cutover that you're _most_ likely to
screw up.  Operators like to have a cutover in which the entire old
infrastructure keeps working while changing over.  We're proposing
something that can't work that way, and it's not a negligible issue.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Scott Schmit <[email-masked]>
Date: Thu, 16 Feb 2012 23:28:22 -0500

> nicer way to say it.  But I think this issue should be highlighted.

Well, there are a few things you can do to minimize the damage:
* Try it out on an alternate hostname to check out your TLSA record
  generation tools
* Use/create tools that will validate the record against the cert chain
  you're using on the server before you deploy the record
* If you have SNI and/or a wildcard cert, do the above but with your
  real server and/or key/cert (akin to the www.v6.example.com domain
  names)
* Publish the TLSA record with a really short TTL initially so you can
  yank it (more) quickly should it prove to be broken.

-- 
Scott Schmit

---

From: James Cloos <[email-masked]>
Date: Fri, 17 Feb 2012 15:58:13 -0500

>> I didn't see an "If you bollocks this step" in the previous post.

AS> If it makes you happier, I'm willing to stipulate that I suck, and
AS> so did my review of the draft.

I wasn't flaming, just explaining why my first reply seems to have
misunderstood your point.  I /thought/ that you were talking about
successful additions of accurate TLSA RRs to an already-signed zone.
Which should work smoothly for all TLS clients.

AS> The point of those ... [was] to note that there's a startup issue
AS> for operators.  It seems to me that's worth taking into account,

That is reasonable.

My point was simply that it is not any worse than all of the other
things which can go wrong when updating networking and/or security
infrastucture.

AS> None of that is to say that, "Yep.  Suck it up," is the wrong answer.
AS> It's rather to say that, if that's our answer, we need to point it out
AS> explicitly, because it seems to me like an important deployability
AS> issue.  If the idea of IETF standards is interoperability, this is a
AS> place where two strategies fail to interoperate.

If explicitly noting that will help implementers then by all means.

I'm sure Paul and Jakob would prefer some suggested prose.

>> error in the A, AAAA, DSK, ZSK, RRSIG or DS RRs.

AS> Yes, this is "only if you screw up".  That's the point, though,

Again, I really didn't get that from the first post; else I'd have
replied differently.

And my apologies if my prose appeared heated; that was not my intention.

-JimC

---

From: Martin Rex <[email-masked]>
Date: Tue, 21 Feb 2012 17:30:58 +0100 (MET)

Paul Hoffman wrote:
> Andrew Sullivan wrote:
> The logic is "if you are going to trust an address record
> to go to a host, you can use the same mechanism to trust
> this certificate". Is there a better way to say that?

I agree with Andrew, the mentioning of A/AAAA is invalid an ought
to be removed.  You NEVER trust A/AAAA in TLS, and neither in TLS+DANE.

Trusting A/AAAA would be foolish anyway, since a network MITM 
as well as any proxies that are traversed can transparently
modify all of the data, without anything spooky being visible
at the IP-Address layer.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 21 Feb 2012 17:38:17 +0100 (MET)

> cannot be used after multiple fetches, it should be marked as

To me that sounds _much_ too complicated.  The TTL on a DNS record
is not a security feature anyway, so I do not see a justification to
treat TTLs of TLSA records any different than TTLs on other DNS records,
so typically on *receipt* of the DNS record.  If there is a local cache
for DNS records, that should work transparently -- either there is
a record with a non-expired TTL available, then it is used, or
there isn't then a new DNS query is necessary.  Obtaining a DNS record
with an expired TTL from a local cache sounds like a bug in the
implementation (or design) of that DNS cache.

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 21 Feb 2012 08:42:53 -0800

> modify all of the data, without anything spooky being visible

Not to be too picky, but I (as co-author) asked for a better way to say what we mean.

At some point, a TLS-using application needs to have enough trust to connect to start a connection on port 443 of a given A or AAAA record. This is not a trust in TLS, it is a trust in DNSSEC (or in the universe, if DNSSEC didn't give a secure response). The TLS client using TLSA records has to have the same level of trust in DNSSEC to use the TLSA records. What is the best way of saying this?

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 21 Feb 2012 08:45:15 -0800

> implementation (or design) of that DNS cache.

+1 to Martin's analysis.

--Paul Hoffman

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 21 Feb 2012 12:00:58 -0500

On Tue, Feb 21, 2012 at 05:38:17PM +0100, Martin Rex wrote:
> treat TTLs of TLSA records any different than TTLs on other DNS
> records

I'd actually agree with this but for the text that was already there,
which says that the negotiation has to complete before the TTL
expires.  Your suggested alternative will not in some cases meet that
requirement.  I presumed the WG had a reason to phrase it this way; if
not, then your suggestion is better.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 21 Feb 2012 12:05:08 -0500

> Not to be too picky, but I (as co-author) asked for a better way to say what we mean.

I think I provided a suggestion, which was basically that if you're
going to use the DNS to set up your connection, your connection is
exactly as secure as any data you get from the DNS.  See
http://www.ietf.org/mail-archive/web/dane/current/msg04405.html.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 21 Feb 2012 10:08:01 -0800

On Feb 21, 2012, at 9:05 AM, Andrew Sullivan wrote:

> I think I provided a suggestion,

You did; my message was aimed at Martin Rex.

> which was basically that if you're

Actual text from your message:

the client to retrieve any resource record from the DNS.

That works for me, but there may be some people who don't agree with the last part because they don't think that DNSSEC is needed for any record if you are using TLS or TLS-with-DANE.

--Paul Hoffman

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 21 Feb 2012 13:21:10 -0500

On Tue, Feb 21, 2012 at 10:08:01AM -0800, Paul Hoffman wrote:
 
> That works for me, but there may be some people who don't agree with
> the last part because they don't think that DNSSEC is needed for any
> record if you are using TLS or TLS-with-DANE.

Ah, yes.  _De gustibus non est disputandum_.  (Sorry, but I just don't
see any value at all in DANE without DNSSEC.)  Nevertheless, how's
this:

    Because TLS is a mechanism for securing connections, and because
    that connection can rely on information retrieved from the DNS,
    this document works from the assumption that the same mechanism
    can be used to retrieve the certificate for TLS.  The security of
    the protocols described in this document relies on the security of
    responses from the DNS, and what the client subsequently does with
    such responses.  DNSSEC-validated responses provide greater
    assurances that the DNS message was not altered in transit than
    those responses that have not been validated.

?

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Wed, 22 Feb 2012 09:26:30 +1100

> not, then your suggestion is better.

The important time is the RRSIG's expiration time of the RRSIG that
validated the RRset (i.e. you have to choose the correct one).  TTL
is a cache refresh parameter.  You will get TTL's of zero seconds
which means "use for this transaction" not "use within 0 seconds".

[TTL trimming is also something that is not well specified in RFC 4035
but that is dnsext fodder for as long as dnsext exists.  Personally I
thing it is too early to shutdown dnsext as DNSSEC is just begining to
be used widely enough for specification problems to start to surface
from applications. Bcc: [email-masked]]

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 24 Feb 2012 17:06:51 +0100

>> implementation (or design) of that DNS cache.

+1 here.  Any objections?  If not I will ask authors to change the document.

O.
--
 Ondřej Surý
 vedoucí výzkumu/Head of R&D department
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:[email-masked]    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 24 Feb 2012 17:11:02 +0100

> I'm sure Paul and Jakob would prefer some suggested prose.

I really like this suggestion :).  It seems it would help to have some simple text about what happens if you screw up TLSA deployment in Operational Considerations (Appendix A), but somebody has to write it.  Any volunteer?

O.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 24 Feb 2012 11:42:53 -0500

> +1 here.  Any objections?  If not I will ask authors to change the document.

That depends on how the document is being changed.  This issue has
also been picked upon dnsext.

My original point stands: the text says that the processing must
happen before the end of the TTL.  As others have noted, this is a
mistake in more than one dimension: the TTL isn't the important
qualified (because the lifetime of the RRSIG is actually the relevant
bit), and the question should merely be whether you got data from the
cache (if you get data from the cache with a negative TTL on it, then
the cache is already broken and you shouldn't have received such data
anyway; the draft is not in the business of warning about DNS problems
nobody has ever reported in the wild, so that can't be the point of
the text).

So, _if_ the WG thinks there needs to be anything about what to do
with data retrieved from a cache (and I was just assuming it did
because the text seems kind of odd; I didn't raise this in the review
and perhaps I should have instead), then we need to say something
about what to do in case the TTL ticks down in that interval.

But I'm in agreement with Mark, Ed Lewis, and implicitly I think
Martin that the right thing to do is to remove any discussion of
whether to worry about the TTL at all during TLS set up.  It's a
category mistake.

On a related topic: I don't think the document should say anything
about the TLS setup and the RRSIG expiration time, either.  I think
the question is merely, "When I got this record, was it valid?"  How
to do that is already covered by DNSSEC and if there are corner cases
about RRSIG expiry, this document isn't the place to fix them.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 24 Feb 2012 18:04:06 +0100

> also been picked upon dnsext.

I propose to change:

   The TLS session that is to be set up MUST be for the specific port
   number and transport name that was given in the TLSA query.  The
   matching or chaining MUST be done within the life of the TTL on the
   TLSA record; using a TLSA record past the lifetime specified in the
   TTL can expose the the TLS client to many types of attacks.

to something like:

   The TLS session that is to be set up MUST be for the specific port
   number and transport name that was given in the TLSA query.  TLSA
   record MUST NOT be cached and a new TLSA query must be made for each
   new TLS session.

> about RRSIG expiry, this document isn't the place to fix them.

We don't say anything about RRSIGs, do we?

O.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 24 Feb 2012 12:28:28 -0500

>    record MUST NOT be cached and a new TLSA query must be made for each

That is not going to fly.  You're saying that TLSA is not allowed to
be cached.  That makes it completely unlike every single other RRTYPE
in the DNS universe.

Why is the TTL stuff in there at all? 

   The TLS session that is to be set up MUST be for the specific port
   number and transport name that was given in the TLSA query.

That's all we need to say.  You get a record inside the TTL of a
record, and you should _never_ get DNS data past its TTL, by
definition.  (If you do, your DNS cache is broken, and that's just out
of scope for this I-D.)

The special handling seemed to be promoting the TTL into some sort of
security service, in which whether a record returned from the DNS is
not the only question.  In other words, as things stand the document
is suggesting that the TTL is not only a control on cache behaviour,
but a control on _application_ behaviour.  The more I think about it,
the more I think that's wrong.  
 
> We don't say anything about RRSIGs, do we?

Nope.  But that's my point; if we have to talk about the TTL as
somehow constraining the application behaviour, then we also have to
talk about the RRSIG lifetime constraining application behaviour.  And
now you're into the same set of problems as DNS generally has about
the link between the TTL and the expiry time on RRSIGs.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 24 Feb 2012 19:29:04 +0100

> be cached.  That makes it completely unlike every single other RRTYPE

Are we talking about the same cache?  Maybe not.  I was trying to say that TLSA record MUST NOT be cached in the _application_.

Would it help to change s/cached/reused/

>>   record MUST NOT be reused and a new TLSA query must be made for each
>>   new TLS session.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 24 Feb 2012 13:51:26 -0500

> Are we talking about the same cache?  Maybe not.  I was trying to say that TLSA record MUST NOT be cached in the _application_.

Apparently not, and yes that solves the issue for me.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 24 Feb 2012 20:11:45 +0100

> Apparently not, and yes that solves the issue for me.

Cool.

Ok, anybody objects to changing second paragraph of Section 5 to (just changed second must to MUST):

>>  record MUST NOT be reused and a new TLSA query MUST be made for each
>>  new TLS session.

We have +1 from me, Andrew Sullivan, and in the spirit of what Martin Rex wrote from Paul Hoffman and Martin Rex.  Am I right?

O.

---

From: Peter Koch <[email-masked]>
Date: Fri, 24 Feb 2012 22:06:41 +0100

> the more I think that's wrong.  

+1;

> the link between the TTL and the expiry time on RRSIGs.

DNSSEC assures authenticity, not correctness, therefore the RRSIG
lifetime is not a commitment to not alter or remove the data (in the
same way the TTL is an instruction to caches, not a promise that
data will be unaltered until the TTL expires).  Neither discussion
has a place in this document.

same stone, second bird:

On Fri, Feb 24, 2012 at 08:11:45PM +0100, Ond??ej Surý wrote:
> > On Fri, Feb 24, 2012 at 07:29:04PM +0100, Ond??ej Surý wrote:
> >>

I do not see a reason why an application that would implement a cache
MUST NOT do that, as long as it conforms to the proper protocol. That
means to adhere to the TTL in this case.  Do we have similar strict language
in the SMTP RFCs?  Are we telling web browsers not to reuse A or AAAA information?
In any case, the MUST NOT as proposed above ought to be justified within
the text.

-Peter

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 24 Feb 2012 16:24:57 -0500

On Fri, Feb 24, 2012 at 10:06:41PM +0100, Peter Koch wrote:

> in the SMTP RFCs?  Are we telling web browsers not to reuse A or
> AAAA information?  In any case, the MUST NOT as proposed above ought
> to be justified within the text.

Actually, the "web browser" comparison makes me realise what this text
is probably for.  Some web browsers _do_ cache the record for
themselves.  They call this "pinning".  It's there partly to prevent a
DNSSEC-proof cross-component attack due to rebinding.  See Jackson, C
et al, "Protecting Browsers from DNS Rebinding Attacks" in CCS'07, 
October29-November 2, 2007.  ACM # 978-1-59593-703-2/07/0011.

There does seem to be a problem here, I'm just not sure that the TTL
is the solution.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Sat, 25 Feb 2012 00:29:50 +0200

> I really like this suggestion :).  It seems it would help to have some simple text about what happens if you screw up TLSA deployment in Operational Considerations (Appendix A), but somebody has to…

How's about adding the following at the beginning of A.1:

A.1.  Creating TLSA Records

When creating TLSA records care must be taken to avoid misconfigurations. Section 5 of this document states that a TLSA RRSET whose validation state is secure MUST be used. This means that the existence of such a RRSET effectively disables other forms of name and path validation. 

A misconfigured TLSA RRSET will effectively disable access to the TLS server for all conforming clients, and this document does not provide any means of making a gradual transition to using TLSA. 

Yoav

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 24 Feb 2012 17:53:38 -0500

> A misconfigured TLSA RRSET will effectively disable access to the TLS server for all conforming clients, and this document does not provide any means of making a gradual transition to using TLSA. 

This seems fine to me, modulo the spelling of RRset.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Olafur Gudmundsson <[email-masked]>
Date: Sat, 25 Feb 2012 14:35:31 -0500

> There does seem to be a problem here, I'm just not sure that the TTL

There are two issues here that we need to separate,
1) can this TLSA record be used to create a connection to the remote 
server and how long can the connection stay open?

2) How long can the application hold on to the TLSA record that it got?

The answer to #2 is "Respect the DNS TTL" but pay attention to the time 
it takes to perform a transaction[below].

The answer to #1 if the TLSA validates it can be used to create 
connection and the connection can stay open as long as both sides agree 
to keep it open, the DNS TTL is immaterial to this issue.

We had a similar discussion in DNSEXT some years back as what is the 
meaning of TTL == 0, the answer we agreed on is:
"The record can be used for the duration of the transaction[below] it is 
part off".
so a TLSA with TTL==0 means it can be used to create one connection and 
only one.

[below] In this context we consider DNS transaction to involve the 
original lookup and any lookups that follow that one. i.e. if a zone has 
NS with TTL==0, the validator will keep the NS while it asks for the 
record asked for and then for the DNSKEY.
Some resolvers will implement MIN_TTL rather than keep track of 
transactions, and use values in the 10..60 seconds range.

	Olafur

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 27 Feb 2012 14:41:19 +0100

> This seems fine to me, modulo the spelling of RRset.

I like the text (with RRset).  Any objections?

O.

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 27 Feb 2012 14:52:51 +0100

Hi Olafur, Andrew and Peter,

On 25. 2. 2012, at 20:35, Olafur Gudmundsson wrote:

> 1) can this TLSA record be used to create a connection to the remote server and how long can the connection stay open?
> 
> The answer to #2 is "Respect the DNS TTL" but pay attention to the time it takes to perform a transaction[below].
> 
> The answer to #1 if the TLSA validates it can be used to create connection and the connection can stay open as long as both sides agree to keep it open, the DNS TTL is immaterial to this issue.
> 
> We had a similar discussion in DNSEXT some years back as what is the meaning of TTL == 0, the answer we agreed on is:
> "The record can be used for the duration of the transaction[below] it is part off".
> so a TLSA with TTL==0 means it can be used to create one connection and only one.
> 
> [below] In this context we consider DNS transaction to involve the original lookup and any lookups that follow that one. i.e. if a zone has NS with TTL==0, the validator will keep the NS while it asks for the record asked for and then for the DNSKEY.
> Some resolvers will implement MIN_TTL rather than keep track of transactions, and use values in the 10..60 seconds range.

I would really like to keep the 'DNS stuff' out of the DANE protocol document.  I don't think it belongs here.

> means to adhere to the TTL in this case.  
> Do we have similar strict language in the SMTP RFCs?  
> Are we telling web browsers not to reuse A or AAAA information?

Well, we kind of do (RFC 2616 Section 15.3):

   In particular, HTTP clients SHOULD rely on their name resolver for
   confirmation of an IP number/DNS name association, rather than
   caching the result of previous host name lookups.

We could add similar section to the DANE protocol Security Considerations and

> number and transport name that was given in the TLSA query.

Ondrej

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 29 Feb 2012 09:32:12 +0100

Hi again,

My suggestion is to:

> number and transport name that was given in the TLSA query.

b) add paragraph to Security Considerations (taken and slightly rewritten from RFC 2616):

X.Y DNS Spoofing

   Implementations of this protocol rely heavily on the Domain Name Service,
   and are thus generally prone to security attacks based on the deliberate
   mis-association of TLSA records and DNS names. Implementations need to be
   cautious in assuming the continuing validity of an TLSA records/DNS name
   association.

   In particular, implementations SHOULD rely on their name resolver for
   confirmation of an TLSA record/DNS name association, rather than
   caching the result of previous domain name lookups. Many platforms
   already can cache domain name lookups locally when appropriate, and
   they SHOULD be configured to do so. It is proper for these lookups to
   be cached, however, only when the TTL (Time To Live) information
   reported by the name server makes it likely that the cached information
   will remain useful.

   If implementations cache the results of domain name lookups in order to
   achieve a performance improvement, they MUST observe the TTL information
   reported by DNS. If implementations do not observe this rule, they could
   be spoofed when a previously-accessed server's TLSA record changes, f.e.
   as part of certificate rollover.

Does this make the document clearer?

O.

On 27. 2. 2012, at 14:52, Ondřej Surý wrote:

> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: James Cloos <[email-masked]>
Date: Wed, 29 Feb 2012 09:11:33 -0500

>>>>> "OS" == Ondřej Surý <[email-masked]> writes:

>> number and transport name that was given in the TLSA query.

OS> b) add paragraph to Security Considerations (taken and slightly rewritten from RFC 2616):

OS> X.Y DNS Spoofing

OS> ....

OS> Does this make the document clearer?

That reads well and explains the issue nicely.

+1

-JimC

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 29 Feb 2012 09:25:01 -0500

I agree
	Olafur

---

From: Paul Wouters <[email-masked]>
Date: Wed, 29 Feb 2012 11:08:39 -0500 (EST)

>   cautious in assuming the continuing validity of an TLSA records/DNS name

I don't like this at all. Because "implementations of this protocol"
should rely on DNSSEC as I thought was the working group conensus? This
section just seems to assume DNSSEC-less dns.

>   caching the result of previous domain name lookups.

I don't think we should try to specify localhost DNS behaviour. In fact,
caching it might be advantagious for instance where I cache the TLSA
when I'm on my trusted home network, and then move into an untrusted
coffee shop wifi area. So I really disagree with this statement. Caching
should in fact be done to the fullest extend possible to avoid attackers
stripping out records.

>  Many platforms

Again, out of scope for this document.

>   as part of certificate rollover.

DNSSEC records cannot be spoofed, so I am not sure what this is supposed
to say.

> Does this make the document clearer?

I don't think so.

Paul

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 29 Feb 2012 18:42:32 +0100

Hi Paul,

On 29. 2. 2012, at 17:08, Paul Wouters wrote:

> should rely on DNSSEC as I thought was the working group consensus?

Yes, this is correct.

> This section just seems to assume DNSSEC-less dns.

No, your assumption is wrong.  TLSA record/DNS name association can stop being valid by pure change in the zone.

> should in fact be done to the fullest extend possible to avoid attackers

I think your requirement still fits into the 'SHOULD'.

> Again, out of scope for this document.

I disagree.  It's entirely valid for this document to specify how to handle DNS records with regards to security.

> DNSSEC records cannot be spoofed, so I am not sure what this is supposed

Please re-read the paragraph.  It's not saying anything about DNS records being spoofed as a part of some DNS based attack, but purely based on the fact that you can cache obsolete information (if you cache the record longer then their TTL).

O.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 29 Feb 2012 10:25:34 -0800

> Please re-read the paragraph.  It's not saying anything about DNS records being spoofed as a part of some DNS based attack, but purely based on the fact that you can cache obsolete information (if…

Also note that I chose to change the name of this section to "DNS Caching" to make the emphasis clearer.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Wed, 29 Feb 2012 13:50:56 -0500 (EST)

> No, your assumption is wrong.  TLSA record/DNS name association can stop being valid by pure change in the zone.

Please show me the "Security Consideration" for an admin
changing/adding/removing TLSA records. If you want to
say "be sure not to remove it before $TTL seconds, then
say that.

> I think your requirement still fits into the 'SHOULD'.

My point is, applications do caching. Browsers cache dns lookups, even if
the system resolver is on localhost. There is no valid reason whatsoever
to suggest them here in the security considerations not to do so and to
re-ask a DNS server. My cached TLSA record MUST be considered valid from
the moment I got it (validated by DNSSEC) until the shortest of RRSIG
expiry and TTL. I don't need to ask anyone anything else nor do I have
to discard it beforehand.

You are suggesting the opposite with "rather than caching the result of
previous domain name lookups".

> Please re-read the paragraph.  It's not saying anything about DNS records being spoofed as a part of some DNS based attack, but purely based on the fact that you can cache obsolete information (if…

right, so I suggest text along the lines of

"An application MUST NOT use cached TLSA records past RRRSIG expiry or TTL"

Paul