Hybrid key exchange in TLS 1.3
draft-ietf-tls-hybrid-design-16

Thanks to Rifaat Shekh-Yusef for their secdir review. 

References:  The references for IND-CCA2, IND-CPA as well as the Fujisaki-Okamoto transform, and maybe HHK should be normative.  My reservation here is the fact that the reference for the first two is a textbook, which is certainly 'stable', but hardly freely available.  I'm going to bet that Katz has references for both of the first two security properties. [note: the textbook reference has a typo - Introductino/Introduction]

# Éric Vyncke, INT AD, comments for draft-ietf-tls-hybrid-design-14
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

Special thanks to Joe Salowey for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric


## COMMENTS (non-blocking)

### Section 1.2

s/Algorithms which are widely deployed today, but *which* may be deprecated in the future/Algorithms *that* are widely deployed today, but may be deprecated in the future/ ?

Same for 'next-gen' ;-) I sincerely hope that TLSng will be faster to deploy than IPng, aka IPv6... ;-)

Who is the "we" in `we do not limit`? The authors, the WG, the IETF ? Please avoid using ambiguous "we" in an IETF document.

After introducing "component" and "composite", the text states `It is intended that the composite algorithms` while the preceeding text seems to prefer not using "composite". Nothing dramatic but puzzling.

s/that is not Diffie-Hellman-based nor a group/hat is *neither* Diffie-Hellman-based nor a group/ ?

### Section 1.4

s/session authentication cannot be retroactively broken/breaking retroactively session authentication is pointless/ ?

### Section 1.5

When reading the part about the sheer size of the key exchange, I wonder whether some text (perhaps in another doc) should be authored for 'contrained' networks (being in ressource or network bandwidth). Strongly suggest adding a sentence around "Using hybrid in constrained systems may not be suitable" or something similar to state that the TLS WG have not ignored the "IoT world".

### Section 2

While I trust the I-D authors to know more than me, I am puzzled by reading "secret key" rather than "private key", which seems more popular.

Please add another informational reference to explain what "IND-CCA2" is (and later in the text "IND-CPA").

The last sentence contains 2 "MUST", but aren't these "MUST" applicable to *any* key TLS key exchange ? I.e., not only to "hybrid" ones ?

### Section 3.3

As non-US "NIST" may appear, let's s/NIST/US NIST/ (and possibly expand NIST).

### Section 4

Should there be an informal reference to `Classic McEliece`?

Should the "can" in `Clients can retry if a failure is encountered` be replaced by "MAY" or even a "SHOULD" ?

### Section 5

Please add an informal reference to the IANA registry URI https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8.

I was not expected an informational RFC to state such a strong binding statement `For these entries in the TLS Supported Groups registry, the "Recommended" column should be "N" and the "DTLS-OK" column should be "Y".` (at least this is a "should"... should this has been a "SHOULD" ?).

Suggest to add guidance to IANA to implement `These assignments should be made in a range that is distinct`


## NITS (non-blocking / cosmetic)

### E.g.

AFAIK, "e.g." should be surrounded by ",".

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg too to generate SVG graphics. It is worth a try especially if the I-D uses the Kramdown file format ;-)

This is a solid and well-written document. Thank you.

In Section 1, it says "Some authors prefer...." It might be useful to be clear which authors are being referenced here -- authors of this RFC? Authors of referenced research papers? Authors of future hybrid specifications?

I appreciate the appendix of related work. You specifically call out one reference as "an overview of post-quantum cryptography as of 2009," which invites the question of why this is the best reference 16 years later. I would either drop the date (if it's still the best overview around) or add a few words stating that while dated, it remains a valuable resource because of [foo].

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

Thank you to Paul Kyzivat for the GENART review.