<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 25, 2017 at 11:44 PM, Ben Francis <span dir="ltr"><<a href="mailto:wirelessben@gmail.com" target="_blank">wirelessben@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><span class=""><span style="font-family:sans-serif;font-size:13.696px">> It's not clear to me how Seif is materially better than TLS</span><div dir="auto"><span style="font-family:sans-serif;font-size:13.696px"><br></span></div></span><div dir="auto"><span style="font-family:sans-serif;font-size:13.696px">TLS works with a stateless protocol, HTTP*, which itself rests on a stateful protocol, TCP. The fact that HTTP intentionally forgets the state it inherited from TCP means the state has to be managed at the higher session level. Cutting off a connection only to re-establish it 5 milliseconds later makes no sense, performance-wise, and moreover introduces opportunities for XSS attacks, HTML injection, and SQL injection.</span></div><div dir="auto"><span style="font-family:sans-serif;font-size:13.696px"><br></span></div><div dir="auto"><span style="font-family:sans-serif;font-size:13.696px">Seif keeps the state TCP already provides and use public/private key pairs to generate the hash and session key. "PGP over TCP" is one way to look at it. No DNS or certificate authorities are needed.</span></div></div></blockquote><div><br></div><div>There's a bunch of stuff here, and I'm not sure it's that productive to get into a long discussion [0]:</div><div><br></div><div>As you say, HTTP state management is a mess. However, that's the state management we have and I don't see a lot of interest from anyone in totally rebooting it, so as a practical matter it seems like the we're going to have cookies and cookie-boosting mechanisms like token binding for quite some time. In any case, the problems you cite in terms of XSS attacks etc. are not really ameliorated by a proposal like Seif because they depend on ambient authority not on cookies. So, for instance, if you simply authenticated someone at the beginning of a connection and then accepted any request they made as coming from them (as you can do with TLS client auth), you would have the same types of problems.</div><div><br></div><div>You are certainly right that HTTP is a stateless protocol, but it's not actually like clients usually disconnect the TCP connection and immediately reestablish it, at least when the clients are browsers. And, of course, HTTP/2 just moves to a full-on multiplexed single connection. So, the performance questions associated with connection establishment are amortized over the life of the connection. This still leaves time to first byte but, as Gerv says, that is something we are addressing in TLS 1.3 with 0-RTT mode.</div><div><br></div><div>This brings us to the topic of DNS and CAs, which are, I think, fairly separable. I don't really see how Seif gets you away from DNS. At the end of the day, URLs (or whatever link replaces them) needs to have some sort of symbolic name so that you can type it. And that name needs to be mapped to an IP address, which at this point means the DNS. One might imagine some DNS replacement, but that's so far into the future horizon that I don't think it's plausible to consider as something that we would implement.</div><div><br></div><div>As far as CAs go, once you have symbolic names, you need some way to establish that a given key is associated with that name (otherwise you have trivial server impersonation attacks). Right now that means CAs, though in the future I suppose that might get replaced [1]. However, even if we had such a replacement, it seems like it shouldn't be that difficult to wedge it into TLS (in fact, people have already done so with DANE).</div><div>So, this really isn't a differentiating factor between protocols.</div><div><br></div><div>-Ekr<br></div><div><br></div><div><br></div><div>[0] As an aside, I worked on S-HTTP, which used principles not too dissimilar from those of Seif, for a number of the reasons you cite, so I do have a certain amount of sympathy for this position, but I think it's clear that the  world has moved in a different direction and many of the issues that are ameliorated by a more message-oriented protocol have been addressed in other ways.</div><div><br></div><div>[1] I'm not actually that enthusiastic about the proposed replacement technologies, but that seems like a different question.</div><div><br></div><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="auto"><font face="sans-serif"><span style="font-size:13.696px">*TBL made HTTP stateless due to the 12 socket limit of the partial socket table in BSD at the time. The design kept BSD from crashing, and it now works great for document retrieval, but it's awful for web apps that require state.</span></font></div><div dir="auto"><font face="sans-serif"><span style="font-size:13.696px"><br></span></font></div><br></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Apr 25, 2017 6:48 PM, "Eric Rescorla" <<a href="mailto:ekr@rtfm.com" target="_blank">ekr@rtfm.com</a>> wrote:<br type="attribution"></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 25, 2017 at 2:14 AM, Gervase Markham <span dir="ltr"><<a href="mailto:gerv@mozilla.org" target="_blank">gerv@mozilla.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 21/04/17 16:37, Ben Francis wrote:<br>
> The Seif Project is now a year old. Is Firefox going to support it?<br>
<br>
</span>"In the case where Alice is trying to connect to Bob, prior to<br>
initiating the connection, the protocol assumes Alice has access to<br>
Bob's public key. The trust management system which helps accomplish<br>
this will not be described and is out of the scope of this document."[0]<br>
<br>
I would suggest the Seif protocol is not yet implementable, as the<br>
hardest problem has been declared out of scope.<br></blockquote><div><br></div><div>This is indeed a problem.</div><div><br></div><div>It's not clear to me how Seif is materially better than TLS, and in some</div><div>ways it's worse.</div><div><br></div><div>-Ekr</div></div></div></div>
<br></div></div><span class="">______________________________<wbr>_________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org" target="_blank">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/listi<wbr>nfo/firefox-dev</a><br>
<br></span></blockquote></div></div>
</blockquote></div><br></div></div>