Subject: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design

From: Douglas Stebila <[email-masked]>
Date: Wed, 12 Feb 2020 14:26:21 -0500

Dear TLS working group,

We would like to request the working group adopt
draft-stebila-tls-hybrid-design, "Hybrid key exchange in TLS 1.3", as
a working group item.  We have updated the draft based on feedback
we've received over the past few months, including from our
presentations at IETF 104 and 105, and think the current version
represents the view of the WG to date.

https://datatracker.ietf.org/doc/draft-stebila-tls-hybrid-design/

Cheers,

Douglas

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 13 Feb 2020 07:46:51 +1100

> represents the view of the WG to date.

I agree that we should adopt this.  I think that the draft is broadly in the right shape.

Skimming through I noticed a few things that I would prefer to see eventually changed, but we can do that in the working group.

At a high level, I think that this would be easier if it were more clearly framed as *recommendations*, especially when it comes to the format of key shares and the input secret.  One advantage of the macro-level design is that the format is can be specified on a case-by-case basis.  For instance, variable-length values might be length-prefixed; fixed size values don't need to be.  That might avoid having to directly specify a single format. 

S 3.1 (Negotiation) suggests that a portion of the named group space be reserved for this use.  I think that is a bad idea because it implies semantics where none are necessary.  Picking codepoints as usual should suffice; indeed, random allocation might be ideal.

The concatenation approach is definitely my preferred approach, but the inconsistency between the design for key shares and secrets is curious.  This design assumes that shares are length-delimited; secrets are not.  The latter implies that the `ss` needs to be fixed length for a given algorithm (both the PQ and classical parts), but `ct`/`pk` does not.  I can guess at why, but when you can avoid the question, then I think you should.  That is, in favour of more generic recommendations on structure.

To answer some of the open questions:

Larger public keys and/or ciphertexts - if we need these, we're in serious trouble.  To give you an idea, even at 1k, these will start being much harder to deploy.  Getting close to 64k adds all sorts of complication.  Better to defer support for big messages.  Acknowledging the limitation should suffice.

Duplication of key shares - not so much an open question as something the draft could acknowledge as a cost.  As previously discussed X25519 is small enough that duplication doesn't hurt enough to care.

Variable-length shared secrets - see above.

Resumption - I would be supportive of policy recommendations about the strength of key exchange on resumption, but as we allow straight resumption without PSKs, this cannot be standardized.

Failures - If this were low enough, I'd be happy to try again.  From our perspective, this isn't technically challenging, it's merely annoying. If this were very low probability (as I would expect), then we might just accept the loss of the occasional connection attempt.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 12 Feb 2020 21:44:12 +0000

I'm jumping in late - so apologies in advance for potential ignorant comments:

On 2/12/20, 3:48 PM, "TLS on behalf of Martin Thomson" <[email-masked] on behalf of [email-masked]> wrote:

>  Larger public keys and/or ciphertexts - if we need these, we're in serious trouble. 
> To give you an idea, even at 1k, these will start being much harder to deploy.
> Getting close to 64k adds all sorts of complication.  

You saw the key sizes that the NIST PQC candidates require? How would you suggest dealing with them unless there's support for larger public keys?

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 13 Feb 2020 08:57:34 +1100

On Thu, Feb 13, 2020, at 08:44, Blumenthal, Uri - 0553 - MITLL wrote:
> You saw the key sizes that the NIST PQC candidates require? How would 
> you suggest dealing with them unless there's support for larger public 
> keys?

Only a few of them.  Some are OK, but the number is few, I agree.  I haven't found a good summary of the second round candidates and I don't have time to dig into all of the candidates.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Feb 2020 22:49:36 +0000

Hiya,

On 12/02/2020 21:57, Martin Thomson wrote:
> Only a few of them.  Some are OK, but the number is few, I agree.  I
> haven't found a good summary of the second round candidates and I
> don't have time to dig into all of the candidates.
Fine reason to wait and see IMO.

I'd be much happier adopting this if we did that with
the explicit understanding that we won't produce an
RFC until the "winners" in the NIST process are known
and their properties understood. (I don't mean waiting
for a FIPS or formal NIST document but at least for
the final announcement from their process.)

