Re: removing keygen from HTML

--001a1147f47e39c2420534224b1f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, May 31, 2016 at 1:40 AM, Reto Gm=C3=BCr <[email protected]> wrote:

> On Tue, 31 May 2016, at 10:04, Harry Halpin wrote:
>
> I do not know anyone from the cryptographic or security community that
> would support keeping <keygen>. Indeed, the default response from the
> security/crypto community would be to drop <keygen> due to legacy usage o=
f
> MD5 and violation of security boundaries (SOP).
>
> That would also be my response if I was employed by the NSA and wanted to
> prevent technologies that allow user controlled strong cryptography and
> decentralized networks of trust (as enabled by webId).
>
>

Reto,

That was both an idiotic and offensive statement. Can you explain how
amateur crypto and home-brewed protocols that no-one in the security or
crypto community reviewed or supports is the way to fight the NSA?

Myself and many others support strong cryptography and decentralized
networks of trust, and fully support that effort. Rather than attribute the
use of broken technology to protocols to NSA, it's also possibly due to
lack of education.

Thus, you may want to look at:

1) MD5 security issues are well-known and documented:
http://merlot.usc.edu/csac-f06/papers/Wang05a.pdf

2) In practice, the WebID+TLS community should use modern crypto and the
Web Security model rather than attempt to build on top of an broken,
obscure, and unstandardised browser behaviour. If you want to fight the NSA
by building new protocols on the Web, I recommend taking a class that
explains how Web security works. Videos are available from this MIT course
explain modern Web Security, including the Same Origin Policy:
https://www.youtube.com/watch?v=3D_1C62Twf0vs

Hopefully others will be more reasonable, but you may wish to familiarize
yourself with this thread rather than endlessly repeat it.
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/pX5NbX0Xac=
k

Note that we're just modernizing with W3C Web Authentication secure and
modern cryptographic one-factor authentication to use modern primitives and
respect user privacy. You are more than welcome to join the Working Group
as an Invited Expert, although an expert should be aware of the basics of
security.

Although there are a number of inaccuracies in this report in terms of
WebCrypto, it's pretty clear Web Authentication matches all requirements in
Section 6 here:
http://w3ctag.github.io/client-certificates/

Thus, it makes sense to hold off and deprecate <keygen> after the fall of
this year, when Web Authentication is deployed in browsers. As stated
earlier, the "WebID" community can simply use Web Authentication rather
than client certs for authentication.

That being said, since the only browser that supports <keygen> currently is
Mozilla, who plans to deprecate regardless of what the TAG says, then it
can also be justified to remove from the standard today as there is no
interoperability.

   cheers,
       harry




> Cheers,
> Reto
>
>
>

--001a1147f47e39c2420534224b1f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, May 31, 2016 at 1:40 AM, Reto Gm=C3=BCr <span dir=3D"ltr">&lt;<=
a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>&gt;</sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>




<div><span class=3D""><div>On Tue, 31 May 2016, at 10:04, Harry Halpin wrot=
e:<br></div>
<blockquote type=3D"cite"><div dir=3D"ltr"><div><div><div>I do not know any=
one from the cryptographic or security community that would support keeping=
 &lt;keygen&gt;. Indeed, the default response from the security/crypto comm=
unity would be to drop &lt;keygen&gt; due to legacy usage of MD5 and violat=
ion of security boundaries (SOP). <br></div>
</div>
</div>
</div>
</blockquote></span><div>That would also be my response if I was employed b=
y the NSA and wanted to prevent technologies that allow user controlled str=
ong cryptography and decentralized networks of trust (as enabled by webId).=
<br></div>
<div>=C2=A0<br></div></div></blockquote><div><br></div><div>Reto,<br><br></=
div><div>That was both an idiotic and offensive statement. Can you explain =
how amateur crypto and home-brewed protocols that no-one in the security or=
 crypto community reviewed or supports is the way to fight the NSA?<br><br>=
</div><div>Myself and many others support strong cryptography and decentral=
ized networks of trust, and fully support that effort. Rather than attribut=
e the use of broken technology to protocols to NSA, it&#39;s also possibly =
due to lack of education. <br><br>Thus, you may want to look at:<br></div><=
div><br>1) MD5 security issues are well-known and documented:<br><a href=3D=
"http://merlot.usc.edu/csac-f06/papers/Wang05a.pdf">http://merlot.usc.edu/c=
sac-f06/papers/Wang05a.pdf</a><br><br></div><div>2) In practice, the WebID+=
TLS community should use modern crypto and the Web Security model rather th=
an attempt to build on top of an broken, obscure, and unstandardised browse=
r behaviour. If you want to fight the NSA by building new protocols on the =
Web, I recommend taking a class that explains how Web security works. Video=
s are available from this MIT course explain modern Web Security, including=
 the Same Origin Policy:<br><a href=3D"https://www.youtube.com/watch?v=3D_1=
C62Twf0vs">https://www.youtube.com/watch?v=3D_1C62Twf0vs</a><br><br>Hopeful=
ly others will be more reasonable, but you may wish to familiarize yourself=
 with this thread rather than endlessly repeat it. <br><a href=3D"https://g=
roups.google.com/a/chromium.org/forum/#!topic/blink-dev/pX5NbX0Xack">https:=
//groups.google.com/a/chromium.org/forum/#!topic/blink-dev/pX5NbX0Xack</a><=
br><br></div><div>Note that we&#39;re just modernizing with W3C Web Authent=
ication secure and modern cryptographic one-factor authentication to use mo=
dern primitives and respect user privacy. You are more than welcome to join=
 the Working Group as an Invited Expert, although an expert should be aware=
 of the basics of security.=C2=A0 <br><br></div><div>Although there are a n=
umber of inaccuracies in this report in terms of WebCrypto, it&#39;s pretty=
 clear Web Authentication matches all requirements in Section 6 here:<br><a=
 href=3D"http://w3ctag.github.io/client-certificates/">http://w3ctag.github=
.io/client-certificates/</a><br><br></div><div>Thus, it makes sense to hold=
 off and deprecate &lt;keygen&gt; after the fall of this year, when Web Aut=
hentication is deployed in browsers. As stated earlier, the &quot;WebID&quo=
t; community can simply use Web Authentication rather than client certs for=
 authentication. <br><br>That being said, since the only browser that suppo=
rts &lt;keygen&gt; currently is Mozilla, who plans to deprecate regardless =
of what the TAG says, then it can also be justified to remove from the stan=
dard today as there is no interoperability. <br></div><div><br></div><div>=
=C2=A0=C2=A0 cheers,<br></div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 har=
ry<br><br></div><div><br>=C2=A0<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex"><div><div></div>
<div>Cheers,<br></div>
<div>Reto<br></div>
<div><div>=C2=A0</div>
</div>
<div>=C2=A0</div>
</div>

</blockquote></div><br></div></div>

--001a1147f47e39c2420534224b1f--