Hi TLSWG,
I have read draft-jhoyla-req-mtls-flag-00 and the ensuing mailing list
discussion. I also watched the recording from IETF 118. I fully under
the use-case where trusted client bots need a mechanism to indicate to
the server that mutual certificate based authentication is desired.
Un
Please see my earlier comment regarding this draft:
https://mailarchive.ietf.org/arch/msg/tls/g3tImSVXO8AEmPH1UlwRB1c1TLs/
In summary: the functionality of this draft is already achievable by
using the client_certificate_type extension defined in RFC 7250:
https://datatracker.ietf.org/doc/html
ty of traffic by any means.
Regards,
Jonathan
On Thu, 4 Apr 2024, 01:17 Christopher Patton,
wrote:
It would be great to here from Jonathan (the author) if RFC
7250 is already sufficient for this use case.
On Tue, Apr 2, 2024 at 10:23 P
Hi Russ, TLS WG:
I had intended to reply on this topic a long time ago but somehow forgot.
I wonder if you have checked Noise Explorer handshake patterns:
https://noiseexplorer.com/patterns/.
I think it covers all the different PSK-based handshake patterns: Npsk0,
Kpsk0, Xpsk1, NNpsk0, NNpsk
ame", at least it's in my opinion
not a "public" domain-name.
With that, please keep RFC7250 "as it is" and if you really insist,
introduce a new certificate type, which then may be trimmed to the
use-case, you have in mind.
br
Achim
Am 18.11.24 um 07:25 schrieb
Hi Hannes, all,
Coming back to this. I'd disagree with the assertion that when using the
raw public key mode, the public key is the identity. We don't open a
connection to a key - we open a connection to a domain name or to an IP
address unless of course we are a HIPster and use Host Iden
Hi Jim,
On 7/6/20 7:06 PM, Jim Schaad wrote:
-Original Message-
From: Mohit Sethi M
<mailto:mohit.m.se...@ericsson.com>
Sent: Monday, July 6, 2020 3:10 AM
To: Jim Schaad <mailto:i...@augustcellars.com>;
draft-ietf-tls-external-psk-
guida...@ietf.org<mailto:guida.
could consider using a construct based on one way hash
functions so that the typed-in external PSK identity (presumably with not so
good privacy properties) are never sent on the wire.
--Mohit
On 7/8/20 5:45 PM, Jim Schaad wrote:
From: Mohit Sethi M
<mailto:mohit.m.se...@ericsson.com>
Hi Carrick,
Thank you for the review. I also added some comments in-line.
On 8/18/20 6:26 PM, Christopher Wood wrote:
> Hi Carrick,
>
> Sorry for the delay. Please see inline below!
>
> On Thu, Jul 9, 2020, at 10:09 PM, Carrick Bartle wrote:
>> Isn’t the rerouting attack described in Section 4 no
A strong +1 on the security issues of decode -> extract -> re-encode ->
verify signature flow. The lack of canonical encoding can also mean that
the resulting bytes can be different in different encoder/decoder
implementations.
It would have been nice to have canonical JSON. Some implementation
Hi Anders,
On 10/7/20 10:14 PM, Anders Rundgren wrote:
> On 2020-10-07 19:47, Mohit Sethi M wrote:
>> A strong +1 on the security issues of decode -> extract -> re-encode ->
>> verify signature flow. The lack of canonical encoding can also mean that
>> the resul
+1 for a deterministic (minimal) encoding.
--Mohit
On 11/15/20 10:13 PM, Eric Rescorla wrote:
Trying to close out this discussion, it seems to me like there are three major
options:
1. The current scheme
2. The current scheme with a deterministic minimal encoding (e.g., the two byte
version is
Top posting to explain the need for a reliable notification of protocol
completion:
On 1/4/21 5:44 AM, Martin Thomson wrote:
I have a much simpler one: the EAP layer has a signal that the protocol is
complete: EAP-Success
Alan Dekok explained in a separate email thread why this is not the cas
Hi again,
The following issues are related but not exactly the same:
1. indication from the server that the handshake is complete and it is
okay to tear down the tunnel
2. indication from the server that no more post-handshake messages
(containing NewSessionTicket or something else) will be sent
Hi Joe,
On 1/5/21 8:44 AM, Joseph Salowey wrote:
On Mon, Jan 4, 2021 at 6:08 AM Alan DeKok
mailto:al...@deployingradius.com>> wrote:
On Jan 3, 2021, at 10:44 PM, Martin Thomson
mailto:m...@lowentropy.net>> wrote:
> # Key Schedule
>
> The other thing I observe is the way that this slices up the
Hi Alan,
Cleaning up the email. The current draft says the exporter should be called
once as:
Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material",
Type-Code, 128)
and then split the 128 into MSK (64) and EMSK (64). As said, from initial
glance, it seem
t to respect the purpose for which
> these inputs were designed.
>
> Cheers,
> Martin
>
> On Wed, Jan 6, 2021, at 17:24, Joseph Salowey wrote:
>>
>> On Tue, Jan 5, 2021 at 8:31 AM Alan DeKok wrote:
>>> On Jan 5, 2021, at 11:13 AM, Mohit Sethi M
>>&
Hi Ben,
On 1/7/21 9:21 AM, Benjamin Kaduk wrote:
> On Tue, Jan 05, 2021 at 10:41:50AM -0500, Alan DeKok wrote:
>> On Jan 5, 2021, at 4:47 AM, Mohit Sethi M wrote:
>>> What I am gathering is that this commitment message should instead be
>>> made into a confirmation m
Hi Martin,
Thanks for the quick response.
On 1/8/21 10:25 AM, Martin Thomson wrote:
> On Fri, Jan 8, 2021, at 18:54, Mohit Sethi M wrote:
>> Thanks for pointing this out. I think Ben also mentioned this in his
>> review. I am not sure if it is necessary to add the type-code to th
Hi Ben,
On 1/29/21 8:32 PM, Benjamin Kaduk wrote:
Hi Alan,
I see that the thread is continuing and that perhaps my reply will even
become stale as I write it, but I'm replying to your note instead of the
tip of the thread because it has good context for making some broader
points that I would li
Hi all,
I have now read both the papers. I am not sure the attacks in [2] are anymore
possible:
- The first attack described in section 4.1.1 shows that an EAP-Success leads
to an unconditional transition to the Authenticated state irrespective of the
current state. However, I am not sure this
Hi all,
Thanks Owen for starting this discussion. For some context, the EMU working
group is currently working on a document titled "Using EAP-TLS with TLS 1.3":
https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-06
There has been recent discussion in the working group on whether EAP-TLS shou
Hi all,
On the topic of external PSKs in TLS 1.3, I found a publication on the
Selfie attack: https://eprint.iacr.org/2019/347
Perhaps this was already discussed on the list. I thought that sharing
it again wouldn't hurt while we discuss how servers distinguish between
external and resumption
,
John
-Original Message-
From: TLS <mailto:tls-boun...@ietf.org> on behalf of
"Hao, Feng"
<mailto:feng@warwick.ac.uk>
Date: Tuesday, 24 September 2019 at 16:09
To: Mohit Sethi M
<mailto:mohit.m.sethi=40ericsson@dmarc.ietf.org>,
"
e
nodes only complete one and where the nodes have different preferred
cipher suites, an attacker can affect which of the two nodes'
preferred cipher suites will be used by blocking the other exchange.”
John
From: TLS <mailto:tls-boun...@ietf.org> on behalf of
Mohit Sethi M
<m
/8/2019 9:46 AM, Christopher Wood wrote:
On Tue, Oct 8, 2019, at 2:55 AM, Mohit Sethi M wrote:
Hi Chris,
For the benefit of the list, let me summarize that the selfie attack is
only relevant where multiple parties share the same PSK and use the
same PSK for outgoing and incoming connections
uting in
> groups, each endpoint needs to know the identifier of the other
> endpoint with which they want to connect and compare it with the other
> endpoint’s identifier in context. Of course, this only prevents
> attacks by non-members; the endpoints that share the group key can
> a
ema wrote:
>>
>> On 10/8/2019 9:46 AM, Christopher Wood wrote:
>>
>>> On Tue, Oct 8, 2019, at 2:55 AM, Mohit Sethi M wrote:
>>>>
>> Hi Chris,
>>
>> For the benefit of the list, let me summarize that the selfie attack is
>> only relevant
identifiers. However, it seems cleaner to
not re-use random nonces from the cryptographic protocols as identifiers.
Cheers,
John
From: TLS <mailto:tls-boun...@ietf.org> on behalf of
Mohit Sethi M
<mailto:mohit.m.sethi=40ericsson@dmarc.ietf.org>
Date: Tuesday, 8 October 2019
I believe that my pull request was indeed covering the different cases you talk
about. See in-line pieces of text from my pull request:
On 11/21/19 10:48 AM, Eric Rescorla wrote:
To recap what I was saying at the microphone earlier today about
selfie/reroute issues, there are actually three separ
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
, please contact the sender and delete the material from any
> computer. This e-mail does not constitute a contract offer, a contract
> amendment, or an acceptance of a contract offer unless explicitly and
> conspicuously designated or stated as such.
>
>
>
> -Ursprüng
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
mitigations.
--Mohit
On 1/21/20 1:26 PM, Mohit Sethi M wrote:
> 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
>
As a member of the design team (and a co-author), I naturally support
the adoption of this document.
I also take this opportunity to thank Chris Wood for shepherding the
design team and getting the document ready.
--Mohit
On 6/5/20 6:05 PM, Sean Turner wrote:
> Just a reminder that this call e
Hi Jim,
Thanks for the review. A clarifying question in-line.
On 7/2/20 12:02 AM, Jim Schaad wrote:
> * In section 4 there is a statement that switching the roles of servers
> which use PSKs will lead to weakening of security properties. As this is a
> common scenario today in situations where y
Reviewer: Mohit Sethi
Review result: Ready
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more
37 matches
Mail list logo
