[TLS]Re: Working Group Last Call for Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3

[Sean Turner]

Just a reminder that this WGLC is still ongoing.

spt

> On May 22, 2024, at 10:14, Sean Turner  wrote:
> 
> This email starts the working group last call for "Legacy RSASSA-PKCS1-v1_5 
> codepoints for TLS 1.3” I-D, located here:
> 
> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-pkcs1/
> 
> The WG Last Call will end 5 June 2024 @ 2359 UTC.
> 
> Please review the I-D and submit issues and pull requests via the GitHub 
> repository that can be found at:
> 
> https://github.com/tlswg/tls13-pkcs1
> 
> Alternatively, you can also send your comments to tls@ietf.org.
> 
> Thanks,
> spt

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: I-D Action: draft-ietf-tls-tls13-pkcs1-01.txt

[Sean Turner]

Hi! I asked the authors to spin a new version because the I-D would have 
expired during the WGLC.  No substantive changes were introduced in this the 
-01 version.

spt

> On May 23, 2024, at 16:44, internet-dra...@ietf.org wrote:
> 
> Internet-Draft draft-ietf-tls-tls13-pkcs1-01.txt is now available. It is a
> work item of the Transport Layer Security (TLS) WG of the IETF.
> 
>   Title:   Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3
>   Authors: David Benjamin
>Andrei Popov
>   Name:draft-ietf-tls-tls13-pkcs1-01.txt
>   Pages:   7
>   Dates:   2024-05-23
> 
> Abstract:
> 
>   This document allocates code points for the use of RSASSA-PKCS1-v1_5
>   with client certificates in TLS 1.3.  This removes an obstacle for
>   some deployments to migrate to TLS 1.3.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-pkcs1/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-tls-tls13-pkcs1-01.html
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-tls13-pkcs1-01
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: WG Adoption for TLS Trust Expressions

[Sean Turner]

Hi! Let’s clam it down some in this thread.  Just a gentle reminder to keep it 
professional.

Thanks,
spt
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: progressing -rrc

[Sean Turner]

> On May 22, 2024, at 10:09, Sean Turner  wrote:
> 
> Hi! If you recall we paused progressing -rrc [1] while we awaited 
> implementations.  Well, we now have that; we have one server and two clients 
> (all DTLS 1.2) [2]. However, we now also have the formal analysis triage 
> panel so we need to run the I-D through them.  Once we run the I-D through 
> that process we will revisit progressing the I-D.  I [have noted / will note] 
> in the datatracker that the document is awaiting external review.
> 
> Cheers,
> spt
> 
> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-rrc/
> [2] https://github.com/tlswg/dtls-rrc/issues/72

I should have added that we are sending this I-D to the formal analysis triage 
team because this I-D might be changing security assumptions in DTLS 1.3 or 
extending it and generally we want those sort of changes to TLS 1.3 evaluated.  
You’ll note we are not suggesting passing the Legacy RSASSA-PKCS1-v1_5 
codepoints for TLS 1.3 I-D to them.

Cheers,
spt
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Working Group Last Call for Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3

[Sean Turner]

> On May 22, 2024, at 10:28, David Benjamin  wrote:
> 
> On Wed, May 22, 2024 at 10:27 AM Salz, Rich 
>  wrote:
> > This email starts the working group last call for "Legacy RSASSA-PKCS1-v1_5 
> > codepoints for TLS 1.3” I-D, located here:
> 
> No comments, ship it.
> 
> > The only comment/question I have about this I-D (and I hope this is not too 
> > much of a bikeshed) is whether the Recommended column should be “D” instead 
> > of “N”.
> 
> I think that would be a mistake as it makes the vast deployment of existing 
> TPM machines nonconformant.  In a few years, maybe. For now, not-recommended 
> is strong enough.
> 
> (I don't have strong feelings on this and am happy to defer this to what 
> everyone else wants. Just briefly noting that "N" in the document isn't an 
> explicit preference here. "D" just didn't exist at the time the document was 
> written.)

I figured this was the case.  Part of the reason for raising this point now is 
to tell the IESG that we actually thought about it when somebody asks about 
whether we considered “D”.

spt
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Working Group Last Call for Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3

[Sean Turner]

> On May 22, 2024, at 10:14, Sean Turner  wrote:
> 
> This email starts the working group last call for "Legacy RSASSA-PKCS1-v1_5 
> codepoints for TLS 1.3” I-D, located here:
> 
> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-pkcs1/
> 
> The WG Last Call will end 5 June 2024 @ 2359 UTC.
> 
> Please review the I-D and submit issues and pull requests via the GitHub 
> repository that can be found at:
> 
> https://github.com/tlswg/tls13-pkcs1
> 
> Alternatively, you can also send your comments to tls@ietf.org.



The only comment/question I have about this I-D (and I hope this is not too 
much of a bikeshed) is whether the Recommended column should be “D” instead of 
“N”.



spt
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Working Group Last Call for Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3

[Sean Turner]

This email starts the working group last call for "Legacy RSASSA-PKCS1-v1_5 
codepoints for TLS 1.3” I-D, located here:

https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-pkcs1/

The WG Last Call will end 5 June 2024 @ 2359 UTC.

Please review the I-D and submit issues and pull requests via the GitHub 
repository that can be found at:

https://github.com/tlswg/tls13-pkcs1

Alternatively, you can also send your comments to tls@ietf.org.

Thanks,
spt
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]progressing -rrc

[Sean Turner]

Hi! If you recall we paused progressing -rrc [1] while we awaited 
implementations.  Well, we now have that; we have one server and two clients 
(all DTLS 1.2) [2]. However, we now also have the formal analysis triage panel 
so we need to run the I-D through them.  Once we run the I-D through that 
process we will revisit progressing the I-D.  I [have noted / will note] in the 
datatracker that the document is awaiting external review.

Cheers,
spt

[1] https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-rrc/
[2] https://github.com/tlswg/dtls-rrc/issues/72
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

Re: [TLS] [EXTERNAL] Re: WG Adoption for TLS Trust Expressions

[Sean Turner]

Ekr (and others from off-list msgs),

Don’t worry the chairs are paying attention.

And, yeah we’ll need to start something formal, but this thread is doing its 
job for now.  BTW since we’d talked to Devon and Co. a lot about this I-D, I 
took inclusion of that phrase as a slip of the tongue so to speak.  But, going 
forward a “hey are you interested in my I-D” emails shouldn’t read “hey I’m 
kicking off a WG adoption call” ;)

spt

> On Apr 29, 2024, at 09:43, Eric Rescorla  wrote:
> 
> Hi folks,
> 
> I haven't yet formed an opinion on this document yet, but I did want to 
> observe that calls for adoption are issued by the chairs, not by individual 
> participants. Of course, anyone can start a thread and comments in this 
> thread are information for the chairs, but if adoption does happen, it will 
> be via some separate process.
> 
> -Ekr
> 
> 
> On Sat, Apr 27, 2024 at 11:42 AM Brendan McMillion 
>  wrote:
> Hi Devon
> 
> I support adoption
> 
> On Fri, Apr 26, 2024 at 7:38 PM Andrei Popov 
>  wrote:
> I support adoption.
> 
> Cheers,
> 
> Andrei
> 
> -Original Message-
> From: TLS  On Behalf Of Watson Ladd
> Sent: Friday, April 26, 2024 7:13 PM
> To: Devon O'Brien 
> Cc: tls@ietf.org; Bob Beck 
> Subject: [EXTERNAL] Re: [TLS] WG Adoption for TLS Trust Expressions
> 
> On Tue, Apr 23, 2024 at 1:39 PM Devon O'Brien 
>  wrote:
> >
> > After sharing our first draft of TLS Trust Expressions and several 
> > discussions across a couple  IETFs, we’d like to proceed with a call for 
> > working group adoption of this draft. We are currently prototyping trust 
> > expressions in BoringSSL & Chromium and will share more details when 
> > implementation is complete.
> >
> >
> > As we mentioned in our message to the mailing list from January, our 
> > primary goal is to produce a mechanism for supporting multiple subscriber 
> > certificates and efficiently negotiating which to serve on a given TLS 
> > connection, even if that ends up requiring significant changes to the draft 
> > in its current state.
> >
> >
> > To that end, we’re interested in learning whether wg members support 
> > adoption of this deployment model and the currently-described certificate 
> > negotiation mechanism or if they oppose adoption (and why!).
> 
> We absolutely need to solve the problem and the draft is a good starting 
> point.
> 
> >
> >
> > Thanks!
> >
> > David, Devon, and Bob
> >
> >
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://www/.
> > ietf.org%2Fmailman%2Flistinfo%2Ftls=05%7C02%7CAndrei.Popov%40micr
> > osoft.com%7C6ca75aa932344f322d9f08dc665fa375%7C72f988bf86f141af91ab2d7
> > cd011db47%7C1%7C0%7C638497808164901299%7CUnknown%7CTWFpbGZsb3d8eyJWIjo
> > iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%
> > 7C=2n8iljUXBtb4Jf%2FZTqN2Nl5j81WoatTYA64c5%2FRoH0A%3D=0
> 
> 
> 
> --
> Astra mortemque praestare gradatim
> 
> ___
> 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

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

[TLS] -rfc8447bis: s15 ambiguity

[Sean Turner]

Hi! I submitted the following PR to address the point Rich and ekr discussed 
about an ambiguity in s15 of -rfc8447bis:
https://github.com/tlswg/rfc8447bis/pull/56

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

Re: [TLS] -draft8447bis: rename Support Group Elliptic curve groups space

[Sean Turner]

To me, it looks like we have rough agreement to change the note as specified in 
the PR.

spt

> On Mar 28, 2024, at 10:52, Sean Turner  wrote:
> 
> 
> 
> **WARNING: Potential bikeshed**
> 
> -connolly-tls-mlkem-key-agreement has suggested that code points for the NIST 
> PQ be registered in the TLS Supported Groups IANA registry [1].  Currently 
> [2], the registry is carved up into three blocks as follows:
> 
> Range: 0-255, 512-65535
> Registration Procedures: Specification Required
> Note: Elliptic curve groups
> 
> Range 256-511
> Registration Procedures: Specification Required
> Note: Finite Field Diffie-Hellman groups
> 
> Assuming that the proposal in -connolly-tls-mlkem-key-agreement is the path 
> for PQ KEM algorithms (and maybe regardless of whether this is the path), we 
> should really replace the “Elliptic curve groups” note in the 0-255, 
> 512-65535 range row with something else.  I am open to suggestions, but would 
> like to propose “unallocated”. I have submitted the following issue:
> https://github.com/tlswg/rfc8447bis/issues/54
> and this PR:
> https://github.com/tlswg/rfc8447bis/pull/55
> to address this.
> 
> spt
> 
> [1] 
> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8
> 
> [2] Originally, RFC 8442 defined the name of the registry as "EC Named Curve 
> Registry” and then RFC 7919 re-named it “Supported Groups” and carved out the 
> FFDH space.

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

Re: [TLS] Dnsdir early review of draft-ietf-tls-svcb-ech-01

[Sean Turner]

Ted & ErikN,

So it looks like ErikN submitted the following PR and ekr approved:
https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/1

If we have resolved your comments, can I ask on of the authors to spin a new 
version and we can look to move this I-D.

Also, could I kindly ask you to revise your review to change to “ready” and 
maybe refer to thread:
https://mailarchive.ietf.org/arch/msg/tls/VQcqUuOXSE8sgcp4_CHa6Jlc394/

spt

> On Mar 30, 2024, at 19:17, Eric Rescorla  wrote:
> 
> 
> 
> On Sat, Mar 30, 2024 at 11:09 AM Ted Lemon  wrote:
> Encrypted dns transport works if you can trust the provider you are talking 
> to. DNSSEC works even if you can’t. And if your provider is trustworthy, 
> DNSSEC validation of results acquired through this tunnel should work. So 
> it’s silly in this case to trust the tunnel—there’s no upside to doing so 
> other than avoiding a few signature verifications. 
> 
> I don't object to people doing DNSSEC validation of ECH records (though AFAIK 
> no major browser does so), but...
> 
> 1. The resolver only gains a limited amount by forging the SVCB response 
> because the resolver already knows the domain name you are going to. This 
> does conceal (say) the ALPN, but that's usually less interesting than the SNI.
> 2. If the authoritative domain is misconfigured, which is not unheard of, 
> then this can create resolution failures (this is true for A/, of 
> course). Probably not much of an issue for the big public recursives, but can 
> definitely be an issue if you are just talking to some locally-supplied 
> resolver.
> 
> -Ekr
> 
> 
> Op za 30 mrt 2024 om 14:02 schreef Rob Sayre 
> On Sat, Mar 30, 2024 at 10:47 AM Erik Nygren  wrote:
> 
> An attacker who can prevent SVCB resolution can deny clients any associated 
> security benefits.
> 
> Yes.
>  
> A hostile recursive resolver can always deny service to SVCB queries, but 
> network intermediaries can often prevent resolution as well, even when the 
> client and recursive resolver validate DNSSEC and use a secure transport. 
> These downgrade attacks can prevent a client from being aware that "ech" is 
> configured which would result in the client sending the ClientHello in 
> cleartext.
> 
> I think s/would/could/ here.
> 
> I don't know if we want to write it, but doesn't using encrypted transport 
> DNS to an IP address avoid this problem? Like using 1.1.1.1 or 8.8.8.8 etc. I 
> know that raises centralization issues, but it does help with this issue.
> 
> thanks,
> Rob
> 

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

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

[Sean Turner]

Noted in the Shepherd write-up.

spt

> On Apr 2, 2024, at 20:30, Stephen Farrell  wrote:
> 
> 
> 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
> 

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

Re: [TLS] Transfer of change control for SSLKEYLOGFILE format

[Sean Turner]

Martin,

Thanks for this. This was noted in the Shepherd write-up for the IESG to find 
during their deliberations.

Cheers,
spt

> On Apr 3, 2024, at 23:14, Martin Thomson  wrote:
> 
> Hey,
> 
> I'm writing this in my capacity as owner for NSS[1], not as a draft author.
> 
> The chairs asked that I formally indicate that Mozilla and the NSS project 
> are willing to transfer ownership of the SSLKEYLOGFILE format[2].  Though it 
> might be obvious to some of us that submitting an Internet-Draft implies that 
> willingness, we might as well make it formal.
> 
> Mozilla and the NSS project are happy to transfer ownership of the 
> SSLKEYLOGFILE format to the IETF.
> 
> Thanks,
> Martin
> 
> [1] https://firefox-source-docs.mozilla.org/mots/index.html#core-security
> [2] https://datatracker.ietf.org/doc/html/draft-ietf-tls-keylogfile
> ___
> 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] Publication has been requested for draft-ietf-tls-keylogfile-01

[Sean Turner via Datatracker]

