Comments on draft-ietf-httpbis-encryption-encoding-04

Eric Rescorla <> Sat, 12 November 2016 06:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 678ED1299A7 for <>; Fri, 11 Nov 2016 22:34:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.397
X-Spam-Status: No, score=-8.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nLS3L9Kl2uaE for <>; Fri, 11 Nov 2016 22:34:52 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CEA5A1299A2 for <>; Fri, 11 Nov 2016 22:34:52 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1c5RqX-00023o-3L for; Sat, 12 Nov 2016 06:31:25 +0000
Resent-Date: Sat, 12 Nov 2016 06:31:25 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1c5RqN-00022O-R6 for; Sat, 12 Nov 2016 06:31:15 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <>) id 1c5RqH-0003pm-Ri for; Sat, 12 Nov 2016 06:31:10 +0000
Received: by with SMTP id v78so11105079ybe.3 for <>; Fri, 11 Nov 2016 22:30:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=FReFect+++RV0duROi7MIlIYpVp2C0d4yrCFco/rK7A=; b=AR5LW0nQx3Atm4jjs//qishhu3KhdVGqp1da6+HW2cLQsTKHp0LRBVfS34jBFkwOtM MAqzTa3H24qyrmTmPiRbTKP8mkchgDJg1L/hNcWC1j64AWJHiWgyKBQuS3MtQ/dtlvbF t5VPwuo7mObFG3/IyxfrlTZNX9SS8g71E5XjCTA0auXwyNJ+WlCMvxvRtnehC7BkEkiB 0Fx73uQ6TZPEM2vtbAl5NJ4taF05n3nLr5NsPy+wM9inD5zQfYv6ULCu4zrmW1ixRhrw WSlhmJFeA1VHls//hvjYYFJSa7MJDBL7TskDxkV0MCWjt57jckKzM+oxiJvz208RzfVY y1uw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=FReFect+++RV0duROi7MIlIYpVp2C0d4yrCFco/rK7A=; b=UIbbP1xJ5l+2uyftqxjbnKOVtG51yXtxAcox4gn3Jq5dW68D5pH44Ad9aHj7fragqF dC7e4ltgYCXDUyQPprFxdqJc+s1wMjjSLifsJGpm08WF2EJmkBAs0e0ynLGUegycOME+ fTpe8PVkLuj3Pjp651kmqhwLwQKqyza7UHA2Gxh3/CArVt3sFDwj4HjqEC2O1lApVbl/ E74JI0YBAGxN5n82QHp0fHV0Y+pZC0XH8p3rag4oa6u5MRvtltlm61PvZIqMalwrwvCI LIxV5P07jYDQ9awWD/g51YAlQd6GYdBwTNruwmpAoQbcwe1Qrk7bJloqOlb/qriw16E9 Uvuw==
X-Gm-Message-State: ABUngveGs0g37fHUXh7i9KsvSIXMToKXNmlNu9g/eOsbSEDE8WFwTNmXhRLzWqV2Zk4qOehbKKVbdGZexjE7Wg==
X-Received: by with SMTP id t9mr6680970ybd.107.1478932243383; Fri, 11 Nov 2016 22:30:43 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 11 Nov 2016 22:30:02 -0800 (PST)
From: Eric Rescorla <>
Date: Fri, 11 Nov 2016 22:30:02 -0800
Message-ID: <>
To: HTTP Working Group <>
Content-Type: multipart/alternative; boundary=f403045db07403b816054114bf0d
Received-SPF: none client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-6.4
X-W3C-Hub-Spam-Report: AWL=-0.451, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1c5RqH-0003pm-Ri ce9535a222b00f5a59f101bdd2480357
Subject: Comments on draft-ietf-httpbis-encryption-encoding-04
Archived-At: <>
X-Mailing-List: <> archive/latest/32866
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Please find some comments on the most recent revision.


S 2.1.
  The "rs" or record size parameter contains an unsigned 32-bit
  integer in network byte order that describes the record size in
  octets.  Note that it is therefore impossible to exceed the
  2^36-31 limit on plaintext input to AEAD_AES_128_GCM.  Values
  smaller than 3 are invalid.

I don't believe that this is correct, because the limit is on the
total number of bytes with the same key, not on the total number
of bytes with one nonce.

S 2.2.
   Why are you using the terminal 0x00 here? I don't see anywhere
   else you HMAC on cek_info without it.

S 3.
This whole Crypto-Key thing seems like a menace. As has been noted,
it's a terrible idea to provide Crypto-Key and encrypted data
for the same key in the same HTTP message, but that's the only
thing you see to support:

   The value or values provided in the Crypto-Key header field is valid
   only for the current HTTP message unless additional information
   indicates a greater scope.

Do we have a concrete use case for Crypto-Key? If not, I would remove
it. If so, I would consider writing a different spec.

S 2.
You should put the graf starting with "The record size" above the diagram
because the diagram rs.

  To prevent an attacker from truncating a stream, an encoder
  MUST append a record that contains only padding and is smaller than
  the full record size if the final record ends on a record boundary.

I would invert the logic here. I.e.,

  If the final record ends on a record boundary, the encoder MUST
  append a record that contains...

  Each record contains between 2 and 65537 octets of padding, inserted
  into a record before the enciphered content.

I think it's kind of a mistake to treat the padding length as part of the

  A consequence of this record structure is that range requests
  [RFC7233] and random access to encrypted payload bodies are possible
  at the granularity of the record size.  Partial records at the ends
  of a range cannot be decrypted.  Thus, it is best if range requests
  start and end on record boundaries.

This is sort of true, but it's not like you can randomly access the
underlying data because there might be padding and you don't know.

S 2.2.
   In order to allow the reuse of keying material for multiple different
   HTTP messages, a content encryption key is derived for each message.
   The content encryption key is derived from the decoded value of the
   "salt" parameter using the HMAC-based key derivation function (HKDF)
   described in [RFC5869] using the SHA-256 hash algorithm [FIPS180-4].

"decoded value" is weird here.