Eric Rescorla's Discuss on draft-ietf-httpbis-encryption-encoding-08: (with DISCUSS and COMMENT)

[Eric Rescorla <[e-mail]>]

Eric Rescorla has entered the following ballot position for
draft-ietf-httpbis-encryption-encoding-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-encryption-encoding/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

   The "aes128gcm" content coding uses a fixed record size.  The final
   encoding consists of a header (see Section 2.1) and zero or more
   fixed size encrypted records; the final record can be smaller than
   the record size.

This restriction seems to be an artifact of your previous design which
used short records as an end marker.  With the new padding delimeter
structure (which I note is isomorphic to the TLS 1.3 structure), I'm
not seeing any reason to require that the records be fixed length (as
they are not in TLS). I didn't see any discussion of this point in the
thread where this structure was designed, so I'd like to get
confirmation that the WG considered this point and decided to continue
with the above restriction. I'll clear this discuss upon either such
confirmation
or removal of the restriction.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


S 2.1.
You should say what idlen is. The QUIC notation here isn't defined :)

S 2.2/2.3.
Can you make clearer that the strings don't have their own null
termination. I.e, that what is fed into the CEK generation function
is  .... 32  38  67  63  6d 00 01
not .... 32  38  67  63  6d 00 00 01


S 4.6.
  
   This mechanism only offers encryption of content; it does not
perform
   authentication or authorization, which still needs to be performed
   (e.g., by HTTP authentication [RFC7235]).

This text is kind of confusing, because the mechanism does provide
data origin authentication. I think you mean that if the server is
just going to process this as an opaque and stuff it somewhere, then
it needs extra authentication? This seems like a layering issue.


S 4.7.
Some citations to some of the various padding traffic analysis papers
might be useful.

   Distributing non-padding data is recommended to avoid
   leaking size information.

I think you mean "distributing this across the records".