Sean Turner has requested publication of draft-ietf-tls-keylogfile-01 as 
Informational on behalf of the TLS working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/


___
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 >>> <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
>> 
> 
> 
> 

___
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] I-D Action: draft-ietf-tls-svcb-ech-01.txt

[Sean Turner]

Hi! I am going to kick off some early reviews from the DNS and HTTP 
directorates to see if we get anything back.

spt

> On Mar 27, 2024, at 16:37, internet-dra...@ietf.org wrote:
> 
> Internet-Draft draft-ietf-tls-svcb-ech-01.txt is now available. It is a work
> item of the Transport Layer Security (TLS) WG of the IETF.
> 
>   Title:   Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings
>   Authors: Ben Schwartz
>Mike Bishop
>Erik Nygren
>   Name:draft-ietf-tls-svcb-ech-01.txt
>   Pages:   6
>   Dates:   2024-03-27
> 
> Abstract:
> 
>   To use TLS Encrypted ClientHello (ECH) the client needs to learn the
>   ECH configuration for a server before it attempts a connection to the
>   server.  This specification provides a mechanism for conveying the
>   ECH configuration information via DNS, using a SVCB or HTTPS record.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-svcb-ech/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-tls-svcb-ech-01.html
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-svcb-ech-01
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> 

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

[TLS] -draft8447bis: rename Support Group Elliptic curve groups space

[Sean Turner]

**WARNING: Potential bikeshed**

-connolly-tls-mlkem-key-agreement has suggested that code points for the NIST 
PQ be registered in the TLS Supported Groups IANA registry [1].  Currently [2], 
the registry is carved up into three blocks as follows:

Range: 0-255, 512-65535
Registration Procedures: Specification Required
Note: Elliptic curve groups

Range 256-511
Registration Procedures: Specification Required
Note: Finite Field Diffie-Hellman groups

Assuming that the proposal in -connolly-tls-mlkem-key-agreement is the path for 
PQ KEM algorithms (and maybe regardless of whether this is the path), we should 
really replace the “Elliptic curve groups” note in the 0-255, 512-65535 range 
row with something else.  I am open to suggestions, but would like to propose 
“unallocated”. I have submitted the following issue:
https://github.com/tlswg/rfc8447bis/issues/54
and this PR:
https://github.com/tlswg/rfc8447bis/pull/55
to address this.

spt

[1] 
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8

[2] Originally, RFC 8442 defined the name of the registry as "EC Named Curve 
Registry” and then RFC 7919 re-named it “Supported Groups” and carved out the 
FFDH space.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Sean Turner]

Minor suggestion to refer to -rfc84446bis:
https://github.com/tlswg/sslkeylogfile/pull/8
aka let’s make a cluster!

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 SSLKEYLOG File

[Sean Turner]

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

[Sean Turner]

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] dispatching DTLS 1.2 errata

[Sean Turner]

Hi! We’ve got 8 reported errata on DTLS 1.2 (RFC 6347):
https://www.rfc-editor.org/errata_search.php?rfc=6347_status=15=records
that we, the royal we where we is the WG, need to dispatch.  By way of 
background, the
IESG has the following statement about processing errata on the IETF stream:
https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-errata-for-the-ietf-stream-20210507/
Based on the IESG statement, please let me know by 3 April if you disagree with 
the following proposed
resolutions:

1. https://www.rfc-editor.org/errata/eid3917

Proposed dispatch: reject
Rationale: RFC 9147 obsoletes RFC 6347 and extensions is added to the 
ClientHello struct (see s5.3).

2. https://www.rfc-editor.org/errata/eid4103

Proposed dispatch: reject
Rationale: RFC 9147 obsoletes RFC 6347 and HelloVerifyRequest is no longer 
applicable to DTLS 1.3.

3. https://www.rfc-editor.org/errata/eid5186

Proposed dispatch: reject
Rationale: RFC 9147 obsoletes RFC 6347 and the section in question was 
extensively revised; the offending text is removed or no longer applies.

4. https://www.rfc-editor.org/errata/eid4104

Proposed dispatch: reject
Rationale: RFC 9147 obsoletes RFC 6347and the paragraph in questions was 
extensively revised; the offending text is removed.

5. https://www.rfc-editor.org/errata/eid4105

Proposed dispatch: reject
Rationale: RFC 9147 obsoletes RFC 6347 and the two sections were merged into 
one.

6. https://www.rfc-editor.org/errata/eid4642

Proposed dispatch: reject
Rationale: RFC 9147 obsoletes RFC 6347, the field has been renamed, and the 
field’s explanation updated.

7. https://www.rfc-editor.org/errata/eid5903

Proposed dispatch: reject
Rationale: RFC 9147 obsoletes RFC 6347 and the paragraph in questions was 
extensively revised; the offending text is reworded.

8. https://www.rfc-editor.org/errata/eid5026

Proposed dispatch: reject
Rationale: RFC 9147 obsoletes RFC 6347 and the 2119-language for the length is 
no longer in RFC 9147.

Cheers,
spt

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

Re: [TLS] TLSFlags ambiguity

[Sean Turner]

I just threw in a couple of PRs to align this I-D with 8446bis & 8447bis, but 
forgot to add this issue.  I have corrected this now so that we won’t forget 
again:
https://github.com/tlswg/tls-flags/issues/36

spt

> On Mar 17, 2024, at 13:53, David Benjamin  wrote:
> 
> Did this ever get resolved? I noticed that there was a draft-13 cut, but the 
> issue Jonathan pointed out was still there.
> 
> Looking at Section 2 again, it's actually even goofier than the original 
> email suggests. Section 2 first says:
> 
> > The FlagExtensions field contains 8 flags in each octet. The length of the 
> > extension is the minimal length that allows it to encode all of the present 
> > flags. Within each octet, the bits are packed such that the first bit is 
> > the least significant bit and the eighth bit is the most significant.
> 
> This is LSB first. Then there's an example, which is also LSB first:
> 
> > For example, if we want to encode only flag number zero, the FlagExtension 
> > field will be 1 octet long, that is encoded as follows:
> >
> >0001
> 
> So that's all consistent. But then the last paragraph of section 2 says:
> 
> > Note that this document does not define any particular bits for this 
> > string. That is left to the protocol documents such as the ones in the 
> > examples from the previous section. Such documents will have to define 
> > which bit to set to show support, and the order of the bits within the bit 
> > string shall be enumerated in network order: bit zero is the high-order bit 
> > of the first octet as the flags field is transmitted.
> 
> This says it's MSB first for some reason. But this is not only inconsistent, 
> but also redundant with the text at the start of section 2. It seems to me we 
> could simply delete the redundant text and move on:
> 
> > Note that this document does not define any particular bits for this 
> > string. That is left to the protocol documents such as the ones in the 
> > examples from the previous section. Such documents will have to define 
> > which bit to set to show support.
> 
> David
> 
> On Wed, Sep 27, 2023, 17:50 David Benjamin  wrote:
> Nice catch! I agree those don't match. I think bit zero should be the 
> least-significant bit. That is, we should leave the examples as-is and then 
> fix the specification text.
> 
> Ordering bits MSB first doesn't make much sense. Unlike bytes, there is no 
> inherent order to bits in memory, so the most natural order is the power of 
> two represented by the bit. Put another way, everyone accesses bit N by 
> ANDing with 1 << N and that's least-significant bits first. I can think of a 
> couple systems (DER, GCM) that chose to order bits most-significant first and 
> both have caused endless confusion and problems. (It's particularly bad for 
> GCM which is actually representing a polynomial, but then messed up the 
> order. Let's not repeat this blunder.)
> 
> On Fri, Sep 15, 2023 at 1:37 PM Jonathan Hoyland  
> wrote:
> Hi TLSWG,
> 
> I'm working on implementing the TLS Flags extension, and I just wanted to 
> clarify a potential ambiguity in the spec.
> 
> In Section 2 the spec says:
> Such documents will have to define which bit to set to show support, and the 
> order of the bits within the bit string shall be enumerated in network order: 
> bit zero is the high-order bit of the first octet as the flags field is 
> transmitted.
> 
> And also gives the example for encoding bit zero:
> For example, if we want to encode only flag number zero, the FlagExtension 
> field will be 1 octet long, that is encoded as follows:
>0001
> In which it seems that the low-order bit of the first octet represents zero.
> 
> I have no preference either way, but when transmitted on the wire, should 
> flag 0 be transmitted as 
> 0x01 or 0x80?
> 
> Regards,
> 
> Jonathan
> ___
> 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] [Technical Errata Reported] RFC6066 (5658)

[Sean Turner]

I suspect that this errata should be rejected.  RFC 6125 was published months 
after RFC 6066 and that makes this addition feel “new" to me and as such it’s 
inappropriate to change through the errata process; see [1].

spt

[1] 
https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-errata-for-the-ietf-stream-20210507/

> On Mar 15, 2019, at 05:35, RFC Errata System  
> wrote:
> 
> The following errata report has been submitted for RFC6066,
> "Transport Layer Security (TLS) Extensions: Extension Definitions".
> 
> --
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5658
> 
> --
> Type: Technical
> Reported by: Owen Friel 
> 
> Section: 3
> 
> Original Text
> -
> 
> 
> Corrected Text
> --
> When a client uses DNS SRV to discover and connect to a server, the 
> client SHOULD include the "source domain" in the "host_name" and SHOULD
> NOT include the "derived domain", where "source domain" and "derived
> domain" are defined in RFC6125. 
> 
> Notes
> -
> The original text is all fine, but it is missing some additional clarifying 
> text on use of SNI when a client users DNS SRV to discover the service it is 
> connecting to.
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC6066 (draft-ietf-tls-rfc4366-bis-12)
> --
> Title   : Transport Layer Security (TLS) Extensions: Extension 
> Definitions
> Publication Date: January 2011
> Author(s)   : D. Eastlake 3rd
> Category: PROPOSED STANDARD
> Source  : Transport Layer Security
> Area: Security
> Stream  : IETF
> Verifying Party : IESG

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

Re: [TLS] [Editorial Errata Reported] RFC6176 (5536)

[Sean Turner]

Paul,

I think you can mark this one as verified.  I don’t think anybody is really 
confused by not citing 2446 in the 1st sentence but the quoted sentence is in 
RFC 2446 so as suggested the sentence is still true.

spt

> On Oct 19, 2018, at 23:33, RFC Errata System  
> wrote:
> 
> The following errata report has been submitted for RFC6176,
> "Prohibiting Secure Sockets Layer (SSL) Version 2.0".
> 
> --
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5536
> 
> --
> Type: Editorial
> Reported by: Eugene Adell 
> 
> Section: 1
> 
> Original Text
> -
>   RFC 4346 [TLS1.1], and later RFC 5246 [TLS1.2], explicitly warned
>   implementers that the "ability to send version 2.0 CLIENT-HELLO
>   messages will be phased out with all due haste".  This document
>   accomplishes this by updating the backward compatibility sections
>   found in TLS [TLS1.0][TLS1.1][TLS1.2].
> 
> Corrected Text
> --
>   RFC 2246 [TLS1.0], and later RFC 4346 [TLS1.1], then RFC 5246
>   [TLS1.2] explicitly warned implementers that the "ability to send
>   version 2.0 CLIENT-HELLO messages will be phased out with all due
>   haste". This document accomplishes this by updating the backward
>   compatibility sections found in TLS [TLS1.0][TLS1.1][TLS1.2].
> 
> Notes
> -
> The warning on the version 2.0 Client Hello is as old as the first TLS 
> version (RFC 2246 Appendix E). That's what the authors meant and wanted to 
> highlight by listing two of the three RFCs containing this warning. This is 
> confirmed by their last sentence. It looks like a small mistake without 
> concrete effects, I push this errata considering "IESG Processing of RFC 
> Errata for the IETF Stream rule 6"
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC6176 (draft-ietf-tls-ssl2-must-not-04)
> --
> Title   : Prohibiting Secure Sockets Layer (SSL) Version 2.0
> Publication Date: March 2011
> Author(s)   : S. Turner, T. Polk
> Category: PROPOSED STANDARD
> Source  : Transport Layer Security
> Area: Security
> Stream  : IETF
> Verifying Party : IESG

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

Re: [TLS] [Technical Errata Reported] RFC8448 (5645)

[Sean Turner]

Hi! This has been lingering for a while, I tend to think we could mark it as 
HFDU (hold for document update).

spt

> On Feb 28, 2019, at 16:20, RFC Errata System  
> wrote:
> 
> The following errata report has been submitted for RFC8448,
> "Example Handshake Traces for TLS 1.3".
> 
> --
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5645
> 
> --
> Type: Technical
> Reported by: Anthony Mai 
> 
> Section: 2
> 
> Original Text
> -
>   Ephemeral private keys are shown as they are generated in the traces.
> 
> Corrected Text
> --
>   Ephemeral private keys are shown as they are generated in the traces.
> Note that X25519 private keys are trimmed in accordance to [RFC 7748]
> Section 5, before use. This is done by clearing bit 0 to 2 of the first
> byte and bit 7 of the last byte. And then set bit 6 of the last byte.
> 
> Notes
> -
> On page 3,5,16,20,29,43,44,55,57, there are ten X25519 ephemeral private
> keys listed. None of these private key value, when used directly in X25519
> calculation, will yield the associated public key listed. These private key
> values are not the actual values used. Instead up to 5 bits are modified as
> recommended by RFC 7748 section 5. Some implementations may choose NOT to
> do such trimming, and it does not affect the connectivity, as the private
> keys are never sent over the wire and does not affect network behavior.
> 
> Not clarifying how the X25519 private keys were modified before using could
> cause serious confusion. I personally struggled for a day before figuring
> out this little obscure detail.
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC8448 (draft-ietf-tls-tls13-vectors-07)
> --
> Title   : Example Handshake Traces for TLS 1.3
> Publication Date: January 2019
> Author(s)   : M. Thomson
> Category: INFORMATIONAL
> Source  : Transport Layer Security
> Area: Security
> Stream  : IETF
> Verifying Party : IESG

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

Re: [TLS] [Editorial Errata Reported] RFC8447 (6009)

[Sean Turner]

Paul,

You can go ahead and mark this one as Verified.  The name of the 0 value is 
“X509”.

spt

> On Mar 7, 2020, at 13:08, RFC Errata System  wrote:
> 
> The following errata report has been submitted for RFC8447,
> "IANA Registry Updates for TLS and DTLS".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6009
> 
> --
> Type: Editorial
> Reported by: Benjamin Kaduk 
> 
> Section: 14
> 
> Original Text
> -
>   o  Added a "Recommended" column to the registry.  X.509 and Raw
> 
> 
> Corrected Text
> --
>   o  Added a "Recommended" column to the registry.  X509 and Raw
> 
> 
> Notes
> -
> Update to match https://www.rfc-editor.org/errata/eid5976
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC8447 (draft-ietf-tls-iana-registry-updates-05)
> --
> Title   : IANA Registry Updates for TLS and DTLS
> Publication Date: August 2018
> Author(s)   : J. Salowey, S. Turner
> Category: PROPOSED STANDARD
> Source  : Transport Layer Security
> Area: Security
> Stream  : IETF
> Verifying Party : IESG

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

