Subject: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design

From: Joseph Salowey <[email-masked]>
Date: Thu, 13 Feb 2020 09:12:59 -0800

The authors of "Hybrid Key Exchange" have asked for adoption of their draft
as a WG item.  Please state whether you support adoption of this draft as a
WG item by posting a message to the TLS list by 2359 UTC 28 February 2020.
Please include any additional information that is helpful in understanding
your position.

NOTE:
If the draft is adopted, the working group has change control over the
draft and the timing of its progression.  This means the document does not
have to be perfect as the working group can and will make changes.
Adopting the draft means the working group thinks the topic is a good idea
and the draft is a good place to start the work.

Thanks,
Chris, Joe, and Sean

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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 13 Feb 2020 18:47:03 +0000

Hiya,

I said this in the other thread but I'll repeat a call
for a bit of clarity that's not normally needed:

> and the draft is a good place to start the work.

I think the draft would be ok to adopt if we don't finish
it until the outcome from the NIST competition is known.
Otherwise I would be against adoption.

That needn't be an insurmountable problem though, e.g. if
the chairs/AD created a milestone dependency on NIST
having finished before publishing this, then that'd make
it clear enough (for me at least).

My request is an unusual one, in that we normally want to
be finished asap, but in this case, doing a good job has
that external dependency and I think we ought not finish
before that's been resolved.

Cheers,
S.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Thu, 13 Feb 2020 18:48:16 +0000

I support its adoption.

From: TLS <[email-masked]> on behalf of Joseph Salowey <[email-masked]>
Date: Thursday, February 13, 2020 at 12:13 PM
To: "<[email-masked]>" <[email-masked]>
Subject: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design

The authors of "Hybrid Key Exchange" have asked for adoption of their draft as a WG item.  Please state whether you support adoption of this draft as a WG item by posting a message to the TLS list by 2359 UTC 28 February 2020.  Please include any additional information that is helpful in understanding your position.

NOTE:
If the draft is adopted, the working group has change control over the draft and the timing of its progression.  This means the document does not have to be perfect as the working group can and will make changes.  Adopting the draft means the working group thinks the topic is a good idea and the draft is a good place to start the work.  

Thanks,
Chris, Joe, and Sean

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 13 Feb 2020 19:00:57 +0000

I think I agree with this, but am not sure. Can we have this on the agenda for Vancouver?

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 14 Feb 2020 08:28:27 +1100

> I think I agree with this, but am not sure. Can we have this on the 

That's a good idea.  Because I'm fairly sure that I disagree.

This work might form the basis of experiments.  If the competition result is known, we might instead want to start the process of defining key exchange with a single algorithm rather than concern ourselves with compositions.  Having the document in place so that we can define experiments with a degree of surety with respect to their risks is best.

In any case, we should adopt this work.

---

From: Nick Sullivan <[email-masked]>
Date: Thu, 13 Feb 2020 13:38:56 -0800

I'm in favor of adopting this work.

Nick

On Thu, Feb 13, 2020 at 9:13 AM Joseph Salowey <[email-masked]> wrote:

> The authors of "Hybrid Key Exchange" have asked for adoption of their
> draft as a WG item.  Please state whether you support adoption of this
> draft as a WG item by posting a message to the TLS list by 2359 UTC 28
> February 2020.  Please include any additional information that is helpful
> in understanding your position.
>
> NOTE:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Carrick Bartle <[email-masked]>
Date: Thu, 13 Feb 2020 16:33:12 -0800

