I support the proposal from Viktor. It is important to minimize the
involved resource and provide the client the ability to explicitly inform
the server its policy.
As explained above, this mechanism comes with no additional complexity and
address a full range of applications.
See below my commen
On Tue, Jan 21, 2020 at 05:46:10PM -0500, Viktor Dukhovni wrote:
> > 2. The additional cost of multiple tickets seems extraordinarily
> >small, so I am not at all persuaded that there is enough value in
> >this use case to justify adding new protocol machinery, even
> >ignoring point (
On Tue, Jan 21, 2020 at 01:17:59PM -0800, Eric Rescorla wrote:
> I would make several points here:
>
> 1. RFC 8446 explicitly discourages ticket reuse
>(https://tools.ietf.org/rfcmarkup?doc=8446#appendix-C.4). so we
>should not be designing an extension to enable reuse. While it's
>po
I would make several points here:
1. RFC 8446 explicitly discourages ticket reuse
(https://tools.ietf.org/rfcmarkup?doc=8446#appendix-C.4). so we
should not be designing an extension to enable reuse. While it's
potentially true that some applications do not benefit from
non-reuse, crea
Viktor and I spoke in more detail. The use-case he brings up makes more sense
to me now. The key observation is that this is not about a "client" in the
conventional (or browser) sense, but rather more like a peer-to-peer kind of
thing, where the client is just the one who initiates a connectio
On Tue, Jan 21, 2020 at 03:24:50PM +, Salz, Rich wrote:
> >This is clearly a subjective call, so I'll step back now.
>
> Yes it is. But I will say that I agree with you and think the
> cleverness introduced by the "255 is magic" proposal is not warranted.
Really? TLS has no sentinel cod
On Tue, Jan 21, 2020 at 07:17:05AM -0800, Eric Rescorla wrote:
> I agree with Martin that this is unnecessary complexity.
The objections stated are non-responsive, and dismiss a valid
use-case.
There is ZERO additional complexity.
- Servers will already range-check the requested ticket count
A question regarding the scope of the PSK design team:
In my opinion there is definitely a need for a secure solution for “low-entropy
PSK” approaches. It seems that this topic does not seem to be within the scope
that Sethi Mohit did have in mind.
If this topic would be out of the scope of the
>This is clearly a subjective call, so I'll step back now.
Yes it is. But I will say that I agree with you and think the cleverness
introduced by the "255 is magic" proposal is not warranted.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org
I agree with Martin that this is unnecessary complexity.
In addition, I would note that switching to a new ticket *does* help even
if the server is using the same STEK because it improves privacy.
-Ekr
On Tue, Jan 21, 2020 at 12:58 AM Martin Thomson wrote:
> On Tue, Jan 21, 2020, at 16:54, Vi
Sean:
I can help with this design team.
Russ
> On Jan 20, 2020, at 11:01 PM, Sean Turner wrote:
>
> At IETF 106, we discussed forming a design team to focus on external PSK
> management and usage for TLS. The goal of this team would be to produce a
> document that discusses considerations f
I am willing to contribute.
-Ekr
On Tue, Jan 21, 2020 at 2:50 AM Jonathan Hoyland
wrote:
> Hi All,
>
> This is something I'm very interested in.
>
> Definitely want to participate.
>
> Regards,
>
> Jonathan
>
> On Tue, 21 Jan 2020 at 10:04, Mohit Sethi M 40ericsson@dmarc.ietf.org> wrote:
Just to clarify myself further, I would not want us to change the TLS
1.3 protocol. I would rather have this design team produce an
informational document that discusses considerations when using external
PSKs in different settings, as well as, privacy of PSK identities and
possible mitigations
Thanks for clarifying. I would still like that this design team to have
a narrow scope. As Sean said in his initial email:
> forming a design team to focus on external PSK management and usage for TLS
--Mohit
On 1/21/20 12:40 PM, Björn Haase wrote:
>> Mohit Sethi M wrote:
>> I would let CFRG d
Hi All,
This is something I'm very interested in.
Definitely want to participate.
Regards,
Jonathan
On Tue, 21 Jan 2020 at 10:04, Mohit Sethi M wrote:
> I would let CFRG deal with the PAKE selection process:
> https://mailarchive.ietf.org/arch/msg/cfrg/-a1sW3jK_5avmb98zmFbCNLmpAs
> and not h
> Mohit Sethi M wrote:
> I would let CFRG deal with the PAKE selection process:
> and not have this design team spend time and energy on designing PAKEs.
That was not what I was suggesting. Instead, I was suggesting to *incorporate*
the results of the selection process into TLS, such that there
I would let CFRG deal with the PAKE selection process:
https://mailarchive.ietf.org/arch/msg/cfrg/-a1sW3jK_5avmb98zmFbCNLmpAs
and not have this design team spend time and energy on designing PAKEs.
--Mohit
On 1/21/20 11:52 AM, Björn Haase wrote:
> Hello to all,
>
> I am also willing to contribu
Hello to all,
I am also willing to contribute. My concern is that I observe that in some
industrial control applications, PSK mechanisms (that actually require
high-entropy keys) are (mis)-used in conjunction with TLS, where the PSK is
actually of insufficient entropy (maybe derived only from a
I am certainly interested and willing to contribute. We need some
consensus on whether PSKs can be shared with more than 2 parties,
whether the parties can switch roles, etc.
EMU is going to work on EAP-TLS-PSK and the question of
privacy/identities will pop-up there too.
--Mohit
On 1/21/20 7
On Tue, Jan 21, 2020 at 07:57:27PM +1100, Martin Thomson wrote:
> On Tue, Jan 21, 2020, at 16:54, Viktor Dukhovni wrote:
> > There's no need to exclude valid use-cases. The refined proposal
> > is rather non-invasive, and handles this case cost-effectively
> > on clients that re-use tickets (and
On Tue, Jan 21, 2020, at 16:54, Viktor Dukhovni wrote:
> There's no need to exclude valid use-cases. The refined proposal
> is rather non-invasive, and handles this case cost-effectively
> on clients that re-use tickets (and don't use early-data, ...).
I don't find your arguments persuasive. Thi
Hello tlsWG,
First I would like to introduce myself to you. My name is Justice Parham
(github mrsylerpowers) a current Senior Undergraduate Student at North
Carolina A&T State University. As my senior project I decided to create a
android system wide implementation of the ESNI Draft. I am planning
22 matches
Mail list logo
