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

On Wed, Nov 12, 2014 at 8:02 PM, Hugo Krawczyk <hugo@ee.technion.ac.il> wrote:
><snip>
>
> * 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?

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
>
> On Tue, Nov 11, 2014 at 3:37 PM, Nico Williams <nico@cryptonector.com>
> wrote:
>>
>> On Tue, Nov 11, 2014 at 09:47:23AM -1000, Yoav Nir wrote:
>> > > On Nov 11, 2014, at 7:33 AM, Nico Williams <nico@cryptonector.com>
>> > > wrote:
>> > > 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.
>> >
>> > There is a revocation scheme. If the private ECDH key is lost, you
>> > revoke the certificate, thereby invalidating the delegation.
>>
>> Ah, good point!
>>
>> > > We could put static DH keys in DNSSEC and learn them that way, which
>> > > would get us 0rt.
>> >
>> > 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
>> > once.
>>
>> Yes.  I like this.
>>
>> Nico
>> --
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> 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