Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sat, 1 Nov 2014 05:41:01 -0400 (EDT)

----- Original Message -----
> During the TLS interim meeting of last week (Oct 22 2014) I suggested that
> TLS
> 1.3 should abandon signature-based authentication (other than for
> certificates)
> and be based solely on a combination of ephemeral Diffie-Hellman for PFS and
> static Diffie-Hellman for authentication. This has multiple benefits
> including
> major performance gain (by replacing the per-handshake RSA signature by the
> server with a much cheaper elliptic curve exponentiation), compatibility
> with
> the mechanisms required for forward secrecy, natural accommodation of a
> 0-RTT
> option, and a simple extension without signatures for client authentication.

That effectively deprecates all existing infrastructure used for TLS that pretty
much only works with RSA and ECDSA certificates (from smart cards, to HSMs and
acceleration hardware). That's not necessarily bad, and we may already be past the
point where TLS 1.3 can be considered a minor revision of TLS 1.2.

> PROTOCOL OPTLS:
> 
> ClientHello
> ClientKeyShare
> ClientData* [K0]       -------->
>                                            ServerHello
>                                            ServerKeyShare
>                                            ServerCertificate* [K1]
>                                            ServerFinished [K2]
>                        <--------           ServerData* [K2]
> ClientFinished* [K2]   -------->
> 
> 
>             Protected Application Data [K3]
>                        <------->
> 1-RTT CASE:
> 
> The basic 1-RTT case omits the ClientData* field. It includes a
> ClientKeyShare
> g^x and a ServerKeyShare g^y and an optional (encrypted) server
> certificate.
> If the certificate is sent (it can be omitted if the client has indicated
> that
> it knows the server key as in the case in the 0-RTT scenario) and is
> encrypted,
> the encryption key K1 is derived from g^{xy}.
> 
> Key K2 is an encryption key derived from both g^{xs} and g^{xy}. It is used
> to
> authenticate-encrypt the ServerFinished and ClientFinished messages (which
> include a hash of the previous traffic) and to encrypt data from the server
> if
> such data is piggybacked to the second message.

How does the client get the DH (or ECDH) group parameters used by the server?

> CLIENT AUTHENTICATION:
> 
> Client authentication can be supported via an option or extension. It would
> include a client certificate for a static DH key g^c sent in the third
> message
> (the certificate can be encrypted under key K2 to provide client's identity
> protection). In this case, the key for computing the ClientFinished message
> and
> the application key K3 would be derived from a combination of the values
> g^xy,
> g^xs, g^yc (and possibly also g^{cs}).

As I understand client authentication as above would only work if both the client
and the server share the same DH/ECDH group for their certificates, and that cannot
be assumed to be true on an infrastructure that is designed to upgrade (e.g., change
client certs from secp192r1 to secp256r1).

regards,
Nikos

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 1 Nov 2014 12:16:11 +0200

> point where TLS 1.3 can be considered a minor revision of TLS 1.2.

The only reason it is called TLS 1.3 ("SSL 3.4") is because we can't use TLS 2.0
designation ("SSL 4.0") on wire because of compatiblity reasons. :->

Regarding the most basic ways to secure long-term private keys (but most servers
don't do even that[1]), those are based on software that is rather easily
upgraded.

[1] Those would have easily stopped dumping of private keys via Heartbleed.

> How does the client get the DH (or ECDH) group parameters used by the server?

Presumably from ServerHello (with CKS being optimistic).

But the case where client misses all its guesses needs to be handled.

>From what I quickly read, the idea was to issue the parameters off EE
certificates, so that getting appropriate group is little problem.

However, this poses some challenges with respect to revocation. From what I
understand, the parameters are intended to have limited lifetime (much
shorter than EE certificates).

The reason this is problematic is that one can't really rely on clocks:
- Even if you happen to have sub-second accurate clock, a lot of computers don't.
- The time protocols often aren't secured, allowing attacker to play tricks
  with endpoint time.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 1 Nov 2014 07:46:26 -0700

On Sat, Nov 1, 2014 at 3:16 AM, Ilari Liusvaara <[email-masked]
> wrote:

Unless I'm missing something, this can be handled the way that we
currently handle missed guesses, I.e., by having a HelloRetryRequest
followed by a new ClientHello/ClientKeyShare. Though of course
the server does need to either keep their RSA private key online
or periodically generate new signed DH shares for every group.

> - The time protocols often aren't secured, allowing attacker to play tricks

We're already starting to have that problem because of a desire to move to
OCSP
stapling, which, with staple, effectively gives the server a credential
which is
valid only within a fairly narrow window. However, I think you're right
that this
probably limits the range of lifetimes you can use with these signed DH
keys.

-Ekr

---

From: Watson Ladd <[email-masked]>
Date: Sat, 1 Nov 2014 14:07:53 -0700

On Sat, Nov 1, 2014 at 7:46 AM, Eric Rescorla <[email-masked]> wrote:
>
> On Sat, Nov 1, 2014 at 3:16 AM, Ilari Liusvaara
> <[email-masked]> wrote:
>>
>> > > PROTOCOL OPTLS:
>> > >
>> > > ClientHello
>> > > ClientKeyShare
> valid only within a fairly narrow window. However, I think you're right that
> this

That's not the problem Illari was talking about: It's not that g^s has
limited lifetime, but that there is no way to know that the lifetime
is expired, so it has long lifetime. NTP is not secure, so we have to
deal with bad clocks. In the case of certificates, this is usually not
so bad as the lifetimes are long. It might not be a problem for this,
as we can occasionally resign, keep s in memory and not be worse off
than today, or say that TLS clients need trusted clocks to avoid
compromise when s is revealed.

I don't think this is worse than today, where short lived certificates
can be wound back by similar means. However, the fact that this
requires changes to the handling of secrets may prove a barrier to
adoption of TLS 1.3. I hope people who are involved with more complex
things than tiny herds of beefy boxes will comment on how this
proposal does or doesn't work for them, and that these issues don't
turn out to be a dealbreaker.

Long term we need secure NTP if we want to limit things by time: there
is a proposal in the NTP WG, but it is overly complex and will likely
never be implemented due to gratuitous use of CMS. This time issue may
very well need to go into Security Considerations as unresolveable.

Sincerely,
Watson Ladd

>
> -Ekr
>
>
> _______________________________________________
> 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: Eric Rescorla <[email-masked]>
Date: Sat, 1 Nov 2014 14:45:49 -0700

On Sat, Nov 1, 2014 at 2:07 PM, Watson Ladd <[email-masked]> wrote:

> >> > > Key K2 is an encryption key derived from both g^{xs} and g^{xy}. It
> is
> >> > > used
> >> > > to
> >> However, this poses some challenges with respect to revocation. From
> what
> >> I
> >> - Even if you happen to have sub-second accurate clock, a lot of
> computers
> >> don't.

Yes. I understand this. My point is that OCSP Stapling is effectively
like short-lived certificates (and short-lived DHE shares) in that
you have a credential which is valid for a relatively short period of
time and which therefore requires that therefore requires tight
clock synchronization. And since we're moving towards OCSP
stapling and short-lived certs, we've got this problem in any case.

Arguably, the situation is slightly better here because the server
gets to select the key lifetime and so it can tune it depending on
its assessment of client clock accuracy, which is unlikely to be
the case with OCSP stapling.

-Ekr

---

From: Watson Ladd <[email-masked]>
Date: Sat, 1 Nov 2014 15:22:57 -0700

>> > <[email-masked]> wrote:
<snip>
> stapling and short-lived certs, we've got this problem in any case.

Ah, I was thinking of a different problem with OCSP stapling, which is
getting the response to staple periodically, and when you don't...

Thinking about it more, I think I don't understand this. X509
certificates have expiration dates. Doesn't that mean the client needs
a synchronized clock already? Why does the duration of the validity of
the response affect the existence of this issue?

With OCSP stapling this problem gets worse because there is no
freshness: it's a stapled response, and one of the security goals was
making revocation take hold quickly So I think an attacker who can
play games with time can already break OCSP stapling. Here we're
limiting the validity time of something equivalent to a certificate,
to deal with all sorts of problems that could lead to disclosure of
secrets.

But it seems like this mechanism might not work, because of endpoint
timing issues where the attacker gets to set the clock. How much worse
off are we than when certificate expiration times or OCSP validity
times get played with?

> the case with OCSP stapling.

The problem isn't that the client has an imprecise clock: +/- 10
minutes should not pose a problem. The problem is an that an attacker
can set the clock to whatever they want if they control the network.
Tuning the validity period doesn't change this. It's not an
operational issue, but a security issue.

Sincerely,
Watson Ladd

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 1 Nov 2014 16:22:05 -0700

On Sat, Nov 1, 2014 at 3:22 PM, Watson Ladd <[email-masked]> wrote:

> >> > We're already starting to have that problem because of a desire to
> move
> >> > to
> >> > OCSP
> a synchronized clock already?

Yes, it does.

> Why does the duration of the validity of

My argument here is that clients have some ability to sanity check
network time information, and so it's not necessarily like the attacker
can set the time to anything (I don't know how NTP clients currently
work). So an attacker who can only move the clock by a day or
two is going to of course be more effective attacking credentials
with a short time window than with a long time window
(though arguably that's because the latter is less secure to start
out with).

Does that make sense?

-Ekr

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Sun, 02 Nov 2014 00:43:31 +0100

> (though arguably that's because the latter is less secure to start
I think it does, at least partially

I'm by no means an expert on NTP security, but in my small experience, I've seen
configurations on laptops where the NTP server is started when a network
connection is established, and with an option that abruptly sets the time
(rather than slowly shifting it) on startup (that's the -s option to openntpd
for example).

So, while I tend to agree that in theory clients could be able to sanity-check
the network time if a precision of the order of days is desired, I'm afraid in
practice it's not happening everywhere.

But sure, needing a higher level of precision can only make more attacks
practical in more circumstances.

Manuel.

---

From: Watson Ladd <[email-masked]>
Date: Sat, 1 Nov 2014 17:45:51 -0700

> (though arguably that's because the latter is less secure to start

It does make sense, but it's wrong.

First, it's not clear that NTP works the way you think it does: my
laptop has no problem imposing a 15-hour jump on the system clock when
connecting to a timeserver after I fiddled with the clock. I'll try
some more tests to be sure that is what is going on, but I see no
description of such sanity checks in the OpenBSD manpage, or
OpenNTPD.org documentation, and haven't found it in the OpenNTPD code
yet. I've found documents indicating that OpenNTPD does change the
time massively on boot, namely presentations by the developers.

I've also had adventures when dual-booting where the RTC would get set
strangely on reboots, and ntp would straighten it out.

The protection that does exist on BSD systems is that the clock can
only be set backwards by adjtime(2) when in secure modes greater than
1. I don't think this used as much as it should be.

Secondly, suppose as an attacker I can twist time by a certain amount
d. This means any credential valid at any time in the range [t-d, t+d]
that I steal can be used at time t. The length of time the credential
is valid for doesn't enter into this analysis: while the attacker
would only be interested in doing this for short validity credentials,
the longer validity credentials are still useful if stolen. I don't
need to play any NTP games if I get the cert.

So to the extent that short-lived credentials work in the sense that
an attacker can only use them until a certain time in the future if
they extract them, it depends entirely on the value of d, which
currently is unbounded. Long-term credentials are just going to work
until they expire, and then plus d, just as short-term credentials do.
But it's more interesting in the case of short-term credentials.

Maybe being able to screw with the clock isn't a realistic assumption,
or we've already ruled it out. Certainly existing revocation
mechanisms can also be avoided in similar ways, under similar
conditions, and protecting system time isn't that hard conceptually:
NTP is massive overkill for most systems, being designed to attain
accuracies far beyond the few seconds a week computers can attain on
their own. So I don't think this security issue necessarily dooms this
proposal.

Of course, this is all moot if RFC 5906 is supported. However, it
seems that most NTP servers the public can use do not support autokey:
the best source for this is a debian bug where a member of the
pool.ntp.org team explains they can't set up an authenticated pool.

Sincerely,
Watson Ladd

---

From: Hugo Krawczyk <[email-masked]>
Date: Mon, 3 Nov 2014 00:05:02 +0200

These are good questions as they point to some of the choices we need to
consider before defining the actual key derivation mechanisms in the
protocol.
Below are some responses.

On Sat, Nov 1, 2014 at 3:44 AM, Eric Rescorla <[email-masked]> wrote:

> Hugo,
>
> Thanks for writing this up. I'm still digesting this, but I had a few
> questions.
>
> 1. In the interim, I believe you suggested MAC of the transcript under
> g^{xs} to authenticate g^y. This is fairly analogous to CertificateVerify,
> except using a MAC rather than a signature. In the current design, you
> instead generate a combined key from g^{xs] and g^{xy}. Are there
> advantages to this design or is it just a matter of style?
>

​Your understanding of the MAC (in the Finished message) as replacing the
functionality of the signature in CertificateVerify is correct. Also
correct is
that we could use g^{xs} for such authentication and derive the session
key(s)
directly from g^{xy}. On the other hand, deriving the key from both g^{xs}
and
g^{xy} has the advantage that an attacker that learns the ephemeral
exponent y
cannot compute the session key; for that it needs to find both y and s.
It also has the property that you get (implicit) authentication even
without the
ServerFinished message but this is not too significant in our case given
that we
mandate the Finished message.

One additional consideration in chosing the key derivation is the number of
exponentiations it requires. One could actually combine g^{xs] and g^{xy}
without requiring two exponentiations by using a HMQV-like key derivation.
However, this does not apply to our case where you either need to explicitly
compute g^{xs} (for encrypting ClientData in the 0-RTT case) or explicitly
compute g^{xy} (for encrypting ServerCertificate in the 1-RTT case).
​

>
> 2. I'm thinking about how to adapt this to PSK+PFS modes (i.e.,
> where you want the PSK for authentication but you want to do
> a DHE exchange for PFS). In the design you propose, it seems
> like the analogous thing to do would be to treat the PSK like
> g^{xy}? Does this interact at all with whether to mix the keys
> or use a MAC?
>

​Indeed, this is one of the conceptual advantages of this design.
You can replace g^{xs} (not g^{xy}) with the PSK shared between client and
server. It is not hard to define the authentication and key derivation
mechanisms so that they apply equally to the non-PSK and PSK settings.
​

>
> 3. WRT client auth, I think we've generally decided that the client's
> certificate ought to be encrypted. Given that, I wonder if it would be
> easier
> for the client to just do a digital signature over the transcript and/or
> an authenticator derived from the secret. Generally, the additional
> cost of the RSA signature isn't a huge problem for most clients and
> those which do should be able to quickly move to EC-based keys.
>
>
​I don't see the advantage of signatures in this case. It is possible to
design a
hybrid protocol with signature authentication at the client side and static
DH
at the server but I wouldn't do that without a clear advantage over the more
uniform approach using static DH on both sides. In any case, doing static
DH at
the client should not be a problem, it is already doing it to authenticate
the
server and compute keys.

Hugo
​

> Thanks,
> -Ekr
>
>
> On Fri, Oct 31, 2014 at 5:54 PM, Hugo Krawczyk <[email-masked]>
> wrote:
>
>> During the TLS interim meeting of last week (Oct 22 2014) I suggested
>> that TLS
>> Below I present a schematic representation of the proposed protocol
>> referred
>> to as OPTLS where OPT stands for OPTimized and/or for One-Point-Three.
>> The presentation is sketchy and omits the exact procedure for key
>> derivation.
>> The latter is a crucial component for the security of the protocol, but
>> before getting into these details we want to get a sense of whether the
>> WG is
>> interested in this approach. In the meantime, Hoeteck Wee and myself are
>> working on the details of the protocol and the security proof.
>>
>> We describe a setting with optional 0-RTT and server-only authentication.
>> Client authentication can be added as a further option or as an extension
>> (similar to the current 1.3 proposal) - see below.
>>
>> NOTATION AND TERMINOLOGY:
>>
>> [K] symbols represent pointers to key material whose exact derivation is
>> not
>> included here except for specifying the basic DH values from which the
>> key is
>> derived (actual derivation will include further information similar to the
>> extended hash mechanisms or SessionHash proposal considered for 1.3).
>> Asterisks represent optional fields that the WG can decide to leave as
>> optional,
>> mandatory, or simply remove without changing the core cryptographic
>> security of
>> the protocol. All references to encryption mean "authenticated encryption"
>> using the encrypt-then-mac paradigm (or any other secure AEAD
>> mechanism).
>>
>> KeyShare's represent ephemeral Diffie-Hellman values exchanged by the
>> parties.
>> All the public key and Diffie-Hellman operations are assumed to happen
>> over a
>> cyclic group with generator g of order q (typically implemented by an
>> elliptic
>> curve group). We use multiplicative notation where ^ denotes
>> exponentiation as
>> in g^x, g^{xy} (here xy denotes multiplication of the scalars x and y),
>> etc.
>> Omitted from the current high level description is a mechanism for
>> testing group
>> membership of DH values or cofactor exponentiation (the specific mechanism
>> depends on the group type and is typically very efficient for elliptic
>> curves).
>>
>> SERVER PUBLIC KEY AND CERTIFICATE:
>>
>> The server has a long term private-public key pair denoted by (s,g^s)
>> where
>> s is uniform random in [0..q-1] (we refer to s and g^s as "static keys").
>> We assume that the server has a certificate that includes the server's
>> public
>> key g^s and a CA-signed binding of this key to the server's identity.
>> We discuss the implementation of such certificates below.
>>
>> PROTOCOL OPTLS:
>>
>> ClientHello
>> ClientKeyShare
>> Key K2 is an encryption key derived from both g^{xs} and g^{xy}. It is
>> used to
>> include a hash of the previous traffic) and to encrypt data from the
>> server if
>> Key K3 is the "application key" used to derive key material for
>> protection of
>> application data.  This key material will include (directional)
>> Authenticated
>> Encryption keys and, possibly, keys for derivation of further re-key
>> material.
>> K3 is computed from  both g^{xs} and g^{xy} similarly to K2, but its
>> derivation
>> will be different than K2, e.g., using a separating key expansion
>> technique.
>>
>> SUPPORT FOR 0-RTT:
>>
>> The above protocol is compatible with a 0-RTT protocol such as QUIC. In
>> this
>> case, the client is assumed to have information about the server's public
>> key
>> and other security parameters. The server is assumed to have some
>> mechanism in
>> place for detecting replay (e.g., via timestamps, stored client nonces,
>> etc.).
>> The resulting protocol is as described above where the ClientData field
>> is sent
>> encrypted under key K0 derived from g^{xs}.
>> The rest of the protocol is identical to the above.
>> Note: In this case, ServerCertificate is not sent as the client had to
>> know
>> the server's public key before the first message (one can imagine a
>> setting
>> where the server may send a different certificate in the second message -
>> if
>> desired, this can be accommodated too as an option or extension).
>>
>> CLIENT AUTHENTICATION:
>>
>> protection). In this case, the key for computing the ClientFinished
>> message and
>> NOTES:
>> Note on Finished messages: The above spec sets ServerFinished as
>> mandatory and
>> ClientFinished as optional. The latter option is needed for a 1-RTT
>> protocol.
>> In principle, both Finished messages could be omitted and still obtain
>> security
>> via implicit authentication (assuming the inputs to key derivation are
>> chosen
>> appropriately). But given the advantages of ServerFinished for providing
>> explicit authentication, key confirmation, and active forward secrecy (see
>> below), it seems advisable to always include it. Including ClientFinished
>> provides key confirmation from client and also explicit client
>> authentication
>> when client certificate is included. ClientFinished also provides
>> Universal
>> Composable (UC) security (this is a result of the Canetti-Krawczyk proof
>> that
>> CK security implies UC security when a client confirmation step is
>> included).
>>
>> Note on certificates: Since in current practice servers hold certificates
>> for
>> RSA signature keys rather than for static DH keys, the certificate field
>> in the
>> above protocol will be implemented by a pair consisting of (i) the
>> server's RSA
>> signature certificate and (ii) the server's signature using this RSA key
>> on the
>> server's static public DH key g^s. The latter signature by the server is
>> performed only when a new static DH key is created (how often this
>> happens and
>> how many such keys are created is completely up to the server - it has the
>> advantage that these keys can be changed often to increase security
>> against
>> leaked keys). This use of RSA also enjoys the high efficiency of RSA
>> verification for the client.
>> The handling of Client certificates would be similar.
>>
>> Note on forward security (a.k.a. as PFS for Perfect Forward Security):
>> PFS is provided by the (mandatory) use of ephemeral Diffie-Hellman keys.
>> The meaning of PFS is that an attacker that finds the (long-term) static
>> private keys of the parties cannot compromise past session keys. Without
>> the
>> ServerFinished message the above protocol ensures forward secrecy against
>> passive attackers (i.e., for sessions where the attacker did not choose
>> g^y).
>> With ServerFinished, PFS holds also against active attackers.  A similar
>> consideration applies to ClientFinished.
>>
>> Client certificates in the first message: We note that in cases where
>> client
>> certificates can be sent in the clear in the first message of the
>> protocol, one
>> can provide PFS and mutual authentication in a 1-RTT at essentially the
>> same
>> cost of an unauthenticated DH exchange (i.e., a cost of little more than
>> two
>> exponentiations). In such a setting one can also obtain mutual
>> authentication in
>> a 0-RTT protocol (with forward secrecy with respect to the client's
>> key).
>> These options, however, require HMQV-like mechanisms and may raise IP
>> issues (this
>> can be investigated further if the WG is interested).
>>
>>

