> Again, think carefully about the data you are recording. Also, TLS1.2 allows
> renegotiation in an active connection to do things like change the cipher
> algorithm, ask the client to send its certificate, and so on. Are you going
> to record those? Client authentication seems like something
Happy 2024! Hoping to close this one out by Monday so get your comment in!
Cheers,
spt
> On Dec 12, 2023, at 08:38, Sean Turner wrote:
>
> Hi! Rich $, Martin T, and ekr have all added some thoughts. Anybody else
> have some thoughts?
>
> spt
>
>> On Dec 6, 2023, at 11:20, Sean Turner
Hi Thom
thanks for the quick review.
Directionality of the extended key updates: I should be more clear in
the examples and in the write-up that these key updates can be initiated
by both parties.
Description about when the keys can be deleted: I will re-review the
text again to improve the
> We would be recording the records send by the client to the servers, and
> those received by the client from the server.
So presumably you need some kind of direction/origin indicator.
___
TLS mailing list
TLS@ietf.org
On Thu, Jan 04, 2024 at 04:26:09PM +, Dennis Jackson wrote:
> From a security perspective, this would be equivalent to having the
> client open a new connection to the server using a session ticket from
> the existing connection with psk_dhe_ke mode?
>
> I guess the ergonomics of that
Hi Ilari,
thanks again for the super quick feedback. Remarks below:
Am 04.01.2024 um 14:53 schrieb Ilari Liusvaara:
On Thu, Jan 04, 2024 at 11:42:13AM +, Tschofenig, Hannes wrote:
Hi all,
we have just submitted a draft that extends the key update
functionality of TLS/DTLS 1.3. We call
> Merging the thread this early didn't help this conversation. I am sure I have
> missed replying to some of my points that you responded to.
Sorry about that, I did not realise it.
There is one important part that was missed, I put it in this message separate
from the previous reply to your
From a security perspective, this would be equivalent to having the
client open a new connection to the server using a session ticket from
the existing connection with psk_dhe_ke mode?
I guess the ergonomics of that approach perhaps aren't as neat, but it
would only require client side
On Thu, Jan 04, 2024 at 04:33:30PM +0100, Hannes Tschofenig wrote:
> Hi Ilari,
>
> When exchanging key shares, the use of supported_groups is mandatory (at
> least that's what I remember).
Only for client, it is not mandatory for server.
RFC 8446 only says that servers "are permitted to send"
> Perhaps a possibility would be "application/tls-record"? This is similar to
> how "application/dns-message" is defined in [RFC 8484 section 6]
Yes, that seems reasonable. Your registration should point out that the
content might not be decodable without external information, and that in at
Skimming the draft, I am not following the timing of this process. Suppose
the client initiates an extended key update. It cannot update the keys yet,
because it does not know the server's response. It needs to keep reading
from the server. In doing so, it will hopefully see a responding
Hi all,
we have just submitted a draft that extends the key update functionality of
TLS/DTLS 1.3.
We call it the "extended key update" because it performs an ephemeral
Diffie-Hellman as part of the key update.
The need for this functionality surfaced in discussions in a design team of the
On Thu, Jan 04, 2024 at 11:42:13AM +, Tschofenig, Hannes wrote:
> Hi all,
>
> we have just submitted a draft that extends the key update
> functionality of TLS/DTLS 1.3. We call it the "extended key update"
> because it performs an ephemeral Diffie-Hellman as part of the key
> update.
>
>
Hi Hannes,
Skimming the document, I had the following questions:
- Can only clients request extended key updates (EKUs)? I think the text does
not attempt to impose this as a restriction, but all the examples are
client-initiating.
- If it is limited to client-initiated EKUs, the client
14 matches
Mail list logo
