Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3

From: "Dan Harkins" <[email-masked]>
Date: Fri, 1 Nov 2013 12:00:53 -0700 (PDT)

On Thu, October 31, 2013 4:09 pm, Nico Williams wrote:
[snip]
>  - Many fewer nonce bytes and random IVs where possible.  Nonce payloads
>    should be sent when needed, if needed.  For example, to derive a
>    session key from an DHE shared secret one does not really need
>    nonces.  This means that counter modes are better, for example, than
>    CBC modes.
>
>    <aside>
>
>    Perry Metzger recently proposed (I'm extrapolating a bit) a
>    random-IV-free CBC-like cipher mode where instead of a nonce one
>    sends a [small] counter which must be encryted to recover the IV
>    for use as the first block in the CBC decryption of the ciphertext.
>    I kinda like this.
>
>    CBC has some advantages over counter modes.  However, for this
>    particular application (TLS and DTLS) it's easy enough to avoid (and
>    detect) counter reuse that counter modes' disadvantages are
>    tolerable.
>
>    </aside>

  In the interest of lessening nonce and IV bytes, especially ones that
are security-critical there is always SIV mode (RFC 5297). That provides
authenticated encryption and only expands the packet by the number of
bits equal to the blocksize of the underlying cipher. You can add a
nonce as additional AAD but it's not necessary and security isn't voided
if such a nonce/counter gets reused. You get a mode that is less fragile,
and doesn't expand the frame as much, at the cost of two passes of the
data.

  I'm not sure about Perry's proposed mode, and I'd be interested in
reading more about it, but SIV has a security proof in the paper by
Rogaway and Shrimpton that defined SIV.

  regards,

  Dan.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 01 Nov 2013 20:09:39 +0100

On 11/01/2013 12:09 AM, Nico Williams wrote:
> 
> My list:
> 
>  - It should be deployable, that's first; in particular, it needs to be
>    deployable with ECDH PFS key exchanges.

(unrelated) It would actually be nice to have a wiki for anyone to add
his wish list there.

>  - Renegotiation should be replaced with an NPN-like extension that
>    provides privacy to the TLS client principal name.

I don't think anyone can avoid renegotiation. Since the TLS packet
counters are 64-bit (and more importantly in DTLS 48-bits), one cannot
avoid renegotiation to reset the counters.

(nevertheless, all the practical VPNs I've seen using TLS, don't use
renegotiation, they just re-establish the session).

regards,
Nikos

---

From: Robert Ransom <[email-masked]>
Date: Fri, 1 Nov 2013 14:21:35 -0700

On 10/31/13, Watson Ladd <[email-masked]> wrote:

> TLS 1.3 should significantly reduce the number of round trips
> required. To this end I propose the following obviously secure scheme:
> the client sends a point on a curve in ClientHello and the server
> responds with certificates (or some other authentication thing) and a
> point on a curve, so that when the client speaks again, it is with a
> negotiated, authenticated shared secret. Before everyone screams about
> needing one signature per connection, note the server can use a time
> based secret key, so only has to do one exponentiation per client.

This protocol should be designed to allow future extension to use
post-quantum encryption and/or key encapsulation cryptosystems.  (I
don't believe that quantum computers will become a threat, but some PQ
cryptosystems may be faster than ECDH.)

It also needs to either allow session resumption without the
possibility of reusing any key used to encrypt or authenticate
application-level data, or explicitly forbid session resumption.

> Renegotiation should be killed: it serves no purpose.

Renegotiation is a critical feature of TLS, which serves multiple purposes.

* Renegotiation allows rekeying of a session.  This is absolutely
required for any ciphersuite based on a block cipher with a 128-bit or
smaller block, because block cipher modes' security properties degrade
after they are used for more than some number of blocks.

* Applications can also use renegotiation-based rekeying to improve
forward secrecy; for example, the Mixminion specification
(<https://github.com/nmathewson/mixminion-doc/blob/a661212831d2afc3200339b2634ca16452e3aeec/spec/minion-spec.txt>,
section 4, line 1040) requires that relay-to-relay TLS connections be
rekeyed using renegotiation every 15 minutes for this purpose.

* A TLS connection can be established by a fully trusted device which
knows a password or other application-layer authorization credential,
authorized to perform some operations using messages within the TLS
connection, and then transferred with the help of renegotiation to a
less trusted device to actually perform those operations.  This is
similar to the preceding use, but to provide 'sideways secrecy' rather
than forward secrecy.

* One version of the Tor 'link protocol' (Tor's term for its outer
TLS-based connection protocol) uses renegotiation to provide secrecy
for the server's certification chain against purely passive attackers.
 The purposes above could be served by applying a one-way function to
the originally derived key material, then discarding the old keys;
this purpose cannot.

Robert Ransom

---

From: Nico Williams <[email-masked]>
Date: Fri, 1 Nov 2013 16:28:37 -0500

> application-level data, or explicitly forbid session resumption.

Sure.

> after they are used for more than some number of blocks.

This can be done without a synchronous renegotiation by just computing a
new sessionkey every so many bytes/blocks/records (whatever's
appropriate to count for the cipher in use).

> rekeyed using renegotiation every 15 minutes for this purpose.

Indeed.  Speaking of which, resumption must support PFS rekeying.

> similar to the preceding use, but to provide 'sideways secrecy' rather

As long as there's no MITM...

> the originally derived key material, then discarding the old keys;

