Subject: Re: [dane] Draft for serializing DNSSEC chains

From: "Osterweil, Eric" <[email-masked]>
Date: Wed, 06 Jul 2011 13:34:34 -0400

On 6/30/11 7:57 PM, "Mark Andrews" <[email-masked]> wrote:

> 
> 
> In message <[email-masked]>, "Richard L. Barnes"
> writes:
>>>>> Managing the crypto in just
>>>>> one system is hard enough, this seems to inheret baggage from two
>>>>> crypto-enhanced systems...  :-/
>>>> 
>>>> I don't think it's quite that bad.  There's not really any PKIX baggage, s
>> ince
>>>> the all of the crypto validation comes from the DNSSEC extension.
>>>> 
>>>> The risk of falling out of sync may just be part of the trade-off for spee
>> d.
>>>> It seems like there's a plausible solution (mod_dnssec_staple), so it does
>> n't
>>>> seem like it necessarily has to be a blocking issue.
>>> 
>>> Again, I think the operational complexities are being vastly underestimated
>> .
>>> The certs have to be regenerated by authorities for websites based on
>>> changes in DNS zones that exist anywhere along the validation chain.  In
>>> particular, how many web server admins keep track of when the root changes
>>> its ZSKs?  I know of the top of my head, but I still would find it a pain i
>> f
>>> I had to go regen certs because someone popped a key somewhere... I still
>>> don't even know how I would find that out?
>> 
>> It's not really so mysterious, it's just the chain from the name in the cert
>> to the root.  If I'm trying to maintain a cert for isoc.org, I have to monito
>> r 9 records (+RRSIGs)
> 
> 6 RRsets + RRSIGs
> 
>> 1. . DNSKEY
>> 2. . DNSKEY RRSIG (15 days validity)
>> 3. org DS    
>> 3. org DS RRSIG (5 days validity)
>> 4. org DNSKEY
>> 5. org DNSKEY RRSIG (20 days validity)
>> 6. isoc.org DS
>> 6. isoc.org DS RRSIG (20 days validity)
>> 7. isoc.org DNSKEY
>> 8. isoc.org DNSKEY RRSIG (14 days validity)
>> 9. isoc.org TLSA
>> 9. isoc.org TLSA (30 days validity)
>> 
>> So my script polls for these records whenever the TTL expires, and issues a n
>> ew cert whenever the chain changes.  Seems like a pretty defined scope, and l
>> ike I said before, a plausible solution.
> 
> Now having the server maintain a DNS TTL controlled cache of the
> records required to validate the TLSA and returning those wouldn't
> break anything the DNS zone operators are depending apon.  This
> doesn't have to be in the CERT.  You can tentitively trust the CERT,
> then request the DNS validation chain, then decide whether you full
> trust the CERT.  The only thing the CERT needs is a indication that
> the server supports requesting the DNS validation chain.  Even if
> the returned validation chain is incomplete the client can request
> the missing bits.

Something like this (where a cert says, "use DNS") makes a lot more sense.
It's when the cert takes a snapshot of the DNS and says, "trust what I saw
back when this was valid" that worries me.  The attack is that an adversary
who compromises a key can re-use that key as long as a browser doesn't look
into DNS an just trusts the cert.

Eric

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 06 Jul 2011 19:54:36 -0400

> into DNS an just trusts the cert.

Which is no different from the adversary intercepting the browser's DNS
queries and responding with the old chain.

Security-wise, there is nothing magic about the DNSSEC distributed
database.  Freshness of DNSSEC data is governed by RRSIG validity, no
matter how the data is obtained.  The stapled chain is a cache and, as
such, it can affect availability, though if the hypothetical
mod_dnssec_staple is used there is no reason to think it would fail any
more often than any other TTL-based cache.

DNSSEC RRSIGs are properly analogous to OCSP responses; they provide the
same functionality.  (DNSSEC just skipped the intermediate stage of
signed long-term certificates because offline operation was not a goal.)
The motivations and security considerations for DNSSEC chain stapling
are much the same as those for OCSP stapling.

(Which raises another point.  OCSP stapling uses a TLS extension.  This
is a more appropriate design than embedding the data in the cert;
additionally, the latter is impossible to do backward-compatibly with a
CA-signed cert.  For DNSSEC chain stapling, embedding is possible.
Chromium may find the ability to use externally automated DNSSEC chain
stapling with existing web servers to be sufficient justification for
choosing the poorer design, but does IETF?)

