Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.txt

From: "Osterweil, Eric" <[email-masked]>
Date: Wed, 5 Feb 2014 15:17:26 +0000

Hey all,

Sorry this response is so delayed.  I think the suggestions made in the proposed text ( http://www.ietf.org/mail-archive/web/dane/current/msg06180.html ) make quite a bit of sense.  In particular, I think the proposal to add the Usage #4 (reject) is likely to be very important.  Specifically, DANE is (imho) excellent example of a standard architecture for certificate discovery using DNS.  From this perspective it seems opportune for it to capitalize on the nuanced difference between saying, ``don't use this cert for this operation,'' and ``this cert is universally revoked.''  These really are fundamentally different, and DANE lets us express them that way.

Also, I think the certificate access field (Section 2.1.4, which enables alternate discovery mechanisms) could actually be a great facility for incremental deployment and transition schemes.  It seems to me that the flexibility added could be crucial as would-be adopters incrementally roll their constituency off of (say) an AD solution and onto a DANE solution.  

Finally, I think the ``_encr'' and ``_sign'' labels are excellent additions to the _discovery_ mechanism that DANE enables.  Viewing DANE as a discovery mechanism for certs, I can't help but feel that the process of trying to discover a signing key vs.trying to discover an encryption key a first class element of the protocol.  Rather than asking for all keys and then selecting from them, I (as an RP) likely already know which of these I want, and I should be able to discover them separately in DANE (and owners should be able to manage them separately in DANE).  Based on that, these changes really seems like great fodder for being encoded in the domain name, imho.

I noticed that the current (-04?) draft doesn't seem to have taken these recommendations, but I think they should be incorporated.

Eric

On Jan 8, 2014, at 9:58 AM, Scott Rose <[email-masked]> wrote:

> I support this work and would like to see more discussion on the list.  Some of us have even proposed text with additions (http://www.ietf.org/mail-archive/web/dane/current/msg06180.html).  
> 
> Haven't seen much discussion on the list, and missed the informal DANE lunch at the last IETF.  Is there enough interest in having the SMIMEA RR?  Some of the changes we offered:
> 
> 1. naming convention to help distinguish between signing and encryption key certs (for enterprises that use separate certs for encrypting and signing).  It helps reduce the size of the SMIMEA RRset a bit, but admittedly minor compared to the size of an X.509 cert.
> 
> 2. a new CU value for "revoked" to indicate that this user's certificates have been revoked.  
> 
> There are some signed/encrypted email projects rolling out now that are using CERT RR's or combinations of SRV RR's and LDAP servers.  Having something like SMIME would be an improvement, but the spec needs to be finalized.  
> 
> Scott
> 
> 
> On Jan 6, 2014, at 4:29 PM, [email-masked] wrote:
> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF.
>> 
>>       Title           : Using Secure DNS to Associate Certificates with Domain Names For S/MIME
>>       Authors         : Paul Hoffman
>>                         Jakob Schlyter
>> 	Filename        : draft-ietf-dane-smime-03.txt
>> 	Pages           : 6
>> 	Date            : 2014-01-06
>> 
>> Abstract:
>>  This document describes how to use secure DNS to associate an S/MIME
>>  user's certificate with the intended domain name, similar to the way
>>  that DANE (RFC 6698) does for TLS.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-dane-smime/
>> 
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-dane-smime-03
>> 
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smime-03
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> _______________________________________________
>> dane mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dane
> 
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 5 Feb 2014 20:12:14 +0100

> I noticed that the current (-04?) draft doesn't seem to have taken these recommendations, but I think they should be incorporated.

As per Paul's reply Jan 8th, we've had no consensus on adding these features as both was (at least by Paul and me) of questionable value. Scott seemed to somewhat agree in a followup mail. However, I do welcome a more elaborate discussion on the pros _and_ cons so we can close these issues.

	jakob

---

From: "Osterweil, Eric" <[email-masked]>
Date: Wed, 5 Feb 2014 20:48:22 +0000

> As per Paul's reply Jan 8th, we've had no consensus on adding these features as both was (at least by Paul and me) of questionable value. Scott seemed to somewhat agree in a followup mail. However,…

Hey Jakob,

Indeed, I was adding in support for Scott's proposal because I agreed with at least three of his points.  I'd be happy to elaborate on any of the issues I pointed out, though I did think the comments I initially made were reasonably detailed, no?  Actually, to that point, I don't recall seeing substantive a rebuttal to Scott's suggestions on Jan 8?

I actually did read Paul's response ( http://www.ietf.org/mail-archive/web/dane/current/msg06281.html ), and I felt it didn't present a very in-depth response to the detailed suggestions that Scott made.  That's why I felt it was important to express my support for Scott's suggestions.

For example, Paul responded:
  ``The slight saving of space also introduces a new, significant failure mode …  I'd say "no" on this one.''
I don't agree that this is a failure mode that invalidates the cert learning, and disagree with its dismissal.  Moreover, I elaborated on other reasons why I think these labels are important, ``Finally, I think the `_encr' and `_sign' labels are excellent additions to the _discovery_ mechanism that DANE enables.  Viewing DANE as a discovery mechanism for certs, I can't help but feel that the process of trying to discover a signing key vs.trying to discover an encryption key a first class element of the protocol.  Rather than asking for all keys and then selecting from them, I (as an RP) likely already know which of these I want, and I should be able to discover them separately in DANE (and owners should be able to manage them separately in DANE).  Based on that, these changes really seems like great fodder for being encoded in the domain name, imho.''

Paul also said,
  ``We considered things like this for TLSA, and the WG seemed very hesitant…''
I also don't agree with this, which I noted in my response:  ``difference between saying, `don't use this cert for this operation,' and `this cert is universally revoked.'  These really are fundamentally different, and DANE lets us express them that way.''

I also think Scott's suggestion for the certificate access field is a very good one, and I'd very much like to see his suggested text incorporated.

Eric

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 5 Feb 2014 21:05:17 +0000

On Wed, Jan 08, 2014 at 07:54:26AM -0800, Paul Hoffman wrote:

> We considered things like this for TLSA, and the WG seemed very
> hesitant to have the DNS be used as a second, unofficial revocation
> mechanism. For instance, what would it mean for the DNS to say that
> an S/MIME cert is revoked, but when the user pulls a fresh CRL,
> the cert isn't there? The best we might do is to have a signal for
> "go refresh your revocation view" in the DNS, but that seems like
> very marginal value.

I strongly support Paul's comment.  Unlike stale on-disk certificates
held by third-parties, published DANE records (SMIMEA, TLSA, ...)
are maintained by the subject's domain and can be presumed *current*
when the publishing domain is not negligent.

Therefore, there is no need for a fragile blacklist mechanism.
The DANE data in DNSSEC is a comprehensive whitelist.  Every
certificate not listed in DANE is the wrong certificate, unlike
CRLs DANE fails closed.

When the DANE associated data published for a user is a CA that
signs multiple EE certs and a particular user's keys need to be
revoked, the simplest solution is to publish an EE association for
that user until the revoked certificate expires.  Either way there
is a special EE DANE record for the user in question, but one or
more valid EE certs are more useful than a list of invalid EE certs.

-- 
	Viktor.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 5 Feb 2014 13:06:15 -0800

On Feb 5, 2014, at 7:17 AM, Osterweil, Eric <[email-masked]> wrote:

> Specifically, DANE is (imho) excellent example of a standard architecture for certificate discovery using DNS.  

As has been noted in many places over the past few decades, using the DNS for information deliver vs. information discover are very different things. Jakob and I have chosen to go with the standard assumption that the DNS is for information delivery, and other protocols (these days, mostly HTTP) can be used for information discovery.

If the DANE WG wants to change this, and the IETF at large agrees, we can certainly walk down that path, both with this document and with TLSA itself.

--Paul Hoffman

---

From: "Osterweil, Eric" <[email-masked]>
Date: Wed, 5 Feb 2014 21:19:24 +0000

> If the DANE WG wants to change this, and the IETF at large agrees, we can certainly walk down that path, both with this document and with TLSA itself.

Hey Paul,

Thanks for the quick response.  I am, however, a little puzzled by it.  So, is there some reason why these discussions here (on the WG list) are not the actual substance of determining what the DANE WG wants?  As I understand it (perhaps incorrectly?), we are discussing a working group document, so discussion of its contents should be inbounds and any resulting rough WG consensus should help direct its contents, no?

As for the broader statement of what DNS is for, and what the IETF at large thinks, I think perhaps you have expressed your own opinion here, and I (personally) do not agree.  In my view, DNS is (very much) a resource mapping (i.e. learning) mechanism.  That's how we find routable endpoints for HTTP. ;)  Content delivery aside.  I suspect you and I may actually be on the same page on that one, but apparently not on the learning issue.

Back to the main issue, I am following up on Scott's solicitation for discussion about his proposed changes, and expressing my support for them.  I have read your response to those and responded to it, and I am happy to discuss the technical details further.

Eric

---

From: "Osterweil, Eric" <[email-masked]>
Date: Wed, 5 Feb 2014 21:30:34 +0000

> certificate not listed in DANE is the wrong certificate, unlike

Hey Viktor,

So, I worry that this relies on implicit assumptions being made about processing being done on the MUA (RP) side.  If something is not available in DNS, does that mean I shouldn't use a cert I may already have in hand, I shouldn't fall back to AD, I shouldn't use a previously seen value, etc… How do I know the domain was ever serving SMIMEA if there is nothing in there now?  I suppose we could conflate deauthorization of certs with revocation of certs.  However, I was suggesting that we _could_ use this opportunity to express an unambiguous piece of evidence that clients should use SMIMEA-processing, and should _not_ use a specific cert (even though it may not be universally revoked).

> more valid EE certs are more useful than a list of invalid EE certs.

As I think you said above, ``DANE records (SMIMEA, TLSA, …) are maintained by the subject's domain and can be presumed *current* when the publishing domain is not negligent.'' I think it's a nice option to give DNS provisioning systems to set a flag in an RR that deauthorizes a cert w/o having to have the CA issue a new association.  Perhaps I'm off here, but it seems far more complicated from an operational perspective to have to hop through a CA and get something issued in order to deauthorize a cert rather than just updating the RR, no?

Eric

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 5 Feb 2014 23:23:36 +0000

On Wed, Feb 05, 2014 at 09:30:34PM +0000, Osterweil, Eric wrote:

> So, I worry that this relies on implicit assumptions being made
> about processing being done on the MUA (RP) side.  If something is
> not available in DNS, does that mean I shouldn't use a cert I may
> already have in hand, I shouldn't fall back to AD, I shouldn't use
> a previously seen value, etc? How do I know the domain was ever
> serving SMIMEA if there is nothing in there now?  I suppose we
> could conflate deauthorization of certs with revocation of certs.
> However, I was suggesting that we _could_ use this opportunity to
> express an unambiguous piece of evidence that clients should use
> SMIMEA-processing, and should _not_ use a specific cert (even though
> it may not be universally revoked).

Well if the DNS is not available, you won't see the DNS revocation
either.  So I think you're imagining a situation were a client is
often disconnected, and caches certificates.

In that case, I would suggest the following strategy for an SMIMEA
capable MUA:

    Each signed message received by the MUA is initially in an
    unknown verificaiton state.  When an SMIMEA lookup is successful,
    and returns a usable certificate the message is marked permanently
    valid (certificate valid at time of message receipt).  The
    certificate can be cached for the shortest of the TTL of the
    SMIMEA RRset, the RRSIG expiration time and a configurable
    local cache limit (suggested default 7 days).

    Each new message received generates a new background attempt
    to determine the SMIMEA records, but if cached data is available,
    a cached certificate can be used (lies within RRSIG lifetime).

    Likewise, outgoing mail can be encrypted to a cached certificate
    only within its DNSSEC validity interval, but otherwise requires
    a new SMIMEA lookup.

Basically the MUA operates with a stored (rather than in-memory)
DANE RRset cache.

> As I think you said above, ``DANE records (SMIMEA, TLSA, ?) are
> maintained by the subject's domain and can be presumed *current*
> when the publishing domain is not negligent.'' I think it's a nice
> option to give DNS provisioning systems to set a flag in an RR that
> deauthorizes a cert w/o having to have the CA issue a new association.
> Perhaps I'm off here, but it seems far more complicated from an
> operational perspective to have to hop through a CA and get something
> issued in order to deauthorize a cert rather than just updating
> the RR, no?

I don't see any reason to de-authorize by publishing a blacklist,
when one can just simply stop publishing the record or replace a
TA record with an EE record.

-- 
	Viktor.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 5 Feb 2014 15:29:29 -0800

> Thanks for the quick response.  I am, however, a little puzzled by it.  So, is there some reason why these discussions here (on the WG list) are not the actual substance of determining what the DAN…

It is often better if a WG decides on a direction, not just a specific technology. During the TLSA discussions, there were many threads about delivery vs. discovery, and the WG early on went for "delivery, not discovery". As I said in the previous message, if the WG wants to revisit that decision and goes towards "discovery", there are lots of ways we can make TLSA and SMIMEA records have some interesting new properties.

> As for the broader statement of what DNS is for, and what the IETF at large thinks, I think perhaps you have expressed your own opinion here, and I (personally) do not agree.  In my view, DNS is (v…

I'm agnostic, and am happy for this document and TLSA go whichever way the IETF wants. However, I'm not in favor of trying to cross the line and see if the IETF notices.

> Back to the main issue, I am following up on Scott's solicitation for discussion about his proposed changes, and expressing my support for them.  I have read your response to those and responded to…

It's not the technical issues that are important, however.

So, WG: is "DNS for delivery vs. DNS for delivery and discovery" a topic people want to revisit?

--Paul Hoffman

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 5 Feb 2014 23:50:02 +0000

> a topic people want to revisit?

Since I am relatively new here, I'll ask:  What is the distinction?

My best guess is:

    - Discovery, one time lookup of data that is retained indefinitely
      and refreshed infrequently, in particular potentially beyond
      the shorter of the DNS TTL and the RRSIG expiration.

    - Delivery, lookup as needed with optional caching bounded by
      the shorter of the record TTL, the RRSIG expiration and any
      applicable local policy.

Is that about right?  If so, since TLSA in an online protocol, it
seems clear that TLSA should be "delivery".

For SMIMEA, the case is a bit less clear-cut.  Whenever one is
capable of receiving new email one is presumably online, and so
receipt of associated SMIMEA records should be feasible.  When
composing encrypted replies one would often, but not always have
a cached copy of the sender's encryption cert and one may not be
online.  

The MUA could defer the encryption step until it is back online,
but then an unencrypted copy of the message sits in the local outbox
until network connectivity is restored.  Otherwise, the user would
have to accept the risk that the most recently cached cert is no
longer valid (no way to check SMIME for a revocation either).

I don't see much of a role for SMIMEA revocations in either case.
Any time one can look-up a blacklist one can lookup a (possibly
empty) whitelist instead.

So it is not clear how "discovery" is a better protocol than
delivery.  Feels like printed credit card black-lists in the 70's
before credit card verification went online.

-- 
	Viktor.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 5 Feb 2014 16:34:41 -0800

> Since I am relatively new here, I'll ask:  What is the distinction?

Well, that's a hard one because different people slice and dice differently. The summary I often use is:

Delivery: tell me how to use X at domain name Y
Discovery: tell me whether there is service X at domain name Y

Another way to do this is:

Delivery: I'm pretty sure domain name Y does X: tell me what I need to know
Discovery: I want to findo out if domain name Y does X

--Paul Hoffman

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 6 Feb 2014 00:48:35 +0000

> Discovery: I want to findo out if domain name Y does X

Hmm, ... neither of these formulations talk about future behaviour.

The SMTP draft I've been working on for most of the past year (with
Wes) is in essence doing downgrade-resistant discovery of STARTTLS
support and getting usable authentication parameters in the process.
This "discovery" is performed for each and every SMTP connection.
So it is "delivery" per my guess at a definition, but seemingly
"discovery" under yours.

So I am at a bit of a loss how the above definition of the dichotomy
bears on the question of certificate revocation.  If "discovery"
means locate once and cache indefinitely, then revocation rears
its ugly head.

Otherwise, it is just about whether some bit of policy or behaviour
is a-priori or based on DNS lookup and I don't see why revocation
support or non-support is related to "discovery" vs. "delivery".

Or is the request for CU 4 not the reason for this tangent? Are we
talking about discovery vs. delivery because of the request to
separate signing vs. encryption certs?  If so, how does the request
cross the line from "delivery" to "discovery"?

-- 
	Viktor.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 5 Feb 2014 17:16:25 -0800

> So it is "delivery" per my guess at a definition, but seemingly

I bet others will say the same. However, I looked at it as "I believe that SMTP server at domain name Y does TLS, give me its certificate". This is the same as "I believe that HTTP server at domain name Y does TLS, give me its certificate".

This is quite different than using the DNS to determine if domain name Y does SMTP/TLS or HTTP/TLS. That's why there are no semantics associated with the TLSA records that say "if DANE says there is a TLS server and you can't reach it, there is something wrong".

(And, yes, my TRYTLS record proposal definitely slides right into the discovery zone. And that's why it has gotten roundly ignored.)

--Paul Hoffman

---

From: "Osterweil, Eric" <[email-masked]>
Date: Thu, 6 Feb 2014 01:50:37 +0000

> It is often better if a WG decides on a direction, not just a specific technology. During the TLSA discussions, there were many threads about delivery vs. discovery, and the WG early on went for "d…

Paul, I don't think we have nearly enough data points to prescribe the general principles of all DANE protocols.  We have TLSA, and that is great.  I sincerely mean that, I think the TLSA work is a great step forward.  However, I also think that a starting assumption that prescribes that all DANE protocols should be executed under the same pre-computed discussions as the TLSA work is very bad for DANE.  S/MIME's semantics, requirements, and usage are different than TLS'.  How different?  I don't even claim to know that.  I think this line of discussion (disc vs. deliv) marginalizes the very specific issues that Scott raised and the subsequent issues that I raised.  Can we try to stay on point?

> I'm agnostic, and am happy for this document and TLSA go whichever way the IETF wants. However, I'm not in favor of trying to cross the line and see if the IETF notices.

I see you keying in on words, and I worry you're objecting to phraseology rather than the technical issues.  Would you prefer to reboot the conversation with more specific terminology?  These issues are important, so how about ``key learning.'' That is, imho, a more accurate description anyway.

> So, WG: is "DNS for delivery vs. DNS for delivery and discovery" a topic people want to revisit?

No, sorry, this is not the question that I raised.  I offered very specific technical justifications for technical suggestions.  Any answer to the above is not something I have raised or am discussing.

Eric

---

From: "Osterweil, Eric" <[email-masked]>
Date: Thu, 6 Feb 2014 02:00:31 +0000

>>> On Feb 5, 2014, at 3:50 PM, Viktor Dukhovni <[email-masked]> wrote:

<snip>

> (And, yes, my TRYTLS record proposal definitely slides right into the discovery zone. And that's why it has gotten roundly ignored.)

<meta comment>
I am only chiming in here to illustrate that there is unneeded polarization in this thread:
</meta comment>

Indeed, the above conversation (which I truncated for those who may still be keeping an eye on this) perfectly illustrates the misalignments of my message and the subsequent messages.  I never outlined discovery this way and if that is the working definition of the word here, then a better description is needed.  Key learning: how one learns the authorized key for a service domain, would be more illustrative, imho.

Eric

PS - I hope using the term ``meta comment'' doesn't run afoul of IETF sensibilities…  too soon? ;)

---

From: "Osterweil, Eric" <[email-masked]>
Date: Thu, 6 Feb 2014 02:20:47 +0000

> often disconnected, and caches certificates.

I didn't say DNS was unavailable.  I said the RR was not available ``in DNS.''  This is a _big_ difference, as service #3 of DNSSEC is secure denial of existence.

> Basically the MUA operates with a stored (rather than in-memory)

I think the above starts to address some concerns, but I think it sidesteps the initial comments I made.  There is a clear semantic we can relay w/ this new flag: ``don't use this cert for this email.''  The above seems like it is trying to address the case where we rush to use certs while they exist, and restrict use after.  I'm ok w/ that, but I think it leaves us with an inference problem instead of being specific.

<snip>

> TA record with an EE record.

Well, what about if I run a mail domain, I issue usage type 3 certs, I don't want to run a CRL or OCSP service, and I want to remove a user account from my domain?  

To be honest, I think usage type 4 would be useful, but I'll only press more illustrative examples if the group wants more discussion?  If no one else thinks it's useful, so be it.  However, (at a high level) I do think it is important to point out that deauthorization is fundamentally different than revocation, and OCSP/CRL services have their own warts too.

Eric

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 6 Feb 2014 02:32:34 +0000

On Thu, Feb 06, 2014 at 02:20:47AM +0000, Osterweil, Eric wrote:

> Well, what about if I run a mail domain, I issue usage type 3
> certs, I don't want to run a CRL or OCSP service, and I want to
> remove a user account from my domain?

An EE cert per user is fine.  Just remove the EE cert in question
from the list of certificates associated with the user.  The
certificate is then no longer valid for signing new mail or
for encrypting new mail addressed to the user.

You're getting at a basic semantic question.  Does an SMIMEA record
publish ALL presently valid certificates for a user (a white-list
that fails closed, so blacklists are redundant), or only SOME of
the valid certificates, in which case one might conceivably want
explicit revocation...  My vote is for ALL.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 5 Feb 2014 22:56:52 -0500 (EST)

> certificate not listed in DANE is the wrong certificate, unlike

+1

Any application caching DNS data beyond the TTL should either forget the
data, or prompt the user. Adding more bells and whistles in DNS to
emulate X.509 offline properties are not appropriate for DNS.

Paul

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 5 Feb 2014 23:23:11 -0500

On Wed, Feb 05, 2014 at 10:56:52PM -0500, Paul Wouters wrote:
> data, or prompt the user.

Pray tell, how does the application learn the TTL?  What if it
doesn't, and guesses wrong?

A

-- 
Andrew Sullivan
[email-masked]

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 6 Feb 2014 04:31:38 +0000

> doesn't, and guesses wrong?

I must plead ignorance of the obstacle, what do you have in mind?

If learning DNS TTLs along with the RRset data is problematic,
application caches should have reasonably short maximum lifetimes.
For an MUA caching an SMIMEA certificate, probably on the order of
7days or less.  This is substantially shorter than typical PKIX
certificate lifetimes and commensurate with say typical Kerberos
ticket renewal lifetimes (another form of short term cached
credentials).

-- 
	Viktor.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 5 Feb 2014 23:44:40 -0500

> I must plead ignorance of the obstacle, what do you have in mind?

I am repeatedly informed by my man pages, RFC 3493, and every web
browser implementer I've ever spoken to that getting the TTL on an RR
coming to you from the system resolver is hard.  I'd be more delighted
than I can express to be misinformed, so if you know otherwise please
say so.

There is a new API (more a meta-api) that Paul Hoffman worked on
(http://www.vpnc.org/getdns-api/) that I think we should all embrace
partly for the above reason, but we're not even at 0-day with that yet
AFAICT.  

> application caches should have reasonably short maximum lifetimes.

I recognise the basic impulse in what you're saying, but it gives me
pause.  Timing attacks involving DNS and the browser "pinning" policy
have always struck me as plausible (and ISTR a demonstration, but I'm
darned if I can come up with it now).  But using this sort of trick
for actual certificate stuff appears to make the target of any
pinning-timing attack more valuable.  Is that a problem?  (That's not
a rhetorical question.  I'm an idiot.)

[I get your other argument about lifetimes.  Not trying to ignore,
just accepting.]

A

-- 
Andrew Sullivan
[email-masked]

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 6 Feb 2014 04:55:24 +0000

> than I can express to be misinformed, so if you know otherwise please

All I know is that libresolv (used in Postfix) returns the TTL with
each RR.  This is only a single data point, so I would not be at all
shocked to discover that other stub resolvers are different in this
regard, just very mildly surprised.

Thanks for the eye-opener.

> partly for the above reason, but we're not even at 0-day with that yet

I'll endeavor to take a look once I am not swamped trying to get
the SMTP draft out the door.

> [I get your other argument about lifetimes.  Not trying to ignore,

Agreed, somewheere underneath all of our security models there are
basic questions like the security of a system clock aggressively
synced with remote NTP servers.  Ensuring integrity at boot time
requires care to seed the PRNG properly, avoid clock rollback
attacks, ...

When designing reusable components, we can only try to do the right
thing at each layer, and hope it all fits together.  Building a complete
secure system requires a separate big-picture analysis.

-- 
	Viktor.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 06 Feb 2014 16:23:43 +1100

> than I can express to be misinformed, so if you know otherwise please

And I say BS.  If you are using a layer above the resolver
(gethostbyname, getaddrinfo) yes it may be hard but for TLSA *there
is no layer above the resolver*.

libresolv/libbind have provided access to the TTL since the 1980's.

Even Microsoft Windows programmers don't have a excuse as DnsQuery
returns the ttl in its results.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms682016(v=vs.85).aspx

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 6 Feb 2014 14:16:15 +0000

> regard, just very mildly surprised.

OK, I also used the DNS client library in Python once for SRV record
lookups, and this too returned TTLs.

Independently of Mark (who beat me to the punch with a more foreceful
objection), I was also wondering whether perhaps you're misremembering
the issue.  Without DANE, browsers have no need for explicit DNS
lookups, they just lookup network address information via getaddrinfo()
and friends.  So perhaps the issue you had in mind was that
getaddrinfo() returns no TTLs and no validation status.  This is
a well known limitation.

Once applications are doing explicit DNS lookups (SRV, TLSA, ...)
perhaps TTLs are generally available along with the RRDATA.

-- 
	Viktor.

---

From: "Osterweil, Eric" <[email-masked]>
Date: Thu, 6 Feb 2014 17:27:40 +0000

> perhaps TTLs are generally available along with the RRDATA.

To follow all of this up: I think Andrew was illustrating a couple of important issues, and one of them is that we cannot always all rely on full knowledge of how people will adopt DANE processing (look at the TTL, don't look at AD, etc.).  Even if we fully specify how it should be used (only look here, don't look over there, etc.), we still have to be liberal in what we accept.  

Rather than focusing narrowly on how an RP might or might not find SMIMEA RRs, consider an incremental deployment case whereby someone rolls _SOME_ of their constituency over to DANE, and leaves some of their clients on (say) AD.  Now, I need my RPs (the MUAs) to know the difference between ``DANE doesn't want you to use a cert,`` and ``you may go find the cert somewhere else.'' 

IMHO, the TTL discussion is useful because it illustrates that not everyone will even _know_ to go looking for it, but we might want to realize that there are other issues we will have to confront when people consider operational rollouts of this.

Eric

---

From: "Wiley, Glen" <[email-masked]>
Date: Fri, 7 Feb 2014 02:12:26 +0000

>partly for the above reason, but we're not even at 0-day with that yet

We are very close to "0-day" for getdns :)

A few of us (NLNetLabs and Verisign) have been working on an open source
Implementation of the specification that we are planning to release prior
to IETF89.

The API provides pretty complete access to the RR data and includes
DNSSEC validation.  Per the spec the API can be used as a stub
Resolver (as with extant libc entry points) or as a recursive
Resolver (the default behavior per the spec).

-- 
Glen Wiley
KK4SFV

Sr. Engineer
The Hive, Verisign, Inc.

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 21 Feb 2014 11:48:24 -0800

> topic people want to revisit?

Sorry for the late response, but "yes" would be my answer.  I've never
been fully convinced that the discussion in the past was truly consensus
one way or the other, and I do think we need some guidelines for doing
security availability discovery.  The world has proven time and time
again that we can't do it without the DNS(SEC) helping to bootstrap it.
-- 
Wes Hardaker
Parsons