Re: IAB agendas now public

[Phillip Hallam-Baker <[e-mail]>]

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 <[e-mail]> 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 Hardie
>
> On Wed, Sep 5, 2018 at 7:31 AM, Thomas Nadeau <tnadeau@lucidvision..com
> <[e-mail]>> wrote:
>
>> +1
>>
>> All of these meetings should be.
>>
>> —Tom
>>
>>
>>
>> > On Sep 5, 2018, at 10:29 AM, Randy Bush <[e-mail]> 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
>> >
>>
>>
>