-- 
Matt

---

From: "Osterweil, Eric" <[email-masked]>
Date: Wed, 06 Jul 2011 20:21:50 -0400

> queries and responding with the old chain.

Wrong.  First, the parent can re-delegate to a new DS pointing to a new KSK,
or or the KSK can sign a new ZSK (whichever got popped), and the rev bit can
be set in the zone.  Then, the keys are served at multiple servers over
multiple network paths.  Thus, you get better freshness AND better path
diversity over DNS.

The vector is much more complex in DNS than it is over HTTP.  I can send u
some closed-form analysis discussing this, but the gist of it is that this
statement is a very severe oversimplification (and the analysis is quite
long).

> database.  

Agreed, but it has rules, and its security is in the same place as its data.
This has the effect of reducing consistency problems.  Thus, the DB is not
magic, but it IS authoritative for its own data.  That's a big difference.

> Freshness of DNSSEC data is governed by RRSIG validity, no

This is very untrue.  First, this is not a cache because it's ability to be
updated neither follows the rules of the DNS protocol, nor is updated with
the state of that authoritative source (the name servers).

Second, you continue to miss the main point I'm trying to make: the more
complexity you add, the more things _will_ break.

I understand that a hypothetical/non-existent/could-be-universally-deployed
Apache mod could address this, but it is not designed/built/deployed and
even if it were, we have not seen how it behaved operationally (regenerating
certs on the fly sounds... Problematic to me).  More generally, this would
be a serious operational problem, imo.

> are much the same as those for OCSP stapling.

Why would you say that?  The two protocols are immensely different and they
have much different goals.  Please provide details if you feel this is in
err.

> CA-signed cert.  

OK, so let's discuss this.  Are you aware of any operational hurdles that
may have hampered OCSP (for what it was intended, let alone for something
new)?

> For DNSSEC chain stapling, embedding is possible.

This will lead to disaster, and opens up new attack vectors.

Eric

---

From: Martin Rex <[email-masked]>
Date: Thu, 7 Jul 2011 03:37:04 +0200 (MEST)

Osterweil, Eric wrote:
> 
> "Matt McCutchen" <[email-masked]> wrote:
> > 

I agree with Matt (I hadn't noticed he had already suggested this
when I wrote my last message).

Processing stapled OCSP responses is similar to processing stapled
DNSSEC records, although the scope of DANE records is slightly broader
than OCSP (because it may include issues server endpoint identification).

> may have hampered OCSP (for what it was intended, let alone for something

AFAIK, the original TLS extension was a single OCSP response, and then
all CAs added intermediate certs so that a single OCSP response was
no longer sufficient to validate a server certificate.

The proposal for a new TLS extension to carry more than a single
OCSP reponse is still an internet draft:
   https://datatracker.ietf.org/doc/draft-pettersen-tls-ext-multiple-ocsp/

> This will lead to disaster, and opens up new attack vectors.

Could you elaborate?  I fail to follow.

The security design of DANE does not have a dependency on the transport
that is used to convey the signed DNS records.  Neither does OCSP and CRLs.

-Martin

---

From: Tony Finch <[email-masked]>
Date: Thu, 7 Jul 2011 10:39:56 +0100

Osterweil, Eric <[email-masked]> wrote:
> > matter how the data is obtained.

Actually RRset TTL.

> > The stapled chain is a cache and, as such, it can affect availability,
> > though if the hypothetical mod_dnssec_staple is used there is no
> > reason to think it would fail any more often than any other TTL-based
> > cache.
>

DNS caches are also not updated by authority servers.

The serialized records should include their TTLs and the time that they
were fetched, so that clients can obey DNS lifetime semantics. If you use
exact DNS wire format then you can just append a timestamp covering the
whole bundle.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Humber, Thames, Dover: South or southeast 5 to 7, decreasing 4 for a time.
Moderate or rough. Showers, occasionally squally. Moderate or good.

---

From: Eric Osterweil <[email-masked]>
Date: Thu, 07 Jul 2011 16:36:23 -0400

> https://datatracker.ietf.org/doc/draft-pettersen-tls-ext-multiple-ocsp/

Yes, but are you aware of the _operational_ problems?  Is the 
distinction between design complexity and operational complexity not 
clear?  If so, is anyone else on the list concerned?

> Could you elaborate?  I fail to follow.
I think (having restated the same position in multiple different ways 
over the last several days) I have outlined the objection pretty 
clearly.  If you are not clear on them, please re-read my previous 
emails and I can clarify any specific points you don't follow.

> that is used to convey the signed DNS records.  Neither does OCSP and 
Actually, it very much does.  If operational issues open attack vectors 
(which they will in this case), then I think the security design (by 
definition) has a dependency.  Is the vector still unclear?

Eric

---

From: Eric Osterweil <[email-masked]>
Date: Thu, 07 Jul 2011 16:41:28 -0400

On 7/7/11 5:39 AM, Tony Finch wrote:
> Osterweil, Eric<[email-masked]>  wrote:
Actually, both. ;)

