Re: [TLS] Adoption call for TLS Flag - Request mTLS

[Watson Ladd]

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 point assignment?
>

Well, don't we want to say how this is supposed to work somewhere? I doubt
this will take much time.

>
> -Ekr
>
> [0] As an aside the IANA considerations of draft-ietf-tls-tlsflags-13
> should clearly have
> a policy which matches 8447 S 7, which is to say that an I-D is sufficient.
>
>
> On Tue, Apr 2, 2024 at 12:59 PM Christopher Patton  40cloudflare@dmarc.ietf.org> wrote:
>
>> 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 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
>>> adoption and are willing to review and contribute text, please send a
>>> message to the list.  If you do not support adoption of this I-D, please
>>> send a message to the list and indicate why.  This call will close on 16
>>> April 2024.
>>>
>>> Thanks,
>>> Deirdre, Joe, and Sean
>>>
>>> [0]
>>> https://mailarchive.ietf.org/arch/msg/tls/9e2S95H9YgtHp5HhqdlNqmQP0_w/
>>> ___
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for TLS Flag - Request mTLS

[Mohit Sethi]

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/rfc7250 with certificate type 
value = 0: 
https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-3.


The table in section 4.2 of RFC8446 even mentions that the extension can 
be included in the ClientHello: 
https://datatracker.ietf.org/doc/html/rfc8446#section-4.2, thereby 
ensuring that the server sends a CertificateRequest message in response 
to the ClientHello received.


OpenSSL already implements this extension since it was needed for 
support raw public keys (RPKs).


As stated earlier: if it is indeed the case that the 
client_certificate_type extension is suitable for the use-case, then 
perhaps it is preferable to not have a separate flag. Otherwise, it 
would make the state machine at the server more complicated (for 
example: handling a ClientHello with both the mTLS flag and the 
client_certificate_type extension.


Therefore, like Ekr, I am mildly negative on adopting this document but 
for different reasons.


--Mohit

On 4/3/24 00:52, Sean Turner wrote:

At the IETF 119 TLS session there was some interest in the mTLS Flag I-D 
(https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-jhoyla-req-mtls-flag%2F&data=05%7C02%7Cmohit.sethi%40aalto.fi%7C42877de6d3d64135e49e08dc534a463b%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638476825681199391%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ERzWFcuBlAfobNyGCcgKDhCl9wex9LOQ%2F3yPYC7idfU%3D&reserved=0);
 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 adoption and are willing to 
review and contribute text, please send a message to the list.  If you do not support 
adoption of this I-D, please send a message to the list and indicate why.  This call will 
close on 16 April 2024.

Thanks,
Deirdre, Joe, and Sean

[0] 
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftls%2F9e2S95H9YgtHp5HhqdlNqmQP0_w%2F&data=05%7C02%7Cmohit.sethi%40aalto.fi%7C42877de6d3d64135e49e08dc534a463b%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638476825681208049%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=eEU6ZPJ5cmfqLHQuM3UYXrFKCJuKaaJVc8Ssk5erRjk%3D&reserved=0
___
TLS mailing list
TLS@ietf.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=05%7C02%7Cmohit.sethi%40aalto.fi%7C42877de6d3d64135e49e08dc534a463b%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638476825681214744%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2B9CGIKB31GI9RMQG62I1rTnbHaDPfSynvlmwrkPn%2FpQ%3D&reserved=0


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Working Group Last Call for SSLKEYLOG File

[Stephen Farrell]

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 negated if the key material is leaked:
https://github.com/tlswg/sslkeylogfile/pull/7/files

We will not be asking the formal analysis folks to weigh in on this I-D; we all 
know the file’s content are the keys to the kingdom.

Martin: If you can spin a new version, I can get the Shepherd write-up drafted.


I like the addition in -01 but would still have preferred if we
weren't so awfully oblique about the consequences of running a
production system with this logging enabled.

Were it up to me (and it's not) I'd suggest an additional addition
along the lines of:

"Systems that enable logging as described here are (while logging
is enabled) unlikely to be consistent with requirements to make use
of state-of-the-art protections, as e.g. is called-for by GDPR
article 32 [1]"

I suppose one could also re-do the above suggested text to refer
to RFC6919, section 3:-) [2]