[TLS] Working Group Last Call for SSLKEYLOG File

[Sean Turner]

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] I-D Action: draft-ietf-tls-tlsflags-12.txt

[Sean Turner]

Hi! I submitted two PRs on this I-D:

1. One updates the discussions about the Recommended column values to refer to 
draft-ietf-tls-rfc8447bis that John raised:
https://github.com/tlswg/tls-flags/pull/33

2. One updatesRFC 8446 references to draft-ietf-tls-rfc8446bis:
https://github.com/tlswg/tls-flags/pull/35

spt

> On Jul 23, 2023, at 15:19, internet-dra...@ietf.org wrote:
> 
> 
> 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   : A Flags Extension for TLS 1.3
>   Author  : Yoav Nir
>   Filename: draft-ietf-tls-tlsflags-12.txt
>   Pages   : 9
>   Date: 2023-07-23
> 
> Abstract:
>   A number of extensions are proposed in the TLS working group that
>   carry no interesting information except the 1-bit indication that a
>   certain optional feature is supported.  Such extensions take 4 octets
>   each.  This document defines a flags extension that can provide such
>   indications at an average marginal cost of 1 bit each.  More
>   precisely, it provides as many flag extensions as needed at 4 + the
>   order of the last set bit divided by 8.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/
> 
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-tls-tlsflags-12
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-tlsflags-12
> 
> 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

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

Re: [TLS] tls@ietf119: agenda requests

[Sean Turner]

msg received!

spt

> On Feb 29, 2024, at 17:00, Jonathan Hoyland  
> wrote:
> 
> Hi Sean,
> 
> I would like to speak briefly on my draft TLS flag that signals client 
> support for mTLS [1], and if possible to have a call for adoption. 
> 
> I would need ~5 mins.
> 
> Regards, 
> 
> Jonathan
> 
> [1] https://datatracker.ietf.org/doc/html/draft-jhoyla-req-mtls-flag-01
> 
> On Thu, 29 Feb 2024, 16:05 Sean Turner,  wrote:
> The TLS WG is meeting at IETF 119 for 2 hours on Tuesday, March 19, 2024 from 
> 0930-1130 (local time) [0] in the Plaza Terrace Room [2]. The chairs would 
> like to solicit input from the WG for agenda topics. Please send your agenda 
> topics request and an estimate for how much time you will need to 
> tls-cha...@ietf.org. Please note that we will prioritize existing WG items. 
> Please also review the guidance for TLS WG presenters that can be found at 
> [2].
> 
> Cheers,
> Chris, Joe, and Sean
> 
> [0] https://datatracker.ietf.org/meeting/119/agenda
> [1] 
> https://datatracker.ietf.org/meeting/119/floor-plan?room=plaza-terrace-room
> [2] https://github.com/tlswg/tlswg-wiki/blob/master/FAQ.md
> ___
> 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] tls@ietf119: I-D submission deadline

[Sean Turner]

Hi! Friendly reminder that the I-D submission deadline for IETF 119 is [1]:

2024-03-04 (Monday) Internet-Draft submission cut-off (for all Internet-Drafts, 
including -00) by UTC 23:59. Upload using the I-D Submission Tool [2]

Cheers,
spt

[1] https://datatracker.ietf.org/meeting/important-dates/
[2] https://datatracker.ietf.org/submit/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] tls@ietf119: agenda requests

[Sean Turner]

The TLS WG is meeting at IETF 119 for 2 hours on Tuesday, March 19, 2024 from 
0930-1130 (local time) [0] in the Plaza Terrace Room [2]. The chairs would like 
to solicit input from the WG for agenda topics. Please send your agenda topics 
request and an estimate for how much time you will need to tls-cha...@ietf.org. 
Please note that we will prioritize existing WG items. Please also review the 
guidance for TLS WG presenters that can be found at [2].

Cheers,
Chris, Joe, and Sean

[0] https://datatracker.ietf.org/meeting/119/agenda
[1] https://datatracker.ietf.org/meeting/119/floor-plan?room=plaza-terrace-room
[2] https://github.com/tlswg/tlswg-wiki/blob/master/FAQ.md
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Sean Turner]

> On Jan 25, 2024, at 10:36, Salz, Rich  
> wrote:
> 
>> Internet-Draft draft-ietf-tls-keylogfile-00.txt is now available. It is a 
>> work
>> item of the Transport Layer Security (TLS) WG of the IETF.
> 
> I assume this just documents the current format and that therefore existing 
> implementations (OpenSSL and Wireshark come to mind) just work.
> 
> If that assumption is true, this seems ready for WGLC.

BTW - I was thinking the same thing.  Let’s wait for Martin to respond and then 
we an get the WGLC going.

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

[TLS] errata (was Re: Late holiday gifts)

[Sean Turner]

> On Jan 18, 2024, at 15:56, Stephen Farrell  wrote:
> 
> Processing those is of course worthy (probably) but so is finishing
> existing specs that've been deployed already.

The TLS WG holds the distinction for have the most reported errata (61) [0].  
We need to start working through these at some point.

spt

[0] 
https://www.rfc-editor.org/errata_search.php?rec_status=2_acronym=sec_acronym=TLS=table


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

Re: [TLS] Late holiday gifts

[Sean Turner]

Hi! We are circling back with the authors and expect a revised draft soon-ish. 
And yes, I am being vague about the actual time frame.

spt

> On Jan 21, 2024, at 11:02, Arnaud Taddei 
>  wrote:
> 
> +1
>  
> From: TLS  on behalf of Stephen Farrell 
> 
> Date: Thursday, 18 January 2024 at 21:56
> To: Salz, Rich , tls@ietf.org 
> 
> Subject: Re: [TLS] Late holiday gifts
> 
> 
> 
> On 18/01/2024 17:46, Salz, Rich wrote:
> > Per last IETF meeting [1] I thought ECH was going to go to WGLC.  Were we 
> > waiting for a new draft?  Something else?
> 
> Looking a bit like we're an errata-only mailing list last while:-)
> 
> Processing those is of course worthy (probably) but so is finishing
> existing specs that've been deployed already.
> 
> So yeah, I agree WGLC would be timely.
> 
> S.
> 
> > 
> > [1] 
> > https://www.google.com/url?q=https://datatracker.ietf.org/doc/minutes-118-tls-202311060830/=gmail-imap=170621621700=AOvVaw3QUgJKQAvNUkaabvM22r89
> > 
> > 
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/tls=gmail-imap=170621621700=AOvVaw3-F_G6Ng12eiZL6-bz5-IZ
> 
> This electronic communication and the information and any files transmitted 
> with it, or attached to it, are confidential and are intended solely for the 
> use of the individual or entity to whom it is addressed and may contain 
> information that is confidential, legally privileged, protected by privacy 
> laws, or otherwise restricted from disclosure to anyone else. If you are not 
> the intended recipient or the person responsible for delivering the e-mail to 
> the intended recipient, you are hereby notified that any use, copying, 
> distributing, dissemination, forwarding, printing, or copying of this e-mail 
> is strictly prohibited. If you received this e-mail in error, please return 
> the e-mail to the sender, delete it from your computer, and destroy any 
> printed copy of it.___
> 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] I-D Action: draft-ietf-tls-rfc8447bis-08.txt

[Sean Turner]

Hi! With author hat on,

This version incorporates all known issues.  The authors believe this version 
is ready for WGLC.

spt

> On Jan 23, 2024, at 13:43, internet-dra...@ietf.org wrote:
> 
> Internet-Draft draft-ietf-tls-rfc8447bis-08.txt is now available. It 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
>   Name:draft-ietf-tls-rfc8447bis-08.txt
>   Pages:   18
>   Dates:   2024-01-23
> 
> Abstract:
> 
>   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 the selected TLS registries.
> 
>   This document updates the following RFCs: 3749, 5077, 4680, 5246,
>   5705, 5878, 6520, 7301, and 8447.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-tls-rfc8447bis-08.html
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-rfc8447bis-08
> 
> 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

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

Re: [TLS] RFC88447bis: additional DE instructions

[Sean Turner]

Happy 2024!  Hoping to close this one out by Monday so get your comment in!

Cheers,
spt

> On Dec 12, 2023, at 08:38, Sean Turner  wrote:
> 
> Hi! Rich $, Martin T, and ekr have all added some thoughts.   Anybody else 
> have some thoughts?
> 
> spt
> 
>> On Dec 6, 2023, at 11:20, Sean Turner  wrote:
>> 
>> Hi! A thread over on the IRTF’s CFRG list, see [0], has resulted in a PR, 
>> see [1], that includes additional instructions for the designated experts 
>> related to “Expert Review of Current and Potential IETF and IRTF Documents". 
>>  Please let us know what you think about the contents of the PR (here or in 
>> the PR). Also, please keep messages related to this PR on this list and off 
>> the CFRG list.
>> 
>> Thanks,
>> spt
>> 
>> [0] https://mailarchive.ietf.org/arch/msg/cfrg/QzxwN9hrSGHl0pBdWOhvfZ1UOhM/
>> [1] https://github.com/tlswg/rfc8447bis/pull/50
>> 
> 

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

Re: [TLS] ECH: Changes to IANA consideration section

[Sean Turner]

FYI the assignments have been made.

spt

> On Dec 12, 2023, at 09:11, Sean Turner  wrote:
> 
> I should also included a link to the revised PR:
> https://github.com/tlswg/draft-ietf-tls-esni/pull/597
> 
> spt
> 
>> On Dec 11, 2023, at 22:01, Sean Turner  wrote:
>> 
>> I am going to go ahead and forward this. Note that since the “Comments” 
>> column isn’t a thing until we get 8447bis through the door the note will 
>> follow.
>> 
>> spt
>> 
>>> On Dec 6, 2023, at 14:46, Sean Turner  wrote:
>>> 
>>> Okay a new proposal the ech_outer_extensions registration:
>>> - Set "TLS 1.3" column to “CH”
>>> - Include the following note in our new “Comments” column [0]: "Only 
>>> appears in inner CH."
>>> 
>>> spt
>>> 
>>> [0] PRs:
>>> https://github.com/tlswg/rfc8447bis/pull/48
>>> https://github.com/tlswg/rfc8447bis/pull/49
>>> 
>>>> On Nov 29, 2023, at 16:09, Stephen Farrell  
>>>> wrote:
>>>> 
>>>> 
>>>> Hiya,
>>>> 
>>>> On 27/11/2023 14:35, Sean Turner wrote:
>>>>> Bumping this up in case anybody missed it.
>>>> 
>>>> 'case it helps, I'm fine with the original mail you sent and any of
>>>> "n/a" or "CH" being used rather than "-". If it helps, I've a very
>>>> minuscule hint of a preference for "CH" so you can count me as agreeing
>>>> with MT.
>>>> 
>>>> But I won't object to any other thing, 'cause I don't think there's a
>>>> perfect answer, and it matters very little, and defining a new thing
>>>> like "CHI" just for this seems OTT, but meh, I could even live with
>>>> that too.
>>>> 
>>>> I'd also be fine with this just left to chair/editor discretion FWIW.
>>>> While it's good to bring things like that to the list, I don't
>>>> think you need to delay based on a small-ish set of responses.
>>>> 
>>>> Cheers,
>>>> S.
>>>> 
>>>> 
>>>> 
>>>>> spt
>>>>>> On Nov 21, 2023, at 21:03, Sean Turner  wrote:
>>>>>> 
>>>>>> Hi! I sent over the early allocation request and the IANA folks rightly 
>>>>>> pointed out two things that need to be added. This email is to make sure 
>>>>>> we have agreement on the two changes to the registrations in s11.1. If 
>>>>>> you don’t agree with the values proposed below please let the list know 
>>>>>> by 1 December 2023.
>>>>>> 
>>>>>> 1. The encrypted_client_hello and ech_outer_extensions registrations 
>>>>>> need to indicate the value for the "DTLS-Only” column. Unless I am 
>>>>>> mistaken, “N” is the obvious value for both. See 
>>>>>> https://github.com/tlswg/draft-ietf-tls-esni/pull/584
>>>>>> 
>>>>>> 2. The "TLS 1.3” column for ech_outer_extensions registration needs to 
>>>>>> indicate a value; remember, this column indicates the messages in which 
>>>>>> the extension may appear.  Currently, it’s “”. “N/A" has been suggested, 
>>>>>> which makes sense to me considering this extension never directly 
>>>>>> appears in CH, SH, EE, CT, CR, NST, or HRR extensions field. We can’t 
>>>>>> use “-“ because that means not used in TLS 1.3. “” is used elsewhere in 
>>>>>> the registry by only for unassigned and reserved values.  The following 
>>>>>> PR change “” to “N/A”: 
>>>>>> https://github.com/tlswg/draft-ietf-tls-esni/pull/59
>>>>>> 
>>>>>> Cheers,
>>>>>> spt
>>>>> ___
>>>>> 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] ECH: Changes to IANA consideration section

[Sean Turner]

I should also included a link to the revised PR:
https://github.com/tlswg/draft-ietf-tls-esni/pull/597

spt

