Re: [TLS] Moving SHA-1 signature schemes to not recommended in draft-ietf-tls-md5-sha1-deprecate

Thank you, Joe. Sent from my mobile device > On Jun 25, 2020, at 1:10 AM, Joseph Salowey wrote: > >  > Hi All, > > I submitted a PR [1] for draft-ietf-tls-md5-sha1-deprecate to move the > recommended IANA registry entries for rsa_pkcs1_sha1 and ecdsa_sha1 in the > Signature Scheme registry

Re: [TLS] Moving SHA-1 signature schemes to not recommended in draft-ietf-tls-md5-sha1-deprecate

* I submitted a PR [1] for draft-ietf-tls-md5-sha1-deprecate to move the recommended IANA registry entries for rsa_pkcs1_sha1 and ecdsa_sha1 in the Signature Scheme registry from Y to N. This change can be incorporated with any updates from the AD review. Yes yes yes. Or no no no? I th

[TLS] Network Tokens I-D and TLS / ESNI

Hi all, I wanted to briefly introduce network tokens ( https://networktokens.org ) into this list, how they relate with TLS and ESNI, and kindly ask anyone that is interested to share feedback and join the discussion. Network tokens is a method for endpoints to explicitly and securely coordinat

Re: [TLS] something something certificate --- boiling a small lake

My aim with something-something- certificate is/was to address a narrow but existing need by documenting current practice while introducing eno

Re: [TLS] something something certificate --- boiling a small lake

Brian Campbell wrote: > My aim with something-something- > > certificate > > is/was to address a narrow but existing ne

Re: [TLS] Network Tokens I-D and TLS / ESNI

One quick comment is that binding tokens to IP addresses is strongly counter-recommended. It doesn't survive NATs or proxies, mobility, and it is especially problematic in IPv6+IPv4 dual-stack environments. (Even in IPv6-only, privacy addressing causes problems here.) Even if you have a way to con

Re: [TLS] something something certificate --- boiling a small lake

BTW, thanks for the something-something-certificate work. Looking at the I-D, draft-bdc-something-something-certificate-04, I see there's no way to send the certificate chain on. I understand the motivation (compression), but it really would be best to send on the full chain sent by the client.

Re: [TLS] Network Tokens I-D and TLS / ESNI

(cross-posting to network-tokens@ as this is the first related topic - apologies for any duplicates) Hi Erik, Thanks for the comments. That's a good point, and wanted to clarify the reasoning around binding fields in general, as well as  binding tokens to IP addresses specifically. Unlike acc

Re: [TLS] Network Tokens I-D and TLS / ESNI

On 6/25/20 3:29 PM, Erik Nygren wrote: > One quick comment is that binding tokens to IP addresses is strongly > counter-recommended. > It doesn't survive NATs or proxies, mobility, and it is especially > problematic in IPv6+IPv4 dual-stack environments. There's been a bunch of past work done devel