Lester White writes:
> Title : Preferred Pronouns Extension for TLS
I think the Security Considerations section needs to mention two security
considerations, firstly the preferred identity is an unauthenticated parameter
and can't safely be used until the Finished message definit
I'm not sure I agree with all of Martin's remarks below,
but I absolutely agree both that we seem to be almost
happily adding complexity and that that's a bad plan.
S.
On 01/04/2021 02:57, Martin Thomson wrote:
I just reviewed the proposal to split HelloRetryRequest into outer and
(encrypted)
On Tue, Mar 30, 2021 at 9:39 PM Joseph Salowey
mailto:j...@salowey.net>> wrote:
There is at least one question on the list that has gone unanswered for some
time [1].
[1] https://mailarchive.ietf.org/arch/msg/tls/yCBYp10QuYPSu5zOoM3v84SAIZE/
I've found most of the OPAQUE drafts are pretty con
Sorry, I was thinking of the wrong draft. See:
https://tools.ietf.org/html/draft-irtf-cfrg-opaque-03#section-4.2.2
and
https://tools.ietf.org/html/draft-irtf-cfrg-opaque-03#appendix-C
thanks,
Rob
On Thu, Apr 1, 2021 at 6:08 AM Scott Fluhrer (sfluhrer)
wrote:
>
>
> On Tue, Mar 30, 2021 at 9:
Thanks Bob for pointing to the "real" ongoing specification of OPAQUE in
https://tools.ietf.org/html/draft-irtf-cfrg-opaque-03
and its careful specification of OPAQUE-3DH, including test vectors (and
sorry Scott for the typos in the other draft).
draft-irtf-cfrg-opaque is still work in process and
Folks-
I am appending what I sent Martin & Gorry this morning. I looked
quite quickly as Martin was looking for quick input. I am happy to
iterate if things aren't all that understandable.
allman
[Quick hit.]
I agree with Martin's DISCUSS and Gorry's notes. A couple more
things here ...
>
Hi Ekr!
> This means that we have rather more latitude in terms of how
> aggressively we retransmit because it only applies to a small
> fraction of the traffic.
(Strikes me as a bit of a weird formulation.)
> Firefox uses 50ms and AIUI Chrome
> uses a value derived from the ICE handshake (whic
Hi Martin, would you mind working out a PR? I think being able to compare
407 to a concrete alternative would be helpful. Just so that we're on the
same page, here's a quick summary of the issues that 407 is designed to
solve. (These may or may not be problems in your view, and I don't claim
this l
Given the range of Martin's comments, I'd be surprised
if that could be reduced to a PR;-)
But let me ask a question meanwhile - how often does HRR
actually happen and could we not just let ECH fail in a
bunch of situations that would otherwise require all this
new complexity?
Thanks,
S.
On 0
The Internet Engineering Task Force (IETF) prides itself on its open
philosophy, where anyone can submit a proposal or comment on work in progress,
regardless of financial resources, industry credentials, race, gender, sexual
orientation, or national origin, without any review by the organizatio
> But let me ask a question meanwhile - how often does HRR
> actually happen and could we not just let ECH fail in a
> bunch of situations that would otherwise require all this
> new complexity?
>
One way HRR is used is in case the client's and server's cipher suite
preferences don't intersect. Th
One way HRR is used is in case the client's and server's cipher suite
> preferences don't intersect. This feature is an essential part of TLS, as
> there's no a priori reason why the client and server will initially
> advertise overlapping preferences. (They usually do, hence the claim that
> HRR i
Thank you!
> On Apr 1, 2021, at 11:13 AM, Lars Eggert wrote:
>
> The Internet Engineering Task Force (IETF) prides itself on its open
> philosophy, where anyone can submit a proposal or comment on work in
> progress, regardless of financial resources, industry credentials, race,
> gender, sex
Hiya,
On 01/04/2021 19:13, Christopher Patton wrote:
But let me ask a question meanwhile - how often does HRR
actually happen and could we not just let ECH fail in a
bunch of situations that would otherwise require all this
new complexity?
One way HRR is used is in case the client's and serv
Gosh, and here I was addressing Peter Gutman's comments. Oh well.
--Les;
Sent: Thursday, April 01, 2021 at 11:13 AM
From: "Lars Eggert"
To: tls@ietf.org
Subject: Re: [TLS] draft-les-white-tls-preferred-pronouns
The Internet Engineering Task Force (IETF) prides itself on its open ph
> I absolutely agree both that we seem to be almost
> happily adding complexity
I don't think you have to assume bad intent (or negligence). Several people
brought up valid concerns and we're trying to address them.
> On Apr 1, 2021, at 4:46 AM, Stephen Farrell wrote:
>
>
> I'm not sure I ag
Hiya,
On 01/04/2021 19:28, Carrick Bartle wrote:
I absolutely agree both that we seem to be almost happily adding
complexity
I don't think you have to assume bad intent (or negligence). Several
people brought up valid concerns and we're trying to address them.
Hmm. I got an offlist mail on
Also additional meeting information is available here:
https://datatracker.ietf.org/meeting/upcoming
On Wed, Mar 31, 2021 at 9:03 PM Joseph Salowey wrote:
> The Transport Layer Security (tls) WG will hold a virtual interim meeting on
> 2021-04-01 from 12:00 to 13:00 America/Los_Angeles (19:00 t
Hi Martin,
Thanks for the comments. As the author of #374, I obviously didn't think it
so clearly unnecessary, but glad to hear your thoughts. Hopefully we can
get on the same page as to what the issues are and/or a better solution.
(Always happy to replace something with a simpler option, provide
Hiya,
On 01/04/2021 19:24, Stephen Farrell wrote:
some guidance on checking your front-
end's choice of curves and failing when some of the HRR
cases get out of whack
Actually it occurs to me that we could for example say
that back-ends are RECOMMENDED to support the first
curve listed in ECH
I'm going to briefly respond, but as this is a public holiday and I have no
real desire to work too much, please forgive any radio silence that follows.
On Fri, Apr 2, 2021, at 05:56, David Benjamin wrote:
> This was a previous attempt at this, but it seems to have been confusing.
>
> I do agree
On Thu, Apr 1, 2021 at 11:21 AM Carrick Bartle wrote:
> Thank you!
>
Yes, thank you. And, also thanks for doing useful engineering such as
https://github.com/NTAP/quant.
Maybe the IESG should consider deleting the IETF general list. I know this
list isn't the right venue to debate that idea, bu
Hi folks,
This pile of PRs was skipped during the interim today. They should be mostly
ready to go:
- https://github.com/tlswg/draft-ietf-tls-esni/pull/415
- https://github.com/tlswg/draft-ietf-tls-esni/pull/414
- https://github.com/tlswg/draft-ietf-tls-esni/pull/411
- https://github.com/tlswg/
23 matches
Mail list logo
