Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

[Filippo Valsorda]

(I am listed as author to one of the drafts, but haven't contributed 
significantly since suggesting the deprecation on the list, so I am going to 
renounce authorship and express my support for the adoption instead.)

As a TLS implementer, I don't want the specs to tell me what is *technically 
possible to implement correctly*. I want the specs to recommend the safer, most 
straightforward options for general purpose use.

*DH reuse is less safe than ephemeral shares.* I don't think we need to debate 
this fact. There is a mile-high pile of CVEs that include the words "if DH 
shares are reused". I personally turned a 2^-32 chance of a carry bug into a 
full key recovery against ES-DH , 
others have pulled off more and cooler attacks. None of these fun, 
job-security-providing stunts work with ephemeral shares, so it's with a heavy 
heart that I say we should absolutely deprecate all DH share reuses. (This 
includes all static kex, and an explicit MUST NOT for reuse in ephemeral kex.)

*Checking the safety of an arbitrary FFDH group is relatively hard, and slow.* 
Implementers tend to skip hard, slow operations with no visible outcome. 
Besides, it's also a compatibility risk, because the only recourse on a failed 
check is to terminate the connection, which again encourages implementers to 
skip or relax the check. The most straightforward path to retaining FFDH in TLS 
1.2 I see is requiring the use of a few, well known groups, that can be checked 
by memcmp. Still, I would rather support deprecating pre-TLS 1.3 FFDH entirely.

It's not like things in the wild suddenly stop working when the IETF deprecates 
a cipher suite (that's my job!), it just tells bystanders "this is not the best 
way to do things" and in the case of DH reuse "you'll be much safer if you 
generate fresh shares" and in the case of FFDH "if you want to do FFDH it will 
be safer and more reliable to use TLS 1.3".

I support adoption, and recommend merging all these deprecations into a single 
draft, which would be easier to refer to and communicate as an implementer.

2021-08-17 03:45 GMT+02:00 Joseph Salowey :
> Regardless of the Raccoon attack, the static DH and ECDH ciphersuites do not 
> provide forward secrecy, which is a main reason cited for deprecating RSA in 
> draft-aviram-tls-deprecate-obsolete-kex.  Do you object to just the citation 
> of the Raccoon attack or do you also feel that we should keep these 
> ciphersuites that do not provide forward secrecy around?
> 
> Cheers,
> 
> Joe
> 
> On Fri, Aug 13, 2021 at 10:20 AM Blumenthal, Uri - 0553 - MITLL 
>  wrote:
>> I agree with Rene’s points.
>> __ __
>> -- 
>> Regards,
>> Uri
>> __ __
>> __ __
>> *From: *TLS  on behalf of Rene Struik 
>> 
>> *Date: *Friday, August 13, 2021 at 09:58
>> 
>> Dear colleagues:
>> __ __
>> I think this document should absolutely *not* be adopted, without providing 
>> far more technical justification. The quoted Raccoon attack is an easy to 
>> mitigate attack (which has nothing to do with finite field groups, just with 
>> poor design choices of postprocessing, where one uses variable-size integer 
>> representations for a key). There are also good reasons to have key 
>> exchanges where one of the parties has a static key, whether ecc-based or 
>> ff-based (e.g., sni, opaque), for which secure implementations are known. No 
>> detail is provided and that alone should be sufficient reason to not 
>> adopt.
>> __ __
>> Rene
>> __ __
>> On 2021-07-29 5:50 p.m., Joseph Salowey wrote:
>>> This is a working group call for adoption for Deprecating FFDH(E) 
>>> Ciphersuites in TLS (draft-bartle-tls-deprecate-ffdhe-00 
>>> ). We 
>>> had a presentation for this draft at the IETF 110 meeting and since it is a 
>>> similar topic to the key exchange deprecation draft the chairs want to get 
>>> a sense if the working group wants to adopt this draft (perhaps the drafts 
>>> could be merged if both move forward).  Please review the draft and post 
>>> your comments to the list by Friday, August 13, 2021.  
>>> __ __
>>> Thanks,
>>> __ __
>>> The TLS chairs
>>> 
>>> 
>>> 
>>> ___
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>> __ __
>> 
>> -- 
>> email: rstruik@gmail.com | Skype: rstruik
>> cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
> ___
> 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] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