---

From: Hugo Krawczyk <[email-masked]>
Date: Mon, 3 Nov 2014 00:24:11 +0200

On Sat, Nov 1, 2014 at 7:15 AM, Watson Ladd <[email-masked]> wrote:

> Dear Hugo,
>
> There are some issues I can see:
>
> -Servers already supporting ECDSA certificates seem to not win. If I'm
> understanding correctly, a server does three exponentiations, one of
> which can be optimized by ephemeral reuse, when using ECDSA+ECDHE. The
> servers that win are the ones with RSA certs. The only way to win vs
> ECDSA is if DH only permits faster exponentiation, which it does, and
> removing the ancillary junk in ECDSA.  However, here we have two
> variable base exponentiations after ephemeral reuse, as opposed to one
> fixed, one variable, so there is a loss in performance on the same
> group, made up for by removing inversions modulo the group order.
>

​Don't forget that 0-RTT cannot be supported with a signature-based
protocol so in that sense going to static DH is a win-win.
As for performance, the gain with respect to (per-session) RSA signatures
is huge.
Comparison with ECDSA is indeed more complex as you point out, but static
DH wins in comparison to the sign+verify performance and saves many
complexities related to ECDSA optimization and (re)definition. It also
avoids the vulnerability of Schnorr-like signatures where leakage of one
ephemeral value compromises the long-term signature key. In contrast,
static DH keys do not leak even if all ephemeral values are disclosed.
Furthermore, one can design the protocol so that the disclosure of the
ServerKeyShare does not even compromise the session key that uses this
value.
​

>
> -I'm interested to see how different this is from ntor.[0] (To my eyes
> it is very similar, which may make proving easier. OTOH, the 0-RTT and
> 1-RTT options require care). Similarly, Michael Backes and coauthors
> have proposed Ace[1], which does similar tricks to HMQV to reduce
> server side cost, and provides a key exchange with some similar
> properties.
>

​I am not familiar with these works, but it is too early to compare with
other protocols as this one is yet not fully specified. Its details will be
set when we get a better understanding of what is needed. One important
element here is that we will be defining several key derivation operations
and we will need to prove (appropriate) security with respect to each such
key.
​

>
> -Estimations of the cost of group computations require care: while
> those in the original email are correct, the estimates for shared-base
> and multibase have to take into account the existence of ladders. A
> seeming optimization might force the use of a slower representation.
> In genus 1 this is no longer an issue.
>

​I am not expert in implementing EC operations so I will appreciate any
guidance regarding these aspects of the protocol.
​

>
> -We've already had controversy on the list about removing
> renegotiation as a mechanism for client authentication. While I would
> really like to see a symmetric client authentication method, the fact
> that some people want to change the client authentication state in the
> middle of the connection limits the kinds of options we have. (I don't
> know what exactly the requirements are or how they limit the options,
> but I remember this being raised in an earlier proposal for removing
> renegotiation)
>
> None of these issues look like showstoppers to me. I think the
> benefits of this proposal, particularly with regards to 0-RTT and
> 1-RTT exchanges where there is a solid proposal as opposed to none at
> all, significantly outweigh the minor disadvantages. It opens the door
> to massive performance increases by removing a dependency on signing,
> and the consequent annoyances. And lastly, it will hopefully have a
> proof that is understandable by humans with reasonable assumptions.
>

​That's the goal.

Hugo
​

>
> Sincerely,
> Watson Ladd
> -----
>
>
> [0] http://cacr.uwaterloo.ca/techreports/2011/cacr2011-11.pdf
> [1] https://www.infsec.cs.uni-saarland.de/~mohammadi/paper/owake.pdf
>
> On Fri, Oct 31, 2014 at 6:59 PM, Eric Rescorla <[email-masked]> wrote:
> > P.S. At first glance this kind of design seems to have some really nice
> > properties and wouldn't be too hard to modify the draft (and
> > implementations)
> > to support. I'm looking forward to hearing what the WG thinks.
> >
> > Best,
> > -Ekr
> >
> > On Fri, Oct 31, 2014 at 6:44 PM, Eric Rescorla <[email-masked]> wrote:
> >>
> >> Hugo,
> >>
> >>> and be based solely on a combination of ephemeral Diffie-Hellman for
> PFS
> >>> and

---

From: Hugo Krawczyk <[email-masked]>
Date: Mon, 3 Nov 2014 00:28:44 +0200

