On Thu, Jun 15, 2023 at 13:37 Christopher Wood wrote:
> Sorry for the delay. This slipped through the cracks. Given that we went
> through this process with the text as-is, I think we can live without this
> change.
>
Hi,
There were a bunch of boring suggestions in my message*. I hope Ekr
consi
On May 22, 2023, at 6:49 PM, Eric Rescorla wrote:On Mon, May 22, 2023 at 1:09 PM Rob Sayre wrote:On Mon, May 22, 2023 at 12:59 PM Christopher Wood wrote:We trust the editors will faithfully enact all editorial changes they agree with as the document moves
On 22/05/2023 20:59, Christopher Wood wrote:
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Chris
Many, although not all, of your messages to the TLS list display the
above and no more. This is indeed what the message
On Mon, May 22, 2023 at 3:49 PM Eric Rescorla wrote:
> On Mon, May 22, 2023 at 1:09 PM Rob Sayre wrote:
>
>> The one real problem (imho) with the document is nested MUST requirements:
>> https://mailarchive.ietf.org/arch/msg/tls/6x0uEVIUCBwMOIaV3UBzqeRt6Ys/
>>
>> EKR called this "guidance", but
On Mon, May 22, 2023 at 1:09 PM Rob Sayre wrote:
> On Mon, May 22, 2023 at 12:59 PM Christopher Wood
> wrote:
>
>> We trust the editors will faithfully enact all editorial changes they
>> agree with as the document moves forward in the process. If there were
>> non-editorial comments that we ove
On Mon, May 22, 2023 at 12:59 PM Christopher Wood
wrote:
> We trust the editors will faithfully enact all editorial changes they
> agree with as the document moves forward in the process. If there were
> non-editorial comments that we overlooked, could you please resurface them?
>
Hi,
I made th
We trust the editors will faithfully enact all editorial changes they agree with as the document moves forward in the process. If there were non-editorial comments that we overlooked, could you please resurface them?Best,Chris On May 21, 2023, at 7:44 PM, Rob Sayre wrote:On Fri, May 19, 2023 at 5
On Fri, May 19, 2023 at 5:03 AM Christopher Wood
wrote:
> Thanks to everyone who provided reviews and feedback for these documents!
> I believe we have consensus to move both forward with changes that have
> been incorporated during the review cycle. We’ll start preparing the
> shepherd writeups
Thanks to everyone who provided reviews and feedback for these documents! I
believe we have consensus to move both forward with changes that have been
incorporated during the review cycle. We’ll start preparing the shepherd
writeups and then move these on in the process.
Best,
Chris
> On Mar 2
Thanks for the info.
>This tweak was introduced as a result of discussions in Philly (IETF115) to
>address David Schinazi’s comment at the mic. If I remember correctly, the
>discussion was that there’s not really a concern about exhausting the registry
>space because it’s a “string" registry, b
> On Apr 11, 2023, at 12:50, Salz, Rich wrote:
>
> I am commenting on 8447bis. This document is just about ready to move
> forward, but two fixes are needed.
>
> Why there are Notes still in the doc (e.g., near end of section 6 it says
> about weaker elliptic curves) and think those should b
On Wed, 5 Apr 2023 at 06:32, Stephen Farrell wrote:
>
>
> Hiya,
>
> On 05/04/2023 02:47, Sean Turner wrote:
> > A post IETF 116 bump to make sure folks get their reviews in. If you
> > look at the diffs from RFC 8446 you can see not that much has
> > changed. We will also take “I read it and it lo
On Wed, Apr 12, 2023 at 12:15 AM Ilari Liusvaara
wrote:
> On Wed, Apr 12, 2023 at 01:18:17AM +, Peter Gutmann wrote:
> > On the subject of clarification, the update also needs to explain why
> PSK is
> > split across two separate extensions, psk_key_exchange_modes and
> > pre_shared_key, with
On Wed, Apr 12, 2023 at 01:18:17AM +, Peter Gutmann wrote:
> On the subject of clarification, the update also needs to explain why PSK is
> split across two separate extensions, psk_key_exchange_modes and
> pre_shared_key, with complex and awkward reconciliation rules between then,
> and why th
Ben Smyth writes:
>Because pre_shared_key appears in ClientHello and ServerHello, whilst
>psk_key_exchange_modes only appears in the former?
That's a circular argument, pre_shared_key already has two different forms
that depend on whether it's the ClientHello or ServerHello it so this is
saying
On Wed, 12 Apr 2023, 03:18 Peter Gutmann, wrote:
> On the subject of clarification, the update also needs to explain why PSK
> is
> split across two separate extensions, psk_key_exchange_modes and
> pre_shared_key
Because pre_shared_key appears in ClientHello and ServerHello, whilst
psk_key_exc
On the subject of clarification, the update also needs to explain why PSK is
split across two separate extensions, psk_key_exchange_modes and
pre_shared_key, with complex and awkward reconciliation rules between then,
and why the PSK has to be the last extension in the client hello. I can't see
an
I am commenting on 8446bis.
I re-read the draft, it is almost ready to move forward. All but one of the
open issues are basically editorial. I think John Mattsson's issue [1] on PSK
identity guidance is worth including; I do not recall much WG discussion of
this.
[1] https://github.com/tlswg/
I am commenting on 8447bis. This document is just about ready to move forward,
but two fixes are needed.
Why there are Notes still in the doc (e.g., near end of section 6 it says about
weaker elliptic curves) and think those should be resolved, one way or another,
before advancing out of the WG
On Wed, Apr 5, 2023 at 1:05 PM Rob Sayre wrote:
>
>
> On Wed, Apr 5, 2023 at 12:53 PM Eric Rescorla wrote:
>
>>
>>
>> On Wed, Apr 5, 2023 at 12:50 PM Rob Sayre wrote:
>>
>>> On Wed, Apr 5, 2023 at 12:26 PM Eric Rescorla wrote:
>>>
Thanks for your feedback. Most of these are editorial comm
On Wed, Apr 5, 2023 at 12:53 PM Eric Rescorla wrote:
>
>
> On Wed, Apr 5, 2023 at 12:50 PM Rob Sayre wrote:
>
>> On Wed, Apr 5, 2023 at 12:26 PM Eric Rescorla wrote:
>>
>>> Thanks for your feedback. Most of these are editorial comments and
>>> so I think they're my decision as editor about whic
On Wed, Apr 5, 2023 at 12:50 PM Rob Sayre wrote:
> On Wed, Apr 5, 2023 at 12:26 PM Eric Rescorla wrote:
>
>> Thanks for your feedback. Most of these are editorial comments and
>> so I think they're my decision as editor about which ones to take
>> absent some instruction from the chairs.
>>
>
>
On Wed, Apr 5, 2023 at 12:26 PM Eric Rescorla wrote:
> Thanks for your feedback. Most of these are editorial comments and
> so I think they're my decision as editor about which ones to take
> absent some instruction from the chairs.
>
I agree concerning most of them. One just finds nitpicks if y
This was discussed extensively when 8446 was published and there wasn't
consensus
to make such a change. If the chairs want to re-open this issue, please
weigh in.
-Ekr
On Tue, Apr 4, 2023 at 7:32 PM Stephen Farrell
wrote:
>
> Hiya,
>
> On 05/04/2023 02:47, Sean Turner wrote:
> > A post IETF 1
Thanks for your feedback. Most of these are editorial comments and
so I think they're my decision as editor about which ones to take
absent some instruction from the chairs.
On Tue, Apr 4, 2023 at 10:43 PM Rob Sayre wrote:
> Hi,
>
> I'm still not sure about the list/vector rename. Aside from tha
Let me try to link this thread to the similar question raised during the
implementation of RPK in openssl.
https://mailarchive.ietf.org/arch/msg/tls/9rXQFjYhAS0z-ZJleMVUgWmvhAA/
My personal "favorite interpretation" of
RFC5246 7.4.6. Client Certificate
is to stick to that definition there reg
I mentioned this to Ekr off-list, but I thought I would add one more thing.
What did we conclude about a client that refuses to provide a raw public key
when asked by a server? Are we in a position to change the minimum length from
1 to 0 in the response? The thread didn't really end with a s
Hi,
I'm still not sure about the list/vector rename. Aside from that, here's
what I found:
> It tightens some requirements and contains
> updated text in areas which were found to be unclear as well as other
> editorial improvements.
"It contains clarifications and tightened requirements." [let'
Hiya,
On 05/04/2023 02:47, Sean Turner wrote:
A post IETF 116 bump to make sure folks get their reviews in. If you
look at the diffs from RFC 8446 you can see not that much has
changed. We will also take “I read it and it looks good” response.
I looked at the diff between 8446bis-07 and 8446
A post IETF 116 bump to make sure folks get their reviews in. If you look at
the diffs from RFC 8446 you can see not that much has changed. We will also
take “I read it and it looks good” response.
Cheers,
spt
> On Mar 28, 2023, at 21:00, Christopher Wood wrote:
>
> As mentioned during yeste
https://author-tools.ietf.org/diff?doc_1=rfc8446&doc_2=draft-ietf-tls-rfc8446bis-07
might be helpful to others.
I opened a few issues, but the TLS 1.3 revision is very much ready to be
published.
For the 8447 revision, I found that our decision to remove the definition of
the fields for each r
31 matches
Mail list logo