Re: [dane] Opening issues...

[Warren Kumari <[e-mail]>]

On Jul 13, 2011, at 12:38 PM, Phillip Hallam-Baker wrote:

> It sounds to me like we are done.
> 
> If there are no outstanding issues to discuss in Quebec we should ask the ADs to issue it as an RFC and declare victory.


I realize that you were (probably) being sarcastic here, but I'm beginning to think that this may actually be the correct approach...
Not to declare victory in the sense that the WG is all done[0], but the protocol doc (draft-ietf-dane-protocol-08) looks to be close to fully baked (Paul and Jakob have been integrating the WGs consensus as we arrive at it, have bumped it after the Use Case document, and there have been no real substantive comment received that affect *that* document). The fact that we are revisiting closes issues, etc may mean that we are starting to dink with things that should not be dunked...

The last hop, etc issues may be better dealt with in another document....


> None of the other issues seem to fit into the charter as defined. There seems to be no interest whatsoever in even listening to any practical constraints on deployment, let alone addressing them.

You have repeatedly waved the deployability flag -- the working group seems to feel that the current system *is* deployable, and there have been numerous discussions on this topic. 
There is nothing stopping launching, and then if a more deployable solution presents itself / real world deployment issues *are* encountered, releasing a "You do DANE, but with these additions / tweaks / options for discovery / scaling / etc" document.

W