I thought this was no longer in use.

Also:

 * Privacy protection for the user's PSK ID and/or cert and/or other
   identifying data.

   But again, an NPN-style extension should take care of this.

 * Relatedly, the server can request user authentication asynchronously,
   in which case NPN-style extensions don't help.

   I'd be happy to get rid of this: user authentication in such cases
   belongs in the app layer.  However, it may not be feasible to get rid
   of such uses of renegotiation, so it probably has to stay :(

Nico
--

---

From: Robert Ransom <[email-masked]>
Date: Fri, 1 Nov 2013 14:34:48 -0700

>    nonces.  This means that counter modes are better, for example, than

If the server sends a nonce during a DHE/ECDHE key exchange, the
server can safely reuse its DH keypair for multiple clients with no
further design or implementation considerations.  If the server does
not send a nonce, it must keep a replay-detection cache of client DH
public keys for the lifetime of its DH keypair.

Robert Ransom

---

From: Robert Ransom <[email-masked]>
Date: Fri, 1 Nov 2013 14:37:10 -0700

> I thought this was no longer in use.

They're trying to get rid of that protocol version.  I don't know
whether they have succeeded yet.

Robert Ransom

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 1 Nov 2013 15:38:06 -0700 (PDT)

On Fri, November 1, 2013 2:34 pm, Robert Ransom wrote:
> further design or implementation considerations.

  I don't believe that's true. If the server reuses its ephemeral D-H key
then caveat emptor applies-- it should validate the client's public key,
regardless of whether a nonce is sent or not.

  Dan.

---

From: Watson Ladd <[email-masked]>
Date: Fri, 1 Nov 2013 15:40:25 -0700

> cryptosystems may be faster than ECDH.)
The PQ transition involves reworking the PKI as well. We also don't know if
NTRU or something else will win. A proffered version byte to avoid
downgrades could work, but I would not want to commit to the future.
> after they are used for more than some number of blocks.
After one zettabyte according to a simple calculation.
> (<
https://github.com/nmathewson/mixminion-doc/blob/a661212831d2afc3200339b2634ca16452e3aeec/spec/minion-spec.txt
>,
If reconnecting is cheap enough that works. Designers need to deal with
connection death anyway.
> similar to the preceding use, but to provide 'sideways secrecy' rather
What does renegotiation get here?
The untrusted device can do everything unless it is being monitored by a
trusted device.
> the originally derived key material, then discarding the old keys;
TOR could send a temporary outer signature and an inner proof. I agree this
is a weakness, but CurveCP like mechanisms only work thanks to some known
key.

---

From: Nico Williams <[email-masked]>
Date: Fri, 1 Nov 2013 18:13:45 -0500

> then caveat emptor applies-- it should validate the client's public key,

Agreed.  A small nonce should suffice for key derivation if either party
reuses their supposedly-ephemeral DH keys.  By "small" I mean "not
nearly as large as 32 bytes, i.e., not enough to suffice for a
Dual_EC-type backdoored RNG attack".  The party reusing a key should
send some such small nonce, possibly a 64-bit nonce.  In any case, the
client ought not be reusing ephemeral DH keys, and any server that does
should be rotating them often (like SSHv1 used to).

> regardless of whether a nonce is sent or not.

For some curves there's no need to validate the client's public key.

Nico
--

---

From: Robert Ransom <[email-masked]>
Date: Fri, 1 Nov 2013 16:34:24 -0700

> should be rotating them often (like SSHv1 used to).

The server should be allowed to send up to 32 bytes of nonce.  Some
servers will want to conceal the lifetime of their keypair by
generating nonces using a counter encrypted or hashed with a secret,
using the cheapest encryption or hash function available; this may be
TEA, AES, SHA-256, or something else, depending on the hardware.  Some
servers will want to use a fast RNG to generate nonces.  32 bytes
should be enough to prevent even a random (or hash-derived) nonce from
repeating; anything less than that may not be enough for some servers.

Robert Ransom

---

From: Nico Williams <[email-masked]>
Date: Fri, 1 Nov 2013 18:40:31 -0500

> repeating; anything less than that may not be enough for some servers.

The point of smaller/fewer nonces is two-fold:

 - if anyone was using 32 bytes of Dual_EC DRBG output before and it
   went unnoticed because, hey, that's what it's there fore, well, now
   it may be more noticeable if they do that sort of thing and spread
   those magic 32 bytes over several nonces

   Yes, this is fighting yesterday's war.  But anyways.

 - less subliminal channel bandwidth (same thing)

   Subliminal channels are very difficult to eliminate.  Merely reducing
   their bandwidth ought to help.  If, for example, there's only a 16
   bytes total of nonces in the handshakes (8 bytes for each of the
   client and server), and the cipher+mode in use doesn't need random
   IVs, then TLS connections would have no subliminal channels
   post-handshake, and hopefully the channel in the handshakes is very
   small (there's still bogus extensions and such to consider, but those
   at least can stand out).

   Worth it?  I think so.

Nico
--

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 1 Nov 2013 17:06:24 -0700 (PDT)

> should be rotating them often (like SSHv1 used to).

  It has nothing to do with key derivation, it's to prevent a small sub-group
attack. Sending a nonce does not prevent this attack since it's just going to
be another known for the attacker to use when running through the small
sub-group looking the right secret.

> For some curves there's no need to validate the client's public key.

  Which curves would those be?

  Dan.

---

From: Robert Ransom <[email-masked]>
Date: Fri, 1 Nov 2013 17:26:28 -0700

> downgrades could work, but I would not want to commit to the future.

If I believed that a 'PQ transition' would be needed, I would argue
for implementing it *now*.  This is purely for performance purposes,
if PQ cryptosystems turn out to be faster than ECDH in at least some
implementations.

> After one zettabyte according to a simple calculation.

For counter mode with a non-GCM-like MAC, yes.  Other modes have other
security bounds.

> If reconnecting is cheap enough that works. Designers need to deal with

Reconnecting allows relatively simple network eavesdropping logs (e.g.
logs which contain connection endpoint addresses, start and end time,
and amount of data transferred) to record more information about the
application's behaviour.

Apart from that, applications should not need to cause connection
death in order to obtain forward secrecy.

> What does renegotiation get here?

Renegotiation can be used to prevent the untrusted device from
decrypting the user's password in order to use it to authorize a later
TLS connection.

> The untrusted device can do everything unless it is being monitored by a

The untrusted device cannot do anything after the TLS connection is closed.

> TOR could send a temporary outer signature and an inner proof.

It's "Tor", not "TOR".

That's what it does now, using a custom authentication protocol with a
custom channel-binding  at the application layer, because the TLS
renegotiation mechanisms available at the time were too problematic.

> I agree this

Or the server could send the blob authenticating its (EC)DH public key
inside the (EC)DH secure channel.  (I mentioned this as an application
of renegotiation because you did not specify that server credentials
would be concealed, not because there is no special-purpose hack to
get around the lack of renegotiation.)

I agree that some of the problems that I know renegotiation can solve
can be addressed using other mechanisms.  I don't see the attraction
of designing and implementing a different protocol feature to solve
each problem when a single secure, well-designed renegotiation
protocol would solve all of them at once.

Robert Ransom

---

From: Robert Ransom <[email-masked]>
Date: Fri, 1 Nov 2013 17:38:15 -0700

> sub-group looking the right secret.

Small-subgroup attacks are entirely orthogonal to whether a server can
be caused to reuse a session key.  (Reusing a session key destroys the
security properties of many bulk encryption methods, including all
stream ciphers, regardless of whether the server's DH secret key is
disclosed.)

>   Which curves would those be?

Curve25519 ECDH implementations which follow the specification in Dr.
Bernstein's paper do not leak any information about the server's
secret key under any active attack.  They prevent small-subgroup
attacks by using the Montgomery ladder on a curve with a secure
quadratic twist, and by generating all secret keys to be divisible by
8 (the LCM of the orders of small subgroups).

Robert Ransom

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 1 Nov 2013 19:13:44 -0700 (PDT)

On Fri, November 1, 2013 5:38 pm, Robert Ransom wrote:
>> attack. Sending a nonce does not prevent this attack since it's just
>> going
>> to

  "caused to reuse a session key"? Who said anything about that. My
statement was in response to yours that said:

   "If the server sends a nonce during DHE/ECDHE key exchange, the
    server can safely reuse its DH keypair for multiple clients WITH NO
    FURTHER DESIGN OR IMPLEMENTATION CONSIDERATIONS  (emphasis
    mine)".

Again, if the server decides to reuse its DH key pair with multiple
clients then it needs some implementation considerations, namely it
needs to protect itself against a small sub-group attack. And this is
regardless of whether it sends a nonce or not. It has nothing to do with
key derivation.

  Also, your statement that "[r]eusing a session key destroys the security
properties of...all stream ciphers" leaves a bit of quantification up to
the reader. It's reuse of a session key _and_ a counter/nonce, and that's
only if you are not using SIV mode.

> 8 (the LCM of the orders of small subgroups).

  Thanks for the reference. I'll check it out.

  Dan.

---

From: Robert Ransom <[email-masked]>
Date: Fri, 1 Nov 2013 20:53:13 -0700

On 11/1/13, Dan Harkins <[email-masked]> wrote:
>   "caused to reuse a session key"? Who said anything about that.

Nico Williams proposed omitting all nonces from (EC)DHE handshakes and
shared secrets in a future version of TLS.  My objection to that
proposal was that servers need to ensure that *something* in the
handshake is fresh, and if that is not a nonce, they will need to
ensure that at least one of the DH keypairs is new.  I thought it was
obvious that the reason for that was to prevent an attacker from
replaying the client DH public key and causing the server to reuse a
session key.  (It was obvious to Nico.)

> My

Sorry.  I forgot that some elliptic-curve groups are meant to be
implemented in such a way that single-use ECDH keypairs appear to
remain safe, but an attacker can obtain the secret portion of an ECDH
keypair if it is used for more than one key exchange.

If the server sends a nonce during DHE/ECDHE key exchange, the server
can safely reuse its DH keypair for multiple clients with no further
*protocol-level* design or implementation constraints.  The
cryptographic primitive still needs to be securely designed and
implemented.

My main point was that if the server does *not* send a nonce, as Nico
suggested, the server needs significant further design,
implementation, and runtime computation to reuse its DH keypair
without reusing session keys.  That further effort may negate the
performance benefits of reusing DH keypairs on the server side, and
may lead implementations to not support (EC)DHE or a hypothetical
future version of TLS.

> only if you are not using SIV mode.

RC4 does not support a counter/nonce.  Adam Langley's proposed
ChaCha/Poly1305 ciphersuites use ChaCha's nonce input for the message
number, not to permit safe reuse of a session key.

GCM mode (which uses AES in counter mode as a stream cipher) may or
may not reuse a nonce.  There's no way to guarantee that a GCM
implementation will not choose to reuse the portion of a nonce that it
generates, especially if it does not know that the key is being
reused, but you do have a point -- GCM can be implemented in such a
way that using a session key twice will not immediately destroy its
security.  (Reusing a session key many times will still eventually
lead to nonce reuse.)

CCM mode (also based on AES in counter mode) may or may not reuse a
nonce.  They cut-and-pasted the text from the GCM RFC that "Each value
of the nonce_explicit MUST be distinct for each distinct invocation of
the GCM encrypt function for any fixed key.", without changing "GCM"
to "CCM", and again without any mention of how this distinctness is to
be guaranteed within a 64-bit field if the implementation does not
know that a key has been reused.  As with GCM, reusing a session key
many times will still lead to nonce reuse in implementations with
limited storage.

SIV mode should be safer under key reuse, but is not used in any TLS
ciphersuite, and is not likely to be useful if future versions of TLS
retain the ServerRandom field (or an equivalent server-provided nonce
in the handshake).

Future stream-cipher-based ciphersuites are likely to be more like the
proposed ChaCha ciphersuite than GCM/CCM.

In any case, for the sake of security, performance, and simplicity,
ciphersuites should be able to rely on the handshake layer to not
generate the same session key twice.

Robert Ransom

---

From: Watson Ladd <[email-masked]>
Date: Fri, 1 Nov 2013 22:19:54 -0700

>>>>> should be rotating them often (like SSHv1 used to).
Or we could use a RNG with a security reduction to something strong.
What is it about cryptography that causes people to invent unproven solutions
against nonexistent problems?
> keypair if it is used for more than one key exchange.
Which ones are those? Assuring near-prime order is trivial, as is
checking points are
on the curve. Maybe this explains why some people think it is okay to
skip curve checks.
> may lead implementations to not support (EC)DHE or a hypothetical
Not really: it just needs to blacklist client keys that it has seen
before. The extra
design is trivial, and computation is checking a hash table or Bloom
filter (false positives
have no cost). If you have multiple threads each can have one cache. However,
the cost of a nonce is small.
> proposed ChaCha ciphersuite than GCM/CCM.
Why are we talking about supporting multiple ciphersuites? We have
strong reductions
to the security of AES for everything we are considering using, or
some similar cipher.
Performance will lead to one clear winner. Options are bad: they
invite incompatibility
and deployment issues, and are a place for bugs to hide. I want to
write TLS 1.3 in an
IOCCC entry ideally. (Well, I would if the success of OpenSSL didn't
ensure people
would use it).

We could parametrize keysize if you really want: give a 128 and 256
option. But no more!
> generate the same session key twice.
For the sake of all three of those we should have one ciphersuite, one
key negotiation,
one curve, and a security proof.

>
>
> Robert Ransom
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sat, 02 Nov 2013 08:26:34 +0100

On 11/01/2013 12:09 AM, Nico Williams wrote:

>    nonces.

Not really. Nonces are needed even in DHE ciphersuites. The nonces in
TLS make sure that the signatures from both parties are fresh and only
valid for this session (i.e., cannot be taken and re-used in another
session). See how PKINIT Kerberos has issues when used with smart cards,
just because it saved a round-trip by not sending a server nonce.

While one could select a message order in order to avoid using nonces by
using the DH public keys as such and maintain security (i.e., one cannot
save a round-trip), what would that buy? It would just make the TLS
shell weaker that would resemble less of a generic security protocol
with algorithm agility.

regards,
Nikos

---

From: Andy Lutomirski <[email-masked]>
Date: Fri, 01 Nov 2013 16:05:01 -0700

> cryptosystems may be faster than ECDH.)

