Re: [TLS] Elliptic Curve J-PAKE

Hi Watson, When the attacker knows the relation, besides the active attack, there may be other things he can exploit. This however is not usually analysed as by the assumption of the proof, this should never happen. You¹re correct that J-PAKE uses Shamir-Fiat heuristics, hence the proof is in

Re: [TLS] Elliptic Curve J-PAKE

On Wed, Mar 27, 2019 at 7:56 PM Feng Hao wrote: > > Hi Hugo, > > > > Thanks for your comments. > > > Just to clarify the difference between SPAKE2 and J-PAKE - The proof of > SPAKE2 depends on the assumption of a trusted setup: the discrete logarithm > between the two group generators must be

Re: [TLS] Elliptic Curve J-PAKE

Hi Hugo, Thanks for your comments. Just to clarify the difference between SPAKE2 and J-PAKE - The proof of SPAKE2 depends on the assumption of a trusted setup: the discrete logarithm between the two group generators must be unknown by anyone. If a powerful adversary (3 letter agency) gathers

Re: [TLS] A use of flags

Is the concern that servers which never renegotiate and do not send any renegotiation_info are being flagged on ratings systems? That is desired behavior. See the final paragraph of section 4.3 . Those servers should be sending an empty

Re: [TLS] A use of flags

I would like to define a flag that says "no renegotiation allowed" This has come up (for pre 1.3 of course) a couple of times, that while you can signal "defaut" or "only secure" renegotiation, you can't signal "no renegotiation" in a way that is visible purely on the wire, to things like

[TLS] A use of flags

Inspired by a few side discussions and Yoav's new draft, I have the pleasure of announcing the first proposal to use that mechanism: https://tools.ietf.org/html/draft-thomson-tls-sic-00 I'm sure that there are plenty of opportunities to bike shed on the flags format, but it's definitely

Re: [TLS] comment on draft-kinnear-tls-client-net-address

On Wednesday, 27 March 2019 14:51:43 CET Martin Thomson wrote: > On Tue, Mar 26, 2019, at 14:30, Hubert Kario wrote: > > On Tuesday, 26 March 2019 09:07:51 CET Martin Thomson wrote: > > > We don't trust that the key share or certificate is good either, but > > > once we have a Finished message,

Re: [TLS] comment on draft-kinnear-tls-client-net-address

On Tue, Mar 26, 2019, at 14:30, Hubert Kario wrote: > On Tuesday, 26 March 2019 09:07:51 CET Martin Thomson wrote: > > We don't trust that the key share or certificate is good either, but once we > > have a Finished message, that is retroactively authenticated and can be > > used. We rely on this

Re: [TLS] A flags extension

On Wed, Mar 27, 2019, at 14:47, Eric Rescorla wrote: > Of course, at some point it starts to make sense to do RLE. I considered that, but I don't see this being sufficiently sparsely populated. ___ TLS mailing list TLS@ietf.org

Re: [TLS] A flags extension

Of course, at some point it starts to make sense to do RLE. -Ekr On Wed, Mar 27, 2019 at 6:43 AM Martin Thomson wrote: > Why not go all in - make this a byte string and start from 0x80 in the > first byte. When we define the 9th flag, we add another byte. Then you > have up to 2040 flags

Re: [TLS] A flags extension

> On 27 Mar 2019, at 12:26, Daniel Kahn Gillmor wrote: > > On Wed 2019-03-27 10:52:20 +0100, Nikos Mavrogiannopoulos wrote: >> Right. What about defining a set of extensions (e.g., 2 extensions) of >> flags as: >> >> struct { >> uint64 flags; >> } Flags; > > If we're going to be doing this

Re: [TLS] A flags extension

On Wed 2019-03-27 10:52:20 +0100, Nikos Mavrogiannopoulos wrote: > Right. What about defining a set of extensions (e.g., 2 extensions) of > flags as: > > struct { >uint64 flags; > } Flags; If we're going to be doing this kind of bit-shaving, this is the way to go, starting with a single

Re: [TLS] A flags extension

On Tue, 2019-03-26 at 10:49 +0100, Yoav Nir wrote: > > On 26 Mar 2019, at 10:35, Nikos Mavrogiannopoulos > > wrote: > > > > On Tue, 2019-03-26 at 10:11 +0100, Yoav Nir wrote: > > > > On 26 Mar 2019, at 9:06, Martin Thomson > > > > wrote: > > > > > > > > This needs more space for each flag. 8

Re: [TLS] Elliptic Curve J-PAKE

Hi Hugo, I raised this issue because the IoT device bootstrapping/commissioning use case was the justification for developing OPAQUE and J-PAKE. J-PAKE seems to have met the requirements by companies working in the Thread Group working on their IEEE 802.15.4 mesh network*. As someone on the