Re: [MLS] [Mls] Comments on Charter

That sounds good to me.  I've added the following text to the Google Doc
(adapted from the QUIC charter):

"""
The specifications developed by this working group will be based on
pre-standardization implementation and deployment experience, and
generalizing the design described in:

* draft-omara-mls-architecture
* draft-barnes-mls-protocol

Note that consensus is required both for changes to the current protocol
mechanisms and retention of current mechanisms. In particular, because
something is in the initial document set does not imply that there is
consensus around the feature or around how it is specified.
"""

On Sun, Mar 18, 2018 at 3:34 PM, Eric Rescorla <ekr@rtfm.com> wrote:

> IMO the charter should just say we're adopting these documents as a
> starting point, with an explicit disclaimer about how everything needs
> consensus (the QUIC charter has some good text here). They're in a pretty
> mature state and reflect what there's already been enthusiasm for.
>
> -Ekr
>
>
> On Tue, Mar 13, 2018 at 3:57 PM, Richard Barnes <rlb@ipv.sx> wrote:
>
>> Hey Simon,
>>
>> Thanks for the comments, sorry for the delay.
>>
>> On Tue, Feb 6, 2018 at 7:11 AM, Simon Friedberger <simon.cfrg@a-oben.org>
>> wrote:
>>
>>> 1. I think key transparency should be mentioned. Key distribution is a
>>> huge semi-solved problem and leaving it out is not really an option. It
>>> seriously degrades security for the average user who does not validate
>>> keys.
>>>
>>
>> Obviously, I agree that authentication is very important, but from what
>> I've heard talking to people, there's not energy to do KT right now.  What
>> we can do now is make sure there's a slot to put a credential in, so that
>> we can leverage things like PKI that provide some benefit over manual key
>> comparison, and later on we can recharter to work on KT if there's interest.
>>
>> To clarify this, I added the following para:
>>
>> """
>> While authentication is a key goal of this working group, it is not the
>> objective of this working group to new authentication technologies.
>> Rather, the security protocol developed by this group will provide a way to
>> leverage existing authentication technologies to associate identities with
>> keys used in the protocol, just as TLS does with X.509.
>> """
>>
>>
>>
>>> 2. Federation (for example like in XMPP, where many people run their own
>>> servers just like for e-mail) probably doesn't require anything specific
>>> but it should be discussed to make sure that it works. It would also be
>>> good to take this into account when discussing authentication and key
>>> transparency to make sure it is clear which guarantees hold for people
>>> on other servers. I think it doesn't necessarily have to be in the
>>> charter but should be in any final proposal.
>>>
>>
>> I think the critical thing to test / validate is that we have
>> interoperability at the level of the specification of the protocol.  Just
>> like BoringSSL and NSS interoperate at the level of TLS, but don't assure
>> interoperability of HTTP running over them, we should be aiming for a
>> security protocol that's interoperable between independent implementations,
>> but not worried about interoperability of the rest of the stack.
>>
>> I did make the following tweak to the charter language, though:
>>
>> "to enable interoperability" -> "to enable interoperability / federation"
>>
>>
>>
>>
>>>
>>>
>>> Best Regards,
>>>
>>> Simon
>>>
>>> _______________________________________________
>>> MLS mailing list
>>> MLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mls
>>>
>>
>>
>> _______________________________________________
>> MLS mailing list
>> MLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/mls
>>
>>
>