Re: [TLS] Simplifying signature algorithm negotiation

Brian Smith <brian@briansmith.org> Sat, 16 January 2016 03:13 UTC

Return-Path: <brian@briansmith.org>
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 52A981B364E for <tls@ietfa.amsl.com>; Fri, 15 Jan 2016 19:13:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 TpTsUW5Q28Up for <tls@ietfa.amsl.com>; Fri, 15 Jan 2016 19:13:29 -0800 (PST)
Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (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 B6F2D1B3651 for <tls@ietf.org>; Fri, 15 Jan 2016 19:13:29 -0800 (PST)
Received: by mail-oi0-x22c.google.com with SMTP id k206so148013605oia.1 for <tls@ietf.org>; Fri, 15 Jan 2016 19:13:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GHi2gcZqfCeg2vkDmEkfjaVZ5R4WdKwYd2S1nnu0D8c=; b=k08+K9jzLUDHUNuFcF2ckP7BKTQb9C+gfuatPuvCGZOT215KfC38HQ8uXvms2B7eiI WG2wYYTiOGCLeW8f/3PpxAEyWDiTDqsfOzqcK8bp2KRoiI417tCCd2tUNJNopriKW5iT XpXLmPWJA0T5lwBgZ2LteldP1LzC511Jl76DzBhKoLmjNhvo11II5Om/FPEeFc79hwMa VS4AQqWeqBCh+gMyq5NNrO6sEYkeb8Jwvbj7AbeuiUhxGRvlH3O20ywgDx57tzcTkASt HHzUN/1cmA6KRPl2TbdhrSMd6Bo5KVc1A5pFxWtnhTK/2OnQLgGaFZ6vz1ETPc4JVpCp hHlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GHi2gcZqfCeg2vkDmEkfjaVZ5R4WdKwYd2S1nnu0D8c=; b=dixqnZRMmJQyX2tWFC3h/CCkFJnTb9MeI5FvCj+W4C7/OQ31JLEclq+NscxtLQ5/2w CRnvZ2smpi4rcvy3xW2fTn0cbD5j56T3RVxvpMBzI2cbZIP/MSarKVqN0nmtVTSQ1/p5 OnqbJldYWeyjcYUjkG6+P99ahBhQnzjTux8c5swbxLQ3ZKcDS4GqkHhcpV0yq1Ju8iwn gMXxsQW+c4R0mMFkeP+2PgNlX7skqVhGMmIOhq57mFDi83x5lq7+3oXcWk69KJu3HRZG yWoQckoZ5/XzLKHSvCH70m5lmyHkZ0Nou/ophMdep1weiFztjSvtZbzl9vTthCff785D wJzQ==
X-Gm-Message-State: ALoCoQnjnTqhg8HzEsPouJBAeBpNVej4aTdW2rkBLYWkKZLLwo5hwrMZ5M6IrTAcXhEWpBNT4kJUYBnq9g/tTvGTjxe2nGKu6Q==
MIME-Version: 1.0
X-Received: by 10.202.60.135 with SMTP id j129mr10533484oia.70.1452914009131; Fri, 15 Jan 2016 19:13:29 -0800 (PST)
Received: by 10.76.170.225 with HTTP; Fri, 15 Jan 2016 19:13:29 -0800 (PST)
In-Reply-To: <CAF8qwaBrzPtLzoAGAfjCzzHHxZzh97W3K53PMGmunJsF-SfVYg@mail.gmail.com>
References: <CAF8qwaCpYqs7ELDcRzXveLLjpL+d-CmBczkxPweh6_RVE1aDeA@mail.gmail.com> <CAFewVt7f4pAbJ_Z3s0w_Qiwdi-cGM-39BnPV5-qF3PLOdpFw0A@mail.gmail.com> <CAF8qwaBrzPtLzoAGAfjCzzHHxZzh97W3K53PMGmunJsF-SfVYg@mail.gmail.com>
Date: Fri, 15 Jan 2016 17:13:29 -1000
Message-ID: <CAFewVt4d9SRGzrEdd0vAt-gtjA6BUygxV8_6PFnTMDPHgfvh6A@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
To: David Benjamin <davidben@chromium.org>
Content-Type: multipart/alternative; boundary=001a113ccad067664005296ae7ab
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/MKAsCQ2VuicB6RlKikmkMMwpjAU>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Simplifying signature algorithm negotiation
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: <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: Sat, 16 Jan 2016 03:13:31 -0000

David Benjamin <davidben@chromium.org>; wrote:

> (Whether such certificates exist on the web is probably answerable via CT
> logs, but I haven't checked.)
>

Me neither, and I think that's the key thing that would need to be checked
to see if my suggestion is viable.

3. You get better interoperability with TLS 1.2's NSA Suite B profile [1].
>> (I don't have any particular affinity for that profile other than it seems
>> to have made choices that have historically been shown to be above average,
>> and it might be a good idea to avoid interop failure with other
>> implementations that might have a special affinity for it.)
>>
>
> What interop faliures are you worried about here?
>

The way I proposed things to work for TLS 1.3 is what the Suite B profile
does for TLS 1.2. A Suite B client cannot describe the Suite B profile
policy with the signature_algorithms extension as-is, so in theory if a
Suite B profile client even exists, it would work better if servers assumed
that ecdsa_sha256 implies P-256 and ecdsa_sha384 implies P-384. I don't
know if any such "Suite B client" actually exists, though.


> I don't think it makes sense to strategically assign the second byte for
> new numbers. Either we believe TLS 1.2 implementations are unlikely to
> react to 0x0703 and not worry about it, or we believe they will and we
> reserve all numbers ending in 00-03. (Or we decide that this (u8, u8) to
> u16 hack is too silly and don't do it at all.)
>

I would bet there will be some logic like "Is sha-256 mentioned at all in
the signature_algorithms extension" and/or "is ecdsa mentioned at all in
the signature_algorithms" extension that is used by some servers to decide
whether to use a SHA-1 cert and/or whether to use an ECDSA cert, so I think
it would be worth the effort at least when the effort is minimal.

Cheers,
Brian
-- 
https://briansmith.org/