I also support adoption of this draft. The concerns raised in the other thread on this topic ([TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design) are irrelevant within the context of adopting an informational draft, as it would be a "timely publication" of "general information [for] the Internet community."

> On Feb 13, 2020, at 9:12 AM, Joseph Salowey <[email-masked]> wrote:
>

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 14 Feb 2020 10:02:08 +0300

Hi,

I support adoption of this document.

Regards,

Valery Smyslov.

From: TLS [mailto:[email-masked]] On Behalf Of Joseph Salowey
Sent: Thursday, February 13, 2020 8:13 PM
To: <[email-masked]>
Subject: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design

NOTE:

Thanks,
Chris, Joe, and Sean

[0]  <https://datatracker.ietf.org/doc/draft-stebila-tls-hybrid-design/> https://datatracker.ietf.org/doc/draft-stebila-tls-hybrid-design/

---

From: Jonathan Hammell <[email-masked]>
Date: Fri, 14 Feb 2020 09:50:43 -0500

I would like to see this work adopted by the working group. I think the
language issues can be addressed after adoption.

However, given the disagreements raised, I would also be okay if the
adoption decision was postponed until after discussion in Vancouver.

Jonathan

On Thu., Feb. 13, 2020, 4:29 p.m. Martin Thomson, <[email-masked]> wrote:

> This work might form the basis of experiments.  If the competition result
> is known, we might instead want to start the process of defining key
> exchange with a single algorithm rather than concern ourselves with
> compositions.  Having the document in place so that we can define
> experiments with a degree of surety with respect to their risks is best.
>

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Fri, 14 Feb 2020 17:35:37 +0000

I support adoption

From: TLS <[email-masked]> On Behalf Of Joseph Salowey
Sent: Thursday, February 13, 2020 12:13 PM
To: <[email-masked]> <[email-masked]>
Subject: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design

The authors of "Hybrid Key Exchange" have asked for adoption of their draft as 
a WG item.  Please state whether you support adoption of this draft as a WG 
item by posting a message to the TLS list by 2359 UTC 28 February 2020. 
Please include any additional information that is helpful in understanding 
your position.

NOTE:
If the draft is adopted, the working group has change control over the draft 
and the timing of its progression.  This means the document does not have to 
be perfect as the working group can and will make changes.  Adopting the draft 
means the working group thinks the topic is a good idea and the draft is a 
good place to start the work.

Thanks,
Chris, Joe, and Sean

[0]  <https://datatracker.ietf.org/doc/draft-stebila-tls-hybrid-design/> 
https://datatracker.ietf.org/doc/draft-stebila-tls-hybrid-design/

---

From: Dan Brown <[email-masked]>
Date: Mon, 24 Feb 2020 16:13:26 +0000

I support rapid adoption, if only based on general principles, as elaborated below.

***

I have not studied the draft in detail, but I think that strongest-link security is important to allow, the sooner the better, for those that can afford it, I think the benefit is worth cost.

I think that the how-to of strongest-link is straightforward enough to start working on it, and I trust the draft authors to have done a good job at it.  Any subtleties or optimizations of strongest-link crypto can be perfected as they arise.

I would also favor using both ECC and PQC, (a) _after_ NIST PQC is done, (b) _before_ a Shor-capable QC arrives.  I’m hoping the time of (a) < (b), and therefore hybrid should be ready to roll out.

I would also favor adding PQC support to TLS _before_ even NIST PQC is done, then just switching over to NIST choices at the time, even though this seems not to be the interpretation consensus opinion, e.g. CFRG opted to wait for NIST.  I agree waiting for NIST is sensible, if one want the best PQC protection, but not to the point of delaying having any PQC protection, see next point.

Getting details right is a known difficulty, with mistakes inevitable.  Haste makes waste, sure, but delay is deadly, so let’s get to debugging the details right away.  Bugs are a nuisance, but better than nothing.

I realize that anybody worried about Shor-capable QC, can add a PQC out-of-band to official TLS, but I understand TLS to offer many benefits as security protocol, such that adding in PQC would create synergy (excuse my word choice here).

I think “hybrid” is the wrong word.  CFRG has adopted another document where “hybrid” means weakest-link.  Can we choose clearer words?  I like “compound”, but strongest-link, and defense-in-depth are clearer at the price of being longer.  (I prefer hybrid to synergy, of course!)

General arguments that attackers will find other system weaknesses than directly attacking crypto are valid, but these arguments already rely on good crypto, and are invalid as an excuse to use weaker crypto, to stop improving crypto.

Best regards,

Dan Brown

BlackBerry

NOTE:

Thanks,
Chris, Joe, and Sean

[0]  <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dstebila-2Dtls-2Dhybrid-2Ddesign_&d=DwMFaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=qkpbVDRj7zlSRVql-UonsW647lYqnsrbXizKI6MgkEw&m=YGrWhrwPJMcluBHfaPE8h_pponmVeM1dfJFrLKO-Y2c&s=QH64ybNj9x2PM84z-J18Fb113WNyH8szhQxy-UzKDZc&e=> https://datatracker.ietf.org/doc/draft-stebila-tls-hybrid-design/

----------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.