Again, I'm not objecting to proceeding, just bemoaning what I see
as us being so oddly timid in calling out real issues.

Cheers,
S.

[1] https://gdpr-info.eu/art-32-gdpr/
[2] https://datatracker.ietf.org/doc/html/rfc6919#section-3



spt


On Mar 28, 2024, at 09:24, Sean Turner  wrote:

Just a reminder that this WGLC ends soon!

spt


On Mar 12, 2024, at 10:57, Sean Turner  wrote:

This is the working group last call for the SSLKEYLOGFILE Format for TLS 
Internet-Draft [1]. Please indicate if you think the I-D is ready to progress 
to the IESG and send any comments to the list by 31 March 2024.

The GH repo for the I-D can be found at [2].

Thanks,

Joe, Deirdre, and Sean

[1] https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/
[2] https://github.com/tlswg/sslkeylogfile




___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for TLS Flag - Request mTLS

[Eric Rescorla]

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 of draft-ietf-tls-tlsflags-13
should clearly have
a policy which matches 8447 S 7, which is to say that an I-D is sufficient.


On Tue, Apr 2, 2024 at 12:59 PM Christopher Patton  wrote:

> 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 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
>> adoption and are willing to review and contribute text, please send a
>> message to the list.  If you do not support adoption of this I-D, please
>> send a message to the list and indicate why.  This call will close on 16
>> April 2024.
>>
>> Thanks,
>> Deirdre, Joe, and Sean
>>
>> [0]
>> https://mailarchive.ietf.org/arch/msg/tls/9e2S95H9YgtHp5HhqdlNqmQP0_w/
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] I-D Action: draft-ietf-tls-keylogfile-01.txt

[internet-drafts]

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

Abstract:

   A format that supports the logging information about the secrets used
   in a TLS connection is described.  Recording secrets to a file in
   SSLKEYLOGFILE format allows diagnostic and logging tools that use
   this file to decrypt messages exchanged by TLS endpoints.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tls-keylogfile-01.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-keylogfile-01

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Artart early review of draft-ietf-tls-wkech-04

[Martin Thomson]

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 if it 
truly does that, for the reasons stated elsewhere.

> Happy to document the validation more, but the basic idea is that the
> ZF checks ECH works, and if it does, then the ZF is ok to re-publish.
> If anyone has ideas on other kinds of checks that'd be sensible, be
> happy to consider incorporating those.

>From my perspective, I'm looking to understand first what the ZK is expected 
>to be responsible for, at the layer you describe here.  Then I would also like 
>to see a description of how it might achieve that more concretely.  You get 
>most of the way there, I think, but it needs to be a bit more thorough.


>> Titles are not sentences.  Lose the period.
>
> Where? (Sorry, not sure, but the RFC editor will fix anyway
> so no worries.)

The title of the document.

> Given all the above, it's probably fine if you wait 'till there's a
> -05 done before we chat more, (assuming you have time), but happy to
> discuss via email in the meantime too of course.

I look forward to it.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for TLS Flag - Request mTLS

[David Schinazi]

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 consensus on
> whether there is sufficient support to adopt this I-D.  If you support
> adoption and are willing to review and contribute text, please send a
> message to the list.  If you do not support adoption of this I-D, please
> send a message to the list and indicate why.  This call will close on 16
> April 2024.
>
> Thanks,
> Deirdre, Joe, and Sean
>
> [0] https://mailarchive.ietf.org/arch/msg/tls/9e2S95H9YgtHp5HhqdlNqmQP0_w/
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for TLS Flag - Request mTLS

[Christopher Patton]

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 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
> adoption and are willing to review and contribute text, please send a
> message to the list.  If you do not support adoption of this I-D, please
> send a message to the list and indicate why.  This call will close on 16
> April 2024.
>
> Thanks,
> Deirdre, Joe, and Sean
>
> [0] https://mailarchive.ietf.org/arch/msg/tls/9e2S95H9YgtHp5HhqdlNqmQP0_w/
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for TLS Flag - Request mTLS

[Salz, Rich]

>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

