In the TLS meeting on Tuesday, Kenny asked about the analysis of OPAQUE in
the context of TLS. One important property of OPAQUE is that its design and
analysis is modular. It applies to the composition of *any* OPRF with *any*
(KCI-secure) key exchange. This is why we can integrate OPAQUE with
Hi Hannes,
J-PAKE is a symmetric PAKE. Both parties store the same password. It is not
suitable for most client-server scenarios where using J-PAKE would mean
that an attacker that breaks into the server simply steals all plaintext
passwords. OPAQUE is an asymmetric (or augmented) PAKE where user
Nick mentioned at the WG meeting today we were having some hiccups.
These hiccups have been fixed and we have a delegated credential.
Please let us know the results. Note the cert has an extra 05 00 in
the extension.
Sincerely,
Watson Ladd
___
TLS
On Tue, Mar 26, 2019 at 04:38:11PM +0100, Yoav Nir wrote:
>
>
> > On 26 Mar 2019, at 14:45, Hubert Kario wrote:
> >
> > On Monday, 25 March 2019 22:09:35 CET Yoav Nir wrote:
> >> Hi. Today at the TLS meeting, there was a discussion at the mic about
> >> 1-bit
> >> extensions that only serve
On Tue, Mar 26, 2019 at 6:21 PM Sniffen, Brian wrote:
> Brotli has a dictionary built into the algorithm. I believe that is indeed
> being used, as it's a part of Brotli. I think the earlier email was saying
> no external certificate-specific dictionary used.
>
>
> Brotli 1.03 and 1.05 each
> On 26 Mar 2019, at 18:49, Hubert Kario wrote:
>
> On Tuesday, 26 March 2019 16:38:11 CET Yoav Nir wrote:
>>> On 26 Mar 2019, at 14:45, Hubert Kario wrote:
>>>
>>> On Monday, 25 March 2019 22:09:35 CET Yoav Nir wrote:
Hi. Today at the TLS meeting, there was a discussion at the mic
On Wed, Feb 20, 2019 at 03:48:18PM -0800, 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. The
> current ESNI draft works but usage of ESNI can still be detected. As
On Tue, Feb 19, 2019 at 11:04:06PM +0300, Dmitry Belyavsky wrote:
> Please take a look at an initial submission of the draft.
> The draft describes a Fake SNI mechanism intended to cheat DPI systems in
> a case
> when a DPI system blocks the connection if ESNI is present.
>
> --
On Tuesday, 26 March 2019 16:38:11 CET Yoav Nir wrote:
> > On 26 Mar 2019, at 14:45, Hubert Kario wrote:
> >
> > On Monday, 25 March 2019 22:09:35 CET Yoav Nir wrote:
> >> Hi. Today at the TLS meeting, there was a discussion at the mic about
> >> 1-bit extensions that only serve to indicate
Brotli has a dictionary built into the algorithm. I believe that is indeed
being used, as it's a part of Brotli. I think the earlier email was saying no
external certificate-specific dictionary used.
Brotli 1.03 and 1.05 each changed the standard dictionary—didn’t they? Perhaps
I am
Hi all,
in context of the OPAQUE talk by Nick today at the TLS WG meeting I mentioned
that the Thread Group has used the Elliptic Curve J-PAKE for IoT device
onboarding.
Here is the draft written for TLS 1.2:
https://tools.ietf.org/html/draft-cragie-tls-ecjpake-01
The mechanism is described in
On Tue, Mar 26, 2019 at 5:07 PM Sniffen, Brian wrote:
> >> WG - I’d like to echo Alessandro request for reviews. If this
> outstanding WG item is not resolved before IETF103 we will discuss the
> outstanding issue there, and barring any other major issues we are planning
> to WGLC the draft
>> WG - I’d like to echo Alessandro request for reviews. If this outstanding
>> WG item is not resolved before IETF103 we will discuss the outstanding issue
>> there, and barring any other major issues we are planning to WGLC the draft
>> after IETF103.
>>
>> One question: There was some
> On 26 Mar 2019, at 14:45, Hubert Kario wrote:
>
> On Monday, 25 March 2019 22:09:35 CET Yoav Nir wrote:
>> Hi. Today at the TLS meeting, there was a discussion at the mic about 1-bit
>> extensions that only serve to indicate support for an optional feature. EKR
>> commented that such
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.
Title : Deprecating TLSv1.0 and TLSv1.1
Authors : Kathleen Moriarty
Stephen
On Monday, 25 March 2019 22:09:35 CET Yoav Nir wrote:
> Hi. Today at the TLS meeting, there was a discussion at the mic about 1-bit
> extensions that only serve to indicate support for an optional feature. EKR
> commented that such extensions take 4 bytes each and that maybe we need to
> replace
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 property for a bunch of things.
yes, but those things are
> On 26 Mar 2019, at 12:05, Peter Gutmann wrote:
>
> Yoav Nir writes:
>
>> Are we really worried that we’re going to have more than 255 optional
>> features for TLS?
>
> You're new here aren't you?
>
No, but I’m looking at the TLS registries (
Yoav Nir writes:
>Are we really worried that we’re going to have more than 255 optional
>features for TLS?
You're new here aren't you?
Peter.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
> 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 bits is a pretty small
>>> space. If you are concerned with the size of the
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 bits is a pretty small
> > space. If you are concerned with the size of the result, we have
> > some variable-length integer encodings you could
On Tue, 26 Mar 2019 at 09:12, Yoav Nir wrote:
> Are we really worried that we’re going to have more than 255 optional
> features for TLS?
Probably not; but what about an optional feature that needs 3 bits? Is
it better to kick them off into 4 bytes?
-tom
> On 26 Mar 2019, at 9:06, Martin Thomson wrote:
>
> This needs more space for each flag. 8 bits is a pretty small space. If you
> are concerned with the size of the result, we have some variable-length
> integer encodings you could try.
Ah, the beautiful variable length encodings. Like:
>This needs more space for each flag. 8 bits is a pretty small space. If
> you are concerned with the size of the result, we have some variable-length
> integer encodings you could try.
Enh, just take 16 bits. Nobody will ever need more than 640k
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 property for a bunch of things.
On Mon, Mar 25, 2019, at 19:12, Hubert Kario wrote:
> On Monday, 25 March 2019 17:02:34 CET
This needs more space for each flag. 8 bits is a pretty small space. If you
are concerned with the size of the result, we have some variable-length integer
encodings you could try.
On Tue, Mar 26, 2019, at 00:22, Salz, Rich wrote:
>
> That was FAST.
>
>
> Looks good.
>
>
> *From: *Yoav
26 matches
Mail list logo
