<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 11/05/2015 20:52, Nico Williams
wrote:<br>
</div>
<blockquote cite="mid:20150511185218.GI7287@localhost" type="cite">
<pre wrap="">On Mon, May 11, 2015 at 04:42:49PM +0000, Viktor Dukhovni wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Mon, May 11, 2015 at 11:25:33AM -0500, Nico Williams wrote:
</pre>
<blockquote type="cite">
<pre wrap=""> - If you don't want to depend on server certs, use anon-(EC)DH
ciphersuites.
Clients and servers must reject[*] TLS connections using such a
ciphersuite but not using a GSS-authenticated application protocol.
</pre>
</blockquote>
<pre wrap="">
[*] Except when employing unauthenticated encrypted communication
to mitigate passive monitoring (oportunistic security).
</pre>
</blockquote>
<pre wrap="">
As this would be replacing RFC2712, it's not opportunistic to begin with :)
</pre>
</blockquote>
<tt>As this would be a new RFC, it might be usable for cases <br>
where RFC2712 was never usable.</tt><tt><br>
</tt><tt><br>
</tt><tt>How about the following simplifications for the new <br>
extension, lets call it "GSS-2" (at least in this e-mail)</tt><tt>.<br>
</tt><tt><br>
</tt><tt>1. GSS (including SASL/GS2) is always done via the SPNego <br>
GSS mechanism, which provides standard handling of <br>
mechanism negotiation (including round-trip optimizations), <br>
and is already its own standard (complete with workarounds <br>
for historic bugs in the dominant implementation...).</tt><tt><br>
</tt><tt><br>
</tt><tt>2. The TLS client always begins by sending the first <br>
GSS/SPNego leg in a (new) TLS extension "GSS-2"</tt><tt>.<br>
</tt><tt><br>
</tt><tt>3. The TLS server (if it supports and allows the extension)
<br>
responds with a 0 byte TLS extension "GSS-2" to confirm <br>
support.</tt><tt><br>
</tt><tt><br>
</tt><tt>4. The second and subsequent legs of the GSS handshake are
<br>
sent as the sole contents of the first encrypted records, <br>
actual application data is not sent until the GSS handshake <br>
succeeds. Note that the first encrypted server to client <br>
record (containing the second leg) can be sent in the same <br>
protocol round trip as the second half of the TLS <br>
handshake. It is an open design issue if these TLS records <br>
should be tagged as application records or key exchange <br>
records.<br>
</tt><tt></tt><tt><br>
</tt><tt>5. In the last legs, the GSS mechanism is told to (mutually
<br>
if possible) authenticate some already defined hash of the <br>
TLS handshake, thereby protecting the key exchange.</tt><tt>
Other<br>
than the round trip saving for the first 2 legs, this is <br>
what distinguishes GSS-2 from simply doing application level <br>
GSS over a TLS connection. Any GSS negotiated keys are not <br>
used beyond this authentication of the TLS key exchange.<br>
<br>
6. If the GSS mechanism preferred by the client requires the <br>
authenticated hash value to be known before sending the <br>
first GSS leg, then the client shall simply abstain from <br>
including that first leg in the first leg SPNego message <br>
if sent in the client hello extension.<br>
<br>
</tt><tt>7. If the client wants encryption of the first GSS leg, it
<br>
can either abstain from including that leg in the first <br>
SPNego GSS leg, or it can send a 0-byte first leg and then <br>
send the real first SPNego leg in the first encrypted client <br>
o server record, with the server responding with the second <br>
leg in the first encrypted server to client record as before <br>
(but no longer in the same round trip as the second half of <br>
the TLS handshake).</tt><tt><br>
<br>
</tt><tt>8. If the GSS mechanism reports failure, the TLS connection
<br>
SHALL be aborted with a specified alert.</tt><tt><br>
</tt><tt><br>
</tt><tt>9. When the "GSS-2" extension is negotiated, TLS <br>
implementations SHOULD allow anonymous (unauthenticated) <br>
cipher suites even if they would not otherwise do so, <br>
however they MUST be able to combine the "GSS-2" extension <br>
with any and all of the cipher suites and TLS versions they <br>
otherwise implement. For instance, if an implementation of <br>
the "GSS-2" extension is somehow bolted on to a fully <br>
patched OpenSSL 1.0.0 library (via generic extension <br>
mechanisms), then that combination would support it with <br>
TLS 1.0 only, and TLS 1.3 capable implementations would be <br>
negotiating TLS 1.0 when doing "GSS-2" with such an <br>
implementation.</tt><tt><br>
</tt><tt><br>
</tt><tt>10. Session resumption and Session renegotiation shall have
<br>
the same semantics for the GSS authentication result as <br>
they do for certificate validation results done in the <br>
same handshakes.</tt><tt><br>
</tt><tt><br>
</tt><tt>11. NPN and ALPN are neither required nor affected by GSS-2
<br>
and operate as they would with any other TLS mechanisms, <br>
such as certificates.</tt><tt><br>
</tt><br>
<pre class="moz-signature" cols="72">Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. <a class="moz-txt-link-freetext" href="http://www.wisemo.com">http://www.wisemo.com</a>
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded </pre>
</body>
</html>