[TLS] The TLS WG has placed draft-jhoyla-req-mtls-flag in state "Call For Adoption By WG Issued"

[IETF Secretariat]

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.ietf.org/mailman/listinfo/tls

[TLS] Adoption call for TLS Flag - Request mTLS

[Sean Turner]

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 adoption and are 
willing to review and contribute text, please send a message to the list.  If 
you do not support adoption of this I-D, please send a message to the list and 
indicate why.  This call will close on 16 April 2024. 

Thanks,
Deirdre, Joe, and Sean

[0] https://mailarchive.ietf.org/arch/msg/tls/9e2S95H9YgtHp5HhqdlNqmQP0_w/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Working Group Last Call for ECH

[Sean Turner]

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, 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:
>>>[ECH-Analysis]
>>>   "A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted
>>>   Client Hello", November 2022.
>> 
>> I'm guessing that'd be:
>> 
>> @inproceedings{bhargavan2022symbolic,
>>  title={A symbolic analysis of privacy for tls 1.3 with encrypted client 
>> hello},
>>  author={Bhargavan, Karthikeyan and Cheval, Vincent and Wood, Christopher},
>>  booktitle={Proceedings of the 2022 ACM SIGSAC Conference on Computer and 
>> Communications Security},
>>  pages={365--379},
>>  year={2022}
>> }
>> 
>> Cheers,
>> S.
>> 
>>> This reference does not provide enough information for anyone to locate the 
>>> document.  I think a reference that everyone can locate is needed here.
>>> Russ
 On Apr 1, 2024, at 6:12 PM, Joseph Salowey  wrote:
 
 This WGLC has concluded.  There is consensus to move this document 
 forward.  I think there are one or two minor changes proposed that should 
 be incorporated into the revision we forward to the IESG.
 
 Joe
 
 On Thu, Mar 28, 2024 at 6:23 AM Sean Turner >>> > wrote:
> Just a reminder that this WGLC ends soon!
> 
> spt
> 
>> On Mar 11, 2024, at 18:00, Joseph Salowey > > wrote:
>> 
>> This is the working group last call for TLS Encrypted Client Hello [1].  
>> Please indicate if you think the draft is ready to progress to the IESG 
>> and send any comments to the list by 31 March 2024.  The comments sent 
>> by Watson Ladd to the list [2] on 17 February 2024 will be considered 
>> last call comments.
>> 
>> Thanks,
>> 
>> Joe, Deirdre, and Sean
>> 
>> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
>> [2] 
>> https://mailarchive.ietf.org/arch/msg/tls/XUCFuNBSQfSJclkhLW-14DZ0ETg/
>>> ___
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>> 
> 
> 
> 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] review requests for -svcb-ech and -wkech

[Sean Turner]

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. Threads can be 
followed here:

DNSOP: https://mailarchive.ietf.org/arch/msg/dnsop/lbTdtFZqB3kHS1iU7U4cve7DgZ0/
HTTPbis: https://lists.w3.org/Archives/Public/ietf-http-wg/2024AprJun/.html

Cheers,
spt

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Working Group Last Call for SSLKEYLOG File

[Sean Turner]

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 analysis folks to weigh in on this I-D; we all 
know the file’s content are the keys to the kingdom.

Martin: If you can spin a new version, I can get the Shepherd write-up drafted.

spt

> On Mar 28, 2024, at 09:24, Sean Turner  wrote:
> 
> Just a reminder that this WGLC ends soon!
> 
> spt
> 
>> On Mar 12, 2024, at 10:57, Sean Turner  wrote:
>> 
>> This is the working group last call for the SSLKEYLOGFILE Format for TLS 
>> Internet-Draft [1]. Please indicate if you think the I-D is ready to 
>> progress to the IESG and send any comments to the list by 31 March 2024.
>> 
>> The GH repo for the I-D can be found at [2].
>> 
>> Thanks,
>> 
>> Joe, Deirdre, and Sean
>> 
>> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/
>> [2] https://github.com/tlswg/sslkeylogfile
> 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Working Group Last Call for ECH