> DNS caches are also not updated by authority servers.

They may or may not be, but they are designed to get their data from 
them (as opposed to a perl script).
> exact DNS wire format then you can just append a timestamp covering the
Sooo... Putting this in a spec is the same as having all implementations 
honor it?  Misconfigurations are no more common?

I think there's a lot of evidence that many DNS caches still get this 
wrong, why would external code automatically overcome the same issues?  
I think the point here is that any realistic proposition must face the 
inevitability that implementations will break, and operations will too.  
The problem here is there are suddenly a LOT more moving parts to get 
broken, and an insufficient discussion on how to mitigate this.

Eric

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 7 Jul 2011 16:59:20 -0400

I'm a little confused by how overwhelmed you are by the operational impact here.  

On the server side, there just needs to be a script that runs every few minutes to generate a certificate and tell the web server about it.  This is basically already done, in the code Adam has published; the only thing missing is a timer and the code to read the TTLs to figure out how to set the timer.

On the client side, it's just an extension to normal certificate validation; there's only more code here, not any big operational change.

ISTM that given the above, the biggest operational impact will be swapping out the server cert every so often.  I'll grant that that could be a major challenge for large, distributed sites (although you could refresh disparate servers independently), but for small-to-medium scale instances, it doesn't seem all that onerous.

Am I missing something here?

--Richard

On Jul 7, 2011, at 4:41 PM, Eric Osterweil wrote:

> They may or may not be, but they are designed to get their data from them (as opposed to a perl script).
>> 
>> 
> Sooo... Putting this in a spec is the same as having all implementations honor it?  Misconfigurations are no more common?
> 
> I think there's a lot of evidence that many DNS caches still get this wrong, why would external code automatically overcome the same issues?  I think the point here is that any realistic proposition must face the inevitability that implementations will break, and operations will too.  The problem here is there are suddenly a LOT more moving parts to get broken, and an insufficient discussion on how to mitigate this.
> 
> Eric
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 7 Jul 2011 17:05:23 -0400

On Thu, Jul 7, 2011 at 4:36 PM, Eric Osterweil <[email-masked]>wrote:

> Yes, but are you aware of the _operational_ problems?  Is the distinction
> between design complexity and operational complexity not clear?  If so, is
> anyone else on the list concerned?
>

Well if any such problems exist it should be possible to state them with
specificity. Otherwise the assertion is FUD pure and simple.

The distinction between design complexity and operational complexity was not
originally clear because no such distinction had been proposed. It was only
after I pointed out that there are empirical criteria for design complexity
that Matt decided that he was talking about operational complexity.

There are empirical criteria for operational complexity as well:

* Number of administrative actions required to perform an operation
* Number of independent services that must be configured to achieve an
action
* Dependence on support for specific capabilities in deployed infrastructure
* State that must be maintained at services

Adam's proposal is better than the previous one on each of these criteria
above. The proposal to use the pickled chain in an OCSP token is better
still.

> I think (having restated the same position in multiple different ways over
> the last several days) I have outlined the objection pretty clearly.  If you
> are not clear on them, please re-read my previous emails and I can clarify
> any specific points you don't follow.
>

Well the purported issue is not at all clear to me and I have twenty years
experience of PKI.

I don't think that the issue you claim exist is real. I am certain that you
have not substantiated your claim.

If you really think that there is a problem explain it to your CTO and then
let him tell us that he thinks there is a problem. If you and Matt really
think there is a problem you should be able to explain it to Burt. In terms
of years of experience he out-ranks everyone here as far as I am aware.

