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

[Russ Housley]

> On Feb 21, 2020, at 5:25 PM, Stephen Farrell  
> wrote:
> 
> On 21/02/2020 22:11, Watson Ladd wrote:
> 
>> 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.
> 
> 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
>  
> 

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



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Carrick Bartle]

> I agree with Watson's reasoning.

Same.


> On Feb 21, 2020, at 2:22 PM, Blumenthal, Uri - 0553 - MITLL  
> wrote:
> 
> 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 
>>  wrote:
>> 
>> On Fri, Feb 21, 2020 at 2:08 PM Stephen Farrell
>>  wrote:
>>> 
>>> 
>>> 
 On 21/02/2020 22:02, Watson Ladd wrote:
 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.
>>> 
>>> Documented where?
>> 
>> 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.
>> 
>>> 
>>> Ta,
>>> S.
>> 
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Stephen Farrell]

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
> doubt given the relevant timelines we would finish before NIST is done
> in any case.

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.



0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

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  wrote:
> 
> 
> 
>> On 21/02/2020 22:11, Watson Ladd wrote:
>> 
>> 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.
> 
> 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
> 
> 
>> 
>>> 
>>> Ta,
>>> S.
> <0x5AB2FAF17B172BEA.asc>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Watson Ladd]

On Fri, Feb 21, 2020 at 2:25 PM Stephen Farrell
 wrote:
>
>
>
> On 21/02/2020 22:11, Watson Ladd wrote:
>
> > 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.
>
> 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.

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.

>
> 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
>
>
> >
> >>
> >> Ta,
> >> S.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Stephen Farrell]

On 21/02/2020 22:11, Watson Ladd wrote:

> 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.

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


> 
>>
>> Ta,
>> S.


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

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 
>  wrote:
> 
> On Fri, Feb 21, 2020 at 2:08 PM Stephen Farrell
>  wrote:
>> 
>> 
>> 
>>> On 21/02/2020 22:02, Watson Ladd wrote:
>>> 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.
>> 
>> Documented where?
> 
> 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.
> 
>> 
>> Ta,
>> S.
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Watson Ladd]

On Fri, Feb 21, 2020 at 2:08 PM Stephen Farrell
 wrote:
>
>
>
> On 21/02/2020 22:02, Watson Ladd wrote:
> > 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.
>
> Documented where?

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.

>
> Ta,
> S.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Stephen Farrell]

On 21/02/2020 22:02, Watson Ladd wrote:
> 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.

Documented where?

Ta,
S.


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Watson Ladd]

On Fri, Feb 21, 2020 at 1:37 PM Stephen Farrell
 wrote:
>
>
> 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.

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

>
> > 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.

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Stephen Farrell]

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.


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Scott Fluhrer (sfluhrer)]

> -Original Message-
> From: TLS  On Behalf Of Russ Housley
> Sent: Friday, February 21, 2020 2:29 PM
> To: Martin Thomson 
> Cc: IETF TLS 
> Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-
> hybrid-design
> 
> 
> 
> > On Feb 12, 2020, at 6:22 PM, Martin Thomson 
> wrote:
> >
> > 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.
> 
> 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.

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Russ Housley]

> On Feb 12, 2020, at 6:22 PM, Martin Thomson  wrote:
> 
> 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.

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Douglas Stebila]

Thanks for the feedback and observations, Ilari.  

Regarding:

> - The draft talks about "any KEM used in this document". Which sounds
>  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  wrote:
> 
> On Wed, Feb 12, 2020 at 02:26:21PM -0500, Douglas Stebila wrote:
>> 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/
> 
> 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 

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

[Loganaden Velvindron]

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

On Wednesday, February 12, 2020, Douglas Stebila  wrote:

> 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
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ilari Liusvaara]

On Wed, Feb 12, 2020 at 02:26:21PM -0500, Douglas Stebila wrote:
> 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/

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Rob Sayre]

On Thu, Feb 13, 2020 at 3:48 AM Douglas Stebila  wrote:

> On Feb 12, 2020, at 11:24 PM, Rob Sayre  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.
>

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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dang, Quynh H. (Fed)]

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

Quynh.

From: TLS  on behalf of Martin Thomson 

Sent: Wednesday, February 12, 2020 4:57 PM
To: Blumenthal, Uri - 0553 - MITLL ; tls@ietf.org 

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

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.

___
TLS mailing list
TLS@ietf.org
https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftlsdata=02%7C01%7Cquynh.dang%40nist.gov%7C66ec528552554b52d03f08d7b006af16%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637171415063382880sdata=DdG71mohtkyXCdRplxvT1z5JWRvg53RqO98BKqswIw4%3Dreserved=0
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Douglas Stebila]

On Feb 12, 2020, at 11:24 PM, Rob Sayre  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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Douglas Stebila]

Hi Martin,

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

> 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. 
> 
> [...]
> 
> 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.

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Rob Sayre]

On Wed, Feb 12, 2020 at 11:26 AM Douglas Stebila  wrote:

> 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/


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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Stephen Farrell]

Hiya,

On 12/02/2020 22:57, Blumenthal, Uri - 0553 - MITLL wrote:
> I don't expect you to be knowledgeable about 25+ proposed 
> algorithms.

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:
> What's the point of composite schemes after the NIST competition 
> finishes?

SHA-0:-)

Cheers,
S.


> 
> 
> 
> On 2/12/20, 5:50 PM, "Stephen Farrell"  
> wrote:
> 
> 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.
> 
> 
> 


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Watson Ladd]

On Wed, Feb 12, 2020 at 3:23 PM Martin Thomson  wrote:
>
> 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.

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.

>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Martin Thomson]

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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Carrick Bartle]

> 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  wrote:
> 
> On Thu, Feb 13, 2020, at 06:26, Douglas Stebila wrote:
>> 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.
> 
> 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.
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Pettis, Darin P]

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

Darin

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


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.



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.

-
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

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"  wrote:
  
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.




smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Stephen Farrell]

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.



0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Martin Thomson]

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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

 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"  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?




smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Martin Thomson]

On Thu, Feb 13, 2020, at 06:26, Douglas Stebila wrote:
> 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.

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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls