Re: [TLS] signature algorithm ID re-use

Nikos Mavrogiannopoulos <nmav@redhat.com> Fri, 07 July 2017 08:40 UTC

Return-Path: <nmavrogi@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B8F129B10 for <tls@ietfa.amsl.com>; Fri, 7 Jul 2017 01:40:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.7
X-Spam-Level:
X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Fdfx_tdZLw2Q for <tls@ietfa.amsl.com>; Fri, 7 Jul 2017 01:40:22 -0700 (PDT)
Received: from mail-wr0-f169.google.com (mail-wr0-f169.google.com [209.85.128.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE28F120726 for <tls@ietf.org>; Fri, 7 Jul 2017 01:40:21 -0700 (PDT)
Received: by mail-wr0-f169.google.com with SMTP id 77so36783121wrb.1 for <tls@ietf.org>; Fri, 07 Jul 2017 01:40:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hqg+wFiF3BttmJ/XwYTCbai3BMR1d3sxN8OlDjM6WnI=; b=Q11p+SlOxJOudiEuZjaBB0RYESPtc1X2Cv1lS94RLPE8IHCBvj4YCGs6LNN55NaWzN KK99ArqrFkY6X5+NNI7XqIlA7ojJ+kO1ok2py+u02grKmseWslfl1aVPYRla9oE09jbF 7iGG83VLV7Je8JNZJ13KIXCDNEIwwmLx1wDzWVywt+vnzEbdTDGeppWLpBRbGFbtxNa9 AGxcKTz7N67/rOEAiolA+PrCWBuNTfpqf9T41wkcfbkIqWMz13nJwkHgKhYHsH70UA1B JpuKnMO7LGcFXN1DNoHmnAAZmC0+CNnFpdLbAXIJ6XCPlQkjAXVhmun4Y1bnxxpHZjW/ Gtbg==
X-Gm-Message-State: AIVw113rzCxhJDglvUvyxIMONVEcwsfLXA0qhKlotFwete5gPrWPcVzC PCT8y9wvjzvX3BwBS45//VZrNSX1/ZAhtjw=
X-Received: by 10.223.166.2 with SMTP id k2mr95930wrc.34.1499416820241; Fri, 07 Jul 2017 01:40:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.20.203 with HTTP; Fri, 7 Jul 2017 01:40:19 -0700 (PDT)
In-Reply-To: <CABkgnnWZQwf03pDnPD1+8fpXx0dmni+vi3uz9TxLLx44ZLcu2A@mail.gmail.com>
References: <1499179408.2892.13.camel@redhat.com> <CABkgnnWZQwf03pDnPD1+8fpXx0dmni+vi3uz9TxLLx44ZLcu2A@mail.gmail.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
Date: Fri, 7 Jul 2017 10:40:19 +0200
Message-ID: <CADh2w8TAD62H1KWTzdohOzPbzeSc+fSYwLzp9t0GdszB19vaiw@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="f403045cf0d2f0eca40553b62e39"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/PI3Q9uwjFHVsPlTjjyksN1xmTJQ>
Subject: Re: [TLS] signature algorithm ID re-use
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 07 Jul 2017 08:40:24 -0000

On Wed, Jul 5, 2017 at 12:50 AM, Martin Thomson <martin.thomson@gmail.com>;
wrote:

> On 4 July 2017 at 07:43, Nikos Mavrogiannopoulos <nmav@redhat.com>; wrote:
> > So my question is why not go for the simpler approach and create new
> > identifiers for the new signature algorithms? (similarly to RSA-PSS).
> > Is there an advantage of re-using the ECDSA signature algorithm
> > identifiers to mean something different in TLS 1.3? Was there some
> > discussion on the topic on the list?
>
>
> This was fairly extensively litigated.  I remember Hannes asking
> exactly the same question, but I forget which in-person meeting it
> was.  It might have been IETF 97.
>
> Unfortunately, any search I do on this subject turns up the hundreds
> of emails on using signature algorithms for selecting certificates.
>
> What I've found is that this isn't that difficult to implement
> correctly, even across versions.  As David Benjamin suggested in
> earlier emails, you can change to using a 16-bit codepoint in your
> code.  Then you add a curve-matching restriction if the selected
> version is TLS 1.3 (or greater).
>

Well, it depends on the definition of correctly :) You can certainly have
interoperation following something similar to what you describe, however
the question is what about semantics. How do you translate that to the
user? If one is careful with semantics and would like to let the user
specify a policy of allowed operations/signature algorithms, he would have
to specify two different signature algorithms, one for ecdsa with any
curve, and another for the restricted to secp256r1, and then make sure that
what is sent over the wire will be interpreted according to the policy by a
TLS 1.2 or a TLS 1.3 server (which I find it quite impossible for any
policy which requires anything else than a single curve and signature
algorithm).

That's why my question is on what is the advantage of the code point
re-use, because I see only disadvantages.

regards,
Nikos