As with almost any institution that is 30 years old, the IETF considers itself to be a newcomer when it is actually approaching its mid-life crisis.
One of the biggest malfunctions in the IETF is that since the Kobe meeting, it has not been allowed to do architecture or only allowed to do it in ways that have the least influence possible. And we need a group that is thinking about architecture and can make recommendations that have broad consensus across the IETF.
To do that, IAB meetings have to be open and include all the stakeholders for a particular issue. Because what is important is not what the decision is but who is going to follow it.
Right now, I see a lot of interesting work going on in service discovery. People are starting to realize that the principal benefit of DNSSEC is not that it eliminates the need to trust the local DNS resolver, it is that it eliminates the need to use the local DNS resolver at all.
No-resolver DNS is a powerful idea. So is the idea of not using DNS as the client-resolver protocol and using a protocol designed to enable service discovery that is as fast and as expressive as possible.
But getting movement there right now is really hard because the problem is split between a number of different IETF areas. There is the applications area which consumes the discovery service and there is the DNS area that maintains the authoritative service and then we have a series of WGs that each demand that they 'own' one piece of the problem and absolutely refuse to listen to any requirements other than the exact set of requirements that justify the exact solution that they came up with in the first place.
Another problem with the lack of architectural direction I see is that we don't have a group that is able to say 'that is a great point solution, other people want to do similar, now propose a general framework'. For example, the MX record was proposed very early in the history of DNS and was clearly essential for service scalability. Yet it took us a decade to generalize as SRV and another decade to establish SRV+TXT records as the principle service discovery mechanism. Meanwhile we have had DANE throw in a service description attribute record but only for one transport protocol and only for one trust model and even though it has seen precisely zero adoption in the WebPKI world, it is apparently the only security policy approach we are permitted to consider.
The TRANS/CT notary infrastructure is great as a mechanism for notarizing PKIX certs. But do we really want to build on that point solution for every other application that needs a notary? Maybe we do, maybe we don't but at least there should be people asking whether that is the right approach or if we should treat that as the MX record proof of concept, the special case for the WebPKI and do something else for the general case.
I would like to see at least some part of the organization do a post mortem on past efforts to ask whether they went wrong because what they were trying to do is impossible, because they were doing it in the wrong way or because there was a necessary pre-condition that was not met. My position on security policy for the past 15 years has been that it is one of the two most important security problems we need to solve, that devising a language for specifying security problem is not difficult.
The biggest deployment obstacle I see is that the security policy records are useless unless they are accurate and they will never be accurate unless there is an automated infrastructure for service management. The biggest technical challenge is what the client is to do when it detects a security policy violation. And that is really difficult to even get people to discuss because what people imagine to be a 'common sense approach' tends to be impossible to reduce to code because it requires a different response to use cases that the client cannot distinguish based on the information available to it when it makes the decision.
On Wed, Sep 5, 2018 at 10:50 AM, Ted Hardie <ted.ietf@xxxxxxxxx> wrote:
As you'll note from following the link provided, that is on today's agenda. Thanks for your input into the agenda item..regards,Ted HardieOn Wed, Sep 5, 2018 at 7:31 AM, Thomas Nadeau <tnadeau@xxxxxxxxxxxxxxxx> wrote:+1
All of these meetings should be.
—Tom
> On Sep 5, 2018, at 10:29 AM, Randy Bush <randy@xxxxxxx> wrote:
>
>> At the IETF 102 plenary session there was a request to the IAB to make
>> its agendas public in advance of its meetings, so that interested
>> members of the community could contact the IAB regarding items on the
>> agenda. The IAB agreed, and the draft agendas will be available at:
>
> my memory is that the critical request that the iab follow the iesg's
> lead and make the meeting o-p-e-n. and i fully and strongly support
> that request.
>
> randy
>
