[TLS] Mohamed Boucadair's No Objection on draft-ietf-tls-hybrid-design-15: (with COMMENT)

[Mohamed Boucadair via Datatracker <[e-mail]>]

Mohamed Boucadair has entered the following ballot position for
draft-ietf-tls-hybrid-design-15: No Objection

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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/



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

Hi Douglas, Scott, and Shay,

Thank you for the effort put into this well-written document. It is an
interesting read.

Thanks also to Tim Chown for the OPSDIR review and the authors for engaging.

Please find below some comments:

# Why is this Informational?

The justification in the writeup seems clear to me. I do think that it would be
useful to mirror in the abstract or the Introduction the main message grabbed
from the writeup:

“It does not modify TLS directly, but rather using existing mechanisms and code
point registries. It does not define any specific hybrid key exchanges.”

This statement may be revisited based on the outcome of the next item.

# Relaxing a MUST in the base TLS spec?

CURRENT:
   [TLS13] requires that ``The key_exchange values for each
   KeyShareEntry MUST be generated independently.'' In the context of
   this document, since the same algorithm may appear in multiple named
   groups, this document relaxes the above requirement to allow the same
   key_exchange value for the same algorithm to be reused in multiple
   KeyShareEntry records sent in within the same ClientHello.

Isn’t this modifying aspects of the base TLS? How to reconcile this with the
claim in the previous point?

# IANA considerations

Unless I missed something the document provides guidance for future
assignments. Shouldn’t a note be added to the TLS registry to track this
guidance and/or add this document as a reference to the registry?

As I’m there,

CURRENT:
For these entries in
   the TLS Supported Groups registry, the "Recommended" column SHOULD be
   "N" and the "DTLS-OK" column SHOULD be "Y".

I guess this should be the value used in the initial registration. The
recommended value may in theory evolve in the future (far future, maybe). If
so, can we make that explicit in the document?

# Minor/nits

## Section 1.2

OLD: for example, FIPS compliance.
NEW: for example, US National Institute of Standards and Technology (NIST) FIPS
compliance.

## Section 1.5

OLD: as long as as
NEW: as long as

## Section 2

CURRENT:
   The main security property for KEMs is indistinguishability under
   adaptive chosen ciphertext attack (IND-CCA2), ..
                                      ^^^^^^^^

   A weaker security notion is indistinguishability under chosen
   plaintext attack (IND-CPA),
                     ^^^^^^^^

Can we cite references for these two?

## Section 3.2

CURRENT:
   Recall that in TLS 1.3 a KEM public key or KEM ciphertext is
   represented as a KeyShareEntry:

Can we have an explicit reference to rfc8446#section-4.2.8 for readers
convenience?

Idem for:

CURRENT:
   [TLS13] requires that ``The key_exchange values for each

Cheers,
Med