Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp

2020-07-30 Thread Töma Gavrichenkov
Peace, On Mon, Jul 27, 2020, 4:18 PM Blumenthal, Uri - 0553 - MITLL wrote: > in this particular case, instead of "if you want to do this, then do it > that way, and I'll help you inter-operate" I prefer "if you want to do this > - you're on your own, don't seek a blessing or advice from me". >

Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp

2020-07-30 Thread Töma Gavrichenkov
Peace, On Wed, Jul 29, 2020, 2:20 PM Salz, Rich wrote: > Also, a CDN is not a proxy. It **IS** an entity that the origin has > contracted with to perform certain functions. > It is (in all but a couple of implementations I think) a *proxy* that the origin has contracted with. Could you please

Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp

2020-07-30 Thread Töma Gavrichenkov
Peace, On Thu, Jul 30, 2020 at 3:33 PM Salz, Rich wrote: >> It is (in all but a couple of implementations I think) > a *proxy* that the origin has contracted with. Could > you please elaborate on your point? > > It has a TLS cert that identifies itself as the origin. It depends! In the majorit

Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp

2020-07-30 Thread Töma Gavrichenkov
Peace, On Thu, Jul 30, 2020, 4:39 PM Salz, Rich wrote: > We have a product, site shield, that customers can use to limit the IP > addresses of who can reach their origin server. Everyone else is blocked.. > Some use that to make sure that *only* Akamai servers will talk to them, > and that ever

Re: [TLS] What is "completed handshake"?

2022-08-08 Thread Töma Gavrichenkov
Peace, On Mon, Aug 8, 2022 at 4:19 PM Dmitry Belyavsky wrote: > RFC 8446 refers to "completed handshake" as a prerequisite for some messages. > But looking for the word "completed", I don't see any definition. Section "2. Protocol Overview", page 13 says: "Upon receiving the server's messages,

Re: [TLS] draft-dkg-tls-reject-static-dh

2018-12-08 Thread Töma Gavrichenkov
n perspective) So no. TLS keyshare reuse is visible from the attacker's point of view, so must not be done under a DDoS attack. | Töma Gavrichenkov | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191 | mailto: xima...@gmail.com | fb: ximaera | telegram: xima_era | skype: xima_

Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1"

2019-04-26 Thread Töma Gavrichenkov
Peace, On Fri, Apr 26, 2019, 6:08 PM Hubert Kario wrote: > I think it's fine as it is. This use case is very specific and the impact > for > it is limited. So yes, I think that the delay between publishing and now > will > change the situation even more out of favour of TLS 1.0. > Exactly my th

Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1"

2019-04-30 Thread Töma Gavrichenkov
On Wed, May 1, 2019 at 2:50 AM Martin Rex wrote: > It is formally provable Everything must be accounted for as provable until it's proved unless it's proved to be false. Do you possess an external (academic?) reference? -- Töma ___ TLS mailing list T

Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1"

2019-05-06 Thread Töma Gavrichenkov
On Fri, May 3, 2019 at 8:31 PM Peter Gutmann wrote: > why not also add MUST NOT MD5 and SHA1 in TLS 1.2 to the text? Because the document has now such a direct and ambitious title that ~most of the target audience won't even read the text beyond the title, hence this message won't be delivered.

Re: [TLS] The TLS WG has placed draft-lvelvindron-tls-md5-sha1-deprecate in state "Call For Adoption By WG Issued"

2019-07-24 Thread Töma Gavrichenkov
On Wed, Jul 24, 2019 at 4:42 PM IETF Secretariat wrote: > The TLS WG has placed draft-lvelvindron-tls-md5-sha1-deprecate in state > Call For Adoption By WG Issued (entered by Sean Turner) I support the adoption. -- Töma ___ TLS mailing list TLS@ietf.o