Re: [dane] Draft for serializing DNSSEC chains

[Eric Osterweil <[e-mail]>]

On 7/7/11 5:05 PM, Phillip Hallam-Baker wrote:
> On Thu, Jul 7, 2011 at 4:36 PM, Eric Osterweil 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     On 7/6/11 9:37 PM, Martin Rex wrote:
>
>>     > > (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.
>>     >
>>     > 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)?
>>
>>     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/
>>
>
>     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.

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. :)

>
> 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
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>