> On Dec 11, 2023, at 22:01, Sean Turner  wrote:
> 
> I am going to go ahead and forward this. Note that since the “Comments” 
> column isn’t a thing until we get 8447bis through the door the note will 
> follow.
> 
> spt
> 
>> On Dec 6, 2023, at 14:46, Sean Turner  wrote:
>> 
>> Okay a new proposal the ech_outer_extensions registration:
>> - Set "TLS 1.3" column to “CH”
>> - Include the following note in our new “Comments” column [0]: "Only appears 
>> in inner CH."
>> 
>> spt
>> 
>> [0] PRs:
>> https://github.com/tlswg/rfc8447bis/pull/48
>> https://github.com/tlswg/rfc8447bis/pull/49
>> 
>>> On Nov 29, 2023, at 16:09, Stephen Farrell  
>>> wrote:
>>> 
>>> 
>>> Hiya,
>>> 
>>> On 27/11/2023 14:35, Sean Turner wrote:
>>>> Bumping this up in case anybody missed it.
>>> 
>>> 'case it helps, I'm fine with the original mail you sent and any of
>>> "n/a" or "CH" being used rather than "-". If it helps, I've a very
>>> minuscule hint of a preference for "CH" so you can count me as agreeing
>>> with MT.
>>> 
>>> But I won't object to any other thing, 'cause I don't think there's a
>>> perfect answer, and it matters very little, and defining a new thing
>>> like "CHI" just for this seems OTT, but meh, I could even live with
>>> that too.
>>> 
>>> I'd also be fine with this just left to chair/editor discretion FWIW.
>>> While it's good to bring things like that to the list, I don't
>>> think you need to delay based on a small-ish set of responses.
>>> 
>>> Cheers,
>>> S.
>>> 
>>> 
>>> 
>>>> spt
>>>>> On Nov 21, 2023, at 21:03, Sean Turner  wrote:
>>>>> 
>>>>> Hi! I sent over the early allocation request and the IANA folks rightly 
>>>>> pointed out two things that need to be added. This email is to make sure 
>>>>> we have agreement on the two changes to the registrations in s11.1. If 
>>>>> you don’t agree with the values proposed below please let the list know 
>>>>> by 1 December 2023.
>>>>> 
>>>>> 1. The encrypted_client_hello and ech_outer_extensions registrations need 
>>>>> to indicate the value for the "DTLS-Only” column. Unless I am mistaken, 
>>>>> “N” is the obvious value for both. See 
>>>>> https://github.com/tlswg/draft-ietf-tls-esni/pull/584
>>>>> 
>>>>> 2. The "TLS 1.3” column for ech_outer_extensions registration needs to 
>>>>> indicate a value; remember, this column indicates the messages in which 
>>>>> the extension may appear.  Currently, it’s “”. “N/A" has been suggested, 
>>>>> which makes sense to me considering this extension never directly appears 
>>>>> in CH, SH, EE, CT, CR, NST, or HRR extensions field. We can’t use “-“ 
>>>>> because that means not used in TLS 1.3. “” is used elsewhere in the 
>>>>> registry by only for unassigned and reserved values.  The following PR 
>>>>> change “” to “N/A”: https://github.com/tlswg/draft-ietf-tls-esni/pull/59
>>>>> 
>>>>> Cheers,
>>>>> spt
>>>> ___
>>>> 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] RFC88447bis: additional DE instructions

[Sean Turner]

Hi! Rich $, Martin T, and ekr have all added some thoughts. Anybody else 
have some thoughts?

spt

> On Dec 6, 2023, at 11:20, Sean Turner  wrote:
> 
> Hi! A thread over on the IRTF’s CFRG list, see [0], has resulted in a PR, see 
> [1], that includes additional instructions for the designated experts related 
> to “Expert Review of Current and Potential IETF and IRTF Documents".  Please 
> let us know what you think about the contents of the PR (here or in the PR). 
> Also, please keep messages related to this PR on this list and off the CFRG 
> list.
> 
> Thanks,
> spt
> 
> [0] https://mailarchive.ietf.org/arch/msg/cfrg/QzxwN9hrSGHl0pBdWOhvfZ1UOhM/
> [1] https://github.com/tlswg/rfc8447bis/pull/50
> 

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

Re: [TLS] ECH: Changes to IANA consideration section

[Sean Turner]

I am going to go ahead and forward this. Note that since the “Comments” column 
isn’t a thing until we get 8447bis through the door the note will follow.

spt

> On Dec 6, 2023, at 14:46, Sean Turner  wrote:
> 
> Okay a new proposal the ech_outer_extensions registration:
> - Set "TLS 1.3" column to “CH”
> - Include the following note in our new “Comments” column [0]: "Only appears 
> in inner CH."
> 
> spt
> 
> [0] PRs:
> https://github.com/tlswg/rfc8447bis/pull/48
> https://github.com/tlswg/rfc8447bis/pull/49
> 
>> On Nov 29, 2023, at 16:09, Stephen Farrell  wrote:
>> 
>> 
>> Hiya,
>> 
>> On 27/11/2023 14:35, Sean Turner wrote:
>>> Bumping this up in case anybody missed it.
>> 
>> 'case it helps, I'm fine with the original mail you sent and any of
>> "n/a" or "CH" being used rather than "-". If it helps, I've a very
>> minuscule hint of a preference for "CH" so you can count me as agreeing
>> with MT.
>> 
>> But I won't object to any other thing, 'cause I don't think there's a
>> perfect answer, and it matters very little, and defining a new thing
>> like "CHI" just for this seems OTT, but meh, I could even live with
>> that too.
>> 
>> I'd also be fine with this just left to chair/editor discretion FWIW.
>> While it's good to bring things like that to the list, I don't
>> think you need to delay based on a small-ish set of responses.
>> 
>> Cheers,
>> S.
>> 
>> 
>> 
>>> spt
>>>> On Nov 21, 2023, at 21:03, Sean Turner  wrote:
>>>> 
>>>> Hi! I sent over the early allocation request and the IANA folks rightly 
>>>> pointed out two things that need to be added. This email is to make sure 
>>>> we have agreement on the two changes to the registrations in s11.1. If you 
>>>> don’t agree with the values proposed below please let the list know by 1 
>>>> December 2023.
>>>> 
>>>> 1. The encrypted_client_hello and ech_outer_extensions registrations need 
>>>> to indicate the value for the "DTLS-Only” column. Unless I am mistaken, 
>>>> “N” is the obvious value for both. See 
>>>> https://github.com/tlswg/draft-ietf-tls-esni/pull/584
>>>> 
>>>> 2. The "TLS 1.3” column for ech_outer_extensions registration needs to 
>>>> indicate a value; remember, this column indicates the messages in which 
>>>> the extension may appear.  Currently, it’s “”. “N/A" has been suggested, 
>>>> which makes sense to me considering this extension never directly appears 
>>>> in CH, SH, EE, CT, CR, NST, or HRR extensions field. We can’t use “-“ 
>>>> because that means not used in TLS 1.3. “” is used elsewhere in the 
>>>> registry by only for unassigned and reserved values.  The following PR 
>>>> change “” to “N/A”: https://github.com/tlswg/draft-ietf-tls-esni/pull/59
>>>> 
>>>> Cheers,
>>>> spt
>>> ___
>>> 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] ECH: Changes to IANA consideration section

[Sean Turner]

Okay a new proposal the ech_outer_extensions registration:
- Set "TLS 1.3" column to “CH”
- Include the following note in our new “Comments” column [0]: "Only appears in 
inner CH."

spt

[0] PRs:
https://github.com/tlswg/rfc8447bis/pull/48
https://github.com/tlswg/rfc8447bis/pull/49

> On Nov 29, 2023, at 16:09, Stephen Farrell  wrote:
> 
> 
> Hiya,
> 
> On 27/11/2023 14:35, Sean Turner wrote:
>> Bumping this up in case anybody missed it.
> 
> 'case it helps, I'm fine with the original mail you sent and any of
> "n/a" or "CH" being used rather than "-". If it helps, I've a very
> minuscule hint of a preference for "CH" so you can count me as agreeing
> with MT.
> 
> But I won't object to any other thing, 'cause I don't think there's a
> perfect answer, and it matters very little, and defining a new thing
> like "CHI" just for this seems OTT, but meh, I could even live with
> that too.
> 
> I'd also be fine with this just left to chair/editor discretion FWIW.
> While it's good to bring things like that to the list, I don't
> think you need to delay based on a small-ish set of responses.
> 
> Cheers,
> S.
> 
> 
> 
>> spt
>>> On Nov 21, 2023, at 21:03, Sean Turner  wrote:
>>> 
>>> Hi! I sent over the early allocation request and the IANA folks rightly 
>>> pointed out two things that need to be added. This email is to make sure we 
>>> have agreement on the two changes to the registrations in s11.1. If you 
>>> don’t agree with the values proposed below please let the list know by 1 
>>> December 2023.
>>> 
>>> 1. The encrypted_client_hello and ech_outer_extensions registrations need 
>>> to indicate the value for the "DTLS-Only” column. Unless I am mistaken, “N” 
>>> is the obvious value for both. See 
>>> https://github.com/tlswg/draft-ietf-tls-esni/pull/584
>>> 
>>> 2. The "TLS 1.3” column for ech_outer_extensions registration needs to 
>>> indicate a value; remember, this column indicates the messages in which the 
>>> extension may appear.  Currently, it’s “”. “N/A" has been suggested, which 
>>> makes sense to me considering this extension never directly appears in CH, 
>>> SH, EE, CT, CR, NST, or HRR extensions field. We can’t use “-“ because that 
>>> means not used in TLS 1.3. “” is used elsewhere in the registry by only for 
>>> unassigned and reserved values.  The following PR change “” to “N/A”: 
>>> https://github.com/tlswg/draft-ietf-tls-esni/pull/59
>>> 
>>> Cheers,
>>> spt
>> ___
>> 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] RFC88447bis: additional DE instructions

[Sean Turner]

Hi! A thread over on the IRTF’s CFRG list, see [0], has resulted in a PR, see 
[1], that includes additional instructions for the designated experts related 
to “Expert Review of Current and Potential IETF and IRTF Documents".  Please 
let us know what you think about the contents of the PR (here or in the PR). 
Also, please keep messages related to this PR on this list and off the CFRG 
list.

Thanks,
spt

[0] https://mailarchive.ietf.org/arch/msg/cfrg/QzxwN9hrSGHl0pBdWOhvfZ1UOhM/
[1] https://github.com/tlswg/rfc8447bis/pull/50

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

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Sean Turner]

> On Dec 6, 2023, at 07:57, Stephen Farrell  wrote:
> 
> Signed PGP part
> 
> 
> On 06/12/2023 05:33, Deirdre Connolly wrote:
>> At the TLS meeting at IETF 118 there was significant support for the draft
>> 'TLS 1.2 is in Feature Freeze' (
>> https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)  This call
>> is to confirm this on the list.  Please indicate if you support the
>> adoption of this draft and are willing to review and contribute text.
> 
> I read the draft and support adopting this. It'll probably
> change as we go in some way or other but it's better that
> the WG figure that out based on a WG draft.
> 
> Cheers,
> S.

Yes, it is a starting point. Where we end up is TBD.

spt



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

Re: [TLS] "Notes" column in draft-ietf-tls-rfc8447bis?

[Sean Turner]

> On Dec 6, 2023, at 08:02, Salz, Rich  
> wrote:
> 
> Yes, I think information regarding if a cipher suite is for TLS 1.3 is very 
> needed to have.  I already asked for that in
> https://mailarchive.ietf.org/arch/msg/tls/0gDKfXJvAemFDm7MWcS1DTDVIe8/
>  
> In addition, I would also like to information if the cipher suite can be used 
> in QUIC.
>  
> The 8447bis draft added a notes column to every TLS registry. The “1.2 is 
> frozen” draft says to use it to indicate things like “for TLS 1.3 and later”. 
> It’s a free-form text field, so we can direct IANA to put anything we want. :)

Yep we added it via:
https://github.com/tlswg/rfc8447bis/pull/48

spt

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

Re: [TLS] Early IANA Allocations for draft-ietf-tls-dtls-rrc

[Sean Turner]

IANA has made the assignments:

1. Content Type: 
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-5

2. Extension: 
https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-1

spt

> On Nov 24, 2023, at 11:37, Sean Turner  wrote:
> 
> Hi! I am going to go ahead and close this call.  While there was a lot of 
> mail on this thread, I am going to send the request to IANA because this I-D 
> has been around for years and at least one person (a DE) said it was fine.
> 
> spt
> 
>> On Nov 6, 2023, at 06:01, Sean Turner  wrote:
>> 
>> Hi! After discussions with the authors of draft-ietf-tls-dtls-rrc, I would 
>> like to determine whether there is consensus to request two early code point 
>> assignments; see RFC 7120. One is for the return_routability_check content 
>> type and would go in the TLS ContentType registry and one is for the rrc 
>> extension that would go in the TLS ExtensionType Values registry; see 
>> Section 10 of the I-D. Please let the list know by 20 November 2023 if you 
>> support these early allocations.
>> 
>> Note the I-D also creates a new sub-registry, but IANA cannot create a 
>> temporary registry and then manage it for us. We will do that in the WG/I-D; 
>> there is not much to manage as only the initial 3 values are needed.
>> 
>> Cheers,
>> spt
> 

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

Re: [TLS] ECH: Changes to IANA consideration section

[Sean Turner]

> On Nov 21, 2023, at 21:03, Sean Turner  wrote:
> 
> Hi! I sent over the early allocation request and the IANA folks rightly 
> pointed out two things that need to be added. This email is to make sure we 
> have agreement on the two changes to the registrations in s11.1. If you don’t 
> agree with the values proposed below please let the list know by 1 December 
> 2023.
> 
> 1. The encrypted_client_hello and ech_outer_extensions registrations need to 
> indicate the value for the "DTLS-Only” column. Unless I am mistaken, “N” is 
> the obvious value for both. See 
> https://github.com/tlswg/draft-ietf-tls-esni/pull/584
> 
> 2. The "TLS 1.3” column for ech_outer_extensions registration needs to 
> indicate a value; remember, this column indicates the messages in which the 
> extension may appear.  Currently, it’s “”. “N/A" has been suggested, which 
> makes sense to me considering this extension never directly appears in CH, 
> SH, EE, CT, CR, NST, or HRR extensions field. We can’t use “-“ because that 
> means not used in TLS 1.3. “” is used elsewhere in the registry by only for 
> unassigned and reserved values.  The following PR change “” to “N/A”: 
> https://github.com/tlswg/draft-ietf-tls-esni/pull/59

Whoops it is PR #597 not #59:
https://github.com/tlswg/draft-ietf-tls-esni/pull/597

> Cheers,
> spt

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

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-07.txt

[Sean Turner]

Hi! -06 and -07 incorporate the “Comment” column that we discussed at IETF 118. 
 Joe and I are planning to ask for WGLC on this version.

spt

> On Nov 27, 2023, at 10:11, internet-dra...@ietf.org wrote:
> 
> Internet-Draft draft-ietf-tls-rfc8447bis-07.txt is now available. It 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
>   Name:draft-ietf-tls-rfc8447bis-07.txt
>   Pages:   18
>   Dates:   2023-11-27
> 
> Abstract:
> 
>   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 the selected TLS registries.
> 
>   This document updates the following RFCs: 3749, 5077, 4680, 5246,
>   5705, 5878, 6520, 7301, and 8447.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-tls-rfc8447bis-07.html
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-rfc8447bis-07
> 
> 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

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

Re: [TLS] ECH: Changes to IANA consideration section

[Sean Turner]

Bumping this up in case anybody missed it.

spt