> 
> 
> On Wed, Jul 13, 2011 at 12:17 PM, Ondřej Surý <[e-mail]> wrote:
> Hi all,
> 
> you must excuse me, but I fail to see how this text relates to the
> subject of the email and the question if we have any open issues we want
> to discuss in Quebec.  Could we please a) stick to the subject (or
> change the subject of the email) and b) stick to the WG topic.
> 
> Also I would recommend re-reading the charter (which we agreed on when
> creating this working group by reaching the consensus) again:
> 
> > Description of Working Group:
> >
> >   Objective:
> >
> >   Specify mechanisms and techniques that allow Internet applications to
> >   establish cryptographically secured communications by using information
> >   distributed through DNSSEC for discovering and authenticating public
> >   keys which are associated with a service located at a domain name.
> >
> >   Problem Statement:
> >
> >   Entities on the Internet are usually identified using domain names and
> >   forming a cryptographically secured connection to the entity requires
> >   the entity to authenticate its name. For instance, in HTTPS, a server
> >   responding to a query for <https://www.example.com> is expected to
> >   authenticate as "www.example.com". Security protocols such as TLS and
> >   IPsec accomplish this authentication by allowing an endpoint to prove
> >   ownership of a private key whose corresponding public key is somehow
> >   bound to the name being authenticated. As a pre-requisite for
> >   authentication, then, these protocols require a mechanism for bindings
> >   to be asserted between public keys and domain names.
> >
> >   DNSSEC provides a mechanism for a zone operator to sign DNS
> >   information directly, using keys that are bound to the domain by the
> >   parent domain; relying parties can continue this chain up to any trust
> >   anchor that they accept. In this way, bindings of keys to domains are
> >   asserted not by external entities, but by the entities that operate the
> >   DNS. In addition, this technique inherently limits the scope of any
> >   given entity to the names in zones he controls.
> >
> >   This working group will develop mechanisms for zone operators to
> >   present bindings between names within their control and public keys, in
> >   such a way that these bindings can be integrity-protected (and thus
> >   shown to be authentically from the zone operator) using DNSSEC and
> >   used as a basis for authentication in protocols that use domain names as
> >   identifiers. Possible starting points for these deliverables include
> >   draft-hallambaker-certhash, draft-hoffman-keys-linkage-from-dns, and
> >   draft-josefsson-keyassure-tls.
> >
> >   The mechanisms developed by this group will address bindings between
> >   domain names and keys, allowing flexibility for all key-transport
> >   mechanisms supported by the application protocols addressed (e.g., both
> >   self-signed and CA-issued certificates for use in TLS).
> >
> >   The solutions specified by this working group rely upon the security of
> >   the DNS to provide source authentication for public keys. The decision
> >   whether the chain of trust provided by DNSSEC is sufficient to trust the
> >   key, or whether additional mechanisms are required to determine the
> >   acceptability of a key, is left to the entity that uses the key
> >   material.  In addition to the protections afforded by DNSSEC, the
> >   protocols and mechanisms designed by this working group require securing
> >   the "last hop" by operating a local DNS resolver or securing the
> >   connection to remote resolver - this WG will not specify new mechanisms
> >   to secure that hop, but will reference existing specifications or
> >   document existing methods in order to allow implementations to
> >   interoperate securely.
> >
> >   Initial deliverables for this working group are limited to distribution
> >   of bindings between names within the zone operator's control and public
> >   keys.  More general statements of policy for a domain are out of scope,
> >   and new tasks in this area may only be adopted through a re-chartering.
> >
> >   The group may also create documents that describe how protocol entities
> >   can discover and validate these bindings in the execution of specific
> >   applications. This work would be done in coordination with the IETF
> >   Working Groups responsible for the protocols.
> 
> While I found Adam's draft interesting and worthy I really think it
> twists the problem around by putting DNSSEC into CERT, while we agreed
> to work on putting CERTs into DNSSEC.
> 
> Also if we are to take "serialization issue" to Quebec then I would love
> to hear more opinions from people who *haven't spoken* yet.  And this
> really applies to everybody - please cool your heads before replying.
> 
> Thanks,
> O.
> 
> On 13.7.2011 17:50, Phillip Hallam-Baker wrote:
> > On Wed, Jul 13, 2011 at 10:46 AM, Eric Osterweil <[e-mail]>wrote:
> >
> >>
> >> On Jul 13, 2011, at 10:24 AM, Nicholas Weaver wrote:
> >>
> >>>
> >>> On Jul 13, 2011, at 6:37 AM, Phillip Hallam-Baker wrote:
> >>>> Adam has actual measurements to back up his claim that support for
> >> unknown records is absent in a prohibitively large number of places. The
> >> only thing that surprises me about his numbers is that I expected them to be
> >> much worse. That is possibly an artifact of doing the measurements on Linux.
> >>>
> >>> Its better than you think, but not great, when measured through Netalyzr.
> >>  http://www.icir.org/christian/publications/2011-satin-netalyzr.pdf
> >>>
> >>> As importantly, its basically the same as TXT records, and its the same
> >> ones which fail.
> >>>
> >>> But more importantly, although we don't have the code to test for it yet,
> >> I suspect that the same set of resolvers that can't handle unknown resource
> >> records is the same set that strips/chokes on DNSSEC records so you can't
> >> get DS records, NSEC/NSEC3, etc...
> >>>
> >>>
> >>> Client resolvers for DNSSEC MUST validate locally (the recursive resolver
> >> can't be trusted, full stop), and MUST be willing to bypass the recursive
> >> resolver infrastructure (the recursive resolver may fail to pass
> >> DNSSEC-related records properly).
> >>
> >> This "full stop" issue may, or may not, be true but one thing I think
> >> deserves a "full stop" is that embedding part of DNSSEC's logic in a place
> >> that is _not_ DNS suffers a lot of architectural and operational complexity.
> >>  Trusting resolvers is one issue, putting data in a different protocols and
> >> trying to cobble DNSSEC-like-validation into remote protocols is the issue I
> >> think needs attention.  We've seen a lot of one-off DNS resolver
> >> implementations and I would argue a lot of _those_ are responsible for the
> >> brokeness that you have measured.  Thus, let's be very weary of adding new
> >> points of brokeness that report to support DNSSEC-like semantics and then
> >> fail to keep up w/ the protocol's evolution.
> >
> >
> > We saw the same sort of thing with deployment of SET, or rather the
> > non-deployment as it turned out.
> >
> > Certain deployment decisions by certain parties meant that we only got one
> > chance to deploy SET. By the time we had real world experience and knew the
> > bits that needed fixing we were unable to make changes there or anywhere
> > else.
> >
> >
> > PKI systems are inherently complex because they are the interface to the
> > trust infrastructure of the real world and the real world is complex.
> >
> > Rather than having people quote what they imagine the end to end principle
> > to be, I would encourage them to read what David Clark actually wrote. It is
> > an argument about complexity and in particular the best places to manage
> > that complexity.
> >
> > I don;t want to be speaking for David here, but he is not a rigid ideologue
> > by any stretch of the imagination. The end to end argument is an argument
> > about practicality and it applies to a specific situation 20 years ago. It
> > was never intended to be stated as an absolute truth.
> >
> > It is not an argument about security either. 'End to end' security predated
> > the Internet and was and is acknowledged to be a form of security that is
> > desirable in an abstract sense but frequently impractical. One Time Pads
> > provide provably unbreakable security, Quantum Cryptography is theoretically
> > unbreakable, but systems built around those schemes have turned out to fail
> > in the real world because it is just not practical to build and use them in
> > a perfect way.
> >
> >
> > At the time the paper was written a computer system capable of running IP
> > protocols was $200K and up. Micros existed but they were limited to 64Kb of
> > memory, not really what you want to be writing an IP stack in.
> >
> > The telephone system has the complexity in the middle because it is a 100
> > year old system and the middle is the only place that could be easily
> > changed. It was also at the time the design was chosen a system operated by
> > one single entity.
> >
> >
> > The 'end to end' argument is really an argument that you don't want to put
> > complexity into the inter-network. At the time the client endpoint was the
> > only other place it could go. For the past 10-15 years we have seen the
> > difficulty of making changes at the client increase to the point that it is
> > very difficult to achieve.
> >
> > The DNS resolver is my preferred point to put DNSSEC processing because it
> > means that I can upgrade my DNSSEC processing by upgrading that one single
> > piece of infrastructure. That means that I have to have a secure means of
> > communicating with my trusted resolver, but that is a solvable problem (e.g.
> > DPLS).
> >
> >
> > It is one thing to say that we will not address issues like DPLS and chains
> > in certs or OCSP, quite another to state that we will write a spec that
> > insists that the only valid deployment is one that is totally impractical.
> >
> > The only valid requirement for DANE is that the DNSSEC records MUST have
> > been validated in a trustworthy fashion. Going beyond that is ideology.
> > Security reacts really badly to ideology.
> 
> 
> --
>  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:[e-mail]    http://nic.cz/
>  tel:[phone]       fax:[phone]
>  -------------------------------------------
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
> 
> 
> 
> -- 
> Website: http://hallambaker.com/
> 
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane