y feedback from the group on this challenge and the
proposed solution.
Best Regards,
Yaroslav
-- Forwarded message -
From:
Date: Sat, Jul 6, 2024 at 11:24 PM
Subject: New Version Notification for
draft-rosomakho-tls-ech-keylogfile-00.txt
To: Hannes Tschofenig , Yaroslav Rosomakho
I fully agree.
I believe that MTI should be the lowest common denominator - something that
is not necessarily the best current practice from compute efficiency or
security perspectives but something that is most widely supported and is
good enough for most use cases. MTI is supposed to be reasonab
Thank you for the feedback, Andrei.
Yes, it is intended to stay on the informational track as an extension
to draft-ietf-tls-keylogfile-02. We tried to keep wording in line with the
keylogfile draft - for instance in the applicability statement it is worded
that "this mechanism MUST NOT be used in
Thank you, Rich.
That's a great idea. I personally believe that the current practice adopted
by many pieces of _production_ software to take an environment variable and
silently dump sslkeylog in a clear text file is rather reckless and should
be strongly discouraged. This functionality must reall
Any reason why we won’t put MLKEM in front of ECDHE key share for all the curves both on the wire and in the naming convention?That would be consistent and harder to get wrong.Or would this make an implementation of hybrid MLKEM and SecP256r1 non FIPS certified in the case of using certified SecP25
I fully agree.
In addition to that wide enough adoption of any mandatory changes to TLS
handshake will take years and any public facing services will have to allow
clients that do not support puzzles for backwards compatibility for quite
some time.
On top of low-powered battery operated clients t
This document certainly needs more work particularly when it comes to
security considerations. However, it is well thought through and it widens
applicability of TLS.
I believe it is ready to be adopted as a working group item and I support
adoption of this work.
-yaroslav
On Fri, Oct 25, 20
Christian,
I believe the issue that we are currently observing with "blocked ECH" is
specific to how public SNI is constructed. A given CDN uses a certain
pre-defined public name for all ECH enabled resources - hence an inline
filtering party that wants to prevent ECH can match on that specific pu
Hello Watson,
On Sat, Nov 16, 2024 at 1:47 AM Watson Ladd wrote:
> A few things jumped out about IANA registries. The first is a silly
> process question that might be really ugly to address now (and require
> the IESG)
>
> Shouldn't the IANA registry here be made by the
> draft-ietf-tls-keylogf
I strongly support adoption of this document.
Best Regards,
Yaroslav
On Tue, Apr 1, 2025 at 2:00 PM Sean Turner wrote:
> We are continuing with our pre-announced tranche of WG adoption calls; see
> [0] for more information. This time we are issuing a WG adoption call for
> the ML-KEM Post-Quant
Hello Stephen,
Can you please point out specifically where you see differences in labels?
As far as I can tell, the text of the labels is defined in ssl/ssl_local.h
(lines 2955-2964 in version 3.5) and (where relevant) it does match the
contents of the draft.
I took the liberty to skim through a
I fully agree.
A common property of all the entries in the current format is Random from
TLS ClientHello as the session key. I think it would be great to keep it
that way.
That is, I believe that new labels should only be used for potential future
TLS extensions and protocols that are always enca
Hi Nick,
First of all, I fully agree that current implementations with a static
public SNI are trivial to block. To a certain extent this mitigates the
positive effects of the ECH.
However, a completely random client generated public SNI will cause a
number of other issues as the public SNI is qu
Hi Raghu,
On Wed, Feb 26, 2025 at 10:41 AM Raghu Saxena wrote:
>
> I think in the context of the censor discussion you linked,
> realistically they can just block ECH (including GREASed ECH), since
> there isn't really mass saturation of ECH (GREASed or not) across most
> TLS clients, so they wo
TechnologiesMIT Lincoln LaboratoryOn Jun 18, 2025, at 19:48, Yaroslav Rosomakho wrote:
On Thu, Jun 19, 2025 at 1: 33 AM Watson Ladd wrote: On Wed, Jun 18, 2025, 4: 30 PM Yaroslav Rosomakho wrote: One of the key use cases is to simplify PKI architectures for closed environments
feedback and discussion on the proposal and the design
specifics.
Best Regards,
Hannes, Mike, Rifaat, Tiru, Yaron and Yaroslav
-- Forwarded message -
A new version of Internet-Draft draft-yusef-tls-pqt-dual-certs-00.txt has
been
successfully submitted by Yaroslav Rosomakho and posted
met with
> > no real change to libraries to implement this. I don't see anything
> > in the introduction of the draft that makes the case here, unlike the
> > one you cite as an alternative.
> >
> > Sincerely,
> > Watson
> >>
> >>
> >&g
On Thu, Jun 19, 2025 at 1:33 AM Watson Ladd wrote:
> On Wed, Jun 18, 2025, 4:30 PM Yaroslav Rosomakho
> wrote:
>
>> One of the key use cases is to simplify PKI architectures for closed
>> environments that will have to deal with a mix of clients.
>>
>> Transiti
meter alert.
>
> I note that you don't seem to require that the lists be
> disjoint above. I.e., you say they are disjoint but there
> is no MUST language and no check.
>
>
>
As mentioned previously, we want to allow overlap algorithms for
root/intermediate certificates.
>
>
> On 19 Jun 2025, at 02:03, Watson Ladd wrote:
>
> On Wed, Jun 18, 2025 at 5:00 PM Yaroslav Rosomakho
> wrote:
>>
>> Because it won’t require running a zoo of PKIs. Ideally just two - classic
>> and pure PQ with eventual convergence on the latter.
>
Thank you for the feedback, Viktor.
Please see inline.
On Sun, Jun 22, 2025 at 4:12 PM Viktor Dukhovni
wrote:
> On Sun, Jun 22, 2025 at 03:53:15PM +0100, Yaroslav Rosomakho wrote:
>
> > Overall, correct implementation of creating a new TLS session, carefully
> > movi
On Sun, Jun 22, 2025 at 6:08 PM Viktor Dukhovni
wrote:
> On Sun, Jun 22, 2025 at 05:13:06PM +0100, Yaroslav Rosomakho wrote:
>
> [ I do understand the stated reasons by the way, they superficially
> make some sense, but I think they're worth a critical look. ]
>
[ I know t
bmitted by Yaroslav Rosomakho and posted to the
IETF repository.
Name: draft-rosomakho-tls-cert-update
Revision: 00
Title:Certificate Update in TLS 1.3
Date: 2025-06-20
Group:Individual Submission
Pages:14
URL:
https://www.ietf.org/archive/id/draft-rosomakho-tls-cert-update-00.
key.
Best Regards,
Yaroslav
On Fri, Jun 20, 2025 at 11:29 PM Watson Ladd wrote:
> On Fri, Jun 20, 2025 at 3:20 PM Yaroslav Rosomakho
> wrote:
> >
> > Hello Watson,
> >
> > On Fri, Jun 20, 2025 at 10:50 PM Watson Ladd
> wrote:
> >>
> >>
> &
Hello Watson,
On Fri, Jun 20, 2025 at 10:50 PM Watson Ladd wrote:
>
> What exactly is the rationale here? Do we expect that identies
> actually change when a certificate expires?
>
Certificate confirms identity information for a certain period of validity
as long as it is not revoked. Communica
On Sun, Jun 22, 2025 at 4:40 PM Viktor Dukhovni
wrote:
> On Sun, Jun 22, 2025 at 04:27:59PM +0100, Yaroslav Rosomakho wrote:
>
> > > This appears to be the case at first blush, but I wonder which is more
> > > likely:
> > >
> > > - The key was alread
gt; wrote:
>>>
>>>> We have a use case where optical systems establish a persistent TLS
>>>> channel that is then used to mint keys used to encrypt massive amounts of
>>>> traffic over fiber optic lines.
>>>> This mechanism could be useful to a
Thank you for the detailed response, Christian!
Please see some comments inline below.
-yaroslav
On Tue, Jun 24, 2025 at 8:54 PM Christian Huitema
wrote:
> On 6/22/2025 7:53 AM, Yaroslav Rosomakho wrote:
>
> > Firstly, in order to "move traffic" the new session would
On Sun, Jun 22, 2025 at 2:31 PM Watson Ladd wrote:
>
>
> On Sun, Jun 22, 2025, 5:14 AM Yaroslav Rosomakho 40zscaler@dmarc.ietf.org> wrote:
>
>> Hi Eric,
>>
>> There are two groups of cases with long-lived sessions that I regularly
>> have t
I support adoption of the draft with the applicability statement.
For my use cases SLH-DSA is particularly appealing in the following
scenarios:
- As the signature scheme for root CAs in private PKIs
- For other components of the certificate chain, including end-entity
certificates used in long-li
30 matches
Mail list logo