If Burt is willing to state that he is sure that there is a problem then I
am willing to re-read your messages.

If Burt is not willing to endorse your claim or you do not have sufficient
confidence in it to take it to him then I am not willing to attempt to
decipher your claims either.

> definition) has a dependency.  Is the vector still unclear?

I don't think that you understand the TLS protocol or the proposal being
made.

All the pickled DNSSEC chain provides is one means of establishing the
validity of the key. It does not have to be the only means.

The problem of Internet time synchronization means that there is an
intrinsic uncertainty of +- 25 hours associated with any validation
operation applied to statically signed data.

It is pretty clear to me that any ambiguities that may arise as a result of
DNS operations are going to be of the same order which is not surprising as
they have much the same underlying causes.

Thus I do not see the concerns you appear to be raising as being valid.

-- 
Website: http://hallambaker.com/

---

From: Eric Osterweil <[email-masked]>
Date: Thu, 07 Jul 2011 17:18:47 -0400

> Am I missing something here?

Sorry, but yes.  How will you be sure that people understand, deploy, 
and maintain the operational status of all of these scripts?  Seriously, 
can you tell us that you're sure user-error won't lead to outages when 
the data in two places (DNS and certs) diverges?  I completely buy that 
_you_ can do this.  However, what about people interested in adopting 
who are just as likely to get burned as to understand the increasing 
complexity?  Can _you_ be sure that _they_ will do all of this right?

Eric

---

From: Eric Osterweil <[email-masked]>
Date: Thu, 07 Jul 2011 17:35:22 -0400

On 7/7/11 5:05 PM, Phillip Hallam-Baker wrote:
> On Thu, Jul 7, 2011 at 4:36 PM, Eric Osterweil 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     distinction between design complexity and operational complexity
>     not clear?  If so, is anyone else on the list concerned?
>
>
> Well if any such problems exist it should be possible to state them 
> with specificity. Otherwise the assertion is FUD pure and simple.

OK.  I don't want my concerns on this to be misconstrued as a litany of 
problems.  So, just some "complications" (no judgements), and not 
intended to be comprehensive:
- Does someone need to provision an OCSP server now when they want to 
use a cert?  Large companies (I wonder who would be a good example? :-P 
) spend a lot of operational capital provisioning their OCSP services, 
and pay for it (bandwidth if nothing else).  Now web server operators 
get to do that too.
- Now, I can take this new list of OCSP servers as a new attack vector: 
pop a DNSKEY, DoS an OCSP server, voila...

I'm not bagging on OCSP, I'm trying to point out that the protocol is 
associated w/ real operational overheads and liabilities, and should 
_not_ be underestimated.
>
> The distinction between design complexity and operational complexity 
> was not originally clear because no such distinction had been 
> proposed. It was only after I pointed out that there are empirical 
> criteria for design complexity that Matt decided that he was talking 
> about operational complexity.

I think you need to re-read that thread.  A late understanding of a 
point does not imply a correspondingly late assertion of that point. :)

> * State that must be maintained at services
More than this.  Operations (unfortunately for them) must account for 
all of the corner cases that were (and were not) foreseen.  This is the 
main reason for the KISS principle that engineers (i.e. us) follow.

>
> Adam's proposal is better than the previous one on each of these 
> criteria above. The proposal to use the pickled chain in an OCSP token 
> is better still.

Again, aside from rather obvious layer violations, I still think you are 
underestimating the points I outlined (even in this email).

Eric

<bait removed>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 7 Jul 2011 17:41:24 -0400

As far as "understand and deploy", well, that sounds like an area where web server vendors could add value.  In principle, all the user would need to do is provision/sign the DANE record and turn the feature on; the rest is algorithmic.

As far as "maintain operational status": Consider what happens if the "cert refresh" script breaks.  At worst, the cert won't validate.  Recognizing stapling as a shortcut, though, even that breakage doesn't need to happen -- if the DANE record has a hash of the public key or the cert, the client can always go back to the DNS to check that everthing's OK.  So really, when things break, you just lose the optimization.

It seems like the question is just whether people are willing to trade some risk of  breakage/delay some of the time for an optimization the rest of the time.

--Richard

On Jul 7, 2011, at 5:18 PM, Eric Osterweil wrote:

> Sorry, but yes.  How will you be sure that people understand, deploy, and maintain the operational status of all of these scripts?  Seriously, can you tell us that you're sure user-error won't lead to outages when the data in two places (DNS and certs) diverges?  I completely buy that _you_ can do this.  However, what about people interested in adopting who are just as likely to get burned as to understand the increasing complexity?  Can _you_ be sure that _they_ will do all of this right?
> 
> Eric

---

From: Martin Rex <[email-masked]>
Date: Thu, 7 Jul 2011 23:43:58 +0200 (MEST)

> clear?  If so, is anyone else on the list concerned?

I do not see any (additional) operational problems.

The server is *ALWAYS* in a better position to obtain OCSP responses
for his own server cert and cache it, and the same goes for DANE records.

So from the operational standpoint, using a TLS extension to
convey the information significantly facilitates the communication
with the _correct_ server.  It doesn't help when talking to an
attempted imposter.

> definition) has a dependency.  Is the vector still unclear?

Nope, it does not.

The only things in dane that is security-relevant during verification
is the signed records and the the RRSIG lifetimes.  The transport
as well as all TTLs are completely irrelevant.

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 7 Jul 2011 18:14:10 -0400

On Thu, Jul 7, 2011 at 5:35 PM, Eric Osterweil <[email-masked]>wrote:

> problems.  So, just some "complications" (no judgements), and not intended
> to be comprehensive:
> - Does someone need to provision an OCSP server now when they want to use a
> cert?
>

No, the proposal is to mandate client support for stapling for this
application.

The OCSP token is then simply a piece of data that is exchanged in the
normal TLS channel.

Use of a standalone OCSP service is not something I had considered. But it
might well be simpler in some deployments. If an enterprise does not want to
upgrade their existing Apache server to one that supports stapling they
could deploy OCSP as an additional service. The OCSP in question being
written to create the OCSP tokens from the DNSSEC data as required.

> Large companies (I wonder who would be a good example? :-P ) spend a lot of
> operational capital provisioning their OCSP services, and pay for it
> (bandwidth if nothing else).  Now web server operators get to do that too.
>

Since one of the objectives here is to pull through support for OCSP
stapling, the overall bandwidth requirement should decline.

> - Now, I can take this new list of OCSP servers as a new attack vector: pop
> a DNSKEY, DoS an OCSP server, voila...
>

Nope, the proposal was to use stapling.

 There are empirical criteria for operational complexity as well:
> More than this.  Operations (unfortunately for them) must account for all
> of the corner cases that were (and were not) foreseen.  This is the main
> reason for the KISS principle that engineers (i.e. us) follow.
>

Expect the unexpected is not actionable advice.

PKIX is a twenty year old legacy. DNSSEC is a to-be-deployed addition to a
twenty year old legacy. Both ponds have the same amount of mud in them. The
only difference being that the DNS pond has been stirred harder and more
recently. Thus the degree of visibility is much better in the PKIX pond than
the other one.

Thus if we are going to go by known unknowns it would seem that you are
arguing to rely on as little DNSSEC infrastructure as is possible.

> underestimating the points I outlined (even in this email).

I don't see any layer violation.

As you might be aware, the layering model was developed for OSI. DNS
protocol is the Internet equivalent of X.500 in OSI terms. DNSSEC is to DNS
what X.509 is to X.500. Ergo if you believe in layers the two schemes are at
the exact same level.

Trying to understand IETF protocols in terms of layers is probably a mistake
in any case. IETF protocols are frequently recursive. TLS is a transport
protocol but it calls OCSP which is an application protocol. There is an
architecture there but it is not the OSI model.

---

From: Eric Osterweil <[email-masked]>
Date: Thu, 07 Jul 2011 18:30:56 -0400

> As far as "understand and deploy", well, that sounds like an area where web server vendors could add value.  In principle, all the user would need to do is provision/sign the DANE record and turn t…
As I said (much earlier), this adds an architectural disconnect between 
data authorities (DNS name servers), and clients (web browsers).  The 
cert generation has no protocol interaction with the DNS servers.

Rather than restate the above, please look at the email I sent 
describing it (it seems more appropriate than retyping it).

>
> As far as "maintain operational status": Consider what happens if the "cert refresh" script breaks.  At worst, the cert won't validate.