The issues regarding group matching (and mis-matching) raised here and
discussed
in other messages are indeed very important. In the case of server-only
authentication this reduces to the client guessing the right g^x and thus
requires dealing with wrong guesses (this only applies to the 1-RTT case as
in
the 0-RTT case the client learns the group together with the server's static
key g^s). In the mutual authentication case, if server and client cannot
agree
on using the same group for authentication, then the client would need to
choose its g^x in the server's group while authentication by the client
would
require the server to send an additional ServerKeyShare in the client's
group.
Note, however, that in the use case where the parties have certificates for
signature keys and they sign their own static DH key, clients and servers
can
possess static DH keys in different groups (without requiring a CA-issued
certificate for each such group), hence more easily support the peer's
group.

Hugo

On Sat, Nov 1, 2014 at 11:41 AM, Nikos Mavrogiannopoulos <[email-masked]>
wrote:

> server

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 2 Nov 2014 14:33:34 -0800

protocol.
> Below are some responses.

Thanks for your explanations.

easier
design a
> hybrid protocol with signature authentication at the client side and
static DH
DH at
> the client should not be a problem, it is already doing it to
authenticate the
> server and compute keys.

Thinking this through some more, if the client is doing certificate
authentication, it is already provisioned with a long-term signature
key and the corresponding certificate.  In order to do static DH for
authentication, it must either:

- Generate a new "static" DH key on the fly and sign it.
- Have some long-term storage where it stuffs the static DH key and
  its signature.

The first option is obviously more computationally expensive than not
doing so (though as I said above, not dramatically so if you are doing
EC). As you suggest, this isn't an issue for servers since they are
doing a lot of handshakes and can amortize the computation. However,
because the client may be slow but not do a lot of exchanges, it may
be an issue for clients.

The second option may be trivial, if the client already has some
generic key storage mechanism (e.g., one in software) though it's of
course more work for the programmer. However, if the client has a
non-generic key storage mechanism, such as a smart card with their
key, then this becomes a significant problem, as it may not be able to
store a DH key and/or use it for the kind of key derivation that
would be required here. In that case, the client must find somewhere
to store the DH key, which may entail significant effort.

This last point points us to a larger issue we need to consider here,
which is as follows. In TLS as it currently stands (both in 1.2 and
the current TLS 1.3 draft), you can implement a system where the
authentication keys are stored in hardware and an attacker who
compromises either the client and the server cannot steal a credential
which he can then use to establish new sessions [Note that if
he steals the session cache, he can use it to resume old sessions.]
In particular, because each signature is tied to a specific exchange,
the attacker cannot reuse signed ephemeral values to impersonate the
server.

However, in a system where the server signs a long-term DH value, it
may be the case that that value cannot be stored in the same hardware
module that you are using for your signature key (purely for
implementation reasons having to do with the interface the module
exposes). In that case, the DH secret will be stored in software and
compromise of the server potentially leaks a credential which can be
used to impersonate the server for a significant period of time, where
that time is dictated by the maximum amount of client-side clock error
the server is willing to tolerate, so probably measured in days to
weeks (and more if you are concerned about the time resetting attack
Watson, Ilari, and I were discussing.) I haven't decided yet sure how
serious an issue this is, but it's probably worth addressing
explicitly.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 2 Nov 2014 14:38:43 -0800

On Sun, Nov 2, 2014 at 2:24 PM, Hugo Krawczyk <[email-masked]>
wrote:

> protocol

I'm not sure that this is correct. If a client does a 1-RTT exchange first
(which he will have to do if he is naive about the server) then the
server can provide a semi-static DH key for future use at that time
and use a signature over the entire transcript to authenticate it, no?

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 2 Nov 2014 14:41:14 -0800

On Sun, Nov 2, 2014 at 2:28 PM, Hugo Krawczyk <[email-masked]>
wrote:

> requires dealing with wrong guesses (this only applies to the 1-RTT case
> as in

I believe the latter is the case we should optimize for, as existing
systems which
do client auth generally use signatures and so it's easier to continue to
assume
that then to expect that clients will get all-new certs. This seems like a
natural
extension of the reasoning which motivates the server signing their g^s in
your
proposal.

-Ekr

Hugo
>> PFS and

---

From: Nico Williams <[email-masked]>
Date: Mon, 3 Nov 2014 10:47:53 -0600

On Sun, Nov 2, 2014 at 4:24 PM, Hugo Krawczyk <[email-masked]> wrote:
> Don't forget that 0-RTT cannot be supported with a signature-based protocol
> so in that sense going to static DH is a win-win.

That was DJB's point a while back, and, really, this goes back to the
old AUTH_DH concept back in 1986.  It goes back further, actually,
IIUC, all the way back to DH's invention.

If you know the peer's public DH key a priori (from DNSSEC, from
/etc/publickey [who remembers that?]) then you can send one security
context establishment message and immediately start sending encrypted
and authenticated data.  You need a response message to get key
confirmation, and you can't get PFS until after consuming that
message.

(The GSS-API deals with this, incidentally.  A security context can be
partially established but ready to encrypt application data with
security caveats.  This is called "prot_ready".)

A proper static-static DH + PFS exchange would take the usual 1.5
round trips, but would be "prot_ready" in 0 round trips.

There's a lot to be said for this.  But note that RSA key transport
also lends itself to being prot_ready in 0 rt, so we still need to
quantify the total cost of static-static DH + PFS, and RSA key
transport + PFS for a proper comparison.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 3 Nov 2014 10:53:29 -0600

On Sun, Nov 2, 2014 at 4:28 PM, Hugo Krawczyk <[email-masked]> wrote:
> in other messages are indeed very important.  [...]

More reason to use DANE...  With DANE the client could find out what
groups/curves the server supports before sending the first message.

Again, AUTH_DH/mech_dh worked that way.  The client could find the
service's pubkey and group in the publickey name services database.
There was no question of in-band negotiation.  The protocol was
effectively 0rt to get started to send data, 1rt to get key
confirmation.  But it long predated DNSSEC, and has been obsolete for
a long time, though mostly for lack of being updated to use DNSSEC and
modern crypto.

Nico
--

---

From: Hanno Böck <[email-masked]>
Date: Mon, 3 Nov 2014 18:32:47 +0100

While you are discussing clock issues:
On Blackhat Amsterdam an attack on HSTS was presented involving an
NTP MitM. (code available [1])

Basically there's already a bunch of TLS related features that require
a reliable clock. And ntp is a zero-security protocol.
The issue of a secure system time needs to be adressed anyway.

I recently changed my servers from ntpd to tlsdated. That's probably
what everyone should do. (this still leaves open the question whom you
trust for your timesource - but it's certainly an improvement over
insecure ntp)

[1] https://github.com/PentesterES/Delorean
-- 
Hanno Böck
http://hboeck.de/

mail/jabber: [email-masked]
GPG: BBB51E42

---

From: Watson Ladd <[email-masked]>
Date: Mon, 3 Nov 2014 19:02:26 -0800

On Sun, Nov 2, 2014 at 2:33 PM, Eric Rescorla <[email-masked]> wrote:
>> I don't see the advantage of signatures in this case. It is possible to
>> design a

The added cost is the cost of one fixed base and one variable base
exponentiation, over the existing ECDHE.
Whether this is enough to recommend making one side sign the
transcript and other DH is a judgement call I can't make.

> the attacker cannot reuse signed ephemeral values to impersonate the

1: If ephemerals are reused, you can MITM until they are refreshed. A
time-bounded cert equivalent isn't worse in this regard.
2: "Can" is the operative word here. Many people didn't, as we learned
the hard way with heartbleed. The reason for this complex, but part of
the issue is that the spec for using hardware devices is inherently
single-threaded, so making one request per connection starts to get
old real fast. Furthermore, this proposal accommodates having the key
on a single device, no matter how many connections you want to serve,
with no downside. It makes key separation easy.
3: 0-RTT requires a certificate that can be used for encryption as
well as signing, in ways that don't interfere. We need to use a DH
share anyway for this, and might as well use it again.

> serious an issue this is, but it's probably worth addressing

I'm not sure, because it wasn't explicitly addressed in Hugo's
original email, but it seems that the relevant server question is how
long it wants to receive 0-RTT without requiring the client to find
the new address: I don't remember resumption being addressed one way
or the other. So the server isn't picking the DH share lifetime for
reasons of clock skew, but rather for PFS refreshment if 0-RTT is
being used.

Sincerely,
Watson Ladd

---

From: Hugo Krawczyk <[email-masked]>
Date: Tue, 4 Nov 2014 10:45:04 +0200

> and use a signature over the entire transcript to authenticate it, no?

​When I said that "0-RTT cannot be supported with a signature-based
protocol"
I meant to say that the key exchanged in the 0-RTT client-to-server message
(used to encrypt ClientData) cannot be authenticated by a server's
session-specific signature and therefore it must use a DH-based mechanism
(or other PK encryption). A signature by the server can still be used to
sign the
semi-static key as you point out but that's an offline signature.
Or maybe I misunderstood your point?
​

---

From: Hugo Krawczyk <[email-masked]>
Date: Tue, 4 Nov 2014 10:47:06 +0200

> transport + PFS for a proper comparison.

​The costs for the 0-RTT option in addition to the cost of an ephemeral DH
are as
follows.
DH+PFS: a single variable-base exponentiation for client and server.
RSA+PFS: for server an RSA decryption, for client an RSA encryption.
So the computational advantage of DH+PFS is very significant for the server.
For client RSA-PFS has some advantage as RSA encryption is faster than a DH
exponentiation but the difference is less dramatic than for the server, in
particular considering that the client is already doing two DH
exponentiations.
In addition, RSA encryption requires added protocol operations (and
implementation care) to prevent Bleichenbacher attack (e.g., you'll need to
dummy-decrypt ClientData even if the received ciphertext is illegal).
And aren't we in the process of phasing out RSA wherever possible?
​

​Hugo
​

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 4 Nov 2014 06:12:31 -0800

On Mon, Nov 3, 2014 at 7:02 PM, Watson Ladd <[email-masked]> wrote:

> > On Sun, Nov 2, 2014 at 2:05 PM, Hugo Krawczyk <[email-masked]>>

I'm not following your reasoning here. For convenience, let's
restrict ourselves to thinking about 1-RTT handshakes. With
TLS 1.2 (or the current TLS 1.3 draft), the server can stop future clients
from accepting any DH share simply by refusing to sign any
further handshakes with that share. If, for instance, it determines
a share has been compromised, it can prevent any new connection
initiations with that share. By contrast, with a time-bounded
cert, an attacker can get clients to continue using that share until
the time expires (or perhaps longer, as you suggested elsewhere).

The situation is of course somewhat more complicated with 0-RTT
because the server must provide the client with a DH share which
he can use for future connections. However, he need not provide
every client with the *same* key, and if the key is authenticated
as part of the initial connection establishment, an attacker cannot
convince other clients to use that key. This is not true with certificates
(or of statically signed keys) which are inherently portable.

> share anyway for this, and might as well use it again.

I'm not sure I follow what you're saying here either. It's true that the
server needs to supply a semi-static DH share, but there's no inherent
reason it needs to be supplied as part of a free-standing transferrable
credential such as a certificate, though of course doing so allows you
to amortize the signature.

> reasons of clock skew, but rather for PFS refreshment if 0-RTT is

I think we may be talking past each other. Let me try again.

Forget about 0-RTT and just consider the 1-RTT flow. In the first flight
the server needs to supply a signed version of g^s. Unless we want
that value to be acceptable to clients indefinitely, it must have some
validity interval. However, because clients have inaccurate clocks,
that interval can't be too narrow or it will cause clients to reject the
g^s value. I'm not sure how narrow it can be, but I would be surprised
if it were less than 12 hours or so. Perhaps someone who runs a
large server farm can report on the values they have historically
seen in the GMT field of the ClientRandom.

-Ekr

---

From: Hugo Krawczyk <[email-masked]>
Date: Wed, 5 Nov 2014 18:27:52 +0200

The issue of validity period of the static key g^s is not different than
that of a regular certificate except that the server can choose a shorter
validity period for g^s than the one for the certificate. That is, if the
client's clock is skewed by Delta and the validity of g^s is up to time T,
the client will accept g^s till time T+Delta. Similarly, if the certificate
expires at time T', the client will accept it until T'+Delta. In either
case, if T<T' the client will accept g^s for less time than it would accept
the certificate.

(Needless to say, a client should not accept a signed g^s past the
expiration date of the certificate signing g^s).

Am I misunderstanding/missing something?

Hugo

---

From: Martin Thomson <[email-masked]>
Date: Wed, 5 Nov 2014 09:45:27 -0800

> Am I misunderstanding/missing something?

I think that the core concern is that Delta is basically unbounded in
some implementations (see [1]).

To make realistic progress on TLS, I think that we have to consider
this as either basically impossible to fix, or as a problem that will
be solved somewhere else.  That means, that until it is solved, we
should instead acknowledge the problem and move on.  It's a problem
worth solving, but we could waste a lot of time on it.  If someone
solves it, then we can react appropriately at that time.

