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 attemp
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 als
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
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.o
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
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 enforce
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 unders
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
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 fi
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
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 t
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 saf
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.
>
>
>
> > w
> 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 t
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 t
(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
po
16 matches
Mail list logo