If the plan were to adopt this and produce an RFC now
(e.g. to mix different curves or something) then I am
against that. There's no need for such combinations so
the real rationale here is PQC and we (at least I, but
I suspect also many IETF participants) don't know enough
about the relevant algorithms yet. (And expecting us
to be knowledgeable about 25+ algorithms isn't realistic.)

Cheers,
S.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 12 Feb 2020 22:57:07 +0000

I don't expect you to be knowledgeable about 25+ proposed algorithms.

I expect you to be knowledgeable about the ballpark of the new key sizes that practically all of the candidates use. The shortest keys are in the ballpark of a few KB, and I won't go into the size of the largest ones.

You may not want to *adopt* them now - but you better be ready to support Key Exchange for sizes far larger than what's currently implemented. And keep in mind that while Signatures aren't a priority yet, that will come eventually.

On 2/12/20, 5:50 PM, "Stephen Farrell" <[email-masked]> wrote:
  
    Hiya,

    

    Cheers,
    S.

---

From: "Pettis, Darin P" <[email-masked]>
Date: Wed, 12 Feb 2020 22:58:30 +0000

+1   Agreeing with Stephen is new to me but there is a first time for everything.  ;-)

Darin

-----Original Message-----
From: TLS <[email-masked]> On Behalf Of Stephen Farrell
Sent: Wednesday, February 12, 2020 4:50 PM
To: Martin Thomson <[email-masked]>; Blumenthal, Uri - 0553 - MITLL <[email-masked]>; [email-masked]
Subject: [EXTERNAL] Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design

Hiya,

I'd be much happier adopting this if we did that with the explicit understanding that we won't produce an RFC until the "winners" in the NIST process are known and their properties understood. (I don't mean waiting for a FIPS or formal NIST document but at least for the final announcement from their process.)

If the plan were to adopt this and produce an RFC now (e.g. to mix different curves or something) then I am against that. There's no need for such combinations so the real rationale here is PQC and we (at least I, but I suspect also many IETF participants) don't know enough about the relevant algorithms yet. (And expecting us to be knowledgeable about 25+ algorithms isn't realistic.)

Cheers,
S.

U.S. BANCORP made the following annotations
---------------------------------------------------------------------
Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation.

---------------------------------------------------------------------

---

From: Carrick Bartle <[email-masked]>
Date: Wed, 12 Feb 2020 15:01:26 -0800

> At a high level, I think that this would be easier if it were more clearly framed as *recommendations*

I'm brand new to the IETF, so please forgive me if I'm totally off base here, but my understanding is that Informational RFCs are explicitly not recommendations (let alone mandates)?

Per https://ietf.org/standards/process/informational-vs-experimental/:

'An "Informational" specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation.'

> On Feb 12, 2020, at 12:46 PM, Martin Thomson <[email-masked]> wrote:
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 13 Feb 2020 10:22:58 +1100

On Thu, Feb 13, 2020, at 10:01, Carrick Bartle wrote:
> I'm brand new to the IETF, so please forgive me if I'm totally off base 
> here, but my understanding is that Informational RFCs are explicitly 
> not recommendations (let alone mandates)?

This would of course be information, but my comment was about phrasing.  This document comes off as being quite prescriptive, where it doesn't really need to be.  Absent actual algorithms, it's just a set of guidelines.  That's reflected in its Informational status, but it would be better if the verbiage also reflected that more clearly.

To address Stephen's comment at the same time: I think that we can publish an RFC on this before the competition completes if it is just a framework.  That might in fact make standardizing the one true composite scheme easier.

---

From: Watson Ladd <[email-masked]>
Date: Wed, 12 Feb 2020 15:41:13 -0800

> To address Stephen's comment at the same time: I think that we can publish an RFC on this before the competition completes if it is just a framework.  That might in fact make standardizing the one…

What's the point of composite schemes after the NIST competition
finishes? The reason imho to have composite schemes now is to be able
to do deployment experiments where the security of the postquantum
scheme doesn't negatively impact the confidentiality of the
transmitted data. Obviously after a scheme has significant
cryptanalysis thrown at it, the value of a composite decreases because
the scheme is considered much more secure, and so the composite adds
much less security and still has costs.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Feb 2020 23:52:28 +0000

Hiya,

> I don't expect you to be knowledgeable about 25+ proposed 

I didn't mean it was you forcing that on me, but if you
want to give it a shot... :-)

> 
> I expect you to be knowledgeable about the ballpark of the new key 
> sizes that practically all of the candidates use. The shortest keys 
> are in the ballpark of a few KB, and I won't go into the size of the 
> largest ones.

Sorry but my understanding is that there are relatively
complicated combinations involving both performance and
sizes of the various PDUs and stored keys involved. I don't
think it'd be a good plan to specify how to handle that
on the Internet until the details are better known and
understood and the set of possible options is small enough
to be sensibly evaluated in detail. IMO, we're not there
yet. (And I'll bet a beer that even after we have 'em,
each of the "winners" arrives with 5 or so variants;-()

> 
> You may not want to *adopt* them now - but you better be ready to 
> support Key Exchange for sizes far larger than what's currently 
> implemented. And keep in mind that while Signatures aren't a
> priority yet, that will come eventually.

We knew that years ago. The sky hasn't fallen yet. I
doubt it'll fall in the next 12-18 months. In contrast
I would not be at all surprised to find we'd made a
well-meaning mistake in trying to standardise this
stuff in the absence of a broad understanding of the
detail.

Maybe putting it another way might help: my experience
is that the worst work I've done involved such ignorance
and what I think of as the less bad work I've done did
not. Maybe others are better than me at dealing with
"known unknowns" though, though IIRC the circumstances
that lead to that phrase didn't pan out as well as had
been hoped.

And one minor addendum:

On 12/02/2020 23:41, Watson Ladd wrote:
> finishes?

SHA-0:-)

Cheers,
S.

> I'd be much happier adopting this if we did that with the explicit 
> understanding that we won't produce an RFC until the "winners" in
> the NIST process are known and their properties understood. (I don't
> mean waiting for a FIPS or formal NIST document but at least for the
> final announcement from their process.)
> 
> If the plan were to adopt this and produce an RFC now (e.g. to mix 
> different curves or something) then I am against that. There's no 
> need for such combinations so the real rationale here is PQC and we 
> (at least I, but I suspect also many IETF participants) don't know 
> enough about the relevant algorithms yet. (And expecting us to be 
> knowledgeable about 25+ algorithms isn't realistic.)
> 
> Cheers, S.
> 
> 
>

---

From: Rob Sayre <[email-masked]>
Date: Wed, 12 Feb 2020 20:24:03 -0800

> https://datatracker.ietf.org/doc/draft-stebila-tls-hybrid-design/

Hi,

Thanks for submitting this draft.

Would it be ok to add a rationale to the "Goals" section around backward
compatibility? I'm not sure how the compatibility points will interact with
downgrade attacks.

thanks,
Rob

---

From: Douglas Stebila <[email-masked]>
Date: Thu, 13 Feb 2020 06:39:46 -0500

Hi Martin,

Thanks for the suggestions.  Indeed, happy to incorporate changes in framing, tone, etc. to better reflect the purpose of the document.

> [...]

There are examples of current PQ candidates that have variable sized ct / pk: SIKE has compressed and uncompressed variants, which are mathematically interoperable and would result in the same shared secret, but trade smaller communication for more computation.

To the best of my knowledge, none of the current PQ candidates have variable sized shared secrets.

We did have some debate internally when preparing the draft about whether shared secrets should have length encoding or not, and in the end decided not, despite the apparent inconsistency in design.

Douglas

---

From: Douglas Stebila <[email-masked]>
Date: Thu, 13 Feb 2020 06:48:21 -0500

On Feb 12, 2020, at 11:24 PM, Rob Sayre <[email-masked]> wrote:
> 
> Would it be ok to add a rationale to the "Goals" section around backward compatibility? I'm not sure how the compatibility points will interact with downgrade attacks.

For now I don't think we're envisioning anything different on downgrade compared to current DH group negotiation.  For example, a client that prefers curve25519 but also is willing to use nistp256 should be able to talk to a server that only supports nistp256.  If the server also supports curve25519, an adversary who removes curve25519 from a hello message to try to trick them into 'downgrading' to nistp256 would eventually be caught by the handshake transcript authentication.  The same holds in this setting.

Douglas

---

From: "Dang, Quynh H. (Fed)" <[email-masked]>
Date: Thu, 13 Feb 2020 15:36:05 +0000

This website has a good summary of the candidates: https://pqc-wiki.fau.edu/w/Special:DatabaseHome  .

Quynh.
________________________________
From: TLS <[email-masked]> on behalf of Martin Thomson <[email-masked]>
Sent: Wednesday, February 12, 2020 4:57 PM
To: Blumenthal, Uri - 0553 - MITLL <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design

_______________________________________________
TLS mailing list
[email-masked]
https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&amp;data=02%7C01%7Cquynh.dang%40nist.gov%7C66ec528552554b52d03f08d7b006af16%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637171415063382880&amp;sdata=DdG71mohtkyXCdRplxvT1z5JWRvg53RqO98BKqswIw4%3D&amp;reserved=0

---

From: Rob Sayre <[email-masked]>
Date: Thu, 13 Feb 2020 14:28:32 -0800

On Thu, Feb 13, 2020 at 3:48 AM Douglas Stebila <[email-masked]> wrote:

> For now I don't think we're envisioning anything different on downgrade
> compared to current DH group negotiation.  For example, a client that
> prefers curve25519 but also is willing to use nistp256 should be able to
> talk to a server that only supports nistp256.
>

This idea is what my question concerns. I'm not sure there should be a
negotiation of that sort, but the WG can sort that out.

thanks,
Rob

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 15 Feb 2020 18:39:46 +0200

> https://datatracker.ietf.org/doc/draft-stebila-tls-hybrid-design/

Some comments and related sidenotes:

- If additional round trips are to be avoided, the public key size
  should be kept low so client hello does not grow so large that
  significant amount of servers barf on it. [LANGLEY] notes that
  3300 bytes was about the maximum they could use.

- That TLS 1.3 does not talk about client-side key reuse seems to
  be a mistake. It for example says SHOULD NOT reuse tickets, with
  rationale that also appiles to client side keys.

- The draft talks about "any KEM used in this document". Which sounds
  odd, given that this document does not define any KEMs.

- The reasons to not reuse public keys, even with CCA-secure KEMs,
  impiles that the relevant benchmarks are:

  * Combined key generation and decapsulation time.
  * Single-thread encapsulation time.
  * Peak memory usage by key generation and decapsulation.
  * Peak memory usage by encapsulation.
  * Size of public key
  * Size of ciphertext
 
  For KEMs used as key exchanges, using decapsulation time alone is
  perverse due to problems with key reuse, again even with CCA-secure
  KEMs.

- Assigning specific range for Hybrid KEX. What is the use of that?
  The server recognizing that client supports Hybrid KEX even if there
  is no algorithm overlap? What the server would do with that
  information?

- The draft has specific data structures. This only makes sense if
  other drafts are to refer to it or are intended to copy the data
  structure definitions. It also has processing algorithms, which only
  makes sense to me if other drafts are to refer to this one.

  Being informational, referencing could lead to downref, but this
  should not be a significant problem.

- I do not view supporting large public keys or ciphertexts as
  realistic.

  Making larger extension would mean extending TLS to support
  "extended extensions". This would impily extra RTT for most key
  exchanges, altough it could be absorbed into extra RTT for client
  missing speculation on group (so it would be 2-RTT).

  Referencing external key is not acceptable:

  * The client would need to have a way to publish its key.
  * Strong incentives to reuse keys, despite problems doing so.
  * The server would need to be able to fetch keys, which causes
    difficult security issues.
  * The server would need to freeze the handshake for obtaining
    the public key. Unless the server API already supports handshake
    freezing, adding that capability is going to be virtually
    impossible (let alone the annoyance of implementing it).

  Additionally, even if blowing the practical ClientHello size limit
  (4kB or so) would already force additional round trip, the >64kB
  key algorithms have such big keys that result would be severe
  performance degradation.

  So in summary, unless all the smaller algorithms are broken beyond
  repair (which is highly unlikely due to complexity reasons) the
  >64kB keys should not be accomodiated. And even in that case, external
  keys are not acceptable.

- Avoiding duplication of key shares is difficult problem:

  * Using traditional scheme is easy on client and server, but can
    result in duplication of shares. And even single duplication of
    PQ share is signficant.
  * Making ServerHello key_share a list is clean specification-wise,
    but might be anything but clean implementation-wise.
  * Making separate extension could cause issues when doing
    hybrid -> next-gen transition in future.
  * Backreferences could be annoying to implement.

- On resumption, I do not think there are currently any restrictions
  in TLS 1.3 about DH groups used in resumption?

  If that is indeed the case, I suspect that implementing such
  restrictions might turn to be annoying to implement.

- On failures: All CCA-secure key exchanges have negligible failure
  rates (because anything else leads to attacks). And even if one
  considers non-CCA key exchanges from the NISTPQC 2nd round, AFAIK
  all of them meant for actual use have failure rate <10^-9.

- On schemes vulernable to chosen-ciphertext attack, SIDH (which
  underlies SIKE) key can be recovered bit-by-bit (even with just
  guess oracle, instead of full decryption oracle) by sending suitable
  chosen ciphertexts. This takes a few hundred samples for full key
  recovery.

-Ilari

---

From: Loganaden Velvindron <[email-masked]>
Date: Sat, 15 Feb 2020 20:50:10 +0400

I support adoption and I'm willing to review the document.

---

From: Douglas Stebila <[email-masked]>
Date: Mon, 17 Feb 2020 11:33:55 -0500

Thanks for the feedback and observations, Ilari.  

>  odd, given that this document does not define any KEMs.

Good point; I've updated the language to say "any KEM used in the manner described in this document" and pushed it to my working copy on Github.

Regarding the rest of the points, I don't think any of them are specific actions to take, but are good points about the overall direction.  

Douglas

> On Feb 15, 2020, at 11:39, Ilari Liusvaara <[email-masked]> wrote:
>

---

From: Russ Housley <[email-masked]>
Date: Fri, 21 Feb 2020 14:29:01 -0500

> On Feb 12, 2020, at 6:22 PM, Martin Thomson <[email-masked]> wrote:
> 

I do not agree.  I do not think the WG should adopt this draft.

The CFRG has stated a position that the IETF should wait for the NIST standardization process to be complete.  There are at least two approaches to mixing symmetric keying material into the TLS 1.3 key schedule for information that needs to be protected for the next few decades.  (The two that I know about are draft-ietf-tls-tls13-cert-with-extern-psk and draft-vanrein-tls-kdh.) These approaches make existing key establishment techniques secure even if a quantum computer gets developed as long as the symmetric key is not disclosed.  In my opinion, those techniques will hold us until the NIST standardization process finishes.

I do not understand the goal of mixing (EC)DH with one of candidate algorithms.  We do not know enough about the candidate algorithms in the NIST process.  If the goal is to add quantum resistance, we do not have enough information to pick well.  If the goal is to learn about mixing in general, then I question the project altogether.  Once the NIST standardization process is complete, we can simply use the selected algorithm without mixing.

Russ

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Fri, 21 Feb 2020 21:24:38 +0000

> From: TLS <[email-masked]> On Behalf Of Russ Housley
> Sent: Friday, February 21, 2020 2:29 PM
> To: Martin Thomson <[email-masked]>
> Cc: IETF TLS <[email-masked]>
> >> I'm brand new to the IETF, so please forgive me if I'm totally off
> >> base here, but my understanding is that Informational RFCs are
> >> explicitly not recommendations (let alone mandates)?
> >
> > This would of course be information, but my comment was about phrasing.
> This document comes off as being quite prescriptive, where it doesn't really
> need to be.  Absent actual algorithms, it's just a set of guidelines.  That's
> reflected in its Informational status, but it would be better if the verbiage
> also reflected that more clearly.
> >
> > To address Stephen's comment at the same time: I think that we can
> publish an RFC on this before the competition completes if it is just a
> framework.  That might in fact make standardizing the one true composite
> scheme easier.
> 
> The CFRG has stated a position that the IETF should wait for the NIST
> standardization process to be complete.

I disagree with Russ's statement that what the CFRG has stated actually applies to this draft.  This draft does not specify what postquantum algorithms should be used (which is what the CFRG is talking about).  What it tries to address is "once we have an approved algorithm, how do we integrate it into TLS".  Surely it would be better to get that preliminary work out of the way first, rather than waiting for the NIST process to conclude, and then start spending the time working on the integration process.

> There are at least two approaches
> to mixing symmetric keying material into the TLS 1.3 key schedule for
> information that needs to be protected for the next few decades.  (The two
> that I know about are draft-ietf-tls-tls13-cert-with-extern-psk and draft-
> vanrein-tls-kdh.) These approaches make existing key establishment
> techniques secure even if a quantum computer gets developed as long as
> the symmetric key is not disclosed.  In my opinion, those techniques will hold
> us until the NIST standardization process finishes.

Symmetric keys solve the problem, but are usable only in scenarios where you have a pre-existing relationship between the client and the server.  It doesn't work in a more general "web-surfing" type scenario.

> 
> I do not understand the goal of mixing (EC)DH with one of candidate
> algorithms.  We do not know enough about the candidate algorithms in the
> NIST process.  If the goal is to add quantum resistance, we do not have
> enough information to pick well.

And, again, the draft does not attempt to pick one.

>  If the goal is to learn about mixing in
> general, then I question the project altogether.  Once the NIST
> standardization process is complete, we can simply use the selected
> algorithm without mixing.

I can see someone disagreeing.  Whatever postquantum algorithm NIST selects, it will be a relatively recent one (and hence one that hasn't gone through as much cryptographical scrutiny as one would like) [1].  And, given that slapping on an ECDH exchange is relatively cheap (both in computation and especially in bandwidth), I can see someone wanting to put it in there as a safety measure, in case that the postquantum algorithm turns out to have a weakness to classical computers.

In any case, even if we ignore mixing, there are questions that need to be considered for a postquantum algorithm (which doesn't behave precisely like DH).  For example, to what extent should we insist that fresh key shared be used each time?  Should we require the key exchange mechanism to have "CCA" security (which DH does, as long as you perform the proper validation tests), or is "CPA" security sufficient?  Should we attempt to support key exchanges with huge (e.g. a Megabyte) public keys?

Those questions can be considered even before we learn which postquantum algorithms we will eventually use.

[1]: Exception: McEliece has been around a long time, and has picked up enough scrutiny for us to trust it.  However, it's also the one with Megabyte keys, and even if we were to support it, it's likely to be only rarely used; the issue will still remain with whatever other postquantum key exchange we also support

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 21 Feb 2020 21:33:26 +0000

Hiya,

On 21/02/2020 21:24, Scott Fluhrer (sfluhrer) wrote:
> What it tries to address is "once we have an
> approved algorithm, how do we integrate it into TLS".  

Except that we do not have an approved algorithm. We have
17 round 2 KEMs with vastly different properties. Even
when NIST are done that number seems likely to be >1.

> Surely it
> would be better to get that preliminary work out of the way first,
> rather than waiting for the NIST process to conclude, and then start
> spending the time working on the integration process.
Given the range of differences in sizes of public values,
CPU etc and the fact that we don't know how those algs
will be parameterised, I don't believe this is work that
can be usefully gotten out of the way first.

Cheers,
S.

PS: I do believe that we'll want to mix NIST PQC algs
with classic DH after we know the details of the PQC
algs, just not before.

---

From: Watson Ladd <[email-masked]>
Date: Fri, 21 Feb 2020 14:02:50 -0800

> when NIST are done that number seems likely to be >1.

All the KEMs are KEMs, meeting the same security properties, and fall
into three categories of problem: lattice, code, and isogeny.

> can be usefully gotten out of the way first.

We have already deployed widespread experiments that conducted the
hybridization described in this draft, already have implementations
supporting an approach similar to this draft, and that produced
valuable input to the standardization process. It really didn't matter
that it was SIKE or NewHope that was being hybridized, and they have
very different characteristics.

What will we know when NIST finishes that we need to know that we do
not know today? Which algorithm we want to hybridize? That's easy to
handle: the mechanism is generic.

Sincerely,
Watson Ladd

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 21 Feb 2020 22:08:10 +0000

> very different characteristics.

Documented where?

Ta,
S.

---

From: Watson Ladd <[email-masked]>
Date: Fri, 21 Feb 2020 14:11:30 -0800

> > very different characteristics.

https://blog.cloudflare.com/towards-post-quantum-cryptography-in-tls/
https://blog.cloudflare.com/the-tls-post-quantum-experiment/

This was also presented at the NIST standardization workshop in October of 2019.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 21 Feb 2020 22:22:06 +0000

I agree with Watson's reasoning.

We know now all we need to to start working on generic mechanisms.

Regards,
Uri

Sent from my iPhone

> On Feb 21, 2020, at 17:11, Watson Ladd <watson=[email-masked]> wrote:
>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 21 Feb 2020 22:25:46 +0000

> This was also presented at the NIST standardization workshop in October of 2019.

Thanks. I read through [1]. It's fine work, but does not
convince me that this draft is ready to be an RFC before
the "winning" algs are known, as some have characteristics
that are quite different from the two that were tested
here. I maintain my position that adoption is fine but
finishing this before NIST are done is not.

Cheers,
S.

[1]
https://csrc.nist.gov/CSRC/media/Presentations/measuring-tls-key-exchange-with-post-quantum-kem/images-media/sullivan-session-1-paper-pqc2019.pdf

---

From: Watson Ladd <[email-masked]>
Date: Fri, 21 Feb 2020 14:28:36 -0800

> finishing this before NIST are done is not.

How do these characteristics affect the proposal in the draft? And I
doubt given the relevant timelines we would finish before NIST is done
in any case.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 21 Feb 2020 22:31:02 +0000

You may have a point regarding finishing this draft - but let's cross that bridge when we get there. :-)

Regards,
Uri

Sent from my iPhone

> On Feb 21, 2020, at 17:26, Stephen Farrell <[email-masked]> wrote:
> 
> 
> 
> <0x5AB2FAF17B172BEA.asc>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 21 Feb 2020 22:37:51 +0000

Hiya,

On 21/02/2020 22:28, Watson Ladd wrote:
> How do these characteristics affect the proposal in the draft? 

I don't know. There are 17 of them. I'm not spending the
time on this myself 'till there are a small number of
winners. Speculating though, NIST often end up with a load
of variants - if they do that again variant#1 of winner#1
might be usable with variant#2 of that same alg being no
good at all. So I could see the definition of code points
being wrong if done prematurely. (I remember the NULL
algorithm parameter non-interop for RSA way back when and
that was after the ASN.1 had existed for some time;-) I'd
bet there'll be other issues discovered along the way as
well.

> And I

Great. In that case you must find my position fine, no? :-)

All I'm asking is that we adopt with the explicit
understanding that the WG don't request publication until
the NIST winners are known. That is a weird ask, but I
think justified in this case. The "Winner all right" call
there can be left to the WG chairs - I'm not asking to
wait for the final FIPS or whatever else NIST do to add
another year or so to the endgame;-)

Cheers,
S.

---

From: Carrick Bartle <[email-masked]>
Date: Fri, 21 Feb 2020 15:21:27 -0800

> I agree with Watson's reasoning.

Same.

> On Feb 21, 2020, at 2:22 PM, Blumenthal, Uri - 0553 - MITLL <[email-masked]> wrote:
>

---

From: Russ Housley <[email-masked]>
Date: Mon, 24 Feb 2020 12:08:26 -0500

> On Feb 21, 2020, at 5:25 PM, Stephen Farrell <[email-masked]> wrote:
> 
> https://csrc.nist.gov/CSRC/media/Presentations/measuring-tls-key-exchange-with-post-quantum-kem/images-media/sullivan-session-1-paper-pqc2019.pdf <https://csrc.nist.gov/CSRC/media/Presentations/measuring-tls-key-exchange-with-post-quantum-kem/images-media/sullivan-session-1-paper-pqc2019.pdf>

These slides clearly indicate that an experiment is being performed.  I encourage the experimentation, but I do not think that the TLS WG should adopt this draft.

TLS 1.3 eliminated a lot of cruft from earlier versions.  This is really good, and it make the security analysis much more tractable.  We all know that adding complexity brings bugs.  I would like adoption of a draft in this general direction after the NIST competition completes so that the TLS WG can focus on a small number of algorithms.

Russ