[1] https://www.blackhat.com/docs/eu-14/materials/eu-14-Selvi-Bypassing-HTTP-Strict-Transport-Security-wp.pdf

---

From: Nico Williams <[email-masked]>
Date: Wed, 5 Nov 2014 11:51:26 -0600

On Wed, Nov 5, 2014 at 11:45 AM, Martin Thomson
<[email-masked]> wrote:
> [...]

Perhaps we should pin latest datetime advertised by the server for
which other things are being pinned.  This would prevent time travel
into the past.  Time travel into the far future is, presumably, not
that big a deal, even with pinning, because server operators will
strive to make sure that doesn't happen.

Nico
--

---

From: Watson Ladd <[email-masked]>
Date: Wed, 5 Nov 2014 09:56:50 -0800

On Nov 5, 2014 9:51 AM, "Nico Williams" <[email-masked]> wrote:
> > [1]
https://www.blackhat.com/docs/eu-14/materials/eu-14-Selvi-Bypassing-HTTP-Strict-Transport-Security-wp.pdf
> strive to make sure that doesn't happen.

Or kernels can set the flag that stops this from being possible. We should
note the issue, and, as with randomness, let the vendors solve it.

For a problem solved by a configuration change,  we are spending a lot of
time on it.

Sincerely,
Watson Ladd

---

From: Nico Williams <[email-masked]>
Date: Wed, 5 Nov 2014 12:01:07 -0600

> note the issue, and, as with randomness, let the vendors solve it.

User-land code can "correct" kernel time.  For example, most Kerberos
libraries record time offset between the client and the KDC, and
correct local time when making AP-REQs for any service subsequently.
Clients trust KDCs, so that's OK.

But if TLS clients also attempt to correct local clocks on the basis
of time advertised by arbitrary servers...  Obviously, that's the
problem: TLS clients should not use the TLS protocol to attempt to
correct local clock skew.

Nico
--

---

From: Watson Ladd <[email-masked]>
Date: Wed, 5 Nov 2014 21:58:27 -0800

> correct local clock skew.

??

No, the issue is that an attacker can fool NTP clients, and thus
change the time on a computer. All we need to do is note the need for
secure clocks, and let the implementor figure out how to get the right
time. If there is an issue with NTP security, and there is, that's for
the NTP WG to solve. That may be an OS issue: the same is true for the
generation of random numbers. We already depend on secure time for
OCSP stapling and certificate validity: I don't think Hugo's proposal
is worse in that regard. We need to document the dependency, but
whether water clock, sundial, atomic clock, pendulum clock, or RTC on
the motherboard, we don't care how that is satisfied. Martin Thompson
makes this same point upthread.

I think the OPTLS proposal makes it extremely easy to host servers
worldwide while keeping the certificate in a nice jurisdiction, or on
a slow HSM while enabling performance enhancements as computers get
faster. I think it resolves many longstanding security issues, and
doesn't introduce any obvious new ones. (Of course, the cross-protocol
attacks may be an issue: why data signed with the same key doesn't
have a type pre-appended to it in the form of a UUID or similar is
beyond me)

It provides most of the tricky requirements like 0-RTT and privacy of
certificates. It's genericly secure. It's a performance enhancement
for sites that have avoided PFS until now because of performance
issues. There's plenty of details to flesh out, and it may be that we
find showstoppers that make the entire approach not work. But it would
be a shame if we wasted another 6 months getting to this point by
patching a protocol that is extremely hard to think about: there isn't
a 0-RTT proposal on the table yet beyond this one.

We still need to decide some details if we move forward, and hammer
out the serialization and interaction with the TLS 1.2 negotiation
that ensues when a TLS 1.3 hello is sent to a TLS 1.2 server (do we
share group specifications? which extensions make sense and which
don't? are ciphersuites going to be shared across the Client Hello?
How do signature groups relate to the DH groups?) If I could start
with a clean slate, it would be with this proposal. Yes, it's a major
change. It doesn't solve all our problems. Some semantics,
particularly around client authentication, will likely change.
However, it has the great benefit of existing, and I hope we decide to
build on it or find flaws that doom it.

Sincerely,
Watson Ladd

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 5 Nov 2014 22:54:11 -0800

> Am I misunderstanding/missing something?

I'm not sure.

The point I was trying to make below is that there are settings in which the
signing key is stored in an HSM but the DH share cannot. In those cases,
there is an additional risk of compromise of the machine holding the DH
share, which can steal the share but cannot steal the signing key
(because of the HSM). I agree that this is partially ameliorated by
having g^s be only valid up to the expiry of the certificate, but since
certificate lifetimes are generally long, only partially so, especially
since
if the signing key is online (as will be required for TLS 1.2 compat)
compromise of the machine will let you sign a DH share with a very
long lifetime.

is that clearer?

-Ekr

---

From: Hugo Krawczyk <[email-masked]>
Date: Thu, 6 Nov 2014 11:34:34 +0200

I agree that when a signature key is better protected than the static DH
key, requiring a fresh signature in each session is better. I assume that
there is no fundamental reason not to have the static DH key in the HSM
other than the fact that this capability is not supported in current HSMs.
We are in a transition period and there are some costs associated to it,
but we should not tie ourselves to the past for this reason. This is a
forward-looking proposal. Besides, it also has advantages regarding the
security of long-term signature keys which need not be online for signing
each exchange.

Regarding the problems with insecure time, it seems that we are reaching
agreement that this should not be a distraction for judging this proposal
(in particular since it does not make things worse than the reliance of
time synchronization for accepting certificates - and it can actually make
things better by having shorter validity periods for the static DH key than
for the long-term certificate).

​​
BTW, I have not mentioned one advantage of removing online signatures from
​ the protocol: It provides plausible deniability of an exchange. In
contrast, with per-exchange signatures that sign all the handshake
messages, you also sign your peer's identity, hence leaving a proof that
you communicated with that peer. The deniability property of OPTLS can be
claimed similarly to that of SKEME as in
http://eprint.iacr.org/2006/280.
This is an additional privacy-protecting aspect of the protocol in addition
to identity encryption and forward secrecy.

Hugo​

---

From: Martin Thomson <[email-masked]>
Date: Thu, 6 Nov 2014 09:05:56 -0800

On 6 November 2014 01:34, Hugo Krawczyk <[email-masked]> wrote:
> (in particular since it does not make things worse than the reliance of time
> synchronization for accepting certificates - and it can actually make things
> better by having shorter validity periods for the static DH key than for the
> long-term certificate).

I think that, based on this discussion, I've concluded that there
needs to be some sort of expiration bound to the signature over g^s.
That at least allows servers to limit the duration of an exposure in
the cases where g^s has to reside outside the HSM.  At worst, the only
concern is clock skew if the server wants to closely replicate online
signing.

Adding an expiration is a fairly trivial tweak.  Other than that, I
think that I'm happy with this being - on balance - worth doing.  I
haven't made up my mind whether the lack of a signature over a peer's
credentials is a good or bad thing entirely.  I like the idea of
deniability, but non-repudiation in general is a hazardous business.

---

From: Andy Lutomirski <[email-masked]>
Date: Thu, 06 Nov 2014 18:41:57 -0800

> option, and a simple extension without signatures for client authentication.

I like this idea a lot.

> Note on certificates: Since in current practice servers hold
> certificates for
> advantage that these keys can be changed often to increase security against

I would like to see one modification of this: I think that the
certificate should be (RSA/ECDSA certificate, server's long-term DH
share, expiration), signed by the cert.  That way any user of a
certificate can sign short-term shares instead of long-term shares,
significantly reducing the impact of a leak.

It would be even better if there were a way to limit one of these things
to a certain host.

That being said, I do have one significant concern with this: what
happens when someone builds a quantum computer?  I don't expect TLS 1.3
to be post-quantum secure, but I would like the road to replacing
primitives for post-quantum security to be reasonably clear.

Unfortunately, I'm not aware of a credible post-quantum DH-like
construction.  On the other hand, post-quantum signatures are
straightforward if rather large right now, and post-quantum public-key
encryption is, as far as I remember, not guaranteed to be a drop-in
replacement for DH.

Will this end up being a problem?

--Andy

---

From: Watson Ladd <[email-masked]>
Date: Thu, 6 Nov 2014 21:45:20 -0800

> significantly reducing the impact of a leak.

Note that in the above proposal, long-term can be entirely defined by
the server or client as the case may be. I feel I'm missing something
here.

> It would be even better if there were a way to limit one of these things

The client cert that is? I'm not sure what this gets you: we know how
to use certs securely.

> Will this end up being a problem?

If supersingular isogeny volcanoes are secure, it won't be a problem.
NTRU for old TLS is also a possible backup plan.

---

From: Andy Lutomirski <[email-masked]>
Date: Thu, 6 Nov 2014 22:21:26 -0800

> The client cert that is? I'm not sure what this gets you: we know how

Sorry, I wasn't very clear.  My thought is that, if we're going to
introduce a new object signed by the PKIX cert, such that a server
only needs the private key associated with that object and not the
certificate's private key, then we should take advantage of this to
add some features.  In particular, we should let it expire before the
certificate, and I think we should allow it to be pinned to a
particular hostname or maybe set of hostnames.  The former was covered
elsewhere in this thread.  The latter was not.

Also, ha ha ha ha.  We know how to user certs securely.  Yeah, right.

If I buy a cert for *.my.domain, I want to be able to provision
foo.my.domain with some secret that lets it act as foo.my.domain but
not bar.my.domain.  Since the PKIX people seem to be completely unable
to address this, pinning DH shares to a domain would solve the problem
without involving any PKIX changes.

> NTRU for old TLS is also a possible backup plan.

The former is a big if, and it makes me nervous to say that, if
someone builds a quantum computer, that TLS 1.2 might be better than
1.3.  And my inner pundit expects NTRU to fail as soon as anyone
pushes it hard.

That being said, this may not be a big deal -- I suspect we'll have
*something* that fits in this framework.

--Andy

---

From: Hugo Krawczyk <[email-masked]>
Date: Fri, 7 Nov 2014 10:32:36 +0200

Regarding the post-quantum question below: Any public key encryption (PKE)
mechanism can be used for PFS, you just need to generate session-specific
private-public key pairs and use them for that session only. So any
quantum-resistant PKE (QR-PKE) scheme can be used for PFS. More
fundamentally, digital signatures do not suffice for key exchange. You need
a  PKE, or similar mechanism, to actually exchange the key (signatures are
only good for authenticating the exchange). Once you have a QR-PKE, you
replace the key g^{xs} in OPTLS with an encryption of a random key under
the server encryption public key and use this random key for computing the
Finished message.

By the way, I am personally more concerned about the possibility of a
significant advance in (classic) ECC cryptanalysis in the near-medium
future than with a practical-enough quantum machine that can break the ECC
cryptography. In particular, progress in quantum will most likely be
gradual and will give us time to prepare the next-generation QR
cryptography while a mathematical break of ECC could happen overnight (or
over several nights :). For all we know, it might have already happened...
(I guess one can say that someone might have already built a quantum
computer but to me that looks much more unlikely).

Hugo

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sat, 08 Nov 2014 11:06:30 -0500

> compromise of the machine will let you sign a DH share with a very

It's conceivable that the online key for TLS 1.2 compatibility could be
one that is not the same as one that is used for signing g^s.

To achieve this separation of purpose, though, we'd need to be able to
distinguish between certificates capable of anchoring the end entity in
a TLS 1.2 session and certificates capable of certifying a long-term
g^s.  Making these distinguishable would probably require a new X.509v3
extension, or extendedKeyUsage.

So we're back to fiddling with X.509, if we want to avoid the described
attack :/

       --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sat, 08 Nov 2014 10:20:38 -0500

> without involving any PKIX changes.

If we could provide this, it could be a very interesting operational win
in the context of expensive/cumbersome CAs and medium-sized
organizations with many services (internal and external).

It would effectively allow a wildcard cert for a given domain to act as
a domain-constained sub-CA, without getting into the X.509 weeds about
domain constraints.  The secret key material corresponding to the
wildcard cert could be kept offline, and used to issue medium-term DH
shares that are distributed to each service.

Unfortunately, i don't see a way to deploy this effectively without
putting the secret key material associated with the wildcard cert online
for each service that needs to support legacy clients, which would make
the security advantage moot.

    --dkg

---

From: Martin Thomson <[email-masked]>
Date: Sun, 9 Nov 2014 11:25:27 -0800

> extension, or extendedKeyUsage.

There may still be operational advantages: you could issue the 1.2
cert with a shorter lifetime and the 1.3 cert with a longer one.

Mucking with X.509 would probably make this harder than its worth, I think.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 10 Nov 2014 12:23:33 -1000

> cert with a shorter lifetime and the 1.3 cert with a longer one.

I'm not sure i understand this suggestion (it may be moot since it
sounds like we're not considering this approach for 1.3 anyway after
yesterday's interim discussion about the risks of introducing delegation
in this fashion).

