[TLS] New draft: Pseudorandom cTLS

Ben Schwartz <bemasc@google.com> Fri, 29 October 2021 13:47 UTC

Return-Path: <bemasc@google.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 C37133A120A for <tls@ietfa.amsl.com>; Fri, 29 Oct 2021 06:47:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 utk4Ze-K4QFE for <tls@ietfa.amsl.com>; Fri, 29 Oct 2021 06:47:35 -0700 (PDT)
Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (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 578133A120F for <tls@ietf.org>; Fri, 29 Oct 2021 06:47:35 -0700 (PDT)
Received: by mail-ua1-x92f.google.com with SMTP id x3so18151904uar.13 for <tls@ietf.org>; Fri, 29 Oct 2021 06:47:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=HL/Gwsr4ySSBMkKBgm9jW0etpS0+ivv4CiNMmuQS9r0=; b=fYCw8Cr/93ghBS7oB2CqyIUHk7v7sRRuyqVqrm7bHwkF1JfaLA+CJDeKM9wuUb72LI jT9+QqONAb+YLOKr3Wlvy9uecLl8tVJ41YFR3Z+DXom2zJSrf+xV+zIKKlzH7UyufNSQ DkT+xReT8wdxmQ6GShHgxSRfqXsB6KZBrrPtdtlFu6SMJ08jqeZTnV14DIL+UiE/VSF7 XPRq54FrAyLWVAhaf5EoXF4ypb+eZoRfPu6S0p+iHEhU7msl5LW+4IecKGUc692FvqhV 41PVJivHA9ZavehB65FuyImUASTyiFytw5YaxVsA7JOsIqVsIa3CJKyuQBYutMaavCnA cD5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=HL/Gwsr4ySSBMkKBgm9jW0etpS0+ivv4CiNMmuQS9r0=; b=D9C8HarIX6vHKxExK8Xedo/SdYLf8DanrIQoqfdO2k0QA9kHs+nuoy4V1hF0sEqDx0 i0moHEMc67r3TrXuExt02fDtAlNVOK/N5so8rn078Ooxig9k3VQuDhpxXbdHTwJ3U6th LfF39+dcwEeyKzjrgfxnm7R8y29+NfPulwEsNNkRTvUIyt/KDIGvfGokD9MH4Uefjy/+ MukcUWyr0cfPiFXjjlAaC1xYpUGpshna0YG/LmJ9TsrDRhEyYXnDfTJjemHcTFIvbxam p5fVccg86VigbmMcXfwoKhS8iJUU43GW0IEXnbQRYX8KtfHSRPWFh2BDBIsdair3ydCa CrYw==
X-Gm-Message-State: AOAM533lL2MNYaRN47H0BfiuqKpD9q3QKnEtfbwJKEPcMVH5XImd4vB2 30GEN2DoLsGhNgrsKNmFDqXenf2ybuMeSKDVPEI04YfYYQM7vw==
X-Google-Smtp-Source: ABdhPJy6HrVGivGDLnkrWt2cpBEiP7aKrmNWPEPqLiHKI7XmVGGxITNWWSjsS3z8XxkrIcla4iUIbnIF6ES2wzFmUtc=
X-Received: by 2002:ab0:6883:: with SMTP id t3mr3521848uar.66.1635515253141; Fri, 29 Oct 2021 06:47:33 -0700 (PDT)
MIME-Version: 1.0
From: Ben Schwartz <bemasc@google.com>
Date: Fri, 29 Oct 2021 09:47:22 -0400
Message-ID: <CAHbrMsBMir3Y7k1mjTDJh_rN+NsOrmebz8cnd7PjniL2ASSX3w@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="000000000000b7971505cf7e11ed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/5GSFkt7Ew4uULApxfFFhSknaU4Q>
Subject: [TLS] New draft: Pseudorandom cTLS
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: Fri, 29 Oct 2021 13:47:40 -0000

Hi TLS,

As discussed during the meeting at IETF 111, we’ve been working on an
extension to cTLS that transforms the record layer into a pseudorandom
bitstream on the wire, and it’s ready for its first review.

https://datatracker.ietf.org/doc/html/draft-cpbs-pseudorandom-ctls-00

Please review and send comments.  We’ll also be presenting an overview of
this draft at the upcoming TLS session.

This proposal depends heavily on the details of the cTLS headers, so it
will have to evolve as cTLS changes.  Part of the reason to develop it now
was to offer feedback on the cTLS design.  After developing this draft, we
offer the following suggestions and requests for cTLS proper.

 * Clarify extensibility rules.  cTLS enumerates keys in the template, but
does not explain how templates can be extended.
   - Suggestion: Clients must reject the whole template if it contains any
key they do not understand.  The “optional” key holds a map of optional
extensions that are safe to ignore.

 * Discuss encoding of Alerts.  It’s currently not clear how plaintext
Alerts are represented.
  - Suggestion: content_type = ctls_alert

 * Discuss fragmentation of handshake messages in cTLS/UDP.  The current
text doesn’t mention this, although it seems relatively clear how it’s
expected to work (using the DTLS Handshake struct).

 * Make fragmented handshake messages self-delimiting in cTLS/TCP so that
recipients can detect the end of a handshake message from the CTLSPlaintext
header alone.
   - Suggestion: Senders set content_type = ctls_handshake_end for a
message’s final fragment.

 * Make header size less variable.  For cTLS/TCP, the headers could all be
the same size.  For cTLS/UDP, the header sizes could be made predictable.
   - Suggestion: Always suppress sequence numbers and disallow connection
IDs in cTLS/TCP.  Move profile_id into ClientHello.  Always include the
connection ID and sequence number in the first record of a cTLS/UDP
datagram, and never in subsequent records.

Thanks,
Ben Schwartz, Chris Patton