> On Nov 21, 2023, at 21:03, Sean Turner  wrote:
> 
> Hi! I sent over the early allocation request and the IANA folks rightly 
> pointed out two things that need to be added. This email is to make sure we 
> have agreement on the two changes to the registrations in s11.1. If you don’t 
> agree with the values proposed below please let the list know by 1 December 
> 2023.
> 
> 1. The encrypted_client_hello and ech_outer_extensions registrations need to 
> indicate the value for the "DTLS-Only” column. Unless I am mistaken, “N” is 
> the obvious value for both. See 
> https://github.com/tlswg/draft-ietf-tls-esni/pull/584
> 
> 2. The "TLS 1.3” column for ech_outer_extensions registration needs to 
> indicate a value; remember, this column indicates the messages in which the 
> extension may appear.  Currently, it’s “”. “N/A" has been suggested, which 
> makes sense to me considering this extension never directly appears in CH, 
> SH, EE, CT, CR, NST, or HRR extensions field. We can’t use “-“ because that 
> means not used in TLS 1.3. “” is used elsewhere in the registry by only for 
> unassigned and reserved values.  The following PR change “” to “N/A”: 
> https://github.com/tlswg/draft-ietf-tls-esni/pull/59
> 
> Cheers,
> spt

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

Re: [TLS] Early IANA Allocations for draft-ietf-tls-dtls-rrc

[Sean Turner]

Hi! I am going to go ahead and close this call.  While there was a lot of mail 
on this thread, I am going to send the request to IANA because this I-D has 
been around for years and at least one person (a DE) said it was fine.

spt

> On Nov 6, 2023, at 06:01, Sean Turner  wrote:
> 
> Hi! After discussions with the authors of draft-ietf-tls-dtls-rrc, I would 
> like to determine whether there is consensus to request two early code point 
> assignments; see RFC 7120. One is for the return_routability_check content 
> type and would go in the TLS ContentType registry and one is for the rrc 
> extension that would go in the TLS ExtensionType Values registry; see Section 
> 10 of the I-D. Please let the list know by 20 November 2023 if you support 
> these early allocations.
> 
> Note the I-D also creates a new sub-registry, but IANA cannot create a 
> temporary registry and then manage it for us. We will do that in the WG/I-D; 
> there is not much to manage as only the initial 3 values are needed.
> 
> Cheers,
> spt

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

Re: [TLS] Early IANA Allocations for draft-ietf-tls-dtls-rrc

[Sean Turner]

> On Nov 17, 2023, at 11:58, Salz, Rich  wrote:
> 
>>> I assume you are concerned about the ContentType registry. I think it's 
>>> okay to add something here.
> 
>> Yes that’s the one. I mean we have 240+ spaces, but it is technically one of 
>> our more scarce spaces.
> 
> Yes but I still think it's fine.
> 
>>> I missed the detail about the RRC Message Type registry, and it would be 
>>> nice to have a portion of it set aside for private use and experimentation.
> 
>> Since the TLS WG is managing that one for a bit, we can the reservations in 
>> before we progress. What are you thinking like 2 values at the end?
> 
> Sure.

PR for this here:
https://github.com/tlswg/dtls-rrc/pull/69

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

[TLS] ECH: Changes to IANA consideration section

[Sean Turner]

Hi! I sent over the early allocation request and the IANA folks rightly pointed 
out two things that need to be added. This email is to make sure we have 
agreement on the two changes to the registrations in s11.1. If you don’t agree 
with the values proposed below please let the list know by 1 December 2023.

1. The encrypted_client_hello and ech_outer_extensions registrations need to 
indicate the value for the "DTLS-Only” column. Unless I am mistaken, “N” is the 
obvious value for both. See 
https://github.com/tlswg/draft-ietf-tls-esni/pull/584

2. The "TLS 1.3” column for ech_outer_extensions registration needs to indicate 
a value; remember, this column indicates the messages in which the extension 
may appear.  Currently, it’s “”. “N/A" has been suggested, which makes sense to 
me considering this extension never directly appears in CH, SH, EE, CT, CR, 
NST, or HRR extensions field. We can’t use “-“ because that means not used in 
TLS 1.3. “” is used elsewhere in the registry by only for unassigned and 
reserved values.  The following PR change “” to “N/A”: 
https://github.com/tlswg/draft-ietf-tls-esni/pull/59

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

Re: [TLS] Early IANA Allocations for draft-ietf-tls-dtls-rrc

[Sean Turner]

> On Nov 15, 2023, at 14:12, Salz, Rich  wrote:
> 
> I assume you are concerned about the ContentType registry. I think it's okay 
> to add something here.

Yes that’s the one.  I mean we have 240+ spaces, but it is technically one of 
our more scarce spaces.

> I missed the detail about the RRC Message Type registry, and it would be nice 
> to have a portion of it set aside for private use and experimentation.

Since the TLS WG is managing that one for a bit, we can the reservations in 
before we progress. What are you thinking like 2 values at the end?

spt

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

Re: [TLS] Early IANA Allocations for draft-ietf-tls-dtls-rrc

[Sean Turner]

Hi! This early allocation check is still going on.

Even though I can infer some implicit support from the WG because this I-D has 
been a WG item for years, it would be good to get some emails in support of the 
assignments because the I-D does assign a new content type value from one of 
our “scarce” registries.

Thanks,
spt

> On Nov 6, 2023, at 06:01, Sean Turner  wrote:
> 
> Hi! After discussions with the authors of draft-ietf-tls-dtls-rrc, I would 
> like to determine whether there is consensus to request two early code point 
> assignments; see RFC 7120. One is for the return_routability_check content 
> type and would go in the TLS ContentType registry and one is for the rrc 
> extension that would go in the TLS ExtensionType Values registry; see Section 
> 10 of the I-D. Please let the list know by 20 November 2023 if you support 
> these early allocations.
> 
> Note the I-D also creates a new sub-registry, but IANA cannot create a 
> temporary registry and then manage it for us. We will do that in the WG/I-D; 
> there is not much to manage as only the initial 3 values are needed.
> 
> Cheers,
> spt

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

[TLS] Early IANA Allocations for draft-ietf-tls-dtls-rrc

[Sean Turner]

Hi! After discussions with the authors of draft-ietf-tls-dtls-rrc, I would like 
to determine whether there is consensus to request two early code point 
assignments; see RFC 7120. One is for the return_routability_check content type 
and would go in the TLS ContentType registry and one is for the rrc extension 
that would go in the TLS ExtensionType Values registry; see Section 10 of the 
I-D. Please let the list know by 20 November 2023 if you support these early 
allocations.

Note the I-D also creates a new sub-registry, but IANA cannot create a 
temporary registry and then manage it for us. We will do that in the WG/I-D; 
there is not much to manage as only the initial 3 values are needed.

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

Re: [TLS] 2nd WG Last Call for draft-ietf-tls-dtls-rrc

[Sean Turner]

Hi! While drafting the Shepherd write-up, the authors agreed to pause the 
publication process until implementations arrived. 20204Q1 (maybe earlier) is 
the expected timeframe for implementations. But, those implemntations need code 
points. We are at the point where this I-D is stable (it has been through 2 
WGLCs). I will kick off an early IANA allocation request for the codes points 
Section 10 of the I-D in another email thread.

spt

> On Oct 17, 2023, at 18:36, Sean Turner  wrote:
> 
> As part of my Shepherd review, I noted two changes that needed to be made:
> 
> 1) IANA - we need to explicitly state how to set the DTLS-OK column and a 
> note that says the rrc content type is helpful.
> 
> 2) Update Header - This document doesn’t really update RFCs 6147 or 91447.
> 
> Both are addressed here:
> 
> https://github.com/tlswg/dtls-rrc/pull/65
> 
> If you object to these please let me know ASAP!
> 
> Cheers,
> spt
> 
>> On Sep 18, 2023, at 17:03, Sean Turner  wrote:
>> 
>> This email starts the 2nd working group last call for "Return Routability 
>> Check for DTLS 1.2 and DTLS 1.3” I-D, located here:
>> 
>> https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-rrc/
>> 
>> The WG Last Call will end 3 October 2023 @ 2359 UTC.
>> 
>> Please review the I-D and submit issues and pull requests via the GitHub 
>> repository that can be found at:
>> 
>> https://github.com/tlswg/dtls-rrc
>> 
>> Alternatively, you can also send your comments to tls@ietf.org.
>> 
>> Thanks,
>> Chris, Joe, & Sean
> 

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

Re: [TLS] Early IANA Allocations for draft-ietf-tls-esni

[Sean Turner]

> On Oct 31, 2023, at 15:53, Sean Turner  wrote:
> 
> 
> 
>> On Oct 30, 2023, at 11:58, Sean Turner  wrote:
>> 
>> 
>>> On Sep 18, 2023, at 20:45, Sean Turner  wrote:
>>> 
>>> Hi! After discussions with the authors of draft-ietf-tls-esni, Joe and I 
>>> would like to determine whether there is consensus to request two early 
>>> code point assignments; see RFC 7120. One is for the encrypted_client_hello 
>>> extension and one is for the ech_required alert; see s11 of the I-D. Please 
>>> let the list know by 03 October 2023 if you support these early allocations.
>>> 
>>> Cheers,
>>> Joe & Sean
>> 
>> We have consensus to go ahead and ask for an early allocation for both the 
>> extension and the alert. The SVCB allocation has already been reserved so 
>> there is no action necessary from IANA on that point.  One final 
>> confirmation: I am sending the request to Paul for the code point numbers 
>> listed in the I-D:
>> 
>> TLS ExtensionType Registry: encrypted_client_hello(0xfe0d)
>> TLS Alert Registry: ech_required(121)
>> 
>> Cheers (and Thanks),
>> spt
> 
> Stephen has corrected pointed out that there are actually two TLS extensions 
> in s11.1. The other is ech_outer_extensions(0xfd00).  I will let this linger 
> until we meet next week, but I am currently under the assumption that I will 
> forward the early allocation request to Paul with the values in the I-D.

We confirmed at the session today that we should keep the code points that are 
in the I-D.  Sending the request to our AD now.

spt

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

Re: [TLS] Early IANA Allocations for draft-ietf-tls-esni

[Sean Turner]

> On Oct 30, 2023, at 11:58, Sean Turner  wrote:
> 
> 
>> On Sep 18, 2023, at 20:45, Sean Turner  wrote:
>> 
>> Hi! After discussions with the authors of draft-ietf-tls-esni, Joe and I 
>> would like to determine whether there is consensus to request two early code 
>> point assignments; see RFC 7120. One is for the encrypted_client_hello 
>> extension and one is for the ech_required alert; see s11 of the I-D. Please 
>> let the list know by 03 October 2023 if you support these early allocations.
>> 
>> Cheers,
>> Joe & Sean
> 
> We have consensus to go ahead and ask for an early allocation for both the 
> extension and the alert. The SVCB allocation has already been reserved so 
> there is no action necessary from IANA on that point.  One final 
> confirmation: I am sending the request to Paul for the code point numbers 
> listed in the I-D:
> 
> TLS ExtensionType Registry: encrypted_client_hello(0xfe0d)
> TLS Alert Registry: ech_required(121)
> 
> Cheers (and Thanks),
> spt

Stephen has corrected pointed out that there are actually two TLS extensions in 
s11.1. The other is ech_outer_extensions(0xfd00).  I will let this linger until 
we meet next week, but I am currently under the assumption that I will forward 
the early allocation request to Paul with the values in the I-D.

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

Re: [TLS] Early IANA Allocations for draft-ietf-tls-esni

[Sean Turner]

> On Sep 18, 2023, at 20:45, Sean Turner  wrote:
> 
> Hi! After discussions with the authors of draft-ietf-tls-esni, Joe and I 
> would like to determine whether there is consensus to request two early code 
> point assignments; see RFC 7120. One is for the encrypted_client_hello 
> extension and one is for the ech_required alert; see s11 of the I-D. Please 
> let the list know by 03 October 2023 if you support these early allocations.
> 
> Cheers,
> Joe & Sean

We have consensus to go ahead and ask for an early allocation for both the 
extension and the alert. The SVCB allocation has already been reserved so there 
is no action necessary from IANA on that point.  One final confirmation: I am 
sending the request to Paul for the code point numbers listed in the I-D:

TLS ExtensionType Registry: encrypted_client_hello(0xfe0d)
TLS Alert Registry: ech_required(121)

Cheers (and Thanks),
spt
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 2nd WG Last Call for draft-ietf-tls-dtls-rrc

[Sean Turner]

As part of my Shepherd review, I noted two changes that needed to be made:

1) IANA - we need to explicitly state how to set the DTLS-OK column and a note 
that says the rrc content type is helpful.

2) Update Header - This document doesn’t really update RFCs 6147 or 91447.

Both are addressed here:

https://github.com/tlswg/dtls-rrc/pull/65

If you object to these please let me know ASAP!

Cheers,
spt

> On Sep 18, 2023, at 17:03, Sean Turner  wrote:
> 
> This email starts the 2nd working group last call for "Return Routability 
> Check for DTLS 1.2 and DTLS 1.3” I-D, located here:
> 
> https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-rrc/
> 
> The WG Last Call will end 3 October 2023 @ 2359 UTC.
> 
> Please review the I-D and submit issues and pull requests via the GitHub 
> repository that can be found at:
> 
> https://github.com/tlswg/dtls-rrc
> 
> Alternatively, you can also send your comments to tls@ietf.org.
> 
> Thanks,
> Chris, Joe, & Sean

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

[TLS] tls@ietf118

[Sean Turner]

The TLS WG is meeting at IETF 118 for 2 hours on Monday, November 6, 2023 from 
0930-1130 (local time) in Congress Hall 1. The chairs would like to solicit 
input from the WG for agenda topics. Please send your agenda topics request and 
an estimate for how much time you will need to tls-cha...@ietf.org. Please note 
that we will prioritize existing WG items. Please also review the guidance for 
TLS WG presenters that can be found at [1].

Cheers,
Chris, Joe, and Sean

[1] https://github.com/tlswg/tlswg-wiki/blob/master/FAQ.md
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 2nd WG Last Call for draft-ietf-tls-dtls-rrc

[Sean Turner]

Just a reminder.

spt

> On Sep 18, 2023, at 17:03, Sean Turner  wrote:
> 
> This email starts the 2nd working group last call for "Return Routability 
> Check for DTLS 1.2 and DTLS 1.3” I-D, located here:
> 
> https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-rrc/
> 
> The WG Last Call will end 3 October 2023 @ 2359 UTC.
> 
> Please review the I-D and submit issues and pull requests via the GitHub 
> repository that can be found at:
> 
> https://github.com/tlswg/dtls-rrc
> 
> Alternatively, you can also send your comments to tls@ietf.org.
> 
> Thanks,
> Chris, Joe, & Sean

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

Re: [TLS] Early IANA Allocations for draft-ietf-tls-esni

[Sean Turner]

Just a reminder.

spt

