Re: [TLS] Possible TLS 1.3 erratum

Nick Harper <ietf@nharper.org> Thu, 15 July 2021 19:48 UTC

Return-Path: <nharper@nharper.org>
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 299163A0D6B for <tls@ietfa.amsl.com>; Thu, 15 Jul 2021 12:48:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 l2zMd95jEvSZ for <tls@ietfa.amsl.com>; Thu, 15 Jul 2021 12:48:40 -0700 (PDT)
Received: from mail-vs1-f46.google.com (mail-vs1-f46.google.com [209.85.217.46]) (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 48F493A0E15 for <tls@ietf.org>; Thu, 15 Jul 2021 12:48:29 -0700 (PDT)
Received: by mail-vs1-f46.google.com with SMTP id z7so3639337vsn.7 for <tls@ietf.org>; Thu, 15 Jul 2021 12:48:29 -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:references:in-reply-to:from:date :message-id:subject:to:cc; bh=c4ZZltZ5927nbzYCPeNNyTl8BHI/urMgLxPVUej94gs=; b=BxHrjj/H/vnwa/nMlppvs6E4x/sJMSKGSJ9ZsmBVZaiRXGxjgMEUWp0H9HMDkO6WPY E2RkbBq4GbtFi+reZx3V2v/nI1USreXI0sWX9BNMIxqoyZTzLvIMbKG5dt9vJl9xcBVY FSZK4/TfYnuSQ/B8FKSsGdJWHjbO9Vyzim+xeTVRwJJfDA3SYzjA/SoFh86I/IkqjKoJ gzUn2XkNHBX98LQPyM6Z/tmHIHkw4yZaoSSeolPIm8ag2187jhVMEvxO6W5rCsWBt3td lrdjrRnh1fBtDEjVN3dy7GSPW58NwqhUoWxCxxufMZSn5Crof5clPMMuiO0t/kSoD7RO orWA==
X-Gm-Message-State: AOAM533b1fIMPN7Uorx8Rt/6QYLXS2esQDTBWVnHy25VCtNmc7OiePkK /yriQ+baGcxIgfdm/SuhDCr4OivYST09Ar6O1b/0wQ==
X-Google-Smtp-Source: ABdhPJwB8qdAul6so0IkTPPOj+iBhKV7MWOQ/imi9vk5/frdM7AFJ6m5fzJWBd5Fy/lp61h3n89TlImnrlZLNtAcmGc=
X-Received: by 2002:a67:7142:: with SMTP id m63mr8924505vsc.59.1626378507890; Thu, 15 Jul 2021 12:48:27 -0700 (PDT)
MIME-Version: 1.0
References: <ME3PR01MB624282F25AA6983F9CEFDCD2EE129@ME3PR01MB6242.ausprd01.prod.outlook.com> <CABcZeBNajvtG8pebcrD2dgmP+Pb4+gTQMfB6NDOMH7hpqNSS-w@mail.gmail.com> <CAF8qwaD=0tHLrtbqYv2gZ35V24yy_mbdov1Rj-TJR7xrBPJhBA@mail.gmail.com>
In-Reply-To: <CAF8qwaD=0tHLrtbqYv2gZ35V24yy_mbdov1Rj-TJR7xrBPJhBA@mail.gmail.com>
From: Nick Harper <ietf@nharper.org>
Date: Thu, 15 Jul 2021 12:48:16 -0700
Message-ID: <CACcvr=m6+Lj1eg2GhF469FJuquR7+71sQESczD3kiJoGtDcmmw@mail.gmail.com>
To: David Benjamin <davidben@chromium.org>
Cc: Eric Rescorla <ekr@rtfm.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003bd0fb05c72ec14c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/glLkKJCOUbeZ7ofMbfK7aQop8RA>
Subject: Re: [TLS] Possible TLS 1.3 erratum
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 15 Jul 2021 19:48:54 -0000

Regarding
> so where 1.2 uses { hash, sig } 1.3 uses values equivalent to { sig, hash
}.

While some TLS 1.3 SignatureScheme enum values might appear to have the sig
in the upper octet and hash in the lower octet, that is not the case and
SignatureSchemes for TLS 1.3 only exist as combinations with all parameters
specified. (Some SignatureSchemes, e.g. ed25519 and ed448 don't decompose
into a separate sig and hash.) It does not make sense to think about
decomposing the on-the-wire representation of a SignatureScheme into a
separate sig and hash.

> Should I submit an erratum changing the above text to point out that the
> encoding is incompatible and signature_algorithms needs to be decoded
> differently depending on whether it's coming from a 1.2 or 1.3 client?

I don't think an erratum or PR is necessary. A TLS 1.2 server can process
the extension as specified in RFC 5246 (and the TLS 1.3 values will be
ignored as {unknown hash, unknown algorithm}). A TLS 1.3 server can process
the extension as values from the TLS 1.3 SignatureScheme enum, even if TLS
1.2 is negotiated. There's no incompatibility here.

On Thu, Jul 15, 2021 at 7:53 AM David Benjamin <davidben@chromium.org>
wrote:

> The SignatureScheme change was perhaps overly clever, but the intent is
> that you can process them the same at both versions and backport
> the single-enum interpretation. (That's what we do.) The key observation is
> that TLS 1.3's allocations will never overlap with a defined TLS 1.2 hash
> or signature value. So an old implementation will never send a value that
> overlaps with TLS 1.3. More importantly, it will interpret any new TLS 1.3
> value as {unknown hash, unknown algorithm} and ignore it, which is what we
> want it to do anyway.
>
> That means an old implementation will interop just fine with new values,
> and we can freely recast the whole extension as SignatureSchemes in new
> implementations.
>
> On Thu, Jul 15, 2021 at 9:02 AM Eric Rescorla <ekr@rtfm.com> wrote:
>
>> As we are currently working on a 8446-bis, the best thing to do would be
>> to file a PR at:
>> https://github.com/tlswg/tls13-spec
>>
>> Thanks,
>> -Ekr
>>
>>
>> On Thu, Jul 15, 2021 at 3:56 AM Peter Gutmann <pgut001@cs.auckland.ac.nz>
>> wrote:
>>
>>> I've got some code that dumps TLS diagnostic info and realised it was
>>> displaying garbage values for some signature_algorithms entries.  Section
>>> 4.2.3 of the RFC says:
>>>
>>>       In TLS 1.2, the extension contained hash/signature pairs.  The
>>>       pairs are encoded in two octets, so SignatureScheme values have
>>>       been allocated to align with TLS 1.2's encoding.
>>>
>>> However, they don't align with TLS 1.2's encoding (apart from being
>>> 16-bit
>>> values), the values are encoded backwards compared to TLS 1.2, so where
>>> 1.2
>>> uses { hash, sig } 1.3 uses values equivalent to { sig, hash }.  In
>>> particular
>>> to decode them you need to know whether you're looking at a 1.2 value or
>>> a 1.3
>>> value, and a 1.2-compliant decoder that's looking at what it thinks are
>>> { hash, sig } pairs will get very confused.
>>>
>>> Should I submit an erratum changing the above text to point out that the
>>> encoding is incompatible and signature_algorithms needs to be decoded
>>> differently depending on whether it's coming from a 1.2 or 1.3 client?
>>> At the
>>> moment the text is misleading since it implies that it's possible to
>>> process
>>> the extension with a 1.2-compliant decoder when in fact all the 1.3 ones
>>> can't
>>> be decoded like that.
>>>
>>> Peter.
>>>
>>> _______________________________________________
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>