[David Benjamin]

I support adoption, and will second everything Filippo says.

Deprecation is about the working group issuing updated guidance. Existing
ecosystems may apply new guidance at different rates. That's up to TLS
implementations and deployments to work through. Some ecosystems may remove
things at long time scales. Some ecosystems may have particularly unusual
setups such that they almost never want to remove anything. That's fine,
but it cannot discount the other ecosystems which *do *incur security risk
from having weak ciphers enabled, or the new TLS uses with no legacy. The
working group needs to maintain up-to-date guidance here, and this is how
we do that.

On arbitrary FFDH groups, I think pre-TLS-1.3 FFDH, even ephemeral, is
unsalvageable [again, as up-to-date guidance, see above]. We don't have a
way to tell the server to only consider DHE ciphers if it would have used a
group the client supports. RFC7919 tried to solve the problem but, by
reusing the old cipher suites, it fails to solve the problem. Triggering an
external client retry instead has interesting downgrade consequences due to
ServerKeyExchange signatures not covering the ClientHello. (In fact, I
suspect RFC7919 has made the downgrade risks worse...)

On Tue, Aug 17, 2021 at 9:29 AM Filippo Valsorda 
wrote:

> (I am listed as author to one of the drafts, but haven't contributed
> significantly since suggesting the deprecation on the list, so I am going
> to renounce authorship and express my support for the adoption instead.)
>
> As a TLS implementer, I don't want the specs to tell me what is *technically
> possible to implement correctly*. I want the specs to recommend the
> safer, most straightforward options for general purpose use.
>
> *DH reuse is less safe than ephemeral shares.* I don't think we need to
> debate this fact. There is a mile-high pile of CVEs that include the words
> "if DH shares are reused". I personally turned a 2^-32 chance of a carry
> bug into a full key recovery against ES-DH
> , others have pulled off
> more and cooler attacks. None of these fun, job-security-providing stunts
> work with ephemeral shares, so it's with a heavy heart that I say we should
> absolutely deprecate all DH share reuses. (This includes all static kex,
> and an explicit MUST NOT for reuse in ephemeral kex.)
>
> *Checking the safety of an arbitrary FFDH group is relatively hard, and
> slow.* Implementers tend to skip hard, slow operations with no visible
> outcome. Besides, it's also a compatibility risk, because the only recourse
> on a failed check is to terminate the connection, which again encourages
> implementers to skip or relax the check. The most straightforward path to
> retaining FFDH in TLS 1.2 I see is requiring the use of a few, well known
> groups, that can be checked by memcmp. Still, I would rather support
> deprecating pre-TLS 1.3 FFDH entirely.
>
> It's not like things in the wild suddenly stop working when the IETF
> deprecates a cipher suite (that's my job!), it just tells bystanders "this
> is not the best way to do things" and in the case of DH reuse "you'll be
> much safer if you generate fresh shares" and in the case of FFDH "if you
> want to do FFDH it will be safer and more reliable to use TLS 1.3".
>
> I support adoption, and recommend merging all these deprecations into a
> single draft, which would be easier to refer to and communicate as an
> implementer.
>
> 2021-08-17 03:45 GMT+02:00 Joseph Salowey :
>
> Regardless of the Raccoon attack, the static DH and ECDH ciphersuites do
> not provide forward secrecy, which is a main reason cited for deprecating
> RSA in draft-aviram-tls-deprecate-obsolete-kex.  Do you object to just the
> citation of the Raccoon attack or do you also feel that we should keep
> these ciphersuites that do not provide forward secrecy around?
>
> Cheers,
>
> Joe
>
> On Fri, Aug 13, 2021 at 10:20 AM Blumenthal, Uri - 0553 - MITLL <
> u...@ll.mit.edu> wrote:
>
> I agree with Rene’s points.
>
>
>
> --
>
> Regards,
>
> Uri
>
>
>
>
>
> *From: *TLS  on behalf of Rene Struik <
> rstruik@gmail.com>
> *Date: *Friday, August 13, 2021 at 09:58
>
> Dear colleagues:
>
>
>
> I think this document should absolutely *not* be adopted, without
> providing far more technical justification. The quoted Raccoon attack is an
> easy to mitigate attack (which has nothing to do with finite field groups,
> just with poor design choices of postprocessing, where one uses
> variable-size integer representations for a key). There are also good
> reasons to have key exchanges where one of the parties has a static key,
> whether ecc-based or ff-based (e.g., sni, opaque), for which secure
> implementations are known. No detail is provided and that alone should be
> sufficient reason to not adopt.
>
>
>
> Rene
>
>
>
> On 2021-07-29 5:50 p.m., Joseph Salowey wrote:
>
> This is a working group call for adoption for Deprecating FFDH(E)
> Ciphersuites in TLS (draft-bartle-tls-dep

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

[Blumenthal, Uri - 0553 - MITLL]

>  Regardless of the Raccoon attack, the static DH and ECDH ciphersuites do not 
>provide

>  forward secrecy,

 

Unless you use semi-static exchange, which in many cases makes sense.

 

>   which is a main reason cited for deprecating RSA in 
> draft-aviram-tls-deprecate-obsolete-kex.

 

Have the authors look at Post-Quantum KEMs?

 

>  Do you object to just the citation of the Raccoon attack or do you also feel 
> that we

>  should keep these ciphersuites that do not provide forward secrecy around?

 

I think these suites should stay around. 

 

While static-static indeed do not provide forward secrecy (and many of us – 
though not everybody! – carry for that), static-ephemeral DH and ECDH are 
perfectly fine from that point of view.

 

 

 

On Fri, Aug 13, 2021 at 10:20 AM Blumenthal, Uri - 0553 - MITLL 
 wrote:

I agree with Rene’s points.

 

-- 

Regards,

Uri

 

 

From: TLS  on behalf of Rene Struik 

Date: Friday, August 13, 2021 at 09:58

Dear colleagues:

 

I think this document should absolutely *not* be adopted, without providing far 
more technical justification. The quoted Raccoon attack is an easy to mitigate 
attack (which has nothing to do with finite field groups, just with poor design 
choices of postprocessing, where one uses variable-size integer representations 
for a key). There are also good reasons to have key exchanges where one of the 
parties has a static key, whether ecc-based or ff-based (e.g., sni, opaque), 
for which secure implementations are known. No detail is provided and that 
alone should be sufficient reason to not adopt.

 

Rene

 

On 2021-07-29 5:50 p.m., Joseph Salowey wrote:

This is a working group call for adoption for Deprecating FFDH(E) Ciphersuites 
in TLS (draft-bartle-tls-deprecate-ffdhe-00). We had a presentation for this 
draft at the IETF 110 meeting and since it is a similar topic to the key 
exchange deprecation draft the chairs want to get a sense if the working group 
wants to adopt this draft (perhaps the drafts could be merged if both move 
forward).  Please review the draft and post your comments to the list by 
Friday, August 13, 2021.  

 

Thanks,

 

The TLS chairs

 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
 
-- 
email: rstruik@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867



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

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

[Eric Rescorla]

On Tue, Aug 17, 2021 at 10:41 AM Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:

> >  Regardless of the Raccoon attack, the static DH and ECDH ciphersuites
> do not provide
>
> >  forward secrecy,
>
>
>
> Unless you use semi-static exchange, which in many cases makes sense.
>

>
>
> >   which is a main reason cited for deprecating RSA
> in draft-aviram-tls-deprecate-obsolete-kex.
>
>
>
> Have the authors look at Post-Quantum KEMs?
>

FWIW I don't think we should use post-quantum KEMs in pure "static" modes
(a la traditional static RSA).

-Ekr


>
> >  Do you object to just the citation of the Raccoon attack or do you also
> feel that we
>
> >  should keep these ciphersuites that do not provide forward secrecy
> around?
>
>
>
> I think these suites should stay around.
>
>
>
> While static-static indeed do not provide forward secrecy (and many of us
> – though not everybody! – carry for that), static-ephemeral DH and ECDH are
> perfectly fine from that point of view.
>
>
>
>
>
>
>
> On Fri, Aug 13, 2021 at 10:20 AM Blumenthal, Uri - 0553 - MITLL <
> u...@ll.mit.edu> wrote:
>
> I agree with Rene’s points.
>
>
>
> --
>
> Regards,
>
> Uri
>
>
>
>
>
> *From: *TLS  on behalf of Rene Struik <
> rstruik@gmail.com>
> *Date: *Friday, August 13, 2021 at 09:58
>
> Dear colleagues:
>
>
>
> I think this document should absolutely *not* be adopted, without
> providing far more technical justification. The quoted Raccoon attack is an
> easy to mitigate attack (which has nothing to do with finite field groups,
> just with poor design choices of postprocessing, where one uses
> variable-size integer representations for a key). There are also good
> reasons to have key exchanges where one of the parties has a static key,
> whether ecc-based or ff-based (e.g., sni, opaque), for which secure
> implementations are known. No detail is provided and that alone should be
> sufficient reason to not adopt.
>
>
>
> Rene
>
>
>
> On 2021-07-29 5:50 p.m., Joseph Salowey wrote:
>
> This is a working group call for adoption for Deprecating FFDH(E)
> Ciphersuites in TLS (draft-bartle-tls-deprecate-ffdhe-00
> ). We
> had a presentation for this draft at the IETF 110 meeting and since it is
> a similar topic to the key exchange deprecation draft the chairs want to
> get a sense if the working group wants to adopt this draft (perhaps the
> drafts could be merged if both move forward).  Please review the draft and
> post your comments to the list by Friday, August 13, 2021.
>
>
>
> Thanks,
>
>
>
> The TLS chairs
>
>
>
> ___
>
> TLS mailing list
>
> TLS@ietf.org
>
> https://www.ietf.org/mailman/listinfo/tls
>
>
>
> --
>
> email: rstruik@gmail.com | Skype: rstruik
>
> cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
>
> ___
> 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] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

[Salz, Rich]

I still support adoption, as I said a couple of weeks ago. I also still think 
we should consider merging this and draft-aviram-tls-deprecate-obsolete-kex-00.

I know that I’ve also said this before (can’t find it in my “sent mail” 
folder), but the fact that some communities can still use this safely, or must 
use it (for a variety of reasons usually around the infeasibility of 
upgrading), doesn’t mean that the general populace should not be warned away 
from doing these kinds of things.

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

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

[Blumenthal, Uri - 0553 - MITLL]

I see absolutely nothing wrong with using FFDH(E) and ECDH, as long as at least 
one of the keys is ephemeral. There is no need to “warn away”, IMHO. 

Regards,
Uri

> On Aug 17, 2021, at 15:19, Salz, Rich  
> wrote:
> 
> 
> I still support adoption, as I said a couple of weeks ago. I also still think 
> we should consider merging this and 
> draft-aviram-tls-deprecate-obsolete-kex-00.
>  
> I know that I’ve also said this before (can’t find it in my “sent mail” 
> folder), but the fact that some communities can still use this safely, or 
> must use it (for a variety of reasons usually around the infeasibility of 
> upgrading), doesn’t mean that the general populace should not be warned away 
> from doing these kinds of things.
>  
> ___
> 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] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

[Loganaden Velvindron]

I also support.

On Tue, Aug 17, 2021 at 11:19 PM Salz, Rich
 wrote:
>
> I still support adoption, as I said a couple of weeks ago. I also still think 
> we should consider merging this and 
> draft-aviram-tls-deprecate-obsolete-kex-00.
>
>
>
> I know that I’ve also said this before (can’t find it in my “sent mail” 
> folder), but the fact that some communities can still use this safely, or 
> must use it (for a variety of reasons usually around the infeasibility of 
> upgrading), doesn’t mean that the general populace should not be warned away 
> from doing these kinds of things.
>
>
>
> ___
> 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] GREASE ECH repeated value after HRR

[Stephen Farrell]

Hiya,

(I'm just getting around to playing with draft-13 ECH and
HRR and have a question...)

In 6.2 talking about GREASEd ECH, the draft says:

   If sending a second ClientHello in response to a
   HelloRetryRequest, the client copies the entire
   "encrypted_client_hello" extension from the first
   ClientHello.  The identical value will reveal to an
   observer that the value of "encrypted_client_hello" was
   fake, but this only occurs if there is a
   HelloRetryRequest.

I don't object to that, but can't recall why we wanted
the same value re-tx'd. (My code just naturally generated
a new GREASE ECH value and it all worked fine, so being
the lazy person I am, I'm wondering if doing nothing is
a good option:-)