I've yet to see one that's remotely competitive in both performance and
message size.  IIRC, the NTRU algorithms have some serious security
questions and the LWE and McEliece-like algorithms have enormous public
keys.

That being said, being ready for quantum computers if and when they show
up is a good idea.  (Note that everything will need to be upgraded to
256-bit security if real quantum computers show up, regardless of
public-key breaks.)

> rekeyed using renegotiation every 15 minutes for this purpose.

Renegotiation is a really heavy-weight way to do this.  Just have both
sides apply some irreversible transformation to the master secret every
now and then.  (For example, they could hash the keys and throw away the
originals.)

OTOH, using renegotiation to request a client certificate after you've
seen the URL is useful.  But this doesn't actually need a change of
cipher -- it just needs the client to prove its identity.

--Andy

---

From: Nico Williams <[email-masked]>
Date: Sat, 2 Nov 2013 16:14:45 -0500

> session key.  (It was obvious to Nico.)

If either party wants to reuse a DH key then all they have to do to make
it safe is also send a counter for salting.  The counter would reveal
some information, so it may have to look random -- like a nonce -- and
anyways, the other party can't validate anything about that counter.
BUT, a) it's optional (if you don't reuse DH keys, you don't reuse
session keys), b) it's *small*, much smaller than 32 bytes.