> Mucking with X.509 would probably make this harder than its worth, I think.

i agree that X.509 is a disaster here, but i think making up a new
delegation protocol won't necessarily be a non-disaster -- we could
instead just rehash some of the sharp bits of the X.509 mess
(revocation, duration, transparency, identity, etc) in a different
format if we're not clear about what we're doing :/

           --dkg

---

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Nov 2014 15:30:17 -0800

> format if we're not clear about what we're doing :/

Prior to the discussion yesterday, I was really warming to this idea.
After it, particularly the discussion around the creation of a
delegation point, I think that I've been convinced that we shouldn't
do this.

Aside fro the delegation advantage, the real benefits of this are
largely seen in the short term for RSA certificates.  Moving to ECDSA
obviates one of the big performance advantages, and the concerns
around getting delegation right make me now against pursuing this.

I don't think that this is categorically bad, or that we should not do
this ever, but it's a big change and one that is much harder to get
right than I originally thought.

---

From: Watson Ladd <[email-masked]>
Date: Mon, 10 Nov 2014 15:45:58 -0800

> delegation point, I think that I've been convinced that we shouldn't

Every 0-RTT solution involves a similar delegation, as the client is using
data sent from the server in the prevoius interaction or OOB to encrypt the
early data.

What exactly was the problem mentioned at the meeting?

> right than I originally thought.

So what is the alternative exactly? Is it hacking 0-RTT and 1-RTT modes
onto TLS 1.2 and hoping miTLS fixes the mistakes?

ECDSA only obviates the performance advantage for genus 1. For genus 2 is a
different story. Furthermore,  eliminating online certificates enables
isolation of certs without a performance penalty.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 10 Nov 2014 14:05:31 -1000

> data sent from the server in the prevoius interaction or OOB to encrypt the
Well, perhaps.

It's quite possible to have the server deliver a key in the initial
handshake that
is usable by the client for future handshakes. However, if the
authentication
of that key is part of the initial handshake (e.g., it's signed as part of
the
transcript), then the key won't be usable by other clients [or more
accurately,
the client won't be able to hand it to other clients and get them to use
it].

I suppose you could argue that this is a delegation, but if so it's a
different
sort of delegation than producing a freestanding credential that can be
given out to any new client.

-Ekr

---

From: Yoav Nir <[email-masked]>
Date: Mon, 10 Nov 2014 14:08:06 -1000

> On Nov 10, 2014, at 1:45 PM, Watson Ladd <[email-masked]> wrote:
> 
> 
> On Nov 10, 2014 3:30 PM, "Martin Thomson" <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > On 10 November 2014 14:23, Daniel Kahn Gillmor <[email-masked] <mailto:[email-masked]>> wrote:
> Every 0-RTT solution involves a similar delegation, as the client is using data sent from the server in the prevoius interaction or OOB to encrypt the early data.
> 

The issue is that the server sends a certificate + a buffer that is a long-term DH public key signed with the private key associated with the public key in that certificate. 

Anyone who has that certificate and buffer plus the long-term DH private key can impersonate the server. It’s delegation in the sense that the server can sign a DH public key and let another node impersonate it. 

So the argument against it is that the new signed buffer is in effect a credential, a certificate. Except that this kind of certificate does not have the PKIX stuff. Specifically, there is no revocation for that signature. A compromised signed  DH public key can only be revoked by revoking the certificate.   As we are not currently prepared to work on TLS delegation, we don’t want to sneak delegation in through the back door.

It should be noted that CloudFlare manages to make delegation work ([1]) even without changing the protocol, but I wonder a little about that solution. Isn’t the latency horrible? How secure is the connection between CloudFlare and the customer? Does it create a sign-everything service?

Yoav

[1] http://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-technical-details/

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 10 Nov 2014 14:15:34 -1000

On 11/10/2014 01:45 PM, Watson Ladd wrote:
> Furthermore,  eliminating online certificates enables

if we get people to move their secret keys offline by replacing certs
with something that is cert-equivalent for purposes of authentication,
then what have we gained?

The reason to move secret keys offline is to protect the identity
credentials of the TLS endpoint, not because those keys are valuable in
themselves.  If a delegation process creates a new object that is an
identity credential for the TLS endpoint, and the secret part of that
object remains online, we haven't actually gained anything.

Note: we *could* gain something, of course, if we manage to clearly and
effectively scope the utility of the delegated credential more narrowly
than the parent credential; then moving the wider-scoped parent
credential's secrets offline is indeed a win.

But it's not clear how to do that kind of scoped delegation correctly --
or even what forms of scoped delegation are desirable -- do we want to
narrow the scope by time?  by identity?  by network address?  by protocol?

If someone wants to work on delegation in its own right, i think that
could be useful.  But adopting delegation "by accident" while we're
defining a new key exchange mechanism seems likely to get us into worse
trouble down the road.

	--dkg

---

From: Nico Williams <[email-masked]>
Date: Mon, 10 Nov 2014 18:19:32 -0600

On Mon, Nov 10, 2014 at 02:08:06PM -1000, Yoav Nir wrote:
> The issue is that the server sends a certificate + a buffer that is a
> long-term DH public key signed with the private key associated with
> the public key in that certificate. 
> 
> Anyone who has that certificate and buffer plus the long-term DH
> private key can impersonate the server. It's delegation in the sense
> that the server can sign a DH public key and let another node
> impersonate it. 

Session tickets too are a form of delegation, with narrower scope (just
one client).  But surely clients won't be sharing these delegated DH
pubkeys with each other?

This sort of delegation is probably a fine thing, except that:

> So the argument against it is that the new signed buffer is in effect
> a credential, a certificate. Except that this kind of certificate does
> not have the PKIX stuff. Specifically, there is no revocation for that
> signature. A compromised signed  DH public key can only be revoked by
> revoking the certificate.   As we are not currently prepared to work
> on TLS delegation, we don't want to sneak delegation in through the
> back door.

it needs to have an explicit notAfter date, that needs be in the near
future.  The acceptable lifetime of a delegated server pubkey should be
comparable to the acceptable lifetime of a session ticket, and both
should be relatively short (hours, not days, and certainly not weeks).

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 10 Nov 2014 18:30:00 -0600

On Mon, Nov 10, 2014 at 02:08:06PM -1000, Yoav Nir wrote:
> It should be noted that CloudFlare manages to make delegation work
> ([1]) even without changing the protocol, but I wonder a little about
> that solution. Isn't the latency horrible? [...]

Session resumption makes up for it, amortizing the impact on the user.

It's probably no worse (typically) than 2 or 3x the normal latency, for
the first connection (or first handful of concurrent connections).  It'd
be interesting to see how noticeable this is, but I suspect that on the
whole it's not really all that noticeable.

>                                      [...] How secure is the
> connection between CloudFlare and the customer? [...]

In principle it should be no less secure than TLS itself.  (I've not
looked closely enough, but I imagine that's exactly what CloudFlare uses
for their connection to their customers' key sign server.)

>                                           [...] Does it create a
> sign-everything service?

Yes, which is why you need to get authentication (of CloudFlare to the
key server) right, so you can authorize key sign requests.  And the
customer should be doing this with server names and certs and keys that
are only for the CloudFlare use anyways.

This brilliantly lets CloudFlare out of the business of having certs
with lots of names, and it simplifies key management for their
customers.  The price is that this requires SNI.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 10 Nov 2014 18:52:22 -0600

> then what have we gained?

The ability to use cheaper, lower-performance HSMs, for one (maaaybe,
and only where one was using an HSM to begin with).  Or, put another
way, to handle more connections with a given HSM investment.  It's not
nothing.  But see below!

> object remains online, we haven't actually gained anything.

The delegation has to have a short lifetime because otherwise it
might as well be a certificate issued by an intermediate CA...

...which the customer can't get because of the failure to widely
implement and deploy PKIX name constraints.

But also because of revocation: if you have to check the status of the
key then you lose the 0rt.

By putting a short lifetime on the delegation that problem goes away.
But then there's no advantage over plain session resumption.

Even if each 0rt connection can lengthen the delegatee key's life by
having the server send a fresh signature of the key as needed, the
server could also just refresh the session resumption state/ticket.

IMO the main value in static DH is in learning the server's static DH
pubkey out of band, via DNSSEC (DANE).  That eliminates all these
concerns while enabling 0rt connections _every_ time for servers that
have such keys.

Of course, 0rt connections can't provide proper PFS to data sent
immediately after the client's first TLS handshake message.  That's a
problem, no?

Nico
--

---

From: Yoav Nir <[email-masked]>
Date: Mon, 10 Nov 2014 15:53:35 -1000

> On Nov 10, 2014, at 2:52 PM, Nico Williams <[email-masked]> wrote:
> 

How short is “short”? This is yet another thing that is hosed by the non-availability of a secure time signal. Clocks are skewed, so if you use a notAfter date that is less than 24 hours away, you’re going to have clients thinking that this has already passed. 

Sure, we MUST fix time. But we also MUST fix PKIX name constraints, and I think we’re close to solving the latter than we are to solving the former.

> concerns while enabling 0rt connections _every_ time for servers that

This assumes a deployed DNSSEC. That will happen some time after the secure time signal.

> immediately after the client's first TLS handshake message.  That's a

I guess you can’t have everything. 

Yoav

---

From: Nico Williams <[email-masked]>
Date: Mon, 10 Nov 2014 20:12:04 -0600

On Mon, Nov 10, 2014 at 03:53:35PM -1000, Yoav Nir wrote:
> How short is “short”? This is yet another thing that is hosed by the
> non-availability of a secure time signal. Clocks are skewed, so if you
> use a notAfter date that is less than 24 hours away, you’re going to
> have clients thinking that this has already passed. 

The time should be relative, as a TTL.

"This resumption ticket is good for 2 hours."

"This DH pubkey is good for 2 hours."

"hours" is good.  "days" is not.

That's good enough.  The items in question should be stored in memory
(tmpfs, ...), not stable storage anyways, so all that matters is that
time tick somewhat accurately for that TTL, unless the client reboots.

> Sure, we MUST fix time. [...]

Not for this.

> This assumes a deployed DNSSEC. That will happen some time after the

Maybe, but until and unless we convince ourselves that these delegated
DH pubkeys can have lifetimes much longer than session resumption state
tickets... then there doesn't seem to be much value in static DH here.

> I guess you can’t have everything. 

API-wise we can: you can have integrity and confidentiality protection
immediately, but PFS not until you consume the server's handshake
message.  (The GSS-API pretty much deals with this in the context of
authentication state, and it'd take adding a boolean flag to do the same
for PFS.)

The problem is that HTTP can't know if the data to be sent is sensitive,
and probably neither can the user-agent.  They have to assume it's all
sensitive.  If you want PFS you have to settle for either: a) (EC)DHE
and no 0rt every time, or b) (EC)DHE and no 0rt occasionally + 0rt w/
session resumption w/ short-lived sessions.

Nico
--

---

From: Watson Ladd <[email-masked]>
Date: Mon, 10 Nov 2014 21:00:06 -0800

> But then there's no advantage over plain session resumption.

Can we make 0-RTT resumption? Snap start doesn't do this, and my
proposal from the summer to do this was thought to not be that great.
I'll look up exactly what was wrong and try to fix it. This may work
better than general 0-RTT exchanges, if delegation is considered to be
a problem.

I do see a benefit, which is that session resumption as currently
envisioned involves keeping keys around that can decrypt old data.
Changing this means that TLS 1.3 resumption works differently than TLS
1.2 resumption, which isn't a problem. We should at minimum fix this
PFS failure.

> concerns while enabling 0rt connections _every_ time for servers that

So we have a root cert with RSA 1024 bit RSA, or the same delegation
point issue. It doesn't eliminate revocation concerns either: DNSSEC
doesn't guarantee liveness. (DNS can have dynamic data, but the size
is strictly limited, so stuffing a cert chain in is a bad idea).

> immediately after the client's first TLS handshake message.  That's a

They can limit the time the key is around, so an attacker has a narrow
window to steal the keys.

There is another set of advantages beyond those mentioned above: TLS
1.2 is annoying to think about for technical reasons, whereas OPTLS
had a good chance of avoiding those. We need to actually design a
secure protocol, not just spray and pray as we have in the past. There
was a 20 year gap between TLS 1.0, and the definitive security
analysis, which discovered new attacks, and is dependent on tool
support. A TLS 1.3 based on TLS 1.2 runs a risk of having significant
security holes in new features unless we take care to do the analysis
before deploying.

I feel the delegation problem was clearly spelled out in Hugo's
message describing the protocol. What I don't understand is why it is
a problem to have a duration-limited credential equivalent in power to
a certificate. Since there is no recording, I can't figure out what
was said and what convinced everyone this was a bad idea.

I've looked at the minutes but they are extremely sparse. What was the
worry associated with complicating the key schedule? Can someone
summarize the argument about delegation, so I can figure out if it
convinces me or not?

Sincerely,
Watson Ladd

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 10 Nov 2014 19:51:25 -1000

