Technically you are correct however give the vast majority of users do not
understand  the basics of encryption and singing, let alone these nuances,
you cannot express them as differences in the connection state to the user.
Hence you should  treat them as equal in the UI.

-----Original Message-----
From: perpass [mailto:[email protected]] On Behalf Of Michael
Richardson
Sent: Thursday, November 20, 2014 12:12 PM
To: Trevor Freeman
Cc: 'Richard Barnes'; 'perpass'
Subject: Re: [perpass] EFF, Mozilla et al. announce new free certificate
authority...


Trevor Freeman <[email protected]> wrote:
    > The certificate warning paradigm is over blown given that the typical
    > alternative is no TLS. An unauthenticated TLS connection is
practically
    > speaking, no different to no TLS at all. The same of true when you see
    > certificate warring messages  S/MIME messages when the rest of the
    > inbox is unsigned email. As long as the two cases are treated equal
why
    > cannot you dispense with the certificate warning messages? 

unauthenticated TLS is resistant to passive (bend the fiber, watch the leak,
starbucks coffee shop wifi) monitoring while no TLS is not.

unauthenticated TLS is not resistant to active (hijack the BGP session,
break the fiber, etc.) attacks.
{authenticated TLS is not resistant to national security letters}

If we had unauthenticated TLS plus TOFU, many home appliances would be more
secure; and we would avoid training end users to click through warning
screens.

In the scenario of home appliances and management access to ILOMs, people
are usually confident that BGP attacks are not occuring; the machine is just
a few layer-2 hops away.

And once you connect to the home appliance, one could then instruct the
device to do "letsencrypt" if you can give it a stable name reachable from
the letsencrypt people.  IPv6 could provide the connectivity.

--
Michael Richardson <[email protected]>, Sandelman Software Works  -=
IPv6 IoT consulting =-




_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass

Reply via email to