[Russ Housley]

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:
>>[ECH-Analysis]
>>   "A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted
>>   Client Hello", November 2022.
> 
> I'm guessing that'd be:
> 
> @inproceedings{bhargavan2022symbolic,
>  title={A symbolic analysis of privacy for tls 1.3 with encrypted client 
> hello},
>  author={Bhargavan, Karthikeyan and Cheval, Vincent and Wood, Christopher},
>  booktitle={Proceedings of the 2022 ACM SIGSAC Conference on Computer and 
> Communications Security},
>  pages={365--379},
>  year={2022}
> }
> 
> Cheers,
> S.
> 
>> This reference does not provide enough information for anyone to locate the 
>> document.  I think a reference that everyone can locate is needed here.
>> Russ
>>> On Apr 1, 2024, at 6:12 PM, Joseph Salowey  wrote:
>>> 
>>> This WGLC has concluded.  There is consensus to move this document forward. 
>>>  I think there are one or two minor changes proposed that should be 
>>> incorporated into the revision we forward to the IESG.
>>> 
>>> Joe
>>> 
>>> On Thu, Mar 28, 2024 at 6:23 AM Sean Turner >> > wrote:
 Just a reminder that this WGLC ends soon!
 
 spt
 
> On Mar 11, 2024, at 18:00, Joseph Salowey  > wrote:
> 
> This is the working group last call for TLS Encrypted Client Hello [1].  
> Please indicate if you think the draft is ready to progress to the IESG 
> and send any comments to the list by 31 March 2024.  The comments sent by 
> Watson Ladd to the list [2] on 17 February 2024 will be considered last 
> call comments.
> 
> Thanks,
> 
> Joe, Deirdre, and Sean
> 
> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
> [2] https://mailarchive.ietf.org/arch/msg/tls/XUCFuNBSQfSJclkhLW-14DZ0ETg/
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
> 



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Working Group Last Call for ECH

[Stephen Farrell]

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{bhargavan2022symbolic,
  title={A symbolic analysis of privacy for tls 1.3 with encrypted 
client hello},
  author={Bhargavan, Karthikeyan and Cheval, Vincent and Wood, 
Christopher},
  booktitle={Proceedings of the 2022 ACM SIGSAC Conference on Computer 
and Communications Security},

  pages={365--379},
  year={2022}
}

Cheers,
S.



This reference does not provide enough information for anyone to locate the 
document.  I think a reference that everyone can locate is needed here.

Russ



On Apr 1, 2024, at 6:12 PM, Joseph Salowey  wrote:

This WGLC has concluded.  There is consensus to move this document forward.  I 
think there are one or two minor changes proposed that should be incorporated 
into the revision we forward to the IESG.

Joe

On Thu, Mar 28, 2024 at 6:23 AM Sean Turner mailto:s...@sn3rd.com>> wrote:

Just a reminder that this WGLC ends soon!

spt


On Mar 11, 2024, at 18:00, Joseph Salowey mailto:j...@salowey.net>> wrote:

This is the working group last call for TLS Encrypted Client Hello [1].  Please 
indicate if you think the draft is ready to progress to the IESG and send any 
comments to the list by 31 March 2024.  The comments sent by Watson Ladd to the 
list [2] on 17 February 2024 will be considered last call comments.

Thanks,

Joe, Deirdre, and Sean

[1] https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
[2] https://mailarchive.ietf.org/arch/msg/tls/XUCFuNBSQfSJclkhLW-14DZ0ETg/



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Working Group Last Call for ECH

[Russ Housley]

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 that everyone can locate is needed here.

Russ


> On Apr 1, 2024, at 6:12 PM, Joseph Salowey  wrote:
> 
> This WGLC has concluded.  There is consensus to move this document forward.  
> I think there are one or two minor changes proposed that should be 
> incorporated into the revision we forward to the IESG.  
> 
> Joe
> 
> On Thu, Mar 28, 2024 at 6:23 AM Sean Turner  > wrote:
>> Just a reminder that this WGLC ends soon!
>> 
>> spt
>> 
>> > On Mar 11, 2024, at 18:00, Joseph Salowey > > > wrote:
>> > 
>> > This is the working group last call for TLS Encrypted Client Hello [1].  
>> > Please indicate if you think the draft is ready to progress to the IESG 
>> > and send any comments to the list by 31 March 2024.  The comments sent by 
>> > Watson Ladd to the list [2] on 17 February 2024 will be considered last 
>> > call comments.
>> > 
>> > Thanks,
>> > 
>> > Joe, Deirdre, and Sean
>> > 
>> > [1] https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
>> > [2] https://mailarchive.ietf.org/arch/msg/tls/XUCFuNBSQfSJclkhLW-14DZ0ETg/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Artart early review of draft-ietf-tls-wkech-04

