Hi Martin,
Thanks for the review. (More such are v. welcome esp as ECH is
now past WGLC.)
On 02/04/2024 00:40, Martin Thomson via Datatracker wrote:
Reviewer: Martin Thomson
Review result: Not Ready
This document describes how an HTTP origin can publish information about its
ECH configuration
Joe:
The ECH Internet-Draft includes this reference:
[ECH-Analysis]
"A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted
Client Hello", November 2022.
This reference does not provide enough information for anyone to locate the
document. I think a reference
Hiya,
On 02/04/2024 15:17, Russ Housley wrote:
Joe:
The ECH Internet-Draft includes this reference:
[ECH-Analysis]
"A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted
Client Hello", November 2022.
I'm guessing that'd be:
@inproceedings{bhargavan2022
Thanks.
This URL gives access without a paywall:
https://www.cs.ox.ac.uk/people/vincent.cheval/publis/BCW-ccs22.pdf
Russ
> On Apr 2, 2024, at 10:31 AM, Stephen Farrell
> wrote:
>
>
> Hiya,
>
> On 02/04/2024 15:17, Russ Housley wrote:
>> Joe:
>> The ECH Internet-Draft includes this reference
This WGLC has concluded. There is consensus to move this document forward.
The material change was to add a security consideration about forward secrecy
guarantees being negated if the key material is leaked:
https://github.com/tlswg/sslkeylogfile/pull/7/files
We will not be asking the formal a
Hi! You might have seen the DNSDIR and ARTART Directorate reviews recently for
-svcb-ech and -wkech, respectively. The chairs are asking for these now that
the ECH I-D has completed WGLC. We have also requested DNSDIR/DNSOP and
HTTPbis review. Ditto on the HTTPbis review for -svcb-ech. Thread
Addressed via:
https://github.com/tlswg/draft-ietf-tls-esni/pull/613
spt
> On Apr 2, 2024, at 10:46, Russ Housley wrote:
>
> Signed PGP part
> Thanks.
>
> This URL gives access without a paywall:
> https://www.cs.ox.ac.uk/people/vincent.cheval/publis/BCW-ccs22.pdf
>
> Russ
>
>> On Apr 2, 20
At the IETF 119 TLS session there was some interest in the mTLS Flag I-D
(https://datatracker.ietf.org/doc/draft-jhoyla-req-mtls-flag/); also, see
previous list discussions at [0]. This message is to judge consensus on whether
there is sufficient support to adopt this I-D. If you support adopti
The TLS WG has placed draft-jhoyla-req-mtls-flag in state
Call For Adoption By WG Issued (entered by Sean Turner)
The document is available at
https://datatracker.ietf.org/doc/draft-jhoyla-req-mtls-flag/
___
TLS mailing list
TLS@ietf.org
https://www.
>If you support adoption and are willing to review and contribute text, please
>send a message to the list.
"I do"
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
I'd like to see this problem solved. There was some discussion about
whether an I-D is needed or all we needed was to register a code point
somewhere. If most agree that an I-D is needed, then let's adopt it. I'm
happy to review.
Chris P.
On Tue, Apr 2, 2024 at 12:22 PM Sean Turner wrote:
> At
I support adoption.
David
On Tue, Apr 2, 2024 at 12:22 PM Sean Turner wrote:
> At the IETF 119 TLS session there was some interest in the mTLS Flag I-D (
> https://datatracker.ietf.org/doc/draft-jhoyla-req-mtls-flag/); also, see
> previous list discussions at [0]. This message is to judge consen
Short inline comments.
On Tue, Apr 2, 2024, at 23:24, Stephen Farrell wrote:
> [...]
> I'm not really sure how to interpret the above tbh. Was that intended
> as a summary of the draft or as a synopsis of the problem space?
That's my sketch of what I think the draft should be doing. I don't know
Internet-Draft draft-ietf-tls-keylogfile-01.txt is now available. It is a work
item of the Transport Layer Security (TLS) WG of the IETF.
Title: The SSLKEYLOGFILE Format for TLS
Author: Martin Thomson
Name:draft-ietf-tls-keylogfile-01.txt
Pages: 10
Dates: 2024-04-02
Abst
Adoption should not be required to register a code point [0], as the policy
is Specification Required.
I'm mildly negative on adopting this document. What is the reason we need
to spend WG time on this, rather than just having a code point assignment?
-Ekr
[0] As an aside the IANA considerations
Hiya,
This is basically for the record and not an objection to proceeding.
On 02/04/2024 17:34, Sean Turner wrote:
This WGLC has concluded. There is consensus to move this document forward.
The material change was to add a security consideration about forward secrecy
guarantees being negate
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
On Tue, Apr 2, 2024, 5:08 PM Eric Rescorla wrote:
> Adoption should not be required to register a code point [0], as the
> policy is Specification Required.
>
> I'm mildly negative on adopting this document. What is the reason we need
> to spend WG time on this, rather than just having a code poi
18 matches
Mail list logo
