Re: [MLS] [Mls] Comments on Charter

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