[Stephen Farrell]

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 so that other nodes can aid it in setting up the DNS records
necessary to run DNS.

Issues:

Most of the document talks about having the back-end servers produce content
for the well-known resource, but there is mention of other servers being
involved as well.  ECH depends on having shared configuration at the
client-facing side for servers, so any configuration process should probably
involve something different.  That is, having each server produce information
about its own (perceived) configuration, with the zone factory being
responsible for synthesizing the information from each into a coherent whole.

In that design, a back-end server would indicate that they are using a shared
client-facing server, and point to it.  The client-facing server would supply
its ECH configuration (which might be different for different back-end
servers).  There are cases where a client-facing server might be able to
produce the content for a back-end server, so that a single resource could make
sense. That might lead to the design we see, but that is not obviously correct
for all aspects of the design.


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?


The current design involves publishing information for a multitude of


Well, s/involves/allows/ is maybe more accurate but that's a nit-pick...


ECHConfigList values and multiple target names (and ports).  It is not obvious
that it is safe to have one origin speak for multiple others in this way or
what conditions might be necessary to have that happen safely.  If there is a
validation process involved, that might work.  The process in S6 is too loose
for me to be confident in that being sufficient.


That's fair. What's defined now supports (hourly) ECH key rotation for
the set of test servers I have on different ports of the same VM. In
that case, there's a different http server implementation listening on
each port, which I guess would be an extremely unlikely production
configuration, but OTOH, it seems right to be able to support that odd
case. And I think if we can support that odd case, then we'll also be
ok for more likely production cases.


The design for publishing alias records is something I cannot decipher at all.
There's a description of the field, but no real supporting material for that.


Also fair. Will add more description of that and we can see if it makes
more sense then. I'm a bit unsure what to add right now though given
it's been hard to test aliasMode - does anyone know if browsers now
support that (with ECH)? (Been a while since I tried that, but will
do some more testing as we produce a -05 draft.)


The different deployment options need to be more clearly articulated in support
of different modes of use, along with any validation that is needed.


Happy to document the validation more, but the basic idea is that the
ZF checks ECH works, and if it does, then the ZF is ok to re-publish.
If anyone has ideas on other kinds of checks that'd be sensible, be
happy to consider incorporating those.



It might be the case that the design is fundamentally sound, but it isn't clear
to me that this is true.


I'm happy to try convince you over time:-)

More concretely, I can try add text to the security considerations
that argues that the design meets some security goal(s) and we can
discuss that text as we go forward.



Nits:

Titles are not sentences.  Lose the period.


Where? (Sorry, not sure, but the RFC editor will fix anyway
so no worries.)



S1, typo: ECHConflgList


Fixed.


Use of the term "front-end" and "back-end" is likely confusing for some
consumers of this specification.  Front-end overwhelmingly refers to the
development of web-facing content, whereas back-end refers to the development
of servers and services.  Why not use client-facing as the ECH specification
does?


I'll give it a shot, but have always found that terminology a
bit confusing. I could also add a diagram too I guess, which
may help the reader a bit.



S3, please avoid using things like "cronjob".  Periodic is fine and doesn't
presume the use of a particular tool.


It's an example, but a fairly well known one. Will look at the wording
though.



S3, typo: regularaly


Fixed.



S4:


The well-known URI defined here MUST be an https URL and therefore the ZF

verifies the correct BE is being accessed. If no new ECH value resulting
"works," then the zone factory SHOULD NOT modify the zone.

This is two very different concepts in the one paragraph.  The first is about
authenticating the content at the .w-k resource.  The second is about
validating it.  There is no segue between the two.  May