> The time should be relative, as a TTL.

relative to what?

If the credential is standalone (e.g. in such a way that the signing key
can be kept offline) then the TTL established can be replayed by an
attacker who takes control of the DH secret to extend the lifetime of
the delegated credential, right?

if the credential isn't standalone (i.e. if it's accepted by the client
based on its inclusion in the signed handshake which has been
authenticated by a signature from the signing key), then we aren't in a
signature-less TLS scheme.

if it's not relative, but it's long-lived, then we introduce a new
revocation problem.  if it's not relative and it is short-lived, then we
introduce interesting clock skew issues (though perhaps those are the
same as OCSP-must-staple clock skew issues?)

None of this is to say that delegation is a terrible idea, but just that
the details matter and it's not something to casually adopt without
understanding the tradeoffs we're taking.

and those tradeoffs are complex enough that they seem to overwhelm the
possible performance gains from the OPTLS proposal.  (esp. when there
are other ways like ECDSA certs that give comparable performance gains).

> "hours" is good.  "days" is not.

I agree that short-lived is nice; I think it also possibly removes the
pro-OPTLS argument about keeping the signing keys offline.  (maybe
that's ok)

But without a concrete specification of what the delegation mechanism
looks like, the properties of the deployed proposal end up being very
different.

	--dkg

---

From: Hugo Krawczyk <[email-masked]>
Date: Tue, 11 Nov 2014 09:46:38 -0500

Wait, wait, wait...

I am surprised to see such an abrupt decision to drop consideration of
OPTLS. There is little information in the minutes as for the rationale for
this move although it seems to be entirely based on the handling of
static-DH certificates and the understanding that in the future one can
still run TLS 1.3 with ECDSA and/or ECDH certificates.

Let me address these issues and the multiple advantages of OPTLS that need
to be considered. Please bear with me in spite of the long email. Since I
will not be in Hawaii (I wish I was...) take this in lieu of a presentation
at the WG meeting (and pardon the advertisement pitch, I believe it is fair
and well-founded).

First, note that if we had ECDH certificates then this whole issue of how
to sign the static DH key g^s would be moot. You would use that certificate
to vow for the server's static DH key. Security would be based on the
protection of s exactly as it is based on the security of a private signing
key today. In particular, the key s would need to be kept online with the
same vulnerabilities (and potential protection) of a signing key today.

The whole reason to create a "sub-certificate" for g^s by signing it with
the server's certified signature is that we currently only have
certificates for signature keys, not ECDH. This may or may not change in
the future - actually, as I argue below, there are advantages of sub-certs
for g^s over a long-term ECDH certificate.

So what is the concern that has been voiced regarding the use of sub-certs
for g^s? That the leakage of a private key s that was sub-certified allows
to impersonate the server for the validity period of that sub-certificate,
and that clients with skewed clocks will be accepting it beyond the
intended validity period. This is true but not different than the situation
with current certificates. In particular, the validity period of the
sub-cert will never exceed that of the signing certificate. How about
revocation? It requires the main certificate revocation exactly as needed
now.

So none of these issues is worse than vulnerabilities of signing keys today.
Actually, there are two non-trivial advantages to the sub-cert approach:
 - clients with good clocks (or small skews) will not accept g^s much past
its validity period, which would be typically much more limited than the
main signing cert. Clients with terrible skews will never be in worse shape
than they are today with respect to validating the signing certificate.
-  a server can issue multiple g^s keys for availability, distribution,
sub-domain use, etc. and to support different groups ECDH groups - which
need to be supported anyway for PFS also in a signature-based protocol.
(There is also the ability to support online retrieval of currently
validated sub-certificates via protocols such as DNSSEC or other specific
mechanisms, even though there seems to be little enthusiasm for this
option, at least currently)

The only downside I can see for sub-certification of g^s is for cases where
protection of an online signature key (as needed today) is better than the
one affordable to the key s, e.g. with current HSMs that support signing
but not ECDH. But this is the price of a looking-forward transition period
as opposed to proposals that keep us tied to the sub-optimality of past
solutions. It needs to be considered in light of the many advantages of a
signature-less protocol as claimed here.

Let me now address the claim that in the future we will have ECDSA
certificates which would enable a signature-based protocol with less cost
than RSA signing today. This claim is mostly true but ignores some
important aspects of the use of ECDSA:
- The wide use of RSA in certificates is not going away any time soon - so
the very significant performance advantages of OPTLS vs a RSA-implemented
signature-based protocol is going to be enjoyed for long time (actually, it
may be a main motivation for adoption of signature-less TLS 1.3 in addition
to PFS)
- The total time of sign+verify in ECDSA is larger than the time of
static-DH authentication used in OPTLS.
- ECDSA presents definition and implementation complexities that do not
exist with ECDH, in particular tied to specific EC groups. In particular,
this is likely to postpone adoption of ECDSA.
- Online ECDSA signatures amplify the vulnerability of the long-term ECDSA
signing key to the leakage of ephemeral values (in ECDSA, as in other
Schnorr-like signatures, there is a per-signature random value that if
revealed, it fully reveals the long-term private signing key). Such
vulnerability does not exist in OPTLS.
- Signature-less protocols have a privacy advantage in providing plausible
deniability, especially when compared to protocols (as current 1.3) that
sign the peer's identity (I wrote on this in a previous message to this
list).
In addition, signature-less protocols can take advantage of sub-certs as
noted above. Even when the algorithm to sign these sub-certs will be ECDSA,
it will allow the use of Offline ECDSA hence ameliorating the above
vulnerability of ECDSA to ephemeral disclosure.

And now to summarize some of the general advantages of ECDH-based (and
signature-less) protocols and some specific advantages of OPTLS:
- 0-RTT support required static ECDH keys (or semi-static, exactly as in
OPTLS) - thus in a signature-based protocol this support would be pure
overhead
- Critical performance gain relative to per-session signing with RSA (an
advantage that will most probably stay with us for long time)
- Compatibility with the already needed mechanisms to provide PFS (hence
amortizing any cost of the underlying crypto)
- Compatibility with pre-shared key authentication: simply replace g^{xs}
with PSK.
- Cryptographically, it relies on the ECDH security of the underlying EC
groups rather than relying on this security PLUS the security of signatures
(which means relying on the weaker of the two primitives)
- Other advantages mentioned above: Sub-cert time limitation and support
for multiple static ECDH keys if so desired, specific advantages with
respect to ECDSA-based protocols (complexity of ECDSA and vulnerability to
ephemeral information), privacy via deniability, offline signatures
(specially significant with ECDSA).

Finally, the advantage of a protocol built with cryptographic logic, not as
a accidental result of many years of patches. I believe the WG has delayed
or never implemented in the past significant changes such as
Encrypt-the-MAC, OAEP, CBC IVs, session binding, etc. This time we can make
it right from the begining.

Hugo

---

From: Watson Ladd <[email-masked]>
Date: Tue, 11 Nov 2014 06:59:36 -0800

On Tue, Nov 11, 2014 at 6:46 AM, Hugo Krawczyk <[email-masked]> wrote:
> First, note that if we had ECDH certificates then this whole issue of how to
> sign the static DH key g^s would be moot. You would use that certificate to
> vow for the server's static DH key. Security would be based on the
> the server's certified signature is that we currently only have certificates
> for signature keys, not ECDH. This may or may not change in the future -
> actually, as I argue below, there are advantages of sub-certs for g^s over a
> long-term ECDH certificate.
>
> and that clients with skewed clocks will be accepting it beyond the intended
> validity period. This is true but not different than the situation with
> current certificates. In particular, the validity period of the sub-cert
> will never exceed that of the signing certificate. How about revocation? It
> requires the main certificate revocation exactly as needed now.
>
> mechanisms, even though there seems to be little enthusiasm for this option,
> at least currently)
>
> one affordable to the key s, e.g. with current HSMs that support signing but
> not ECDH. But this is the price of a looking-forward transition period as
> opposed to proposals that keep us tied to the sub-optimality of past
> than RSA signing today. This claim is mostly true but ignores some important
> aspects of the use of ECDSA:
> - Other advantages mentioned above: Sub-cert time limitation and support for
> multiple static ECDH keys if so desired, specific advantages with respect to
> ECDSA-based protocols (complexity of ECDSA and vulnerability to ephemeral
> information), privacy via deniability, offline signatures (specially
> significant with ECDSA).
>

I agree with what you say here: we need to get it right.

However, EKR privately pointed out the following: once TLS 1.3 based
on OPTLS is deployed, a user of TLS 1.2 who puts their private key in
an HSM has a problem. If an attacker gains control of the box
connected to the HSM they can sign a credential that permits permanent
impersonation, and can do so even without the user upgrading to TLS
1.3.

I don't think this is a major problem, and if we address it, it should
be by designing a protocol that avoids it, not by hacking and patching
TLS 1.2.
Sincerely,
Watson Ladd

---

From: Nico Williams <[email-masked]>
Date: Tue, 11 Nov 2014 10:50:24 -0600

> > The time should be relative, as a TTL.

Relative to the time the server made the signature.  The signature might
need to be taken over a payload that includes a timestamp (see NTP
thread) and/or a nonce from the client.

> the delegated credential, right?

It has to be tied to the delegation act, the signature made with the
delegator credential.

> signature-less TLS scheme.

Well, sure we are: most of the time, just not all of the time.

> same as OCSP-must-staple clock skew issues?)

Right.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 11 Nov 2014 11:19:38 -0600

> proposal from the summer to do this was thought to not be that great.

TLS session resumption with tickets looks almost exactly like Kerberos,
and Kerberos definitely supports a 0rt mode: you send the AP-REQ and
immediately start sending protected data, and when the server sends an
AP-REP you switch to a new set of session keys.

In the Kerberos case there's an understanding that there's been no key
confirmation until you get the AP-REP.

The GSS-API calls this understanding "prot_ready": the security context
is ready to provide data protection services, but it's not fully
established therefore it's not safe to assume that both peers are fully
authenticated to each other.  The API has a way to signal this.

The question is: if there's something wrong with 0rt session resumption,
isn't there also something wrong with Kerberos "prot_ready"?

My take is: there's nothing wrong with it that we aren't already well
aware of and that isn't fully captured in the security considerations of
the GSS-API's prot_ready concept.

(The same prot_ready point about authentication not being complete also
applies to PFS.)

> envisioned involves keeping keys around that can decrypt old data.

Yes, because that's the only way to make it go fast (all symmetric key
crypto; no PK), and it's also why a short lifetime on the resumption
credentials is important.

Session resumption with additional PFS but no additional authentication
would also be faster than non-resumption (for non-anon ciphersuites
anyways), since there'd be just the (EC)DHE PK + the session resumption
symmetric key crypto, but it would be slower than all-symmetric-key-
crypto resumption, and it would have the sec. cons. given above as to
when PFS is available.

> 1.2 resumption, which isn't a problem. We should at minimum fix this

I'm not up on the details.  I think the right way to do this is as
follows:

 - model resumption as Kerberos-like authentication and key exchange;

 - add optional PFS key exchange to resumption by having the client and
   server exchange (integrity-protected, with the resumption session
   key) (EC)DHE pubkeys, and switch to using the new PFS session keys as
   soon as available;

   (one way to handle this is to make TLS modular, even if only conceptually)

 - adopt the GSS-API prot_ready concept.

Which yields:

 - 0rt for sending "prot_ready" data (no PFS, no key confirmation yet);

 - 1rt for sending data with PFS and key confirmation.

Not bad.

> So we have a root cert with RSA 1024 bit RSA, or the same delegation

That's either missing the forest for the trees (i.e., the root key can,
and we can bet will, be upgraded to something stronger), or [likely
justified] paranoia (i.e., the root key is kept weak on purpose).

> is strictly limited, so stuffing a cert chain in is a bad idea).

There's no stuffing of cert chains.  You can always build and/or staple
the chain (as Chrome supported, briefly).

And there are timestamps in some of the relevant RRtypes.

> window to steal the keys.

I meant this:

          C->S:  hello w/ resumption and ephemeral (EC)DH pubkey, CCS
-no-PFS-> C->S:  <application data>
          S->C:  hello w/ resumption and ephemeral (EC)DH pubkey, CCS
----PFS-> C<->S: <application data>

You can have 0rt w/o PFS.  You can have 1rt w/ PFS.  You can have both
too with the GSS prot_ready concept.

The problem, of course, is that in a complex protocol stack you might
have no idea if the first application record *needs* PFS, so you have to
assume that if PFS was requested, then it must be afforded, and you're
back to needing 1rt.

> security holes in new features unless we take care to do the analysis

A new protocol has its costs too.  Both, new design, and extension, have
one-time costs, and both require careful analysis.  I'm not convinced
that TLS 1.2 is DoA here, but I'd love to see a fresh start if that's
realistic.  Among many benefits it'd give existing implementations' devs
a great excuse to clean house.  But again: is it realistic?

> was said and what convinced everyone this was a bad idea.