Ta,
S.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] GREASE ECH repeated value after HRR

[David Benjamin]

It's because of the rules in RFC8446. If the server doesn't utter an
extension in HelloRetryRequest, the client is not allowed to change the
corresponding ClientHello extension. We found an implementation which
actually enforces this.
https://github.com/tlswg/draft-ietf-tls-esni/issues/358

David

On Tue, Aug 17, 2021 at 4:03 PM Stephen Farrell 
wrote:

>
> Hiya,
>
> (I'm just getting around to playing with draft-13 ECH and
> HRR and have a question...)
>
> In 6.2 talking about GREASEd ECH, the draft says:
>
> If sending a second ClientHello in response to a
> HelloRetryRequest, the client copies the entire
> "encrypted_client_hello" extension from the first
> ClientHello.  The identical value will reveal to an
> observer that the value of "encrypted_client_hello" was
> fake, but this only occurs if there is a
> HelloRetryRequest.
>
> I don't object to that, but can't recall why we wanted
> the same value re-tx'd. (My code just naturally generated
> a new GREASE ECH value and it all worked fine, so being
> the lazy person I am, I'm wondering if doing nothing is
> a good option:-)
>
> 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

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

[Benjamin Kaduk]

On Tue, Aug 17, 2021 at 07:25:33PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> I see absolutely nothing wrong with using FFDH(E) and ECDH, as long as at 
> least one of the keys is ephemeral. There is no need to “warn away”, IMHO. 