Large nonces and explicit random IVs form a great subliminal channel.
Taking direct outputs from a Dual_EC DRBG-style RNG for 32 byte nonces
in TLS handshake messages makes you vulnerable to attack via the RNG.
While having tiny nonces (or no nonces if not reusing your DH key) and
random-IV-free cipher modes makes such attacks much harder to mount
because the total number of bits of subliminal channel becomes fixed and
is way less than the number needed for that sort of attack.

Clearly there's a trade-off here:

 - no nonces -> no DH key reuse

 - large nonces -> no constraints on DH key reuse

 - small nonces -> limited number of DH key reuses

And:

 - large nonces facilitate some attacks via subliminal channels and RNG
   attacks

 - no nonces (and no explicit random IVs) -> no subliminal channels

 - small nonces -> lower subliminal channel bandwidth

There's no reason to pick one for all implementations.  And there's
reason to avoid large nonces.

> generate the same session key twice.

Then GCM and friends are out.  They fail catastrophically with key
reuse.  But I think your concern is misplaced -- see above.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Sat, 2 Nov 2013 16:22:54 -0500

> just because it saved a round-trip by not sending a server nonce.

If your DH key is fresh then you don't need a nonce: the shared secret
will have a minimum of entropy close to that which you put into
selecting the DH private key, even if your peer reuses their DH key.

If you reuse DH keys then you need a coutner/nonce; the size of the
counter/nonce relates to the number of times you plan on reusing the DH
key.

>              [...], what would that buy? [...]

Nonces and explicit (even confounded) random IVs -especially the latter-
provide high subliminal channel bandwidth.  Smaller/fewer nonces and
explicit random IVs -> less subliminal channel bandwidth.  Capping the
number of subliminal channel bits per-connection is even more
interesting.

Nico
--

---

From: Robert Ransom <[email-masked]>
Date: Sat, 2 Nov 2013 14:51:18 -0700

> reason to avoid large nonces.

If your implementation is backdoored, you're screwed no matter what.
Avoiding nonces won't help you.

As for the nonce size tradeoff:

* no nonce: no DH keypair reuse, or a replay-detection cache
* 32-byte nonce: server can use a PRNG, or can use a keyed hash to
hide its key-use counter
* 16-byte nonce: server must disclose its key-use counter or use a
block cipher to hide it
* 8-byte nonce: server must disclose its key-use counter or use a
64-bit block cipher (e.g. 3DES or TEA) to hide it

32-byte nonces must be allowed.  There's no downside to using a
32-byte nonce field in all cases; the server can pad with zero bytes
(or PRNG output, or whatever it wants) if it uses AES to hide its
counter.

> reuse.  But I think your concern is misplaced -- see above.

No.  The reason that ciphersuites should be able to rely on the
handshake layer to not generate the same session key twice is to
*allow* GCM and other stream-cipher-based constructions.

Robert Ransom

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Sun, 3 Nov 2013 17:03:48 +0000

Hi,

avoid renegotiation. It serves no purpose and only adds complexity. It is
so much more secure to kill and re-establish the TLS if the counters run
out instead of renegotiating.

This might be better placed in a higher layer:
It is desirable for the server to know how the client authenticated the
server. E.g. currently the a server does not know if the client matched the
Server's Certificate's CommonName against the URI or if the client
performed full certificate chain authentication. Currently the server
blindly trusts the client (e.g. user) to check the certificate chain and
match the URI<>CN.

(An example are jabber servers using TLS. Most clients allow the user to
accept any server certificate without verification. The jabber server has
no way to detect which client performed proper certificate verification and
CN<>URI match).

regards,

ralf

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Sun, 3 Nov 2013 17:18:13 +0000

Hi,

> after they are used for more than some number of blocks.

Can you be more specific about 'some number of blocks'? This number is
astronomically large. Reconnect the TLS if you have to.

> rekeyed using renegotiation every 15 minutes for this purpose.

Mixminion falsely assume  that the security degrades if a connection is
live for more than 15 minutes. That's security wise not true. In today's
security design (TLS) the negotiated session key material is secure for
years (if not decades). Gone are the times when DES was used and DES could
be cracked in 24h and it was desirable to use a new DES key every 24 hours.
Gone. Gone Gone.

If you negotiate session keys that could be cracked within a year you
should not have negotiated those sessions keys in the first place.

> similar to the preceding use, but to provide 'sideways secrecy' rather

Renegotiation comes at a huge cost of complexity (not just from a
development point of view but also from a security audit point of view).
All features of re-negotiation can be achieved by re-connecting.
Re-connecting is well understood, easily tested and audited.

> the originally derived key material, then discarding the old keys;

reconnect!

regards,

ralf

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sun, 03 Nov 2013 18:46:08 +0100

> Re-connecting is well understood, easily tested and audited.

The fact that renegotiation is available in almost all implementations,
says that the cost is not as huge as you mention. You also seem to imply
that renegotiation is as secure as terminating a connection and
re-establishing another one. It is not.

regards,
Nikos

---

From: Yoav Nir <[email-masked]>
Date: Sun, 3 Nov 2013 19:18:08 +0000

On Nov 3, 2013, at 9:03 AM, Ralf Skyper Kaiser <[email-masked]> wrote:

> Hi,
> 
> avoid renegotiation. It serves no purpose and only adds complexity. It is so much more secure to kill and re-establish the TLS if the counters run out instead of renegotiating.
> 

Hi, Ralf