No, at worse, an attack vector has been opened or we come to the case 
where people fail to understand why validation is failing and simply 
remove DANE security.  This, imho, is the much more likely case, and 
could lead to larger groups rejecting the approach as overcomplicated.  
Of course, this is an operational issue that would only avail itself of 
us at scale if we don't anticipate it.

> Recognizing stapling as a shortcut, though, even that breakage doesn't need to happen -- if the DANE record has a hash of the public key or the cert, the client can always go back to the DNS to check that everthing's OK.  So really, when things break, you just lose the optimization.
That doesn't stop the attack vector.

> It seems like the question is just whether people are willing to trade some risk of  breakage/delay some of the time for an optimization the rest of the time.
There is also the question of non-experts trying to catch up and 
realizing the propensity for this approach to fall out of sync can lead 
to major consequences (attacks, removing security, etc).  One very 
possible outcome is that people stop trying to use the DANE protocol 
altogether because "it" seems to often be out of sync.

Eric

---

From: Martin Rex <[email-masked]>
Date: Fri, 8 Jul 2011 01:00:28 +0200 (MEST)

Eric Osterweil wrote:
> use a cert?

Admittedly I have zero experience with the use of OCSP, so I'm
trying to do some logical guessing here.

I guess the presence of an AIA-OCSP extension in the server certificate
is a prerequisite, and the signature on the OCSP response must be
either from the certificate issuer itself or from a designated
OCSP responder signed by the certificate issuer and explicitly
included in the OCSP response certs container.

The idea is that OCSP response stapling only makes sense when it
reliably allows the TLS client to perform revocation checking
on the server certificate without any additional external information.

>
> Large companies (I wonder who would be a good example? :-P 

It should be up to the that issued the server's certificate to
provide fresh OCSP responses for the server's cert (chain)
on a regular basis.

I believe it is undesirable for a business to have clients fail
server authentication in indeterministic fashions, without the
server knowing when, why and how to fix it.

> associated w/ real operational overheads and liabilities, and should 

If there is any value in certificate revocation checking at all,
then the most efficient, most reliable and most manageable fashion
is to have the server obtain the OCSP responses and convey them
stapled and in-band to the communication peer.

"It's a dirty job, but somebody's got to do it".
Chasing OCSP for the server certificate on the client is a design flaw.

There are no performance and connectivity problems -- the server admin
is free to choose a CA with an OCSP responder that meets the server
operators desired service levels, availability and response times,
caching OCSP responses for its own certificate(s) is easy for the
server.  New OCSP responses can be checked before replacing the
existing ones, so the admin has a head start on knowing about the
problem and fixing it before it affects operations, and the server
admin remains in full control of everything.

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 7 Jul 2011 19:08:06 -0400

On Thu, Jul 7, 2011 at 6:30 PM, Eric Osterweil <[email-masked]>wrote:

> realizing the propensity for this approach to fall out of sync can lead to
> major consequences (attacks, removing security, etc).  One very possible
> outcome is that people stop trying to use the DANE protocol altogether
> because "it" seems to often be out of sync.

Scripts suck, a solution that can only be implemented using scripts is
likely to break.

The point here is that the solution does not depend on the use of scripts at
all.

It is quite easy to implement this in the Web Server alone. The only change
the Web server needs is:

1) Determine that it should send the server generated OCSP token.
2) Check the expiry of the token.
3) If the token has expired, generate a fresh one.
4) Staple the OCSP token into the response

3a) Alternatively schedule an internal action to generate the fresh token
pro-actively.

That is a code set that is quite easy to add into the .NET TLS handling
code. I would imagine the OpenSSL code to be very similar but have not
checked that as recently.

Since the token is part of the negotiation it is also an input to the master
secret.

An alternative would be to implement the scheme as a standalone OCSP
service. This has the advantage that the existing Web Server does not need
to be touched at all.

This feature could even be implemented as an extension to the Web Server
itself (i.e. an ISAPI or fastCGI type extension, not one that requires a
recompile). So this does not have to even require support for a new service.

---

From: John Gilmore <[email-masked]>
Date: Thu, 07 Jul 2011 18:04:32 -0700

I'm a little confused here.

> provide fresh OCSP responses for the server's cert (chain)

We don't trust the CAs, so we are asking that DNSSEC-provided keys be
served up to end users via OCSP, run by the CAs?  No, that would be
too straightforward.  Instead the proposal is that CAs would serve
OSCP to the secured web servers, which would cache them and serve them
up to the clients via some kind of SSL extension.