That's an interesting position to take.  Let me see if I understand it 
correctly.
(I will just write "DH" even though I mean (EC)DH.)

Static-static DH results in re-generating the same derived key on multiple 
protocol
instantiations, which is in some sense reusing a single key for multiple things 
and
thus disrecommended.  Though, in TLS, we have the Randoms that go into the key 
schedule,
so the actual traffic/Finished/etc. keys will diverge even for the 
static-static case.
However, it's hard to do formal analysis when the same secret is used across 
many
protocol instantiations spread out over time, and one has to ensure that the 
Randoms
actually are non-repeating in order for this to be a reliable scheme.  So 
there's plenty
of risk here and reasons to stay away.

Ephemeral-static DH makes a new derived key for each protocol instantiation and
simplifies the analysis (though subject to similar caveats as above about 
actually
using a unique ephemeral value each time).  It's clearly an improvement over 
static-static,
but anyone armed with a protocol transcript who discovers the secret part of 
the static
DH value can recover the derived key and deprotect the application data.  
Forward secrecy
is not obtained until the "static" private value is discarded, leaving risk of 
loss
of confidentiality due to endpoint compromise.

Ephemeral-ephemeral DH also makes a new derived key for each protocol 
instantiation, but
also allows the private DH values to be discarded "immediately", before any 
significant
application data is protected using key material stemming from the derived key. 
 This provides