The one use of renegotiation that I'm aware of, is for overcoming a UI issue in browsers. If you do a TLS handshake with mutual authentication (so the server sends a CertReq), the browser pops up a dialog box with all the certificates you might have. Website designers with to avoid that, especially on the welcome screen, so the web server does not send a CertReq. Instead, they present a welcome screen with a button or link that says "Login with certificates" Clicking that performs a regular SSL handshake (or does nothing at all if the connection is already established), but when the request comes in ("GET /login_with_certs HTTP/1.1"), the web server sends a HELLO_REQUEST, and in the resulting handshake it sends the CertReq, so the pop-up appears when the user *is* expecting it.

I totally agree that renegotiation for rekeying is useless for people who are not doing DES-CBC and 3DES-CBC. It's even superfluous for them in most cases (you're pretty save doing 500,000,000 blocks, and that's 4 GB in 3DES. How many sites do you browse with 4 GB?  Maybe downloading stuff…)  

But before we can drop renegotiation from the standards, or recommend that implementors don't implement it, we need an alternate mechanism to upgrade from server-authenticated to mutually-authenticated within the same session. That is a real market need. How about allowing a CertReq sent from the server to the client in the middle of a connection, followed by the client sending a Certificate and Certificate Verify. For simplicity, we could always do that after the Finished, so that it's always Server-authenticated session when the Finished is sent.

Yoav

---

From: Robert Ransom <[email-masked]>
Date: Sun, 3 Nov 2013 12:30:25 -0800

> should not have negotiated those sessions keys in the first place.

Mixminion correctly assumes that anyone who obtains a session key by
compromising a server can use that key to decrypt all traffic
protected by it, no matter how long brute-force search would have
taken to find the key.

Robert Ransom

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Sun, 3 Nov 2013 23:12:30 +0000

Hi,

someone who can compromise the server to extract the currently used session
keys can also extract all future session keys (or at least is most likely
able to). There is no (practical) need or added security when the session
key is renegotiated every 15 minutes.

ralf

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Sun, 3 Nov 2013 23:23:10 +0000

Hi Yoav,

i agree with the UI issue. That's the only use that I can see where
renegotiation is useful.

I would guess here that 99% of all TLS users (if not 99.99%) do not need
this feature.

The 99.99% of all users would have to carry the risk of complexity to
satisfy the need of the 0.01% of users.

There are hopefully other ways to satisfy the need of the 0.01% without the
99.99% of us having to take an extra risk (complexity). (Anyone? Ideas are
welcome...).

(ps when i'm speaking about complexity i do not mean the working hours it
would take to write the code [earlier replies by somebody indicated this]
but rather the security complexity [making mistakes and auditing a
process/procedures/... that is rarely used]).

regards,

ralf

On Sun, Nov 3, 2013 at 7:18 PM, Yoav Nir <[email-masked]> wrote:

> > avoid renegotiation. It serves no purpose and only adds complexity. It
> is so much more secure to kill and re-establish the TLS if the counters run
> The one use of renegotiation that I'm aware of, is for overcoming a UI
> issue in browsers. If you do a TLS handshake with mutual authentication (so
> the server sends a CertReq), the browser pops up a dialog box with all the
> certificates you might have. Website designers with to avoid that,
> especially on the welcome screen, so the web server does not send a
> CertReq. Instead, they present a welcome screen with a button or link that
> says "Login with certificates" Clicking that performs a regular SSL
> handshake (or does nothing at all if the connection is already
> established), but when the request comes in ("GET /login_with_certs
> HTTP/1.1"), the web server sends a HELLO_REQUEST, and in the resulting
> handshake it sends the CertReq, so the pop-up appears when the user *is*
> expecting it.
>
> I totally agree that renegotiation for rekeying is useless for people who
> are not doing DES-CBC and 3DES-CBC. It's even superfluous for them in most
> cases (you're pretty save doing 500,000,000 blocks, and that's 4 GB in
> 3DES. How many sites do you browse with 4 GB?  Maybe downloading stuff…)
>
> But before we can drop renegotiation from the standards, or recommend that
> implementors don't implement it, we need an alternate mechanism to upgrade
> from server-authenticated to mutually-authenticated within the same
> session. That is a real market need. How about allowing a CertReq sent from
> the server to the client in the middle of a connection, followed by the
> client sending a Certificate and Certificate Verify. For simplicity, we
> could always do that after the Finished, so that it's always
> Server-authenticated session when the Finished is sent.
>
> Yoav
>
>

---

From: Watson Ladd <[email-masked]>
Date: Sun, 3 Nov 2013 15:28:14 -0800

> 99.99% of us having to take an extra risk (complexity). (Anyone? Ideas are
Kick it into the application layer.
>> especially on the welcome screen, so the web server does not send a CertReq.
>> Instead, they present a welcome screen with a button or link that says
>> "Login with certificates" Clicking that performs a regular SSL handshake (or
>> does nothing at all if the connection is already established), but when the
>> request comes in ("GET /login_with_certs HTTP/1.1"), the web server sends a
>> HELLO_REQUEST, and in the resulting handshake it sends the CertReq, so the
>> pop-up appears when the user *is* expecting it.
>>
>> cases (you're pretty save doing 500,000,000 blocks, and that's 4 GB in 3DES.
>> How many sites do you browse with 4 GB?  Maybe downloading stuff…)
>>
>> from server-authenticated to mutually-authenticated within the same session.
>> That is a real market need. How about allowing a CertReq sent from the
>> server to the client in the middle of a connection, followed by the client
>> sending a Certificate and Certificate Verify. For simplicity, we could
>> always do that after the Finished, so that it's always Server-authenticated
>> session when the Finished is sent.
>>
>> Yoav
>>
>
>

---

From: Yoav Nir <[email-masked]>
Date: Sun, 3 Nov 2013 23:41:58 +0000

> Kick it into the application layer.

Do you mean HTTP or the actual application?

Neither of them has all the cruft that is involved in accepting certificates (ASN.1, revocation validation, etc). So do we reduce complexity a little for TLS, at the expense of a huge increase in complexity for higher layers?

The security of the system depends in part on the complexity, but that's the complexity of the whole system, not of a particular component. Kicking the complexity around from one component to another only helps if that makes for a more logical separation. Moving client authentication into another layer doesn't do that.

Yoav

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Sun, 3 Nov 2013 23:48:16 +0000

Hi,

Yoav, Waton did not mean to 'move the entire client side auth' into the
application layer.

Instead it is possible to remove renegotiation from the standard and still
be able to authenticate clients by certificate without UI pop up.

In the earlier example with HTTPS and 'Login with certificate button': The
button could indicate to the client to establish a new TLS connection and
authenticate the client by certificate (without the need of renegotiation).
There are endless options to make this neatly without UI pop-up as well.

regards,

ralf

On Sun, Nov 3, 2013 at 11:28 PM, Watson Ladd <[email-masked]> wrote:

> CertReq.
> 3DES.
> session.

---

From: [email-masked] (Martin Rex)
Date: Tue, 5 Nov 2013 01:36:52 +0100 (CET)

> no way to detect which client performed proper certificate verification and

Huh?

What policy the client applies when checking the server's certificate
chain is none of the server's business.  This is entirely at the
discretion of the client.

-Martin

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Tue, 5 Nov 2013 02:03:31 +0000

Hi Martin,

exactly, and that's the problem: "What policy the client applies when
checking the server's certificate chain is at the discretion of the client."

There is no easy way to solve this. The client (and user) can always cheat
if he wants to. But we are not discussing dishonest users. Let's assume a
honest user who wants to connect to a TLS service securely.

The user uses a TLS client (say pidgin for jabber). This client has several
options to configure the TLS connection. These options include if the chain
should be checked at all, if the user is allowed to accept self-signed
certificates and against which CA-bundle to verify the server's certificate.

A securely configured TLS client would verify the certificate chain.

The server has no way to check if the TLS client is configured securely.
The server blindly trusts the client that it is configured securely. That
does not scale. Users make mistakes. Users will connect to a service not
knowing that the connection is not secure (even over TLS) because they did
not configure the TLS correctly.

A flag that would tell the server how the client has verified the
connection would enable the server to block the user from using the service
UNTIL his client is configured securely.

Tata. Better security.

regards,

ralf

---

From: Jeff Jarmoc <[email-masked]>
Date: Mon, 4 Nov 2013 20:45:32 -0600

And what prevents the client from setting the flag despite not checking?

It's the client's responsibility to validate the server's identity (or not) to the extent it chooses to do so.  It's the server's responsibility to validate the client's identity (or not) to the extent it chooses to do so.  

Neither end can take on that responsibility for the other.

> On Nov 4, 2013, at 8:03 PM, Ralf Skyper Kaiser <[email-masked]> wrote:
> 
> Hi Martin,
> 
> exactly, and that's the problem: "What policy the client applies when checking the server's certificate chain is at the discretion of the client."
> 
> There is no easy way to solve this. The client (and user) can always cheat if he wants to. But we are not discussing dishonest users. Let's assume a honest user who wants to connect to a TLS service securely.
> 
> The user uses a TLS client (say pidgin for jabber). This client has several options to configure the TLS connection. These options include if the chain should be checked at all, if the user is allowed to accept self-signed certificates and against which CA-bundle to verify the server's certificate.
> 
> The server has no way to check if the TLS client is configured securely. The server blindly trusts the client that it is configured securely. That does not scale. Users make mistakes. Users will connect to a service not knowing that the connection is not secure (even over TLS) because they did not configure the TLS correctly.
> 
> A flag that would tell the server how the client has verified the connection would enable the server to block the user from using the service UNTIL his client is configured securely.
> 
> Tata. Better security.
> 
> regards,
> 
> ralf
> 
> 
>

---

From: Nico Williams <[email-masked]>
Date: Mon, 4 Nov 2013 21:19:09 -0600

> honest user who wants to connect to a TLS service securely.

What are you talking about?  Of course the client and server (and CAs,
and...) can all cheat on *themselves*.  But the whole point of
verifying some other party's certificate is to protect yourself.  The
client (unless it's a dumb, dumb client) is going to do check the
server's cert.

> certificates and against which CA-bundle to verify the server's certificate.

Yes, it'd be nice if XMPP clients had a
leap-of-faith/trust-on-first-use option.  That has nothing to do with
this thread unless you're proposing a different method of
authenticating servers.

> A securely configured TLS client would verify the certificate chain.

I know right?  So that's a bug in the client.  Nothing wrong with TLS
itself.  (Well, the PKIX bits are not trivial, and that has to do with
why some clients get things wrong, but surely you're not proposing
replacing the PKIX bits.)

> The server has no way to check if the TLS client is configured securely. The

And vice-versa.  Of course.

> server blindly trusts the client that it is configured securely. That does
> not scale. Users make mistakes. Users will connect to a service not knowing
> that the connection is not secure (even over TLS) because they did not
> configure the TLS correctly.
>
> A flag that would tell the server how the client has verified the connection
> would enable the server to block the user from using the service UNTIL his
> client is configured securely.
>
> Tata. Better security.

Ah!  You want a secure bit.  Like RFC3514 (note the publication date).
 It doesn't work.

Nico
--

---

From: Yoav Nir <[email-masked]>
Date: Tue, 5 Nov 2013 05:53:01 +0000

On Nov 4, 2013, at 6:45 PM, Jeff Jarmoc <[email-masked]<mailto:[email-masked]>> wrote:

Right. This is what the NEA people call "the lying endpoint" problem, and it can't be solved without some pretty rubegoldbergian stuff like trusted computing.

I don't want a client on my machine acting as an agent of the server, informing it that my machine is not configured correctly. Sometimes this information leaks (like when my ClientHello has only SSLv3 and TLS_RSA_EXPORT_WITH_RC4_40_MD5. But beyond that, this is none of the server's business.

Yoav

---

From: Johannes Merkle <[email-masked]>
Date: Tue, 05 Nov 2013 14:18:49 +0100

> not configure the TLS correctly.

I don't see the point. You are referring to a verification of the server's certificate by the client.
When a client identifies a server, what is the benefit for the server to ensure that the client performs the
identification in a proper way?

If the verification is not done properly by the client, the client may be susceptible to impersonation attacks on the
server side, i.e. may trust a malicious server pretending to be the honest server. If such a case occurs, i.e, if the
client has connected to a malicious server, what were the point in the honest server's checking the client's policy? In
such a case, the honest server is not even participating in the communication, and the malicious server, who is
participating in the communication, will certainly not insist on a strict client policy (not if he is a clever attacker,
at least).

So, what threat scenario is your requirement (of the server being able to verify the client's policy) addressing?

-- 
Johannes

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 5 Nov 2013 09:51:16 -0800 (PST)

Hello,

> UNTIL his client is configured securely.

  Doesn't RFC 3514 solve this problem for you? If not, then maybe it's
time for a 3514-bis.

  regards,

  Dan.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 5 Nov 2013 17:55:23 +0000

> identification in a proper way?

There is a benefit in making the whole ecosystem more secure, and rejecting components that are insecurely configured, because they can compromise the whole system.

I don't think that's enough to justify this kind of thing.

Yoav

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 5 Nov 2013 17:59:18 +0000

I am failing to see the security benefit or threat the server verification of client's hygiene on certification path validation provides.

If the client ends up trusting the wrong key, it will go to a bad server.

If the client is connected to the good server, certification path validation does not matter since it is already at the right place no matter how it got there.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan Harkins
Sent: Tuesday, November 05, 2013 12:51 PM
To: Ralf Skyper Kaiser
Cc: [email-masked]
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3

  Hello,

On Mon, November 4, 2013 6:03 pm, Ralf Skyper Kaiser wrote:
> There is no easy way to solve this. The client (and user) can always 
> cheat if he wants to. But we are not discussing dishonest users. Let's 
> assume a honest user who wants to connect to a TLS service securely.
>
> The user uses a TLS client (say pidgin for jabber). This client has 
> several options to configure the TLS connection. These options include 
> if the chain should be checked at all, if the user is allowed to 
> accept self-signed certificates and against which CA-bundle to verify 
> the server's certificate.
>
> The server blindly trusts the client that it is configured securely. 
> That does not scale. Users make mistakes. Users will connect to a 
> service not knowing that the connection is not secure (even over TLS) 
> because they did not configure the TLS correctly.
>
> connection would enable the server to block the user from using the 
> service UNTIL his client is configured securely.

  Doesn't RFC 3514 solve this problem for you? If not, then maybe it's time for a 3514-bis.

  regards,

  Dan.

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Tue, 5 Nov 2013 19:49:30 +0000

Hi,

i mentioned earlier that this would not prevent dishonest clients (I am not
trying to achieve this). The goal is not to solve "the lying endpoint"
problem or re-invent trusted computing.

There are some applications which implement such a notification in the
application layer already. For example a web server can query a web-browser
if the browser is using 'Private Browsing' and if prevent the client from
using the web-site.

The user/browser can lie (but it would be to the disadvantage of the user).

As somebody else mentioned it's a flag that enables the server to prevent
accidental misconfiguration of a client - unless the user is dishonest - in
which case it is to the disadvantage of the user.

Maybe we need a real-life scenario:

You are better off wearing a seat-belt in a car. You might one day forget
to put on the seat belt (honest mistake!). So a mechanism that the car
warns you about it. Yes, you can cheat the car and pretend you put the
seat-belt on when you did not - but that's to your disadvantage.

Equally does it not mean that every time you do not wear a seat-belt  that
you will have an accident ('are attacked'...) (some people suggest this).

regards,

ralf

regards,

ralf

On Tue, Nov 5, 2013 at 2:45 AM, Jeff Jarmoc <[email-masked]> wrote:

> It's the client's responsibility to validate the server's identity (or
> not) to the extent it chooses to do so.  It's the server's responsibility
> to validate the client's identity (or not) to the extent it chooses to do
> so.
>
> several options to configure the TLS connection. These options include if
> the chain should be checked at all, if the user is allowed to accept
> self-signed certificates and against which CA-bundle to verify the server's
> certificate.
>