> You might have wanted to respond to all list, not just me personally.
Yes, thanks.
> ср, 10 апр. 2019 г. в 14:25, Melvin Keskin :
>
> > Thanks for explaining critical aspects of secure communication.
> >
> > But end-to-end encryption is about sending encrypted messages from
> one
> > secure
On Wed, Apr 10, 2019 at 1:43 PM, Melvin Keskin wrote:
But end-to-end encryption is about sending encrypted messages from one
secure endpoint to another secure endpoint. It is not about securing
the endpoints themselves. If an endpoint is compromised, no end-to-end
encryption can help.
Thanks for explaining critical aspects of secure communication.
But end-to-end encryption is about sending encrypted messages from one
secure endpoint to another secure endpoint. It is not about securing
the endpoints themselves. If an endpoint is compromised, no end-to-end
encryption can help.
If you are speaking of a cosy feeling of being secure, then yes, ATT does
not diminish its level. If you're talking about real security, it
absolutely does, cause one compromised device compromises all your and your
chat partner's devices. Some examples:
When you go through the US customs you may
Hello Andrew,
ATT simply eliminates the disadvantage in usability which comes from
using one key per device so that you can have all advantages of OMEMO
but without the disadvantage of many manual authentications. It does
not diminish the security level of OMEMO or other benefits.
Pleas have a
On Wed, Apr 3, 2019 at 6:02 PM, Melvin Keskin wrote:
I appreciate that you think of UX aspects but ATT should not degrade
UX
when another way of authentication is implemented alongside it. For
ATT
no user interaction is needed and it can always be used. It is not
necessary to deactivate it.
On Wed, Apr 3, 2019 at 5:52 PM, Melvin Keskin wrote:
Every way has its advantages and its disadvantages.
Everything is relative, I see.
That was the reason for creating ATT. I
wanted the users to benefit from automating the whole process of key
authentication now and not some day in the
On Wed, 3 Apr 2019, 20:42 Paul Schaub, wrote:
> Thats more a general OMEMO critic that has nothing to do with ATT, right?
>
No, I can totally see the benefits of OMEMO for a (very unwelcome) subset
of our users. However, ATT seems to actually diminish said benefits.
Thats more a general OMEMO critic that has nothing to do with ATT, right?
Am 3. April 2019 17:25:23 MESZ schrieb "Ненахов Андрей"
:
>What I don't get about this Trust Transfer thing is that it is kinda
>defeating the purpose of OTR-like encryption. If you are really that
>paranoid that you
What I don't get about this Trust Transfer thing is that it is kinda
defeating the purpose of OTR-like encryption. If you are really that
paranoid that you want/need forward secrecy for whatever you do, it's kinda
counter-productive to have message conveniently copied to all your
different
> I already replied: if we produce both XEPs, we'll end up with some
> devices with manual/ATT verification and others with EAX. This will
> further degrade UX. So the XEPs interaction is required to be
> documented.
I appreciate that you think of UX aspects but ATT should not degrade UX
when
> I kinda misread your proposal, so it's irrelevant in the context of
> the
> proposal, sorry for confusion.
OK, you're welcome.
> Well, I understand all this. However, a complete picture I see is
> CA-signed certificates by default, and ATT and/or manual
> verification
> when you need more
> Maybe one could bundle all those verifications up in some data
> structure and then either send 1! message or even do it over IQ.
In the next version of ATT fingerprints of keys of multiple contacts
will be bundled.
Thanks for your proposal.
___
On Wed, Apr 3, 2019 at 5:06 PM, Melvin Keskin wrote:
ATT does not depend on EAX. It just tackles the challenge of key
authentication when using end-to-end encryption with multiple devices
having different keys.
I already replied: if we produce both XEPs, we'll end up with some
devices with
On Wed, Apr 3, 2019 at 4:54 PM, Melvin Keskin wrote:
Hello Evgeny,
thanks for your comments.
Hi, Melvin!
This is especially doubtful,
since it's speculated that the topology of a social graph has power-
law
distribution [1] and thus only a few people will benefit from the
"trust
> In the series of body semantics rants, I feel the need to mention
> that I
> don't like the wire format. I don't see any reason to overload body
> semantics with this new feature.
>
> Clients that don't support this XEP won't be able to do anything with
> it
> and that would only appear raw to
> If the Council accepts both XEPs as is, then we raise
inconsistency in our XEPs.
ATT does not depend on EAX. It just tackles the challenge of key
authentication when using end-to-end encryption with multiple devices
having different keys.
___
Hello Evgeny,
thanks for your comments.
> I don't understand how this will work in practice indeed.
> 1) The "trusted" graph is not connected (i.e. you cannot reach any
> vertex from any other vertex), thus, in the worst case the
> complexity
> of verification will remain the same.
In all
Hello Dave,
thank you for your comments.
> * It always worries me when people suggest security protocols and use
> odd
> naming conventions. There is, surely, no such thing as "trust
> transfer",
> whether automatic or not. Trust can be transitive, of course, but not
> transferable.
I would
Hi,
(Just for context: some of us (including the author of the XEP) are
currently at the XMPP Sprint in Berlin so there is a lot of discussion
happening about ATT here as well but we try to also mirror some of
that discussion to the mailing list.)
And again, just because it wasn’t clear to me
On Sat, 30 Mar 2019 at 10:16, Daniel Gultsch wrote:
> Hi,
>
> I apologize in advanced for reiterating something that might have been
> obvious to anyone else but wasn’t to me:
>
> This XEP does two things:
> 1) Provide something that is basically equivalent to cross signing.
> Meaning if you
Hi,
I apologize in advanced for reiterating something that might have been
obvious to anyone else but wasn’t to me:
This XEP does two things:
1) Provide something that is basically equivalent to cross signing.
Meaning if you trust one of my devices you can trust all of my devices
2) When on
On 2019/03/29, Maxime Buquet wrote:
> On 2019/03/26, Jonas Schäfer wrote:
> > The XMPP Extensions Editor has received a proposal for a new XEP.
> >
> > Title: Automatic Trust Transfer (ATT)
> > Abstract:
> > ATT specifies an automatic transfer of trust in public identity keys
> > used by the
On 2019/03/26, Jonas Schäfer wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Automatic Trust Transfer (ATT)
> Abstract:
> ATT specifies an automatic transfer of trust in public identity keys
> used by the end-to-end encryption protocol OMEMO.
>
> URL:
On Fri, Mar 29, 2019 at 5:08 PM, Dave Cridland
wrote:
In Winfried's case, he attended the 2016 FOSDEM key signing event
where someone turned up with a specimen passport, and all but 20
people signed his key anyway since they naturally assumed that nobody
would be doing that. Winfried
On Fri, 29 Mar 2019 at 14:02, Evgeny wrote:
>
>
> On Fri, Mar 29, 2019 at 4:57 PM, Dave Cridland
> wrote:
> >
> > That's interesting, because my understanding was that the result of
> > ATT was that if I manually verify one of your keys, I could then
> > transitively trust all of your keys - I
On Fri, Mar 29, 2019 at 4:57 PM, Dave Cridland
wrote:
That's interesting, because my understanding was that the result of
ATT was that if I manually verify one of your keys, I could then
transitively trust all of your keys - I didn't read this as being
that I might trust any third party
On Fri, 29 Mar 2019 at 13:08, Evgeny wrote:
> On Thu, Mar 28, 2019 at 8:23 PM, Dave Cridland
> wrote:
> > Overall, my view is that this specification is very unclear and
> > impossible to implement as written.
>
> I don't understand how this will work in practice indeed.
> 1) The "trusted"
On Fri, Mar 29, 2019 at 4:07 PM, Evgeny wrote:
1) The "trusted" graph is not connected (i.e. you cannot reach any
vertex from any other vertex), thus, in the worst case the complexity
of verification will remain the same. This is especially doubtful,
since it's speculated that the topology of
On Thu, Mar 28, 2019 at 8:23 PM, Dave Cridland
wrote:
Overall, my view is that this specification is very unclear and
impossible to implement as written.
I don't understand how this will work in practice indeed.
1) The "trusted" graph is not connected (i.e. you cannot reach any
vertex from
On Tue, 26 Mar 2019 at 16:44, Jonas Schäfer wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Automatic Trust Transfer (ATT)
> Abstract:
> ATT specifies an automatic transfer of trust in public identity keys
> used by the end-to-end encryption protocol OMEMO.
Hello,
I am the author of Automatic Trust Transfer (ATT).
You can find further information and links in the ATT repository:
https://github.com/olomono/att
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Automatic Trust Transfer (ATT)
Abstract:
ATT specifies an automatic transfer of trust in public identity keys
used by the end-to-end encryption protocol OMEMO.
URL:
33 matches
Mail list logo