the strongest kind of forward secrecy (provided that endpoints actually discard 
the private
ephemeral values), and is again a step up from the ephemeral-static case.

In light of the above, it seems that your concerns are more focused on "key 
reuse" than
forward secrecy.  Is that correct?
I have heard a lot of people saying that forward secrecy is important to them, 
so it's
not clear that your stance is the consensus position.

Thanks,

Ben

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

Re: [TLS] GREASE ECH repeated value after HRR

[Stephen Farrell]

Thanks David.
Cheers,
S.

On 17/08/2021 21:15, David Benjamin wrote:

It's because of the rules in RFC8446. If the server doesn't utter an
extension in HelloRetryRequest, the client is not allowed to change the
corresponding ClientHello extension. We found an implementation which
actually enforces this.
https://github.com/tlswg/draft-ietf-tls-esni/issues/358

David

On Tue, Aug 17, 2021 at 4:03 PM Stephen Farrell 
wrote:



Hiya,

(I'm just getting around to playing with draft-13 ECH and
HRR and have a question...)

In 6.2 talking about GREASEd ECH, the draft says:

 If sending a second ClientHello in response to a
 HelloRetryRequest, the client copies the entire
 "encrypted_client_hello" extension from the first
 ClientHello.  The identical value will reveal to an
 observer that the value of "encrypted_client_hello" was
 fake, but this only occurs if there is a
 HelloRetryRequest.

I don't object to that, but can't recall why we wanted
the same value re-tx'd. (My code just naturally generated
a new GREASE ECH value and it all worked fine, so being
the lazy person I am, I'm wondering if doing nothing is
a good option:-)

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





OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

[Dan Brown]

Deprecating non-forward-secure ECDH and FFDH is important.
Keeping FFDHE may be okay, e.g. for those who want forward security, but still 
don't trust ECC.


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


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

[TLS] RFC8447bis

[Christopher Wood]

Hi folks,

Based on discussing regarding draft-ietf-tls-hybrid-design during IETF 111, it 
became clear that we need some mechanism to deal with temporary, experimental 
codepoints for testing out new features. To that end, Sean and Joe recently 
published this draft:

   https://datatracker.ietf.org/doc/html/draft-salowey-tls-rfc8447bis-00

This document obsoletes RFC8447 and updates a number of other relevant 
documents. The main changes in this document are:

- Experimental codepoint policy and process 
(https://datatracker.ietf.org/doc/html/draft-salowey-tls-rfc8447bis-00#section-17)
- Updated Recommended registry values 
(https://datatracker.ietf.org/doc/html/draft-salowey-tls-rfc8447bis-00#section-5)

Please review the document, especially if you have thoughts about the 
experimental policy. Assuming there are no major objections, I'd like to 
propose that we proceed with the proposal to get things started.

Thanks,
Chris

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

Re: [TLS] RFC8447bis

[Martin Thomson]

I don't think that this approach is the best we could do.

Experiments, particularly large-scale ones, turn into deployments.  
Consequently the difference between "an experiment" and "a standard" is the 
date at which you look.  See also RFC 6648.

In that light, why not use the entire unassigned space for experiments?  A 
registry policy that allowed allocations for experiments, but marked those 
entries as temporary (the word "provisional" is usual here) would suffice.  
Reclaiming these codepoints might be more challenging than the draft makes out; 
the expiration time you have in the draft is fine, though I expect that any 
dates will be roundly ignored if code is still shipping.

The point of a registry is to avoid collisions and the interoperability 
failures that follow.  So I would also add that all new allocations (experiment 
or otherwise) should draw from the unassigned space at random, rather than 
sequentially.  That should minimize collisions up until the point where we have 
exhausted the space.

I would also prefer to have no space reserved for private use (though a very 
small space is tolerable).

(It shouldn't be a surprise, but I'm advocating for the same general approach 
that QUIC took.)

On Wed, Aug 18, 2021, at 09:34, Christopher Wood wrote:
> Hi folks,
> 
> Based on discussing regarding draft-ietf-tls-hybrid-design during IETF 
> 111, it became clear that we need some mechanism to deal with 
> temporary, experimental codepoints for testing out new features. To 
> that end, Sean and Joe recently published this draft:
> 
>https://datatracker.ietf.org/doc/html/draft-salowey-tls-rfc8447bis-00
> 
> This document obsoletes RFC8447 and updates a number of other relevant 
> documents. The main changes in this document are:
> 
> - Experimental codepoint policy and process 
> (https://datatracker.ietf.org/doc/html/draft-salowey-tls-rfc8447bis-00#section-17)
> - Updated Recommended registry values 
> (https://datatracker.ietf.org/doc/html/draft-salowey-tls-rfc8447bis-00#section-5)
> 
> Please review the document, especially if you have thoughts about the 
> experimental policy. Assuming there are no major objections, I'd like 
> to propose that we proceed with the proposal to get things started.
> 
> Thanks,
> Chris
> 
> ___
> 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] RFC8447bis

[Eric Rescorla]

On Tue, Aug 17, 2021 at 5:09 PM Martin Thomson  wrote:

> I don't think that this approach is the best we could do.
>
> Experiments, particularly large-scale ones, turn into deployments.
> Consequently the difference between "an experiment" and "a standard" is the
> date at which you look.  See also RFC 6648.
>
> In that light, why not use the entire unassigned space for experiments?  A
> registry policy that allowed allocations for experiments, but marked those
> entries as temporary (the word "provisional" is usual here) would suffice.
> Reclaiming these codepoints might be more challenging than the draft makes
> out; the expiration time you have in the draft is fine, though I expect
> that any dates will be roundly ignored if code is still shipping.
>
> The point of a registry is to avoid collisions and the interoperability
> failures that follow.  So I would also add that all new allocations
> (experiment or otherwise) should draw from the unassigned space at random,
> rather than sequentially.  That should minimize collisions up until the
> point where we have exhausted the space.
>
> I would also prefer to have no space reserved for private use (though a
> very small space is tolerable).
>
> (It shouldn't be a surprise, but I'm advocating for the same general
> approach that QUIC took.)
>

I agree with the bit about the unified space.

I'm a bit less sure about randomly versus sequentially, but I could go
either way. IIRC the QUIC thing leaned somewhat on the space being very big.

-Ekr


> On Wed, Aug 18, 2021, at 09:34, Christopher Wood wrote:
> > Hi folks,
> >
> > Based on discussing regarding draft-ietf-tls-hybrid-design during IETF
> > 111, it became clear that we need some mechanism to deal with
> > temporary, experimental codepoints for testing out new features. To
> > that end, Sean and Joe recently published this draft:
> >
> >https://datatracker.ietf.org/doc/html/draft-salowey-tls-rfc8447bis-00
> >
> > This document obsoletes RFC8447 and updates a number of other relevant
> > documents. The main changes in this document are:
> >
> > - Experimental codepoint policy and process
> > (
> https://datatracker.ietf.org/doc/html/draft-salowey-tls-rfc8447bis-00#section-17
> )
> > - Updated Recommended registry values
> > (
> https://datatracker.ietf.org/doc/html/draft-salowey-tls-rfc8447bis-00#section-5
> )
> >
> > Please review the document, especially if you have thoughts about the
> > experimental policy. Assuming there are no major objections, I'd like
> > to propose that we proceed with the proposal to get things started.
> >
> > Thanks,
> > Chris
> >
> > ___
> > 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] RFC8447bis

[Martin Thomson]

On Wed, Aug 18, 2021, at 11:31, Eric Rescorla wrote:
> I'm a bit less sure about randomly versus sequentially, but I could go 
> either way. IIRC the QUIC thing leaned somewhat on the space being very 
> big.

That is true.  QUIC has a large space, but TLS is a lot smaller.  This is just 
my attempt to avoid a repeat of the extension 26 mess.

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