Re: [TLS] Fwd: New Version Notification for draft-belyavskiy-fakesni-00.txt

2019-02-20 Thread Dmitry Belyavsky
On Wed, Feb 20, 2019 at 10:35 AM Dmitry Belyavsky wrote: > > > On Wed, Feb 20, 2019 at 10:21 AM Peter Gutmann > wrote: > >> Dmitry Belyavsky writes: >> >> >Fake SNI is delivered out-of-band for the handshake >> >> But then won't the DPI check the out-of-band source as well? If you've >> got a

Re: [TLS] Negotiated Finite Field Diffie-Hellman shared secret calculation

2019-02-20 Thread David Benjamin
(We haven't actually implemented RFC 7919 and have no plans to, so I'm just going by the document.) RFC 7919 doesn't say anything, so I think the only reasonable interpretation is to continue with the legacy option for TLS 1.2 and below. It's also the only interoperable option given how the docume

Re: [TLS] Negotiated Finite Field Diffie-Hellman shared secret calculation

2019-02-20 Thread Andrey Jivsov
Why isn't the "The server indicates the choice of group to the client by sending the group's parameters as usual in the ServerKeyExchange" https://tools.ietf.org/html/rfc7919#section-4 an evidence that the server supports RFC 7919? On 2/20/19 10:29 AM, David Benjamin wrote: > (We haven't actuall

Re: [TLS] Negotiated Finite Field Diffie-Hellman shared secret calculation

2019-02-20 Thread David Benjamin
It is some evidence, but the server may have been configured with that group anyway. Regardless, the specification doesn't say anything, so I think the only reasonable interpretation is the existing TLS 1.2 mechanism, sadly. On Wed, Feb 20, 2019 at 12:48 PM Andrey Jivsov wrote: > Why isn't the >

Re: [TLS] Negotiated Finite Field Diffie-Hellman shared secret calculation

2019-02-20 Thread Martin Thomson
What David said. We implement 7919, which includes an option to only accept server shares from the 7919 groups. With that option a simple comparison is used to determine if the group is one from the spec, rejecting all else, but we otherwise just treat the share as normal. I'm not aware of an

Re: [TLS] Fwd: New Version Notification for draft-belyavskiy-fakesni-00.txt

2019-02-20 Thread Christian Huitema
On 2/20/2019 3:06 AM, Dmitry Belyavsky wrote: > > > On Wed, Feb 20, 2019 at 10:35 AM Dmitry Belyavsky > wrote: > > > > On Wed, Feb 20, 2019 at 10:21 AM Peter Gutmann > mailto:pgut...@cs.auckland.ac.nz>> wrote: > > Dmitry Belyavsky

Re: [TLS] Fwd: New Version Notification for draft-belyavskiy-fakesni-00.txt

2019-02-20 Thread Peter Gutmann
Christian Huitema writes: >Would it be possible to engineer a hidden channel in the TLS 1.3 Hello? I bet >that's quite doable. I am sure that fields like "opaque Random[32]" or "opaque >legacy_session_id<0..32>" could be used creatively, and there are other fields >in common extensions that could

Re: [TLS] Fwd: New Version Notification for draft-belyavskiy-fakesni-00.txt

2019-02-20 Thread Salz, Rich
It’s an arms race, privacy against inspection/blocking. There’s no way to avoid it. IETF specs being open documents freely available make the “good guys” job a little harder, maybe. :) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/list

Re: [TLS] Negotiated Finite Field Diffie-Hellman shared secret calculation

2019-02-20 Thread Peter Gutmann
Martin Thomson writes: >We implement 7919, which includes an option to only accept server shares from >the 7919 groups. With that option a simple comparison is used to determine if >the group is one from the spec, rejecting all else, but we otherwise just >treat the share as normal. My code fa

Re: [TLS] Fwd: New Version Notification for draft-belyavskiy-fakesni-00.txt

2019-02-20 Thread Stephen Farrell
On 20/02/2019 23:48, Christian Huitema wrote: > > Out of all the requirements listed in the encryption requirements draft, > the requirement to "not stand out" is probably the hardest to comply > with. Yep. I think it'd be worthwhile spending a bit of time to see if we could do better on that