Re: [TLS] PR#28: Converting cTLS to QUIC-style varints

Anders Rundgren <anders.rundgren.net@gmail.com> Wed, 07 October 2020 19:14 UTC

Return-Path: <anders.rundgren.net@gmail.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 466FF3A131B for <tls@ietfa.amsl.com>; Wed, 7 Oct 2020 12:14:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.311
X-Spam-Level:
X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 ExXKKXwTgW4r for <tls@ietfa.amsl.com>; Wed, 7 Oct 2020 12:14:40 -0700 (PDT)
Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) (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 7BA513A1317 for <tls@ietf.org>; Wed, 7 Oct 2020 12:14:40 -0700 (PDT)
Received: by mail-wm1-x343.google.com with SMTP id q5so3765687wmq.0 for <tls@ietf.org>; Wed, 07 Oct 2020 12:14:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=kjxCGCtRZuT/CHmqp7Wt/7gr1FG0mw4xwAARgAeL5y8=; b=e2NdYjWEbtHMIGhud3I2hFMf3wfCVryGsX19zYkiqrszj5M6pC8TNKtqc7RcGAkqn7 rc6kRuhDARlAPTqPJNozrG9IeD0zhJXobM8qjnt2qCHd4TQ7Sz1Ern2e7qWvuwcutpi8 gIA+TyoMPS58nYnxJmqbkK5NIhUtH6eWtq1IleJKztXcBoV5D7wIpNbYHCrUkBn4cmhL 1LJ63sc9KEByez71qUwAgIEcUsTJ2dgJ8Qh1ZPTi8UTkCOayC3+egzzWK8wYq020u640 FUEnrqYQX0kcZnUgiar8uzPjQjoPmrrElNzrQPADyxtSdDn4O9wKxrivYF6b5gxDGJls f2bw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=kjxCGCtRZuT/CHmqp7Wt/7gr1FG0mw4xwAARgAeL5y8=; b=Pxwc2Svq/AHzCm59OtiyarTvMqKMrPf5Ce0lRzGDzXR3xp9z1+a2EmIdyLnDrhIbuL w0QGtWAzVDEmzVfhxCHLzT0B1fw7dMXw5cdAq/McJehqfUfaCK+aZORSpR8jgFyHYm6X Mmo8zjfaEkGRXXwuVZeygyhK28uh+kIsuTBUezaaj3/iVS29LCv5nBtdUlQ3gq5NiYD4 OjecZkmtmOVza79BXNJkeXBWALvC6FDWUdhNyieC5y4coxoHYGTT7qbfL5K1pflL4uiy xiB40aLGPma2weHqpQneWJbge8mO7giyP7OcFz4AOhxWQ//OsWDRnoavc2/2iJ1EcPcL Tm0Q==
X-Gm-Message-State: AOAM532fQuorf2yrukwu9/EVkQ+EgQAeCZZ30bGyxKOPkvThDyKhkxWY YtE2LyMMPxRwEGDd8BiWfReMpYnv53fV2w==
X-Google-Smtp-Source: ABdhPJy65WjbrbtlB61wsmV9XYe98ncfsPx3BKFc7HRTy0+lpOf3K//hUy2rShKDoQU8qVqy1wdulQ==
X-Received: by 2002:a1c:3bd4:: with SMTP id i203mr4096574wma.28.1602098078367; Wed, 07 Oct 2020 12:14:38 -0700 (PDT)
Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id b25sm1643602wmj.21.2020.10.07.12.14.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Oct 2020 12:14:37 -0700 (PDT)
To: Mohit Sethi M <mohit.m.sethi=40ericsson.com@dmarc.ietf.org>, Watson Ladd <watsonbladd@gmail.com>, Christian Huitema <huitema@huitema.net>
Cc: "tls@ietf.org" <tls@ietf.org>
References: <CABcZeBPNFhGoLhgqeR9ObwyU68BYq=hXG1PhXcqNsNDNFGGyaw@mail.gmail.com> <CAOYVs2rEDtgJFVpiQkcaaYG2LAyW1hB5Cou4kUoG2_dkxMFTww@mail.gmail.com> <CABcZeBP3BUDEeiV2T-kxYTmC841XE_BrXhPHSoRqfdH0hHd-6w@mail.gmail.com> <BBA456AB-EC42-47DD-A3E3-5FC0E9E7A534@akamai.com> <53DD7D0D-D325-4246-86F2-C409875134FB@ll.mit.edu> <8e8ca76e-37ce-ce10-ae42-ea26d87c35fc@pobox.com> <9CED80DA-FAE7-4C7F-9687-3B61B63587E9@akamai.com> <a49d4b8c-cf49-51df-0c6b-332a4459f318@pobox.com> <b8f4597c-37de-0092-6179-c6bf275c20f9@huitema.net> <CACsn0c=V035wmmhwTzJoREHwmGJmVujcdm0LQKQqLCCBRzv4oQ@mail.gmail.com> <0fbf5f36-9480-ceb6-dc20-5e27e41061a8@ericsson.com>
From: Anders Rundgren <anders.rundgren.net@gmail.com>
Message-ID: <d6556cb3-260c-f120-4e52-fff205ced760@gmail.com>
Date: Wed, 7 Oct 2020 21:14:33 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: <0fbf5f36-9480-ceb6-dc20-5e27e41061a8@ericsson.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/L_2FrJFxIwBybyr3_RNvNq6tn9s>
Subject: Re: [TLS] PR#28: Converting cTLS to QUIC-style varints
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: Wed, 07 Oct 2020 19:14:42 -0000

On 2020-10-07 19:47, Mohit Sethi M wrote:
> A strong +1 on the security issues of decode -> extract -> re-encode ->
> verify signature flow. The lack of canonical encoding can also mean that
> the resulting bytes can be different in different encoder/decoder
> implementations.
> 
> It would have been nice to have canonical JSON. Some implementations
> support it with flags such as "JSON_PRESERVE_ORDER"
> (https://jansson.readthedocs.io/en/2.8/apiref.html). Some specs try to
> specify things like keys should be in alphabetical order but fail to
> realize the complication with nested structures.

Hi Mohit,

Since a few months back there is an RFC (8785) which specifies a
scheme for canonicalizing JSON, albeit limited to the JSON subset
supported by ECMAScript and browsers.

It can be tested in an on-line application where it is combined with
JWS: https://mobilepki.org/jws-jcs/home

Anders

> 
> CBOR has thankfully specified canonical representation (called as
> deterministic encoding in 7049bis). Some CBOR libraries have added
> support: https://github.com/agronholm/cbor2/issues/6.
> 
> --Mohit
> 
> On 10/7/20 7:30 AM, Watson Ladd wrote:
>> On Tue, Oct 6, 2020 at 10:13 AM Christian Huitema <huitema@huitema.net> wrote:
>>> On 10/6/2020 10:00 AM, Michael D'Errico wrote:
>>>
>>>> It matters in X.509 certificates because the basic
>>>> encoding rules (BER) allow you to specify the same
>>>> thing in different ways.  With DER, there is only
>>>> one way to encode every element, so everybody will
>>>> come up with the same string of bytes and hashes of
>>>> those strings will be the same, signatures will
>>>> verify, etc.
>>>
>>> Well, we have learned a few things since 1994. The DER rules are defined
>>> to allow a "re-encoding" workflow:
>>>
>>> * Sender side: prepare the message, encode with DER, sign the result
>>>
>>> * Receiver side: receive the message, parser with generic ASN.1 decoder,
>>> process the message using the "parsed" representation, re-encode with
>>> DER, check the signature.
>>>
>>> Experience showed that this workflow is very problematic, because the
>>> parse/reencode process may introduce subtle changes and the signature
>>> will fail.  One may argue that these changes are due to implementation
>>> bugs, but fact it that this is a rich environment for growing bugs.
>>> Based on experience, the receiver side is better done as:
>>>
>>> * Receiver side: receive the message, save it, parse and process, and
>>> when it is time to verify the signature go back to the original message
>>> and check the signature.
>> Examining signed data ahead of verification, particularly to determine
>> what should have signed it, is fraught with issues. In particular
>> parser errors that would only be exploitable by trusted parties become
>> exploitable by anyone. Furthermore, you should know the expected
>> signer ahead of time. That this isn't possible in X509 due to
>> inordinate flexibility is one of many pitfalls for implementors. This
>> sort of issue periodically leads to authentication bypasses and other
>> such fun.
> A strong +1 to this.
>>
>> Sincerely,
>> Watson Ladd
>>
>>
>>
>> --
>> Astra mortemque praestare gradatim
>>
>> _______________________________________________
>> 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
>