> On Sep 18, 2023, at 20:45, Sean Turner  wrote:
> 
> Hi! After discussions with the authors of draft-ietf-tls-esni, Joe and I 
> would like to determine whether there is consensus to request two early code 
> point assignments; see RFC 7120. One is for the encrypted_client_hello 
> extension and one is for the ech_required alert; see s11 of the I-D. Please 
> let the list know by 03 October 2023 if you support these early allocations.
> 
> Cheers,
> Joe & Sean

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

Re: [TLS] Early IANA Allocations for draft-ietf-tls-esni

[Sean Turner]

> On Sep 18, 2023, at 21:39, Stephen Farrell  wrote:
> 
> I wonder if we also need to say something about the ech= SVCB
> parameter value 5 that's reserved at [1]? Not sure, but maybe
> no harm to make that "official" at the same time if possible.
> (There could be current code that assumes that 5 in a wire-
> format HTTPS RR value maps to 0xff0d within an ECHConfigList
> even if that isn't really right.)

I’ll check with the dnsops chairs.

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

Re: [TLS] 2nd WG Last Call for draft-ietf-tls-dtls-rrc

[Sean Turner]

Hi! Especially for this draft which has been lingering for a while and hasn’t 
changed much in a year, the chairs would like to see some positive 
confirmations that this I-D is ready to head out the door.

Cheers,
spt

> On Sep 18, 2023, at 17:03, Sean Turner  wrote:
> 
> This email starts the 2nd working group last call for "Return Routability 
> Check for DTLS 1.2 and DTLS 1.3” I-D, located here:
> 
> https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-rrc/
> 
> The WG Last Call will end 3 October 2023 @ 2359 UTC.
> 
> Please review the I-D and submit issues and pull requests via the GitHub 
> repository that can be found at:
> 
> https://github.com/tlswg/dtls-rrc
> 
> Alternatively, you can also send your comments to tls@ietf.org.
> 
> Thanks,
> Chris, Joe, & Sean

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

[TLS] Early IANA Allocations for draft-ietf-tls-esni

[Sean Turner]

Hi! After discussions with the authors of draft-ietf-tls-esni, Joe and I would 
like to determine whether there is consensus to request two early code point 
assignments; see RFC 7120. One is for the encrypted_client_hello extension and 
one is for the ech_required alert; see s11 of the I-D. Please let the list know 
by 03 October 2023 if you support these early allocations.

Cheers,
Joe & Sean
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] 2nd WG Last Call for draft-ietf-tls-dtls-rrc

[Sean Turner]

This email starts the 2nd working group last call for "Return Routability Check 
for DTLS 1.2 and DTLS 1.3” I-D, located here:

https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-rrc/

The WG Last Call will end 3 October 2023 @ 2359 UTC.

Please review the I-D and submit issues and pull requests via the GitHub 
repository that can be found at:

https://github.com/tlswg/dtls-rrc

Alternatively, you can also send your comments to tls@ietf.org.

Thanks,
Chris, Joe, & Sean
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Recentattendees] Registration Open for IETF 118 Prague, 4-10 November 2023

[Sean Turner]

Just a gentle reminder that “Super Early Registration” end on @23:59 UTC 
2023-09-18.

spt

> On Aug 23, 2023, at 09:31, Sean Turner  wrote:
> 
> FYI
> 
>> Begin forwarded message:
>> 
>> From: IETF Executive Director 
>> Subject: [Recentattendees] Registration Open for IETF 118 Prague, 4-10 
>> November 2023
>> Date: August 22, 2023 at 16:24:56 EDT
>> To: IETF Announcement List 
>> Cc: recentattend...@ietf.org
>> Reply-To: admin-disc...@ietf.org
>> 
>> IETF 118 Prague
>> 4-10 November 2023
>> 
>> I am pleased to announce that registration is now open for the IETF 118 
>> Prague meeting and hackathon. 
>> 
>>https://registration.ietf.org 
>> 
>> You will need an IETF datatracker account to register and participate. If 
>> you don’t already have one, you can create an account before [1] or during 
>> the registration process. Your datatracker account is used to authenticate 
>> you with Meetecho, our participation tool used by both remote and onsite 
>> participants during the meeting.
>> 
>> IETF 118 Prague will be a 7-day meeting on 4-10 November. Preliminary agenda 
>> details for the meeting will be published on 6 October. The IETF Hackathon 
>> [2] will be held 4-5 November. Full details about the meeting are available 
>> at:
>> 
>>https://www.ietf.org/how/meetings/118/ 
>> 
>> # Registration options
>> 
>> Please note that we have changed the name of the registration options to 
>> Super Early, Early and Standard.  You are now able to purchase a Standard 
>> registration at any time, or an Early registration during the Super Early 
>> period, as this is a good way to support the IETF financially.
>> 
>> Onsite:
>> 
>>A. Super Early registration: USD 875 + VAT, if paid in full prior to 
>> 23:59 UTC 2023-09-18
>>B. Early registration: USD 1095 + VAT, if paid in full prior to 23:59 UTC 
>> 2023-10-23
>>C. Standard Registration: USD 1200 + VAT, if paid after 23:59 UTC 
>> 2023-10-23
>>D. Full-time Student Registration: USD 150 + VAT (with proper ID)
>>E. One Day Pass Registration: USD 470 + VAT
>>F. Hackathon only: No Fee
>>Remote:
>> 
>>A. Super Early registration: USD 250, if paid in full prior to 23:59 UTC 
>> 2023-09-18
>>B. Early registration: USD 310, if paid in full prior to 23:59 2023-10-23
>>C. Standard Registration: USD 360 if paid after 23:59 2023-10-23
>>D. Full-time Student Registration: USD 55 (with proper ID)
>>E. One Day Pass Registration: USD 140
>>F. Hackathon only: No Fee
>>G. Fee Waiver: No Fee (see below for more details)
>> 
>> # Remote participation fee waivers
>> 
>> We understand that not everyone can afford the remote registration fee and 
>> so we make an unlimited number of fee waivers available to remote 
>> participants. This operates on a trust basis with no checks on eligibility, 
>> and the list of fee waiver recipients is kept confidential. If you wish to 
>> participate remotely but cannot afford the registration fee then please take 
>> the fee waiver option:
>> 
>>   https://www.ietf.org/how/meetings/registration-fee-waivers/ 
>> 
>> # Registration changes and cancellation
>> 
>> If you register for onsite participation and wish to change to an online 
>> registration then you can cancel with a full refund and re-register. If you 
>> wish to cancel your registration for any other reason please contact us at 
>> supp...@ietf.org. Please request any cancellations and refunds by contacting 
>> us at supp...@ietf.org before the cutoff time of UTC 23:59 2023-10-30.
>> 
>> # Extended Friday schedule
>> 
>> To accommodate the growing number of session requests, the IESG is 
>> experimenting with a longer meeting day on Friday. Sessions are likely to 
>> extend to either 16:30 or 17:00, so please plan your travel accordingly. 
>> 
>> # Meeting venue 
>> 
>> The meeting venue and main IETF hotel is the Hilton Prague.
>> 
>> Once you have registered, a hotel information link will be available in your 
>> confirmation email and on your attendee dashboard [3]. The attendee 
>> dashboard link is also provided in your confirmation email. Staying at the 
>> main conference hotel has a number of benefits, including free unfiltered 
>> high-speed Internet provided by the IETF NOC, a specially negotiated room 
>> rate and of course being in the same hotel as many other IETF participants. 
>> 
>> Please note that the cancellation po

[TLS] Fwd: [Recentattendees] Registration Open for IETF 118 Prague, 4-10 November 2023

[Sean Turner]

FYI

> Begin forwarded message:
> 
> From: IETF Executive Director 
> Subject: [Recentattendees] Registration Open for IETF 118 Prague, 4-10 
> November 2023
> Date: August 22, 2023 at 16:24:56 EDT
> To: IETF Announcement List 
> Cc: recentattend...@ietf.org
> Reply-To: admin-disc...@ietf.org
> 
> IETF 118 Prague
> 4-10 November 2023
> 
> I am pleased to announce that registration is now open for the IETF 118 
> Prague meeting and hackathon. 
> 
>https://registration.ietf.org 
> 
> You will need an IETF datatracker account to register and participate. If you 
> don’t already have one, you can create an account before [1] or during the 
> registration process. Your datatracker account is used to authenticate you 
> with Meetecho, our participation tool used by both remote and onsite 
> participants during the meeting.
> 
> IETF 118 Prague will be a 7-day meeting on 4-10 November. Preliminary agenda 
> details for the meeting will be published on 6 October. The IETF Hackathon 
> [2] will be held 4-5 November. Full details about the meeting are available 
> at:
> 
>https://www.ietf.org/how/meetings/118/ 
> 
> # Registration options
> 
> Please note that we have changed the name of the registration options to 
> Super Early, Early and Standard.  You are now able to purchase a Standard 
> registration at any time, or an Early registration during the Super Early 
> period, as this is a good way to support the IETF financially.
> 
> Onsite:
> 
>A. Super Early registration: USD 875 + VAT, if paid in full prior to 23:59 
> UTC 2023-09-18
>B. Early registration: USD 1095 + VAT, if paid in full prior to 23:59 UTC 
> 2023-10-23
>C. Standard Registration: USD 1200 + VAT, if paid after 23:59 UTC 
> 2023-10-23
>D. Full-time Student Registration: USD 150 + VAT (with proper ID)
>E. One Day Pass Registration: USD 470 + VAT
>F. Hackathon only: No Fee
>Remote:
> 
>A. Super Early registration: USD 250, if paid in full prior to 23:59 UTC 
> 2023-09-18
>B. Early registration: USD 310, if paid in full prior to 23:59 2023-10-23
>C. Standard Registration: USD 360 if paid after 23:59 2023-10-23
>D. Full-time Student Registration: USD 55 (with proper ID)
>E. One Day Pass Registration: USD 140
>F. Hackathon only: No Fee
>G. Fee Waiver: No Fee (see below for more details)
> 
> # Remote participation fee waivers
> 
> We understand that not everyone can afford the remote registration fee and so 
> we make an unlimited number of fee waivers available to remote participants. 
> This operates on a trust basis with no checks on eligibility, and the list of 
> fee waiver recipients is kept confidential. If you wish to participate 
> remotely but cannot afford the registration fee then please take the fee 
> waiver option:
> 
>   https://www.ietf.org/how/meetings/registration-fee-waivers/ 
> 
> # Registration changes and cancellation
> 
> If you register for onsite participation and wish to change to an online 
> registration then you can cancel with a full refund and re-register. If you 
> wish to cancel your registration for any other reason please contact us at 
> supp...@ietf.org. Please request any cancellations and refunds by contacting 
> us at supp...@ietf.org before the cutoff time of UTC 23:59 2023-10-30.
> 
> # Extended Friday schedule
> 
> To accommodate the growing number of session requests, the IESG is 
> experimenting with a longer meeting day on Friday. Sessions are likely to 
> extend to either 16:30 or 17:00, so please plan your travel accordingly. 
> 
> # Meeting venue 
> 
> The meeting venue and main IETF hotel is the Hilton Prague.
> 
> Once you have registered, a hotel information link will be available in your 
> confirmation email and on your attendee dashboard [3]. The attendee dashboard 
> link is also provided in your confirmation email. Staying at the main 
> conference hotel has a number of benefits, including free unfiltered 
> high-speed Internet provided by the IETF NOC, a specially negotiated room 
> rate and of course being in the same hotel as many other IETF participants. 
> 
> Please note that the cancellation policy for the Hilton Prague is stricter 
> than normal. You can cancel your reservation without penalty until 21 days 
> prior to check-in/arrival date. In the case of cancellation 21-14 days prior 
> to check-in, the hotel will charge three room nights at the group rate as a 
> cancellation fee. In the event of a cancellation less than 14 days prior to 
> the event or scheduled check in, the hotel retains the right to charge the 
> full length of stay as reserved as a cancellation fee. However, if the hotel 
> is fully booked on the dates of stay they may not charge a cancellation fee 
> for those nights.
> 
> If you prefer to stay at a different hotel, there are numerous options in the 
> general area.
> 
> # Visas
> 
> Our thanks go to Michal Krsek & partneri s.r.o. for generously providing our 
> IETF 118 letter of invitation 

[TLS] Add DTLS implementations to TLS WG GH wiki?

[Sean Turner]

Probably should have done this a while ago, but anyway ….

I have heard that there is at least one DTLS 1.3 implementation available. I 
would like to either 1) add DTLS implementations to the GH wiki; see 
https://github.com/tlswg/tlswg-wiki/blob/master/IMPLEMENTATIONS.md; or 2) add a 
new DTLS implementations file. Any preference?

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

Re: [TLS] [Editorial Errata Reported] RFC8773 (7598)

[Sean Turner]

Russ,

Yeah the change looks right. The server is selecting based on what’s in the 
ClientHello. Anybody else see it differently?

spt

> On Aug 11, 2023, at 12:35, Russ Housley  wrote:
> 
> I believe thatthis errata should be verified.
> 
>> On Aug 11, 2023, at 12:23 PM, RFC Errata System  
>> wrote:
>> 
>> The following errata report has been submitted for RFC8773,
>> "TLS 1.3 Extension for Certificate-Based Authentication with an External 
>> Pre-Shared Key".
>> 
>> --
>> You may review the report below and at:
>> https://www.rfc-editor.org/errata/eid7598
>> 
>> --
>> Type: Editorial
>> Reported by: Russ Housley 
>> 
>> Section: 5.1
>> 
>> Original Text
>> -
>> When the "psk_key_exchange_modes" extension is included in the
>> ServerHello message, servers MUST select the psk_dhe_ke mode
>> for the initial handshake.
>> 
>> Corrected Text
>> --
>> When the "psk_key_exchange_modes" extension is included in the
>> ClientHello message, servers MUST select the psk_dhe_ke mode
>> for the initial handshake.
>> 
>> Notes
>> -
>> According to RFC 8446, the "psk_key_exchange_modes" extension only appears 
>> in the ClientHello message. Further, the slides presented on this topic at 
>> IETF 101show the "psk_key_exchange_modes" extension in the ClientHello 
>> message and no other place.  It is pretty clear that this is an editorial 
>> error.
>> 
>> Instructions:
>> -
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party  
>> can log in to change the status and edit the report, if necessary. 
>> 
>> --
>> RFC8773 (draft-ietf-tls-tls13-cert-with-extern-psk-07)
>> --
>> Title   : TLS 1.3 Extension for Certificate-Based Authentication 
>> with an External Pre-Shared Key
>> Publication Date: March 2020
>> Author(s)   : R. Housley
>> Category: EXPERIMENTAL
>> Source  : Transport Layer Security
>> Area: Security
>> Stream  : IETF
>> Verifying Party : IESG
> 
> ___
> 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] whitepaper from ambit inc

[Sean Turner]

