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

Martin Thomson <martin.thomson@gmail.com> Wed, 05 November 2014 17:45 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91AB1A9035 for <tls@ietfa.amsl.com>; Wed, 5 Nov 2014 09:45:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNDCpY6mOkGn for <tls@ietfa.amsl.com>; Wed, 5 Nov 2014 09:45:29 -0800 (PST)
Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CEAB1A9028 for <tls@ietf.org>; Wed, 5 Nov 2014 09:45:29 -0800 (PST)
Received: by mail-la0-f51.google.com with SMTP id q1so1159726lam.10 for <tls@ietf.org>; Wed, 05 Nov 2014 09:45:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.112.146.229 with SMTP id tf5mr25049513lbb.73.1415209527665; Wed, 05 Nov 2014 09:45:27 -0800 (PST)
Received: by 10.25.215.134 with HTTP; Wed, 5 Nov 2014 09:45:27 -0800 (PST)
In-Reply-To: <CADi0yUOZ8LqsJbTTZmYL6XgrTjWvTMqvFMd7euzv+xQPU9vPJg@mail.gmail.com>
References: <CADi0yUObKsTvF6bP=SxAwYA05odyWdzR1-sWutrDLUeu+VJ1KQ@mail.gmail.com> <CABcZeBNQBC1XXFR5sGo=V8WmxmL5thaBpeHSasy3SordbqNRTQ@mail.gmail.com> <CADi0yUMM6C=NpvFsc67J6Dc6uEO3OZ490tFWhAYmD362mC+D4A@mail.gmail.com> <CABcZeBNKpTMg+xhMK5TnO_W99MotoPw+_m9yrTqTUSwqyPpUPA@mail.gmail.com> <CACsn0cnkRZ5ZzX0bHfVFsvsrNoJxU2Txs0O2YW386fsg9GF1vQ@mail.gmail.com> <CABcZeBMQc5Mb_FK3davMxi0oBgzawqCMaYp1DqGYgg3nEHYHHw@mail.gmail.com> <CADi0yUOZ8LqsJbTTZmYL6XgrTjWvTMqvFMd7euzv+xQPU9vPJg@mail.gmail.com>
Date: Wed, 05 Nov 2014 09:45:27 -0800
Message-ID: <CABkgnnV1jcdXeZJ5BwZB1sM7xwuJt9Q3UUujTgddjC3sHDJxpA@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Hugo Krawczyk <hugo@ee.technion.ac.il>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/faRVAMi6tlTPx6-1vsvIG4KXu3I
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Nov 2014 17:45:31 -0000

On 5 November 2014 08:27, Hugo Krawczyk <hugo@ee.technion.ac.il> 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.

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