Why does this smell to me like a scheme by CAs to make secure web
sites keep paying CAs?

What was wrong with clients just doing DNS lookups to get DNSSEC
records, rather than proxying them through two intermediaries using
two separate protocols?  If there IS a problem with being able to do
DNSSEC lookups, like perhaps no good asynchronous library
implementation that does it, then let's fix that, rather than
convoluting the protocols and adding unnecessary middlemen.

	John

---

From: Martin Rex <[email-masked]>
Date: Fri, 8 Jul 2011 04:15:08 +0200 (MEST)

John Gilmore wrote:
> > It should be up to [CA] the that issued the server's certificate to
> served up to end users via OCSP, run by the CAs?

I'm sorry for causing confusion.  Let me retry.

This was an answer question who would be issuing/signing OCSP responses
that the server can staple into a multiple-OCSP-responses TLS extension
(and whether that would/could be a company OCSP server) and applies
only to CA-issued server certificates (that IMHO ought to have an
AIA OCSP extension in case OCSP is desired).

In the general case, the server should not make any assumptions about
which OCSP responders the TLS client might trust, and for simplicity
only send OCSP responses that were either signed directly by the
certificate issuer or alternatively by an OCSP issuer authorized
by the certificate issuer and its OCSP issuer cert contained in
the OCSP response, i.e. _everything_ conveyed inline.

If the server additionally has his server certificate authorized
by DANE TLSA records, it should use a different TLS extension,
similar to the OCSP response extension, to convey _ALL_
DNSSEC records that are necessary for a validation of the
server certificate.