> On Jul 23, 2023, at 04:46, bingma2022=40skiff@dmarc.ietf.org wrote:
> 
> https://www.ambit.inc/pdf/KyberDrive.pdf It says "Kyber-1024 is known to have 
> 254 bits of classical security and 230 bits of quantum security (core-
> SVP hardness)." So the future version of TLS may require triple 256-bit AES. 
> Since meet-in-the-middle attack, it requires three different 256-bit AES 
> keys. Furthermore, consider whether to use post-quantum RSA (even if NIST 
> said it does NOT guarantee quantum resistance) for hybrid TLS, because pqRSA 
> provides much higher security level for classical computers. 
> https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-Cryptography/documents/round-1/submissions/PostQuantum_RSA_Enc.zip
>  The document says "pqRSA provides much higher pre-quantum security levels 
> than most post-quantum proposals." In conclusion, Kyber1024 is more secure 
> than AES for quantum computers, but triple 256-bit AES is more secure than 
> Kyber1024 for classical computers, it may need post-quantum RSA (even though 
> it's NOT post-quantum) for hybrid TLS handshake.

While I let this one through the moderator queue, it might be more appropriate 
for the CFRG. 

> NSA still has NOT approved ChaCha20 for their ciphersuit.

On this point, you’ll need to take that up with them ;)

Cheers,
spt

> ___
> 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] tls@ietf117: saag report

[Sean Turner]

Hi! At the IETF 117 TLS session we discussed the following:

* ECH (draft-ietf-tls-esni and draft-ietf-tls-wkech): We learned about existing 
deployment experiments with Firefox, Chrome, and Cloudflare. Some issues are 
being investigated and more experiments are going to be done, but the 
experiments returned encouraging results. Based on these, the author team plans 
to move into a mode of either addressing or closing issues with a plan for a 
new version of the ECH I-D to be released sometime around IETF 118.  The 
ultimate goal is to get the ECH I-D to the IESG sometime in early 2024 (assumes 
everything goes smoothly).

* Abridged Certificates (draft-jackson-tls-cert-abridge): This is a new 
certificate compression scheme that looks very promising. The sense of the room 
was positive and the chairs will issue a WG call for adoption shortly.

* TLS 1.2 is Frozen (draft-rsalz-tls-tls12-frozen): The I-D is going to be 
split in two. The part that provides how to use any guidance into UTA. The part 
that stays will be the text (possibly short) that says TLS 1.2 is feature 
frozen.

* Update on post-quantum signatures (from NIST): NIST is running another round 
of their competition because there aren't any good, performant and small, 
signature algorithms yet.  Many of the algorithms have already fallen. We will 
see how the process ends.

* An AOB topic about Exported Authenticators: There is some interest from the 
HTTPbis WG in the possibility of clients just client certificate without being 
requested by server.  Will need security proofs.

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

Re: [TLS] tls@ietf117

[Sean Turner]

And another gentle reminder.

Cheers,
spt

> On Jul 11, 2023, at 10:42, Sean Turner  wrote:
> 
> Now that the submission deadline has passed … here’s a gentle reminder!
> 
> Cheers,
> spt
> 
>> On Jun 18, 2023, at 19:25, Sean Turner  wrote:
>> 
>> The TLS WG is planning to meet at IETF 117. A 2 hour slot has been 
>> requested, but not yet scheduled. The chairs would like to solicit input 
>> from the WG for agenda topics. Please send your agenda topics request and an 
>> estimate for how much time you will need to tls-cha...@ietf.org. Please note 
>> that we will prioritize existing WG items. Please also review the guidance 
>> for TLS WG presenters that can be found at [1].
>> 
>> Cheers,
>> Chris, Joe, and Sean
>> 
>> [1] https://github.com/tlswg/tlswg-wiki/blob/master/FAQ.md
> 

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

Re: [TLS] RFC 9345 on Delegated Credentials for TLS and DTLS

[Sean Turner]

Congrats to all who helped to get this done!

spt

> On Jul 13, 2023, at 18:29, rfc-edi...@rfc-editor.org wrote:
> 
> A new Request for Comments is now available in online RFC libraries.
> 
> 
>RFC 9345
> 
>Title:  Delegated Credentials for TLS and DTLS 
>Author: R. Barnes,
>S. Iyengar,
>N. Sullivan,
>E. Rescorla
>Status: Standards Track
>Stream: IETF
>Date:   July 2023
>Mailbox:r...@ipv.sx,
>sub...@fb.com,
>n...@cloudflare.com,
>e...@rtfm.com
>Pages:  17
>Updates/Obsoletes/SeeAlso:   None
> 
>I-D Tag:draft-ietf-tls-subcerts-15.txt
> 
>URL:https://www.rfc-editor.org/info/rfc9345
> 
>DOI:10.17487/RFC9345
> 
> The organizational separation between operators of TLS and DTLS
> endpoints and the certification authority can create limitations. 
> For example, the lifetime of certificates, how they may be used, and
> the algorithms they support are ultimately determined by the
> Certification Authority (CA).  This document describes a mechanism to
> overcome some of these limitations by enabling operators to delegate
> their own credentials for use in TLS and DTLS without breaking
> compatibility with peers that do not support this specification.
> 
> This document is a product of the Transport Layer Security Working Group of 
> the IETF.
> 
> This is now a Proposed Standard.
> 
> STANDARDS TRACK: This document specifies an Internet Standards Track
> protocol for the Internet community, and requests discussion and suggestions
> for improvements.  Please refer to the current edition of the Official
> Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
> standardization state and status of this protocol.  Distribution of this 
> memo is unlimited.
> 
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
>  https://www.ietf.org/mailman/listinfo/ietf-announce
>  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
> 
> For searching the RFC series, see https://www.rfc-editor.org/search
> For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
> 
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
> 
> 
> The RFC Editor Team
> Association Management Solutions, LLC
> 
> 
> ___
> IETF-Announce mailing list
> ietf-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce

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

Re: [TLS] WG Last Call for draft-ietf-tls-deprecate-obsolete-kex

[Sean Turner]

> On Jul 11, 2023, at 13:52, Salz, Rich  wrote:
> 
>> This email starts the working group last call for "Deprecating Obsolete Key 
>> Exchange Methods in TLS 1.2” I-D, located here:
> 
>> .  https://datatracker.ietf.org/doc/draft-ietf-tls-deprecate-obsolete-kex
> 
> Three minor issues and a question.
> 
> Consider saying once, early.in the document, that this does not address TLS 
> 1.0 and TLS 1.1 as they were already deprecated.

This appears in s2:

Note that TLS 1.0 and 1.1 are deprecated by [RFC8996]
and TLS 1.3 does not support FFDH [RFC8446].

You’re suggesting that this be moved to s1?

> Are the appendices normative?  I think so. That should be explicitly stated 
> in each appendix.

Maybe … if the the IANA considerations section stays as is they probably should 
be. But, see below.

> I would shuffle the appendices so that the order is B first (since it 
> contains NEW information not in the registry) and then A C D. The rationale 
> is that it puts all registry changes (mark as "not recommended" in one spot).
> 
> The question might be more appropriate for the TLS chairs.  About sync'ing 
> this with the registry changes draft [1].  That document adds a DISCOURAGED 
> value. Can we put this doc and [1] in the same cluster, so that the 
> "discourage" use (currently in appendix B) gets reflected into the registries 
> right away?
> 
> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/

This I-D doesn’t refer to -rfc8447bis so if we wanted to put them in the same 
cluster we’d need to get PaulW to add some kind of instruction for the RFC 
editor.  But, we could “fix” that by tweaking the IANA considerations to just 
provide IANA instructions to IANA for those cipher suites that we are changing 
in s5 and reference -rfc8447bis.  The thing is that some of the suites listed 
in Appendix C are already “N" so we need to be clearer about what IANA needs to 
do.  Sorting the IANA registry based on the Recommended column Y” and comparing 
it to what’s in Appendix C, the new changes are:

Y-> N

0xCC,0xAA   TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
0xCC,0xAD   TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256
0xC0,0xA7   TLS_DHE_PSK_WITH_AES_256_CCM
0xC0,0xA6   TLS_DHE_PSK_WITH_AES_128_CCM
0xC0,0x9F   TLS_DHE_RSA_WITH_AES_256_CCM
0xC0,0x9E   TLS_DHE_RSA_WITH_AES_128_CCM
0x00,0xAB   TLS_DHE_PSK_WITH_AES_256_GCM_SHA384
0x00,0xAA   TLS_DHE_PSK_WITH_AES_128_GCM_SHA256
0x00,0x9F   TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
0x00,0x9E   TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

N->D

All in Appendix B.

Did I get that right? 

If that’s the case then maybe make Appendix B normative (and resort the 
Appendices), list the Y->N changes above in s5, and leave the rest informative 
(since they’re already or will be N)?

And, we should probably change the name of the Appendices from “XXX Cipher 
Suites Deprecated by This Document” to “Deprecated XXX Cipher Suites” to not 
mislead readers that this document did all the deprecation.  But, I do like the 
idea of adding a reference to this document for all the registry entries listed 
in Appendices - kind of like a tombstone.

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

[TLS] WG Last Call for draft-ietf-tls-deprecate-obsolete-kex

[Sean Turner]

This email starts the working group last call for "Deprecating Obsolete Key 
Exchange Methods in TLS 1.2” I-D, located here:

https://datatracker.ietf.org/doc/draft-ietf-tls-deprecate-obsolete-kex/

The WG Last Call will end 25 July 2023 @ 2359 UTC.

Please review the I-D and submit issues and pull requests via the GitHub 
repository that can be found at:

https://github.com/tlswg/draft-deprecate-obsolete-kex

Alternatively, you can also send your comments to tls@ietf.org.

Thanks,
Chris, Joe, & Sean
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] tls@ietf117

[Sean Turner]

Now that the submission deadline has passed … here’s a gentle reminder!

Cheers,
spt

> On Jun 18, 2023, at 19:25, Sean Turner  wrote:
> 
> The TLS WG is planning to meet at IETF 117. A 2 hour slot has been requested, 
> but not yet scheduled. The chairs would like to solicit input from the WG for 
> agenda topics. Please send your agenda topics request and an estimate for how 
> much time you will need to tls-cha...@ietf.org. Please note that we will 
> prioritize existing WG items. Please also review the guidance for TLS WG 
> presenters that can be found at [1].
> 
> Cheers,
> Chris, Joe, and Sean
> 
> [1] https://github.com/tlswg/tlswg-wiki/blob/master/FAQ.md

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

[TLS] tls@ietf117

[Sean Turner]

The TLS WG is planning to meet at IETF 117. A 2 hour slot has been requested, 
but not yet scheduled. The chairs would like to solicit input from the WG for 
agenda topics. Please send your agenda topics request and an estimate for how 
much time you will need to tls-cha...@ietf.org. Please note that we will 
prioritize existing WG items. Please also review the guidance for TLS WG 
presenters that can be found at [1].

Cheers,
Chris, Joe, and Sean

[1] https://github.com/tlswg/tlswg-wiki/blob/master/FAQ.md
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Fwd: NomCom 2023 Call for Volunteers

[Sean Turner]

TLS participants: Please strongly consider volunteering for this years NOMCOM. 
It’s is not that much time and it is very important to the IETF to have good 
people on the NOMCOM. And as you see below, you will get to spend some more 
time with Martin.

Cheers,
spt

> Begin forwarded message:
> 
> From: NomCom Chair 2023 
> Subject: NomCom 2023 Call for Volunteers
> Date: June 5, 2023 at 19:50:08 EDT
> To: "IETF Announcement List" 
> Reply-To: nomcom-chair-2...@ietf.org
> 
> The IETF Nominating Committee (NomCom) appoints people to fill the open slots 
> on the IETF LLC, IETF Trust, the IAB, and the IESG.  Ten voting members for 
> the NomCom are selected from a pool of volunteers.  A large pool of 
> volunteers helps make the process work better.
> 
> CLICK HERE TO VOLUNTEER: https://datatracker.ietf.org/nomcom/volunteer
> 
> NomCom activity is expected to start in July and run through to November.  
> The goal is to do the bulk of the work at IETF 117 and 118, with supplemental 
> conference calls between those times.  Remote participation will be supported.
> 
> The NomCom activities involve collecting requirements from the community, 
> reviewing candidate responses, reviewing feedback from community members 
> about candidates, interviewing candidates, and nominating a slate of 
> candidates.
> 
> RFC 8713 details the NomCom process.  With the recent publication of RFC 
> 9389, this is the first year of new qualification criteria, after a few years 
> of trials.  People qualify for NomCom participation in one of three ways: 
> attendance at IETF meetings (online or virtual), service as a working group 
> chair or secretary, or publication of IETF RFCs.
> 
> https://datatracker.ietf.org/accounts/profile/ lists your eligibility, but 
> you can still volunteer even if that says "No".  You can also volunteer by 
> sending me an email.
> 
> Within the next week or two, I will add more details on the timeline and the 
> selection process.
> 
> Thank you!
> Martin Thomson
> nomcom-chair-2...@ietf.org
> 
> ___
> IETF-Announce mailing list
> ietf-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce

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

Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

[Sean Turner]

> 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 be resolved, one way or 
> another, before advancing out of the WG.

There were still notes in s5 and s6 to draw attention to cipher suite listing 
in light of I-D.ietf-tls-deprecate-obsolete-kex and I guess now John’s I-D too. 
 Joe and I will circle with those authors to make sure we have the appropriate 
coverage.

> Sec 7 adds a note that says the experts "will highly encourage registrants to 
> provide a link" while Sec 13 says experts "ensure the specification is 
> publicly available."  So is that SHOULD or MUST?  (And s/highly/strongly/ IMO)

I can get behind s/highly/strongly:
https://github.com/tlswg/rfc8447bis/pull/39

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, but we still wanted the DEs to make 
sure the structure is followed, i.e., "EXPORTER:” is included. So … in some 
respects I think of it as a SHOULD, but then that does clash with s13.

I guess the question is as DE, is the guidance going to lead to problems?

> A nit, this line appears multiple times:
>   Setting a "Recommended" column value to Y or D requires Standards
> There should probably be quotes around the letters Y and D, for consistency 
> with other text.

I hope I got ‘em all here:
https://github.com/tlswg/rfc8447bis/pull/38

Cheers,