No recording?  That's terrible, unacceptable even.  Can we do better
than that for interims, *please*??  I've attended interim WG meetings
for other WGs in the past.  I know it's a low-tech affair by comparison
to normal IETF meetings, but TLS WG interim meetings are potentially
highly consequential!

> summarize the argument about delegation, so I can figure out if it

Seconded.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 11 Nov 2014 11:33:27 -0600

On Tue, Nov 11, 2014 at 09:46:38AM -0500, Hugo Krawczyk wrote:
> OPTLS. [...]

I didn't see such a decision.  Just a lot of questions.

> to sign the static DH key g^s would be moot. [...]

Yes, though there'd be no 0rt the first time a client meets a server
(unless DANE is used).

> certificates for signature keys, not ECDH. This may or may not change in

That and the fact that we can't have intermediate CA certs because of
the lack of implementation (and deployment) of naming constraints, nor
can we have proxy certs [RFC3820] -I think, but correct me if I'm wrong-
for similar reasons.

(Note that RFC3820 proxy certs have no revocation mechanism.)

> for g^s over a long-term ECDH certificate.

Isn't "sub-cert" ~= proxy cert?

> for g^s? That the leakage of a private key s that was sub-certified allows

That the "sub-cert" needs either a revocation scheme (not likely) or a
short lifetime.  The latter puts this on a par with session resumption,
thus making one (well, me) wonder what the advantage to the static DH
concept would be.

We could put static DH keys in DNSSEC and learn them that way, which
would get us 0rt.

> So none of these issues is worse than vulnerabilities of signing keys today.

Server certificates can be revoked (wellll).  Delegations can't be, not
without losing the optimization value of delegation in the first place.
That seems like a deal killer for anything other than short-lived
delegation.

Nico
--

---

From: Yoav Nir <[email-masked]>
Date: Tue, 11 Nov 2014 09:47:23 -1000

> On Nov 11, 2014, at 7:33 AM, Nico Williams <[email-masked]> wrote:
> 

There is a revocation scheme. If the private ECDH key is lost, you revoke the certificate, thereby invalidating the delegation.

> We could put static DH keys in DNSSEC and learn them that way, which

Another possibility is to place the ECDH public key in a certificate extension. This gives it a lifetime as long as the certificate, and it doesn’t matter whether the “regular” certificate public key is RSA or ECDSA or anything else. 

It removes the need to use signatures at all by the server. Not even once.

Yoav

---

From: Nico Williams <[email-masked]>
Date: Tue, 11 Nov 2014 14:37:44 -0600

On Tue, Nov 11, 2014 at 09:47:23AM -1000, Yoav Nir wrote:
> There is a revocation scheme. If the private ECDH key is lost, you
> revoke the certificate, thereby invalidating the delegation.

Ah, good point!

> Another possibility is to place the ECDH public key in a certificate
> extension. This gives it a lifetime as long as the certificate, and it
> doesn’t matter whether the “regular” certificate public key is RSA or
> ECDSA or anything else. 

Sure, certs could have multiple subject public keys.  That'd be a very
nice.  A cert could have an encryption key, a different signature key,
and a key agreement key.

> It removes the need to use signatures at all by the server. Not even

Yes.  I like this.

Nico
--

---

From: Hugo Krawczyk <[email-masked]>
Date: Wed, 12 Nov 2014 23:02:25 -0500

>From the discussions in this list and some offline conversations it is clear
that people like OPTLS for its features but are concerned with the issue of
"delegation", namely, the need for the server to create certificates for
static DH keys g^s by signing (using the RSA key in the server's
certificate)
the key g^s, the validity period (T1,T2) and possibly some other
information.
I'll call this signature a sub-certificate or subcert (some suggested
calling
this a proxy certificate but I prefer not to use established terminology
since
I am not sure what the exact semantics/connotations of these terms).

Here is a summary of the concerns and some of the available techniques to
deal
with them.

* The delegation concerns do NOT exist in a model where the attacker either
  gets full control of the private signing key (e.g., steals it) or
otherwise
  has no access to it. Indeed, in this case either the  key is secure and
the
  attacker cannot produce subcerts or the key is fully compromised and one
  cannot possibly provide server security (in this or any previous version
of
  TLS).

* Thus, delegation concerns only arise when assuming an attacker that cannot
  steal the signing key but can get temporary access to a signing device and
  create a few signatures on arbitrary data. In such case, the attacker can
  generate subcerts for keys g^s for which it knows the secret key s, hence
  allowing him to impersonate the server against any client accepting this
  subcert.

* I am not sure how common the above "partial exposure" problem is in
practice
  but note that if the signing key was only used to generate TLS 1.3
subcerts
  then it could be well guarded since it would be used rarely and never
needed
  online. This would be the case if servers equipped themselves with
signature
  certificates solely used for this purpose (rather than using the same
  certificate in protocols like TLS 1.2 that require online signatures).

NOTE: One way of using a TLS 1.3 RSA key would be to generate a bunch of
subcerts for g^s values in all the EC groups that the server supports and
then
DESTROY the signing key. (This is equivalent, functionally and
security-wise,
to getting DH certificates for all these groups without requiring the CA to
issue DH certificates at all!)

* Assuming that servers will not want to get certificates for use with TLS
1.3
  only (why not?), then we need to address the above subcert forgery
scenario
  where the atacker gets limited access to the signing key. An imperfect but
  effective solution is to only issue subcerts with short validity period,
  i.e.  where the difference T2-T1 is small. In this case the attacker with
  temporary access to the signing key can only create a limited number of
  subcerts covering a limited time span.

Operational note: It is the servers' responsibility to create such
short-lived
subcerts but it is the clients' responsibility to check the subcerts are
indeed short-lived (otherwise an attacker can generate a long-lived subcert
that the client will accept).

* Clients with clocks with significant deviations from the correct time will
  have trouble accepting valid subcerts and may be induced to accept old (or
  into-the-future) subcerts. I can imagine this to be a problem. But is it
  enough to abandon the benefits of a ECDH-based solution like OPTLS?

* The acceptable validity periods can be fixed by the protocol or can be
part
  of the "negotiation" where the client will say which validity-period
lengths
  are acceptable to him and the server will send an error message if it does
  not support such periods. Or the server can simply send the subcert with
the
  shortest validity period which is still valid and the client accept it
  depending on his clock and policy.

Note: One could accommodate, in principle, a period length of 0, meaning a
subcert that is only valid instantaneously; in other words, this would be a
per-session signature on g^s that will also include the client nonce.

* There is no need to have a revocation mechanism for subcerts. The rule is
  that subcerts are not accepted once the RSA certificate is expired or
  revoked. Hence, the revocation of the RSA certificate implies revocation
of
  all subcerts signed with it.

FINAL NOTE: The above issues will be eventually solved with servers getting
certificates for use with TLS 1.3 (either ECDH certificates or signature
certificates used as explained in the first NOTE above).

Hugo

---

From: Watson Ladd <[email-masked]>
Date: Thu, 13 Nov 2014 07:42:46 -0800

>   enough to abandon the benefits of a ECDH-based solution like OPTLS?

I don't think this is quite right. An attacker might root a box
connected to an HSM, and sign several thousand short term shares: to
the HSM this looks like the website being popular, and will cover a
large range of time. There doesn't seem to be an easy way to limit the
time the signature was made, and such a limitation could be
counterproductive in some scenarios. However, I don't think this is a
real problem: HSM usage on major sites is extremely low, and OPTLS
makes it easier.

Sincerely,
Watson Ladd

---

From: Hugo Krawczyk <[email-masked]>
Date: Thu, 13 Nov 2014 12:38:12 -0500

I am a bit hesitant to bring a new idea immediately before the meeting today
but since I won't be there I would like to mention it in case people find it
useful. I will be happier with the direct adoption of OPTLS but the idea
below
addresses the delegation concerns at some extra (temporary) cost.

The idea is to build OPTLS in a way that allows to use it in two "modes":
In the regular mode (r-mode), the protocol is exactly  OPTLS as proposed
originally in the first message of this thread
http://www.ietf.org/mail-archive/web/tls/current/msg14385.html.
It enjoys all the benefits of OPTLS including avoiding online signatures.
It also avoids most concerns with delegation when servers have TLS 1.3
certificates (more on this below).

