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

Martin Thomson <> Wed, 05 November 2014 17:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E91AB1A9035 for <>; Wed, 5 Nov 2014 09:45:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jNDCpY6mOkGn for <>; Wed, 5 Nov 2014 09:45:29 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6CEAB1A9028 for <>; Wed, 5 Nov 2014 09:45:29 -0800 (PST)
Received: by with SMTP id q1so1159726lam.10 for <>; Wed, 05 Nov 2014 09:45:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3ptukLXHLlDxx5RPTU9QtVVeHWtV2j+f7MVEF4lD4To=; b=HLZ1Z/O5iAIhSVys0THFHrjLdwpPwWNAdcXOoYotXeQClhuv8Iz99XCtfpbVP6sK76 2dXurDZET7u1qqEVj6SucjNSc69U6q/yJDZ7Hn5wUCvSeehmkQOrtf/QVqfv5e71Sn3f SHBSXPAUnPLobXzcQnPyr6QTaagu6uSh5hAUVSgtlsIRO4trnGk939U8SGIcQ6xgtJJs JBTNikjaHK/QSlf7/BZ1a8PQbYnB7E25auXZW3MlKnz54HfG+EuAndfBktLd+dk9PNhD WgNccmWs4vrkLgopQRXOVYLigKhDXap0ynXtfOhBBp9A8hAM7YU0CHKim40RyE+0DzAU RcUg==
MIME-Version: 1.0
X-Received: by with SMTP id tf5mr25049513lbb.73.1415209527665; Wed, 05 Nov 2014 09:45:27 -0800 (PST)
Received: by with HTTP; Wed, 5 Nov 2014 09:45:27 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Date: Wed, 05 Nov 2014 09:45:27 -0800
Message-ID: <>
From: Martin Thomson <>
To: Hugo Krawczyk <>
Content-Type: text/plain; charset="UTF-8"
Cc: "" <>
Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 05 Nov 2014 17:45:31 -0000

On 5 November 2014 08:27, Hugo Krawczyk <> wrote:
> 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?

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.