> 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 yesterday's meeting, this email starts the working group 
>> last call for "The Transport Layer Security (TLS) Protocol Version 1.3" and 
>> "IANA Registry Updates for TLS and DTLS” I-Ds, located here:
>> 
>> - 
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis__;!!GjvTz_vk!Ulz2iHrqiHDTnXaSY0-d3Vo3dX-wtwR6OtahB_aLeEKhAfPj4rRfFY4jViJ3R9YUrgSyiMh7$
>>  
>> 
>>  
>> - 
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis__;!!GjvTz_vk!Ulz2iHrqiHDTnXaSY0-d3Vo3dX-wtwR6OtahB_aLeEKhAfPj4rRfFY4jViJ3R9YUrjrMdAm2$
>>  
>> 
>>  
>> 
>> The WG Last Call will end on April 18, 2023.
>> 
>> Please review the documents and submit issues or pull requests via the 
>> GitHub repositories, which can be found at:
>> 
>> - 
>> https://urldefense.com/v3/__https://github.com/tlswg/tls13-spec__;!!GjvTz_vk!Ulz2iHrqiHDTnXaSY0-d3Vo3dX-wtwR6OtahB_aLeEKhAfPj4rRfFY4jViJ3R9YUrj6Gs5p8$
>>  
>> 
>>  
>> - 
>> https://urldefense.com/v3/__https://github.com/tlswg/rfc8447bis__;!!GjvTz_vk!Ulz2iHrqiHDTnXaSY0-d3Vo3dX-wtwR6OtahB_aLeEKhAfPj4rRfFY4jViJ3R9YUrpamqVl6$
>>  
>> 
>>  
>> 
>> Alternatively, you can also send your comments to tls@ietf.org 
>> .
>> 
>> Thanks,
>> Chris
>> ___
>> TLS mailing list
>> TLS@ietf.org 
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!Ulz2iHrqiHDTnXaSY0-d3Vo3dX-wtwR6OtahB_aLeEKhAfPj4rRfFY4jViJ3R9YUrjkidxUX$
>>  
>> 
>>  
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!Ulz2iHrqiHDTnXaSY0-d3Vo3dX-wtwR6OtahB_aLeEKhAfPj4rRfFY4jViJ3R9YUrjkidxUX$
>  
> 
>  
> 
> 
> 

___
TLS mailing list
TLS@ietf.org

Re: [TLS] WG Adoption call for draft-sbn-tls-svcb-ech

[Sean Turner]

This WG adoption call has ended. There is consensus to adopt this I-D as a WG 
item.

Authors: Please submit a WG version when you get the chance.

Cheers,
spt

> On Mar 28, 2023, at 00: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 
> 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 indicate why.
> 
> Cheers,
> Chris, Joe, and Sean
> 
> [1] https://datatracker.ietf.org/doc/draft-sbn-tls-svcb-ech/

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

Re: [TLS] [Technical Errata Reported] RFC7465 (7476)

[Sean Turner]

I think we can safely delete this errata.

spt

> On Apr 28, 2023, at 08:01, RFC Errata System  
> wrote:
> 
> The following errata report has been submitted for RFC7465,
> "Prohibiting RC4 Cipher Suites".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7476
> 
> --
> Type: Technical
> Reported by: Rajeev Kumar Surroach 
> 
> Section: 7465
> 
> Original Text
> -
> 7465
> 
> Corrected Text
> --
> 7465
> 
> Notes
> -
> Solve the issue
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC7465 (draft-ietf-tls-prohibiting-rc4-01)
> --
> Title   : Prohibiting RC4 Cipher Suites
> Publication Date: February 2015
> Author(s)   : A. Popov
> Category: PROPOSED STANDARD
> Source  : Transport Layer Security
> Area: Security
> Stream  : IETF
> Verifying Party : IESG

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

Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

[Sean Turner]

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 yesterday's meeting, this email starts the working group 
> last call for "The Transport Layer Security (TLS) Protocol Version 1.3" and 
> "IANA Registry Updates for TLS and DTLS” I-Ds, located here:
> 
> - https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis
> - https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis
> 
> The WG Last Call will end on April 18, 2023.
> 
> Please review the documents and submit issues or pull requests via the GitHub 
> repositories, which can be found at:
> 
> - https://github.com/tlswg/tls13-spec
> - https://github.com/tlswg/rfc8447bis
> 
> Alternatively, you can also send your comments to tls@ietf.org.
> 
> Thanks,
> Chris
> ___
> 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] WG Adoption call for draft-sbn-tls-svcb-ech

[Sean Turner]

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 indicate why.

Cheers,
Chris, Joe, and Sean

[1] https://datatracker.ietf.org/doc/draft-sbn-tls-svcb-ech/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-04.txt

[Sean Turner]

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-changes-for-this-rfc

spt

> On Mar 27, 2023, at 19:15, Salz, Rich  
> wrote:
> 
> - 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
> https://www.ietf.org/mailman/listinfo/tls

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

Re: [TLS] How are we planning to deprecate TLS 1.2?

[Sean Turner]

just want to point of out that at least in the IETF that RFC 9325 [1] was 
recently published.

spt

[1] https://datatracker.ietf.org/doc/rfc9325/

> On Mar 3, 2023, at 13:40, Eric Rescorla  wrote:
> 
> Nimrod,
> 
> Thanks for bringing this up. I don't think we really have had much of a 
> discussion.
> 
> I *do* think we should be thinking about deprecating TLS 1.2 at some point, 
> not so much because
> it is bad (though of course we believe TLS 1.3 is better)  but because it's 
> better to just have
> one thing that we work on and not have to reason about/work on TLS 1.2. And 
> of course, we really
> don't want to have to do major work on TLS 1.2, e.g. for Post-Quantum.
> 
> I don't have strong feelings about the timeline.
> 
> -Ekr
> 
> 
> 
> 
> On Fri, Mar 3, 2023 at 10:18 AM Nimrod Aviram  wrote:
> Hi Everyone,
> 
> We’ve recently had a brief side discussion around the issue of letting 
> vendors (or operators) know when something is expected to be deprecated:
> https://mailarchive.ietf.org/arch/msg/tls/Djk35kp5P5Z1WfmN8_OJj_eYRLo/
> 
> Currently, there is no expected deprecation timeline for any specific 
> primitive or protocol version. As one example, it seems like we plan to 
> deprecate RSA key exchange in TLS 1.2 soon (as part of 
> draft-ietf-tls-deprecate-obsolete-kex). However, so far we did not explicitly 
> communicate this to vendors, and it seems like vendors either have to follow 
> the mailing list and deduce the likelihood of an upcoming deprecation, or 
> face a deprecation RFC at some random point in time (from their point of 
> view).
> 
> And whatever the specifics of RSA key exchange deprecation, this will likely 
> not be the last time we deprecate something :-)
> 
> Specifically, we will have to decide when/if to deprecate version 1.2 of TLS 
> within, say, the next 20 years.
> 
> One possible solution is to publish “expected deprecation timeline” documents:
> Let’s fix some timeframe which “is enough for everyone to upgrade at least 
> once” (famous last words, I know). I think of this timeframe as 3 or 5 years, 
> but it could as well be 8 or 10 years, and this solution would still be 
> viable; let’s denote the number of years as X. So, an “expected deprecation 
> timeline” document could specify that within X years, implementations MUST 
> support TLS 1.3, and within 2X years, implementations MUST NOT support TLS 
> 1.2. (If X=8 years, then we specify that by 2031 implementations MUST support 
> TLS 1.3, and by 2039 implementations MUST NOT support TLS 1.2.) This would 
> clarify the WG’s expectations to vendors, and would save the WG valuable time 
> discussing whether enough implementations in the field support the new 
> protocol/primitive.
> 
> Is there interest here in such a solution?
> 
> Credit where it’s due: This is based on an idea I heard from Dan Bernstein - 
> thanks Dan.
> 
> Best,
> Nimrod
> 
> ___
> 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] tls@ietf116

[Sean Turner]

Hi! We have tentatively been scheduled for Wednesday at 1300-1500 (Tokyo Time):
https://datatracker.ietf.org/meeting/116/agenda
The final agenda will be posted tomorrow.

I am forwarding this in case you missed the original call for agenda items for 
the TLS WG’s session. Thanks to those who have already sent in their requests.

spt

> On Feb 8, 2023, at 13:24, Sean Turner  wrote:
> 
> The TLS WG will meet at IETF 116. A 2 hour slot has been requested, but not 
> yet scheduled. The chairs would like to solicit input from the WG for agenda 
> topics. Please send your agenda topics request and an estimate for how much 
> time you will need to tls-cha...@ietf.org. Please note that we will 
> prioritize existing WG items. Please also review the guidance for TLS WG 
> presenters that can be found at [1].
> 
> Cheers,
> Chris, Joe, and Sean
> 
> [1] https://github.com/tlswg/tlswg-wiki/blob/master/FAQ.md

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

[TLS] tls@ietf116

[Sean Turner]

The TLS WG will meet at IETF 116. A 2 hour slot has been requested, but not yet 
scheduled. The chairs would like to solicit input from the WG for agenda 
topics. Please send your agenda topics request and an estimate for how much 
time you will need to tls-cha...@ietf.org. Please note that we will prioritize 
existing WG items. Please also review the guidance for TLS WG presenters that 
can be found at [1].

Cheers,
Chris, Joe, and Sean

[1] https://github.com/tlswg/tlswg-wiki/blob/master/FAQ.md
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] consensus call: deprecate all FFDHE cipher suites

[Sean Turner]

During the tls@IETF 115 session topic covering 
draft-ietd-tls-deprecate-obsolete-kex, the sense of the room was that there was 
support to deprecate all FFDHE cipher suites including well-known groups. This 
message starts the process to judge whether there is consensus to deprecate all 
FFDHE cipher suites including those well-known groups. Please indicate whether 
you do or do not support deprecation of FFDHE cipher suites by 2359UTC on 6 
January 2023. If do not support deprecation, please indicate why.

NOTE: We had an earlier consensus call on this topic when adopting 
draft-ietd-tls-deprecate-obsolete-kex, but the results were inconclusive. If 
necessary, we will start consensus calls on other issues in separate threads.

Cheers,
Chris, Joe, and Sean
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] tls@ietf115: minutes

[Sean Turner]

Draft of minutes are posted:
https://datatracker.ietf.org/meeting/115/materials/minutes-115-tls-202211100930-00
Please submit any changes by Friday (12/2).

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

Re: [TLS] draft-ietf-tls-batch-signing

[Sean Turner]

Please note that this I-D has been abandoned.

spt

> On Nov 10, 2022, at 06:29, Benson Muite  wrote:
> 
> The above draft has expired.  However, if there is still interest in it, the 
> EdDSA specification will need to be updated based on findings in [1] and [2]. 
> An erratum to [3] has been filed [4]. Libsodium seems to offer best checks 
> for batch verification. Currently testing other libraries that offer support 
> for EdDSA.
> 
> 1) Chalkias, Garillot, and Nikolaenko "Taming the many EdDSAs" 
> https://eprint.iacr.org/2020/1244
> 
> 2) Brendel, Cremers, Jackson, and Zhao "The Provable Security of Ed25519: 
> Theory and Practice" https://eprint.iacr.org/2020/823
> 
> 3) https://datatracker.ietf.org/doc/html/rfc8032
> 
> 4) https://www.rfc-editor.org/errata_search.php?rfc=8032_status=0
> 
> ___
> 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] Fwd: IETF WG state changed for draft-ietf-tls-batch-signing

[Sean Turner]

FYI

> Begin forwarded message:
> 
> From: IETF Secretariat 
> Subject: IETF WG state changed for draft-ietf-tls-batch-signing
> Date: November 10, 2022 at 06:07:24 EST
> To: , 
> Resent-From: 
> Resent-To: j...@salowey.net, c...@heapingbits.net, sean+i...@sn3rd.com
> 
> 
> The IETF WG state of draft-ietf-tls-batch-signing has been changed to "Dead
> WG Document" from "WG Document" by Sean Turner:
> 
> https://datatracker.ietf.org/doc/draft-ietf-tls-batch-signing/
> 
> 

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

[TLS] Call for adoption of draft-thomson-tls-keylogfile

[Sean Turner]

Hi!

At TLS@IETF115, the sense of the room was that there was WG support to adopt 
draft-thomson-tls-keylogfile [1].  This message is to judge consensus on 
whether the WG should adopt draft-thomson-tls-keylogfile. Please indicate 
whether you do or do not support adoption of this I-D by 2359UTC on 12 December 
2022. If do not support adoption, please indicate why.

Cheers,
Chris, Joe, and Sean

[1] https://datatracker.ietf.org/doc/draft-thomson-tls-keylogfile/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] tls@ietf115: Agenda Topics

[Sean Turner]

Gentle reminder.

Cheers,
spt

> On Oct 12, 2022, at 03:44, Sean Turner  wrote:
> 
> The TLS WG will meet at IETF 115. A 2 hour slot that has been scheduled for 
> Thursday, 10 November 2022, 0930-1130 UTC [0]. The chairs would like to 
> solicit input from the WG for agenda topics. Please send your agenda topics 
> request and an estimate for how much time you will need to 
> tls-cha...@ietf.org. Please note that we will prioritize existing WG items. 
> Please also review the guidance for TLS WG presenters that can be found at 
> [1].
> 
> Cheers,
> Chris, Joe, and Sean
> 
> [0] https://datatracker.ietf.org/meeting/115/agenda-neue
> [1] https://github.com/tlswg/tlswg-wiki/blob/master/FAQ.md

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

[TLS] tls@ietf115: Agenda Topics

[Sean Turner]

The TLS WG will meet at IETF 115. A 2 hour slot that has been scheduled for 
Thursday, 10 November 2022, 0930-1130 UTC [0]. The chairs would like to solicit 
input from the WG for agenda topics. Please send your agenda topics request and 
an estimate for how much time you will need to tls-cha...@ietf.org. Please note 
that we will prioritize existing WG items. Please also review the guidance for 
TLS WG presenters that can be found at [1].

Cheers,
Chris, Joe, and Sean

[0] https://datatracker.ietf.org/meeting/115/agenda-neue
[1] https://github.com/tlswg/tlswg-wiki/blob/master/FAQ.md
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Delegated Credentials Test Vectors

[Sean Turner]

Thanks for pulling this together.

spt

> On Aug 17, 2022, at 14:33, Jonathan Hoyland  
> wrote:
> 
> Hi All,
> 
> I've been putting together a generator for test vectors for DCs.
> This code is available as a PR at 
> https://github.com/tlswg/tls-subcerts/pull/119
> The vectors generated are for:
> Leaf public key signature algorithm - DC public key signature algorithm
>   •  ECDSA (P-384) - EdDSA (Ed25519)
>   •  ECDSA (P-384) - RSAPSS (2048 + SHA512)
>   •  EdDSA (Ed25519) - ECDSA (P-256 + SHA256)
>   •  EdDSA (Ed25519) - RSAPSS (2048 + SHA256)
>   •  RSAPSS (2048 + SHA256) - ECDSA (P-256 + SHA256)
>   •  RSA (2048 + SHA256) - EdDSA (Ed25519)
> Where possible the test vectors are checked against multiple implementations 
> to ensure they actually work.
> 
> Any feedback is welcome.
> 
> Regards,
> 
> Jonathan
> ___
> 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