So if someone uses an organizational CA (that does not chain
to the TLS X.509 PKI, he could still use OCSP for the TLS server
cert if he really wanted to (or was required to by some policy
or regulation).

> two separate protocols?

The purpose is twofold: supply TLS clients behind broken DNS proxies
(of which there seem to be quite a lot in the installed base),
as well as clients in private DNS universe networks connecting through
HTTP(S) proxies with the CONNECT method (basically every browser
in a company with a sensibly firewalled internal network).

(how does the root key rollover work for those DNS-disconnected clients?)

The other idea is that the client does not need any additional
network connection other than that to the server in order to retrieve
all information that is necessary to validate the server's certificate.
It is the most efficient if everyone, and servers in particular,
provide the non-revocation proofs (OCSP) or DNSSEC confirmation (DANE)
that they're using a valid certificate.

>
>                   If there IS a problem with being able to do

Personally, I consider the asynchronous library implementation
a total non-issue.  If there are folks using fancy programming
environments where they don't have that readily available,
then they should either write it themselves (which should be
easy if they're Pros and their fancy environment is at least
remotely useful), or they should switch to a more adequate
environment when their current one just doesn't cut it.

-Martin

---

From: Tony Finch <[email-masked]>
Date: Fri, 8 Jul 2011 09:52:06 +0100

> (how does the root key rollover work for those DNS-disconnected clients?)

It doesn't work for lots of clients, e.g. software on the shelf. The current planned timing for root key rollovers is MUCH too short - basically the minimum allowed by RFC 5011. If a root key rollover ever happens it will probably have to be done via software updates.

Tony.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 8 Jul 2011 13:28:25 -0400 (EDT)

> up to the clients via some kind of SSL extension.

I agree that this is not buying us much. The energy is better invested in
locating and fixing the hypothetical systems that cannot be configured to
do DNSSEC with their upstreams. Heck, DNSSEC-over-HTTP from Kaminsky would
beat this chaining dnssec inside certificate hacks.

The big issue with OCSP is the loss of privacy to a third party, and while I
trust organisations like google and mozilla more then I trust the CAs, I don't
really want to need to trust them for this - and I know some of these trusted
organisastions prefer not to have to run these things either.

On top of it, there is a port 80 to 443 untrusted leap when doing this.

Paul

---

From: Jakob Schlyter <[email-masked]>
Date: Fri, 8 Jul 2011 19:43:16 +0200

8 jul 2011 kl. 10:52 skrev Tony Finch <[email-masked]>:

> It doesn't work for lots of clients, e.g. software on the shelf. The current planned timing for root key rollovers is MUCH too short - basically the minimum allowed by RFC 5011.
> If a root key rollover ever happens it will probably have to be done via software updates.

Please elaborate on why it would not work, I'd be most interested why. And why you did not present these findings when we asked for feedback more than a year ago. 

  Jakob (speaking as one of the people who choose the parameters)

---

From: Martin Rex <[email-masked]>
Date: Fri, 8 Jul 2011 19:56:15 +0200 (MEST)

Paul Wouters wrote:
> 
> The big issue with OCSP is the loss of privacy to a third party,

The privacy issue with OCSP exists only when trying to collect OCSP
responses for someone else's certificate.  There is no privacy issue
when obtaining OCSP responses for your own cert.

This is one of the reasons why I want to see servers sending
OCSP responses for their own server cert in-band through a TLS extension.
It is much more robust, much more efficient and there is no privacy issue.

On all my browsers I have server cert revocation checking disabled,
because it creates huge new security problems without really solving any,
and it kills your privacy.

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 8 Jul 2011 14:04:30 -0400

I think that the problem is that deployed software has a service life
between 3 months and up to 15 years.

There is a lot of infrastructure about that cannot upgrade its firmware and
you really wouldn't want it to either. The plotter in my office is 15 years
old. A replacement would cost me $4500 and wouldn't let me refill my own
cartridges.

There is a lot of embedded infrastructure out there that can't update
firmware or parameters easily.

So its a problem, but not one that we can't solve.

The approach I prefer is to make the root of trust for an enterprise a key
that is under their control. So they would use the CSR supplied by IANA to
sign the ICANN root under their private CA and then place the resulting cert
plus their root cert in a CERT record at their own zone apex.

The root of trust would also be their KSK or be used to sign it.

Applications would embed that root as their ultimate root of trust.

The result of that approach is that the enterprise can choose all the roots
of trust it is willing to rely on.

On Fri, Jul 8, 2011 at 1:43 PM, Jakob Schlyter <[email-masked]> wrote:

> > It doesn't work for lots of clients, e.g. software on the shelf. The
> current planned timing for root key rollovers is MUCH too short - basically
> the minimum allowed by RFC 5011.
> Please elaborate on why it would not work, I'd be most interested why. And
> why you did not present these findings when we asked for feedback more than
> a year ago.
>

---

From: Tony Finch <[email-masked]>
Date: Tue, 12 Jul 2011 19:15:19 +0100

Jakob Schlyter <[email-masked]> wrote:
> > current planned timing for root key rollovers is MUCH too short -
> > basically the minimum allowed by RFC 5011. If a root key rollover ever
> > happens it will probably have to be done via software updates.
>
> Please elaborate on why it would not work, I'd be most interested why.
> And why you did not present these findings when we asked for feedback
> more than a year ago.

I have discussed this at length several times on the DNSOP list. See for
instance the thread starting with
http://www.ietf.org/mail-archive/web/dnsop/current/msg08603.html

The essential problem is that ICANN doesn't provide any way for a device
to bootstrap trust if it misses an RFC 5011 rollover, and the rollover
timing is very short so this will be a very common problem. ICANN say that
vendors have to solve the bootstrap problem for themselves, since the
published signatures for the root KSK don't have any published security
properties or lifetime or service level.

This problem isn't necessary: RFC 5011 allows you to prepare and
pre-publish a standby KSK well in advance, in a way that fits in with
typical software release and support schedules. If this was done for the
root KSK then everyone could obtain and verify the next trust anchor and
the problem would basically go away.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Bailey: Southeast 3 or 4, increasing 5 or 6 later. Slight or moderate. Fair,
rain later. Good.

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 12 Jul 2011 23:43:17 +0200

On 12 jul 2011, at 20.15, Tony Finch wrote:

> timing is very short so this will be a very common problem.

ICANN publish each root KSK signed with its own long term X.509 CA. Vendors who do not want to use this mechanism, may choose to use their own CA to sign the root KSK CSR. Using these mechanisms is being implemented, e.g. verifying new root KSKs with the ICANN DNSSEC CA is implemented in later versions of Unbound.

> the problem would basically go away.

This has been considered and rejected as part of the design . Depending on how the production KSK would be compromised, a standby KSK needs to protected using a similar set of security controls (but not the very same) as the production KSK and/or need to use another algorithm (but we don't now which yet). Yes, it possible to design something that would work in theory, but combining this with the current mechanisms to provide transparency (trusted community representatives et al.) does not make sense. 

	jakob