A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the Transport Layer
Security (TLS) WG of the IETF.
Title : IANA Registry Updates for TLS and DTLS
Authors : Joe Salowey
Sean Turner
On 3/26/23 23:59, Eric Rescorla wrote:
Hans Petter,
Before I address your technical points, I would observe that your
tone here isn't ideal for getting people excited about your ideas.
If you think there's something that people don't understand, then
by all means explain it, but telling people t
> Title : IANA Registry Updates for TLS and DTLS
> Authors : Joe Salowey
> Sean Turner
> Filename : draft-ietf-tls-rfc8447bis-04.txt
...
> This document updates the changes to TLS and DTLS IANA registries
> made in RFC 8447. It adds a new value "D" for discouraged to the
> recommended column of t
I would prefer to have any substantive changes in 8446-bis and the policy
changes in 8447-bis
-Ekr
On Mon, Mar 27, 2023 at 2:10 AM Salz, Rich wrote:
>
> > Title : IANA Registry Updates for TLS and DTLS
> > Authors : Joe Salowey
> > Sean Turner
> > Filename : draft-ietf-tls-rfc8447bis-04.txt
>
I would prefer to have any substantive changes in 8446-bis and the policy
changes in 8447-bis
Now I’m more confused, since I consider policy changes substantive things. And
I’m not sure what policy is.
___
TLS mailing list
TLS@ietf.org
https://www.i
On Mon, Mar 27, 2023 at 2:28 AM Salz, Rich wrote:
>
>
> I would prefer to have any substantive changes in 8446-bis and the policy
> changes in 8447-bis
>
>
>
> Now I’m more confused, since I consider policy changes substantive
> things. And I’m not sure what policy is.
>
Looking at 8446 and 844
- 8446 registered new code points
- 8447 (mostly) changed the policies for issuance of new code points
I'm suggesting that we maintain that separation for the -bis documents.
I can live with the current setup then.
___
TLS mailing list
TLS@ietf.org
htt
FYI: IANA nicely did a review of -rfc8446bis prior to this IETF and suggested a
new section be addd to -rfc84446bis that makes it clear what changes are being
made as a result of that update. That section can be found here:
https://www.ietf.org/archive/id/draft-ietf-tls-rfc8446bis-07.html#name-ch
> FYI: IANA nicely did a review of -rfc8446bis prior to this IETF and suggested
> a new section be addd to -rfc84446bis that makes it clear what changes are
> being made as a result of that update. That section can be found here:
https://www.ietf.org/archive/id/draft-ietf-tls-rfc8446bis-07.html#n
h...@selasky.org said:
> A typical video stream of 4 MBit/s may produce on average 333 packets per
> second, and I ask a simple question if it is really needed to authenticate
> all of those packets while the user sits in a chair and eats popcorn?
Are you sure there is a user eating popcorn?
Ar
On Sun, Mar 26, 2023, 7:03 PM Rob Sayre wrote:
>
>
> On Sun, Mar 26, 2023 at 6:51 PM Watson Ladd wrote:
>
>>
>>
>> On Sun, Mar 26, 2023, 5:05 PM Rob Sayre wrote:
>>
>>> Hi,
>>>
>>> The problem is also incompletely described, right?
>>>
>>> It doesn't address stuff like:
>>> https://github.com/F
On Mon, Mar 27, 2023 at 4:48 PM Watson Ladd wrote
>
> No. XDP is acting as a firewall and Tubular is mapping packets to sockets.
> The TCP is handled by the kernel and given to the application through the
> usual interfaces.
>
> That's different from DPDK where the application is completely respo
This concern is also why many implementations of client certificates in TLS 1.2
and earlier would perform a handshake without requesting a client certificate,
then immediately begin renegotiation to exchange the client certificate under
encryption. TLS 1.3 removes the need to do this.
-Orig
At TLS@IETF116, the sense of the room was that there was WG support to adopt
draft-sbn-tls-svcb-ech [1]. This message is to confirm the consensus in the
room. Please indicate whether you do or do not support adoption of this I-D by
2359UTC on 18 April 2023. If do not support adoption, please in
The TLS WG has placed draft-sbn-tls-svcb-ech in state
Call For Adoption By WG Issued (entered by Sean Turner)
The document is available at
https://datatracker.ietf.org/doc/draft-sbn-tls-svcb-ech/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org
> At TLS@IETF116, the sense of the room was that there was WG support to adopt
> draft-sbn-tls-svcb-ech [1]. This message is to confirm the consensus in the
> room. Please indicate whether you do or do not support adoption of this I-D
> by 2359UTC on 18 April 2023. If do not support adoption, pl
On 28/03/2023 05:57, Salz, Rich wrote:
At TLS@IETF116, the sense of the room was that there was WG support to adopt
draft-sbn-tls-svcb-ech [1]. This message is to confirm the consensus in the
room. Please indicate whether you do or do not support adoption of this I-D by
2359UTC on 18 April 2
I support adoption.
On Tue, Mar 28, 2023 at 2:20 PM Stephen Farrell
wrote:
>
>
> On 28/03/2023 05:57, Salz, Rich wrote:
> >> At TLS@IETF116, the sense of the room was that there was WG support to
> adopt draft-sbn-tls-svcb-ech [1]. This message is to confirm the consensus
> in the room. Please i
Adopt. But please include an example, even if the public key is
0x010203040506...
On Tue, Mar 28, 2023, at 13:54, Sean Turner wrote:
> At TLS@IETF116, the sense of the room was that there was WG support to
> adopt draft-sbn-tls-svcb-ech [1]. This message is to confirm the
> consensus in the r
I support adoption.
David
On Tue, Mar 28, 2023 at 3:41 PM Martin Thomson wrote:
> Adopt. But please include an example, even if the public key is
> 0x010203040506...
>
> On Tue, Mar 28, 2023, at 13:54, Sean Turner wrote:
> > At TLS@IETF116, the sense of the room was that there was WG support to
20 matches
Mail list logo