A second mode, call it "transitional mode" (t-mode), is appropriate for
servers that use the same certificates for TLS 1.2 and 1.3 and completely
avoids the delegation concerns. The price for this variant is one more
exponentiation relative to the cost of the current TLS 1.3 specification.
This extra cost is not nice but is not huge either: As a percentage of the
performance cost of current TLS 1.3 spec (two exponentiations for PFS and a
online RSA signature), the addition of one EC exponentiation is relatively
minor (<10% ?).
This t-mode works as in OPTLS but replaces the validity period of the
subcert
with the client nonce. That is, the subcert
sign-rsa(g^s, T1, T2, stuff)
used in OPTLS (where T1, T2 indicate the limits of validity period and
sing-rsa indicates a server's signature using his certified signing key)
will be replaced with
sign-rsa(g^s, client-nonce, stuff).
The rest of the protocol stays the same.
Thus t-mode preserves the current online signature, preempts the delegation
concerns, but costs one more exponentiation (g^{xs}) relative to current 1.3
spec. The cost of the t-mode stays the same as the original OPTLS in the
cases
of 0-RTT, PSK or session resumption.

So why am I saying that TLS 1.3 specific certificates will address the
delegation concerns? First, by "TLS 1.3 specific certificates" I mean
certificates (typically RSA or ECDSA) that have an indication of use for TLS
1.3 (I assume such indication can be accommodated in certificates).
In this case, a server can use the signing key to only sign static DH keys,
hence the signing key is never used online. This allows for a better
protection of the key (the concerns with delegation stemmed from temporarily
vulnerable keys). Moreover, as I indicated in a previous email, a server can
even use this signing key to sign multiple static keys (for multiple groups
and/or multiple validity periods), securely store these DH keys, and destroy
the signature key. Why do these certificates have to be TLS 1.3 specific
(i.e., have an indication in the certificate that this is for use in TLS
1.3)?
Because clients need to know when to accept the protocol in r-mode or run it
in t-mode. The idea would be that clients accept the former only with
1.3-enabled certificates.

Interestingly, this approach supports "sound economics": It is the interest
of
the server to move to r-mode in order to save on the cost of online
signatures
hence it has a motivation for paying for the extra TLS 1.3 certificate...

Hugo

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 13 Nov 2014 13:18:13 -0500

I think the major concern is that this is a pretty radical change from the current deployment model of SSL/TLS.  For what it's worth, I think it's cool and clever and has a number of real nice properties. But we are already getting 'picked on' for adding too many new things, and I am concerned that adding this, fairly late in the game, will delay the deployment of TLS 1.3 as people will take a step back and consider if they really need to use this revolutionary new protocol, rather than the evolutionary changes they were expecting.

I used my personal opinion here, but I feel pretty comfortable saying I'm not the only one who feels this way. It's a case of "too much, too late."

Does that make sense?

Can we wrap up TLS 1.3 and perhaps do a TLS 2 based on these concepts, including a  non-CA trust model?

	/r$

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Thu, 13 Nov 2014 18:27:58 +0000

I'd be comfortable with OPTLS added to 1.3. 

--
Regards,
Uri Blumenthal                            Voice: (781) 981-1638
Cyber Systems and Technology   Fax:   (781) 981-0186
MIT Lincoln Laboratory                Cell:  (339) 223-5363
244 Wood Street, Lexington, MA 02420-9185       

Web:  http://www.ll.mit.edu/CST/
MIT LL Root CA:  <https://www.ll.mit.edu/labcertificateauthority.html>

----- Original Message -----
From: Salz, Rich [mailto:[email-masked]]
Sent: Thursday, November 13, 2014 01:18 PM
To: Hugo Krawczyk <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3

Does that make sense?

	/r$

---

From: Hugo Krawczyk <[email-masked]>
Date: Thu, 13 Nov 2014 13:54:40 -0500

If you consider the t-mode of OPTLS I suggested in the previous email then
the changes relative to 1.2 are not much more significant than those
introduced in 1.3. Please think about this point. It is important! Right
now people are going through the process of digesting these ideas so it all
seems much more complex than they really are.

This is particularly true for the t-mode where the only thing that changes
w.r.t current TLS 1.3 is that servers generate keys g^s which they can do
as frequently or non-frequently as they wish, can support as many groups as
they wish, require no certification and raise no issues of delegation. The
rest is just a change of what you sign and the key derivation formulas. It
is hard to believe that this should be considered as changing things
radically. The fact that this enables the more forward looking r-mode
should be an advantage that servers can enjoy down the road (without yet
another revision of the protocol). In particular, the r-mode could be the
real incentive (together with 0-RTT, for those that need it) to move to
1.3. Currently, the only substantial thing that 1.3 is offering (other than
security improvements that people seem to consider less significant than
functional/performance improvements) is forward secrecy. I am not sure that
by itself it would be a strong enough incentive to upgrade.

Hugo

On Thu, Nov 13, 2014 at 1:18 PM, Salz, Rich <[email-masked]> wrote:

> I think the major concern is that this is a pretty radical change from the
> current deployment model of SSL/TLS.  For what it's worth, I think it's
> cool and clever and has a number of real nice properties. But we are
> already getting 'picked on' for adding too many new things, and I am
> concerned that adding this, fairly late in the game, will delay the
> deployment of TLS 1.3 as people will take a step back and consider if they
> really need to use this revolutionary new protocol, rather than the
> evolutionary changes they were expecting.
>
> I used my personal opinion here, but I feel pretty comfortable saying I'm
> not the only one who feels this way. It's a case of "too much, too late."
>
> Does that make sense?
>

---

From: Watson Ladd <[email-masked]>
Date: Thu, 13 Nov 2014 11:41:57 -0800

On Nov 13, 2014 10:18 AM, "Salz, Rich" <[email-masked]> wrote:
>
> I think the major concern is that this is a pretty radical change from
the current deployment model of SSL/TLS.  For what it's worth, I think it's
> Can we wrap up TLS 1.3 and perhaps do a TLS 2 based on these concepts,
including a  non-CA trust model?

Wrap up what exactly? The TLS 1.3 draft as it stands has had very little
security analysis applied. Important questions remain to be resolved. It's
already a major change from TLS 1.2 and increasingly so as more gets
reworked.

OPTLS is not something to be added as an option on top of whatever else we
want. It's a protocol that solves the problems TLS 1.3 was intended to
solve, and to do so with a design that takes advantage of our knowledge of
security analysis.

Whatever deployment issues exist will exist for TLS 1.3: reuse of TCP
connections reduces the impact of latency.

TLS 2 could do a lot more for security: use formal languages to make
parsing easy, make implementation simplicity a priority.  I doubt the IETF
ever could achieve this: we had IRC and now have XMPP, to name the most
egregious example.

While you can use a different deployment model you don't have to: certs can
be put on all frontend machines exactly as now.

As for non-CA trust model, I'm not sure we have a good one that includes
all uses of TLS: I'd like to know what you propose,  but I'm not sure this
list is the place.

Sincerely,
Watson Ladd

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 13 Nov 2014 14:58:41 -0500

> As for non-CA trust model, I'm not sure we have a good one that includes all uses of TLS: I'd like to know what you propose,  but I'm not sure this list is the place.

Doesn't matter, since I don't have one to propose and was just pointing it out as an issue with OPTLS v1

	/r$

--  
Principal Security Engineer, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Dan Brown <[email-masked]>
Date: Tue, 18 Nov 2014 16:53:08 +0000

Some similarity between the OPTLS proposal and some previous key agreements 
schemes may be relevant.  The main benefit of such similarity is that portions 
of the previous security analysis (whether security proofs, or lack of 
attacks) of the previous schemes may be applicable to OPTLS.  In other words, 
OPTLS is not a radically new design. Obviously, the details by which OPTLS 
differs from previous schemes can be also be very important, especially with 
different goals and fixes to defects.

One previous similar scheme is Blake-Wilson, Johnson and Menezes (BJM) key 
agreement (protocol 1). Specifically, if one replaces the initiator (client) 
static key with the ephemeral key in the BJM protocol, then BJM derives an 
authentication key in a way similar to OPTLS, and derives a separate session 
key from both ephemerals, similar to OPTLS.

Another previous similar scheme is the unified model key agreement from NIST 
SP 800-56A (and ANSI X9.63).  As with BJM, OPTLS differs from Unified in that 
OPTS replaces a static key from one side (the client) with the ephemeral key, 
and derives several types of keys (instead of just one in Unified model).  The 
unified model key agreement has the defect of key-compromise impersonation 
(KCI attacks), but that does not seem to apply to OPTLS if the client is 
anonymous.

Best regards,

Dan

From: TLS [mailto:[email-masked]] On Behalf Of Hugo Krawczyk
Sent: Friday, October 31, 2014 8:54 PM
To: [email-masked]
Cc: Hoeteck Wee
Subject: [TLS] OPTLS: Signature-less TLS 1.3

During the TLS interim meeting of last week (Oct 22 2014) I suggested that TLS
1.3 should abandon signature-based authentication (other than for 
certificates)
and be based solely on a combination of ephemeral Diffie-Hellman for PFS and
static Diffie-Hellman for authentication. This has multiple benefits including
major performance gain (by replacing the per-handshake RSA signature by the
server with a much cheaper elliptic curve exponentiation), compatibility with
the mechanisms required for forward secrecy, natural accommodation of a 0-RTT
option, and a simple extension without signatures for client authentication.

Below I present a schematic representation of the proposed protocol referred
to as OPTLS where OPT stands for OPTimized and/or for One-Point-Three.
The presentation is sketchy and omits the exact procedure for key derivation.
The latter is a crucial component for the security of the protocol, but
before getting into these details we want to get a sense of whether the WG is
interested in this approach. In the meantime, Hoeteck Wee and myself are
working on the details of the protocol and the security proof.

[K] symbols represent pointers to key material whose exact derivation is not
included here except for specifying the basic DH values from which the key is
derived (actual derivation will include further information similar to the
extended hash mechanisms or SessionHash proposal considered for 1.3).
Asterisks represent optional fields that the WG can decide to leave as 
optional,
mandatory, or simply remove without changing the core cryptographic security 
of
the protocol. All references to encryption mean "authenticated encryption"
using the encrypt-then-mac paradigm (or any other secure AEAD mechanism).

KeyShare's represent ephemeral Diffie-Hellman values exchanged by the parties.
All the public key and Diffie-Hellman operations are assumed to happen over a
cyclic group with generator g of order q (typically implemented by an elliptic
curve group). We use multiplicative notation where ^ denotes exponentiation as
in g^x, g^{xy} (here xy denotes multiplication of the scalars x and y), etc.
Omitted from the current high level description is a mechanism for testing 
group
membership of DH values or cofactor exponentiation (the specific mechanism
depends on the group type and is typically very efficient for elliptic 
curves).

The server has a long term private-public key pair denoted by (s,g^s) where
s is uniform random in [0..q-1] (we refer to s and g^s as "static keys").
We assume that the server has a certificate that includes the server's public
key g^s and a CA-signed binding of this key to the server's identity.
We discuss the implementation of such certificates below.

PROTOCOL OPTLS:

ClientHello
ClientKeyShare

1-RTT CASE:

The basic 1-RTT case omits the ClientData* field. It includes a ClientKeyShare
g^x and a ServerKeyShare g^y and an optional (encrypted) server certificate.
If the certificate is sent (it can be omitted if the client has indicated that
it knows the server key as in the case in the 0-RTT scenario) and is 
encrypted,
the encryption key K1 is derived from g^{xy}.

Key K2 is an encryption key derived from both g^{xs} and g^{xy}. It is used to
authenticate-encrypt the ServerFinished and ClientFinished messages (which
include a hash of the previous traffic) and to encrypt data from the server if
such data is piggybacked to the second message.

Key K3 is the "application key" used to derive key material for protection of
application data.  This key material will include (directional) Authenticated
Encryption keys and, possibly, keys for derivation of further re-key material.
K3 is computed from  both g^{xs} and g^{xy} similarly to K2, but its 
derivation
will be different than K2, e.g., using a separating key expansion technique.

SUPPORT FOR 0-RTT:

The above protocol is compatible with a 0-RTT protocol such as QUIC. In this
case, the client is assumed to have information about the server's public key
and other security parameters. The server is assumed to have some mechanism in
place for detecting replay (e.g., via timestamps, stored client nonces, etc.).
The resulting protocol is as described above where the ClientData field is 
sent
encrypted under key K0 derived from g^{xs}.
The rest of the protocol is identical to the above.
Note: In this case, ServerCertificate is not sent as the client had to know
the server's public key before the first message (one can imagine a setting
where the server may send a different certificate in the second message - if
desired, this can be accommodated too as an option or extension).

CLIENT AUTHENTICATION:

Client authentication can be supported via an option or extension. It would
include a client certificate for a static DH key g^c sent in the third message
(the certificate can be encrypted under key K2 to provide client's identity
protection). In this case, the key for computing the ClientFinished message 
and
the application key K3 would be derived from a combination of the values g^xy,
g^xs, g^yc (and possibly also g^{cs}).

NOTES:

Note on Finished messages: The above spec sets ServerFinished as mandatory and
ClientFinished as optional. The latter option is needed for a 1-RTT protocol.
In principle, both Finished messages could be omitted and still obtain 
security
via implicit authentication (assuming the inputs to key derivation are chosen
appropriately). But given the advantages of ServerFinished for providing
explicit authentication, key confirmation, and active forward secrecy (see
below), it seems advisable to always include it. Including ClientFinished
provides key confirmation from client and also explicit client authentication
when client certificate is included. ClientFinished also provides Universal
Composable (UC) security (this is a result of the Canetti-Krawczyk proof that
CK security implies UC security when a client confirmation step is included).

Note on certificates: Since in current practice servers hold certificates for
RSA signature keys rather than for static DH keys, the certificate field in 
the
above protocol will be implemented by a pair consisting of (i) the server's 
RSA
signature certificate and (ii) the server's signature using this RSA key on 
the
server's static public DH key g^s. The latter signature by the server is
performed only when a new static DH key is created (how often this happens and
how many such keys are created is completely up to the server - it has the
advantage that these keys can be changed often to increase security against
leaked keys). This use of RSA also enjoys the high efficiency of RSA
verification for the client.
The handling of Client certificates would be similar.

Note on forward security (a.k.a. as PFS for Perfect Forward Security):
PFS is provided by the (mandatory) use of ephemeral Diffie-Hellman keys.
The meaning of PFS is that an attacker that finds the (long-term) static
private keys of the parties cannot compromise past session keys. Without the
ServerFinished message the above protocol ensures forward secrecy against
passive attackers (i.e., for sessions where the attacker did not choose g^y).
With ServerFinished, PFS holds also against active attackers.  A similar
consideration applies to ClientFinished.

Client certificates in the first message: We note that in cases where client
certificates can be sent in the clear in the first message of the protocol, 
one
can provide PFS and mutual authentication in a 1-RTT at essentially the same
cost of an unauthenticated DH exchange (i.e., a cost of little more than two
exponentiations). In such a setting one can also obtain mutual authentication 
in
a 0-RTT protocol (with forward secrecy with respect to the client's key).
These options, however, require HMQV-like mechanisms and may raise IP issues 
(this
can be investigated further if the WG is interested).

---

From: Hugo Krawczyk <[email-masked]>
Date: Tue, 18 Nov 2014 15:10:04 -0500

I am aware of these protocols of course (and their shortcomings) and of
several other relevant works (e.g Katz et al).
There is also my own SKEME protocol from 1995 (which predates these other
schemes) which is closer in the approach to OPTLS in the sense of providing
a flexible framework for supporting things like session resumption and
Pre-shared key.
None of these, however, support basic requirements from OPTLS such as 0-RTT
and server-only authentication.

In any case, similarity between KE protocols is not a guarantee of
security. The devil is in the details, and OPTLS has not even fixed these
details. We are waiting to understand better the requirements before fixing
these. It may well be the case that there will be no need to fix them if
the WG is not interested in pursuing this direction (which is quite a
shame).

Hugo

PS: BTW, the UM protocol from NIST 56A is not only subject to UKS but also
to the interleaving attack from BJM.

On Tue, Nov 18, 2014 at 11:53 AM, Dan Brown <[email-masked]> wrote:

> Some similarity between the OPTLS proposal and some previous key
> agreements schemes may be relevant.  The main benefit of such similarity is
> that portions of the previous security analysis (whether security proofs,
> or lack of attacks) of the previous schemes may be applicable to OPTLS.  In
> other words, OPTLS is not a radically new design. Obviously, the details by
> which OPTLS differs from previous schemes can be also be very important,
> especially with different goals and fixes to defects.
>
>
>
> agreement (protocol 1). Specifically, if one replaces the initiator
> (client) static key with the ephemeral key in the BJM protocol, then BJM
> derives an authentication key in a way similar to OPTLS, and derives a
> separate session key from both ephemerals, similar to OPTLS.
>
>
>
> Another previous similar scheme is the unified model key agreement from
> NIST SP 800-56A (and ANSI X9.63).  As with BJM, OPTLS differs from Unified
> in that OPTS replaces a static key from one side (the client) with the
> ephemeral key, and derives several types of keys (instead of just one in
> Unified model).  The unified model key agreement has the defect of
> key-compromise impersonation (KCI attacks), but that does not seem to apply
> to OPTLS if the client is anonymous.
>
>
>
> Best regards,
>
>
>
> Dan
>
>
>
> *From:* TLS [mailto:[email-masked]] *On Behalf Of *Hugo Krawczyk
> *Sent:* Friday, October 31, 2014 8:54 PM
> *To:* [email-masked]
> *Cc:* Hoeteck Wee
> *Subject:* [TLS] OPTLS: Signature-less TLS 1.3
>
>
>