[TLS] Question to draft-ietf-tls-esni 6.2.1.

[风扇 滑翔翼]

Due to the existence of GREASE ECH, for requests made by clients that have 
implemented ECH but do not have a suitable ECH Config, the server always fails 
to decrypt and can choose to send retry config.
Why not treat this an opportunity to upgrade Plaintext Hello to ECH(if 
certificate verification succeed), but require the client to ignore it? Will 
this lead to a possible vulnerability?
At present, the initial distribution of ECH Config can only be done through 
DNS. Can't it uses methods similar to mentioned earlier to remind clients of 
potential upgrades?
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: AD review draft-ietf-tls-rfc8447bis-10

[Sean Turner]

Okay PRs are ready to merge:
https://github.com/tlswg/rfc8447bis/pull/61
https://github.com/tlswg/rfc8447bis/pull/62

And I found some typos:
https://github.com/tlswg/rfc8447bis/pull/63

Will merge Sunday (when submission window re-opens) and spin a new version, 
unless you say otherwise.

spt

> On Mar 10, 2025, at 8:10 PM, Paul Wouters  wrote:
> 
> 
> On Fri, Mar 7, 2025 at 12:52 PM Sean Turner  > wrote:
>> 
>> 
>>> On Mar 6, 2025, at 9:33 PM, Paul Wouters 
>>> mailto:40aiven...@dmarc.ietf.org>> 
>>> wrote:
>>> 
>>> AD review of draft-ietf-tls-rfc8447bis-10
>>> 
>>> I have some comments and small change requests. Do let me know if I got it 
>>> wrong.
>> 
>> Will do.  BTW - one choice for you below.
>> 
>>> Section 3
>>> 
>>> Setting a value to "Y" or "D" in the "Recommended" column requires
>>> IETF Standards Action [RFC8126]. Any state transition to or from a
>>> "Y" or "D" value requires IESG Approval.
>>> 
>>> Isn't this easier written as:
>>> 
>>> Setting a value to "Y" or "D" in the "Recommended" column requires
>>> IETF Standards Action [RFC8126] or IESG Approval.
>>> 
>>> This appears in a number of sections in the document.
>> 
>> This sentence structure appears in 10 places. The same types of sentences 
>> appear in 5 places in RFC 8447, but there is it "Y" and "N" not “Y" an "D". 
>> This I-D updates all of those 5 in RFC 8447, so sure we can make this change.
> 
> Great.
>>> Section 4 TLS ExtensionType Values
>>> 
>>> Values with the first byte in the range 0-254 (decimal) are
>>> assigned via Specification Required [RFC8126].  Values with the
>>> first byte 255 (decimal) are reserved for Private Use [RFC8126].
>>> 
>>> I'd rather not let IANA figure out decimal network order byte math. Or
>>> require everyone to do that math when checking the registry. Why not:
>>> 
>>> Values in the range 0-65279 are assigned via Specification Required
>>> [RFC8126]. Values in the range 65280-65535 are reserved for Private
>>> Use [RFC8126].
>>> 
>>> Also, this is not true for:
>>> 
>>> 65281   renegotiation_info
>>> 
>>> which is clearly not usable for Private Use. Maybe it makes sense to say:
>>> 
>>> Values in the range 0-65279 are assigned via Specification Required
>>> [RFC8126]. Values in the range 65280-65295 are Reserved. Values in
>>> the range 65296-65535 are reserved for Private Use [RFC8126].
>>> 
>>> This then leaves 0xff00-0xff0f for whatever the reason for 65281 was to be
>>> able to happen a few more times, and keep the private range valid without
>>> strange exceptions.
>> 
>> I don’t think that has actually been much of a problem because it has been 
>> specified this way since RFC 4346.  So, we got two options:
>> 
>> 1) leave it alone
>> 2) drop the offending text because we are not changing anything WRT to the 
>> ranges in those 3 sections. If we do that I would suggest:
>> 
>> OLD:
>> 
>> *  Change the registration procedure to:
>> 
>> Values with the first byte in the range 0-254 (decimal) are assigned
>> via Specification Required [RFC8126].  Values with the first byte
>> 255 (decimal) are reserved for Private Use [RFC8126].  Setting a
>> "Recommended" column value to "Y" or "D" requires Standards Action 
>> [RFC8126].
>> Any state transition to or from a "Y" or "D" value requires
>> IESG Approval.
>> 
>> NEW:
>> 
>>  *  Adjust the registration procedure related to setting the “Recommended” 
>> column as follows:
>> 
>>   Setting a value to "Y" or "D" in the "Recommended" column requires
>>   IETF Standards Action [RFC8126] or IESG Approval.
>> 
>> Which do you prefer?
> 
> I prefer 2)
>>> Section 6 TLS Supported Groups
>>> 
>>> * Replace the registry range table note column for the 0-255,
>>>   512-65535 range with "Unallocated".
>>> 
>>> This makes no sense. That current line with its note reads:
>>> 
>>> 0-255, 512-65535Specification Required  Elliptic curve 
>>> groups
>>> 
>>> I understand that the note should remove the text "Elliptic curve groups",
>>> but it makes no sense to add "Unallocated" because the range does have
>>> allocations in it. Maybe just instruct IANA to remove the note "Elliptic
>>> curve groups" ?
>> 
>> I can get behind that.
> 
> Okay
>>> Section 11 TLS ClientCertificateTypes registry
>>> 
>>> The registry name is not "TLS ClientCertificateTypes" registry, but
>>> "TLS ClientCertificateTypes Identifiers" registry.
>> 
>> You are correct!
> 
> Good :)
> 
> Paul

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

[TLS] Re: AD review draft-ietf-tls-rfc8447bis-10

[Sean Turner]

> On Mar 7, 2025, at 12:51 PM, Sean Turner  wrote:
> 
>> Section 5  TLS Cipher Suites Registry
>> 
>> This section contains some reasoning why it is Discouraging things. The 
>> current
>> IANA registry also contains such reasoning on the form of notes, but this 
>> section
>> does not add to the notes. So now this inforation is splintered between RFC 
>> and
>> Registry. I think the easiest fix is to add these few reasons specified here
>> as Note: to the IANA registry.
>> 
>> 
>> Note that this registry states:
>> 
>> When this registry is modified, the YANG module
>> "iana-tls-cipher-suite-algs" [iana-tls-cipher-suite-algs] must
>> be updated as defined in [RFC9645].
>> 
>> Has this happened or is it scheduled? If so who is the contact I can follow 
>> up with?
> 
> The YANG module is empty right now so I assume it needs to be scheduled. I 
> assume IANA will run this as part of their IANA Actions process.  Confirming 
> with Kent now.

For the list, I checked with Kent (author of RFC 9645) and he confirmed that 
IANA will does this as part of their process.

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

[TLS] Re: draft-ietf-tls-trust-anchor-ids-00

[Luke T2]

Hey David,
 
Thanks for the draft! I had some thoughts about how Relying Parties build their 
list of Trust Anchor IDs to send to the Authenticating Parties. In the draft 
currently there is different behaviour by the Relying Party depending on 
whether it is a retry connection or not.
When a relying party receives the tls-trust-anchors in the DNS Service 
Parameter they compute the intersection of the received trust anchors with 
their configured trust anchors, then they use that information to determine 
their trust_anchors list - in this case relying parties should offer multiple 
options.  In the other case, when retrying a connection, relying parties should 
choose a single Trust Anchor ID from the EncryptedExtensions to send.
Could you talk me through your reasoning for the different mechanisms?  I would 
suggest using the same mechanism for calculating the trust_anchors on retry as 
when using the DNS Service Parameter, so the client has consistent behaviour 
and then the authenticating party has the final choice of the certificate chain 
to serve.
Otherwise, the issue described in Section 5.3 of the draft could occur on retry 
with the client picking a trust anchor which includes a certificate in the 
chain it doesn’t support the signature for.

Cheers,
Luke

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

[TLS] Re: FW: I-D Action: draft-kwiatkowski-tls-ecdhe-mlkem-03.txt

[D. J. Bernstein]

Peter C writes:
> In ML-KEM, Bob derives b deterministically from m and H(ek).
> If Bob tried to reuse b with a different public key, then the
> re-encryption check would fail during decapsulation.

That check doesn't affect processing of valid ciphertexts, so it often
won't be tested, so some implementations will get it wrong (even if they
aren't actively suppressing code that doesn't seem necessary), exactly
the same way that we keep finding code that fails to check signatures.

Again, I'm not saying any of this is safe. I'm just pointing out some of
the possibilities that can be triggered by (1) implementors pursuing
speed and (2) code having bugs.

---D. J. Bernstein

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

[TLS] Re: [Wimse] Public side meetings on identity crisis in attested TLS for Confidential Computing

[John Kemp]

Hi Usama,

The title of this email is quite alarming to me ("identity crisis") and 
yet I'm not able to understand what the actual issue is other than 
someone wishing to replace public-key authentication with "attestation".


Personally, I wouldn't do that.

Although TLS PKI authentication involves a kind of attestation itself (I 
have to trust a CA installed in my trust store, and possibly some 
intermediate CAs too, that have blessed the authenticated key) and only 
good faith and good practices prevent a private key being copied all 
over the place and violating the attestation, I agree with anyone is 
saying that providing attested measurements of a TEE is not the same 
thing as attesting a key within a PKI. They are complementary.


Where is the "identity crisis" exactly?

Cheers, John

El 03/06/25 a las 04:14, Muhammad Usama Sardar escribió:

(Note for TLS WG only: announcing with approval of chairs [0])

Hi all,

*TL;DR*: There will be a couple of /public side meetings/ on attested 
TLS. For organizational purposes (e.g., to ask for a bigger room 
[current room capacity: 20]), if you are interested in presenting or 
attending /in-person/, please drop me a short email. Since some of the 
attested TLS team members will be remote (and in Europe), we have 
selected a time slot suitable for them. But if you are really interested 
and this time does not work for you, please let me know and we will seek 
alternatives. Also see call for presentations below.


Date: 17th March (Monday) and 19th March (Wednesday)

Time: Both meetings at 15:00 - 17:00

Room: Meeting Room 3

Relevant for:

  * *RATS*: Design space to inject remote attestation into transport
protocols; and related security considerations
  * *TLS*: Extension of TLS with remote attestation
  * *WIMSE*: Identity crisis in confidential computing

No prior knowledge is assumed but knowledge of TLS will be helpful.

The current agenda is based on joint works with Arto Niemi, Hannes 
Tschofenig, Thomas Fossati, Simon Frost, Ned Smith, Mariam Moustafa, 
Tuomas Aura, Yaron Sheffer, Ionut Mihalcea and Jean-Marie Jacquet.


*Draft agenda for first side meeting*:

The first side meeting aims to bring everyone on the same page for 
discussion of the open questions in the second side meeting. We plan to 
cover the following topics (subject to changes dependent on the interest 
and background of attendees):


  * Network Security (TLS: RFC8446bis [1])
  o Without client authentication
  o With client authentication
  * Endpoint Security (Remote Attestation (RA): including RFC9334 and
RFC9683)
  o Disambiguate attestation and authentication
  * Attested TLS (RA || TLS) including [4] and [5]
  o Design Options
  + Pre-handshake attestation
  + Intra-handshake attestation
  + Post-handshake attestation
  o Protocols
  + Server as Attester
  + Client as Attester

*Draft agenda and call for presentations for second side meeting*:

  * Technical details of impersonation attacks [6]
  o Attack1 in [6]
  o Attack2 in [6]
  * Proposed solution (Recommendation [6])
  * Discussion of open questions [6]
  * Other relevant open questions

We aim to scope the side meetings to Confidential Computing and welcome 
presentations around the theme of attacks mentioned here [6] within this 
scope. If interested, please send me your topic and time estimate until 
10th March.


Additional readings:

  * Attested TLS [7]
  * Attestation in Arm CCA and Intel TDX [8]


We look forward to your perspectives and discussions during the side 
meetings!



Kind regards,

Usama


[0] https://mailarchive.ietf.org/arch/msg/tls/RHyArzvEJHimDi49b2bboPAUW_c/

[1] https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis/

[2] https://datatracker.ietf.org/doc/rfc9334/

[3] https://datatracker.ietf.org/doc/rfc9683/

[4] https://datatracker.ietf.org/doc/draft-fossati-tls-attestation/

[5] https://datatracker.ietf.org/doc/draft-fossati-tls-exported-attestation/

[6] https://mailarchive.ietf.org/arch/msg/tls/Jx_yPoYWMIKaqXmPsytKZBDq23o/

[7] https://ieeexplore.ieee.org/document/10752524

[8] https://ieeexplore.ieee.org/document/10373038




--
Independent Security Architect
t: +1.413.645.4169
e: stable.pseudo...@gmail.com

https://www.linkedin.com/in/johnk-am9obmsk/
https://github.com/frumioj

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

[TLS] Re: FW: I-D Action: draft-kwiatkowski-tls-ecdhe-mlkem-03.txt

[D. J. Bernstein]

Viktor Dukhovni writes:
> I'd expect such designs to be quite unlikely

That's different from "not possible". :-)

I agree with your API comments: one can't build this by simply calling
the FIPS 203 standard keygen-enc-dec functions for ML-KEM. However, if
that were the end of the story then we wouldn't see things like


https://csrc.nist.gov/csrc/media/Presentations/2024/how-multi-recipient-kems-help-deploy-pqc/images-media/prest-how-multi-recipient-kems-pqc2024.pdf

or some people saying that they're storing ML-KEM private keys as seeds.
It also wouldn't be surprising to see reuse of what I labeled as G (even
when A is changing), which in turn would increase the speed incentives
to reuse b. Again, I'm not saying any of this is safe.

---D. J. Bernstein

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

[TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

[Sean Turner]

Just a quick reminder that this adoption call is still ongoing.

spt

> On Feb 28, 2025, at 1:56 PM, Sean Turner  wrote:
> 
> In response to the WG adoption call, Dan Bernstein pointed out some potential 
> IPR (see [0]), but no IPR disclosure has been made in accordance with BCP 79. 
>  Additional information is provided here; see [1].
> 
> BCP 79 makes this important point:
> 
>  (b) The IETF, following normal processes, can decide to use
>technology for which IPR disclosures have been made if it decides
>that such a use is warranted.
> 
> WG members can take this information into account during this adoption call 
> to determine if we should adopt these drafts. If this information changes a 
> view that you have already expressed during this WG adoption call, please 
> post a follow-up message. We also extend the WG adoption call to 14 March 
> 2025.
> 
> Reminder:  This call for adoption has nothing to do with picking the 
> mandatory-to-implement cipher suites in TLS.
> 
> 
> Cheers,
> Joe and Sean
> 
> [0] https://mailarchive.ietf.org/arch/msg/tls/mt4_p95NZv8duZIJvJPdZV90-ZU/
> [1] https://mailarchive.ietf.org/arch/msg/spasm/GKFhHfBeCgf8hQQvhUcyOJ6M-kI/
> 
>> On Feb 26, 2025, at 1:26 PM, Sean Turner  wrote:
>> 
>> At IETF 121, the WG discussed “Post-Quantum Hybrid ECDHE-MLKEM Key Agreement 
>> for TLSv1.3”; see [0] and [1]. We also had some discussion in an information 
>> gathering thread; see [2]. We would like to now determine whether there is 
>> 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 WG adoption call will close at 2359 UTC on 12 March 2025.
>> 
>> One special note: this adoption call has nothing to do with picking the 
>> mandatory-to-implement cipher suites in TLS.
>> 
>> Thanks,
>> Sean & Joe
>> 
>> [0] Link to I-D: 
>> https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-mlkem/
>> [1] Link to slides: 
>> https://datatracker.ietf.org/meeting/121/materials/slides-121-tls-post-quantum-hybrid-ecdhe-mlkem-key-agreement-for-tlsv13-00
>> [2] Link to information gather thread: 
>> https://mailarchive.ietf.org/arch/msg/tls/yGZV5dBTcxHJhG-JtfaP6beTd68/
> 

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

[TLS] Re: ML-KEM IANA and draft-connolly-tls-mlkem-key-agreement codepoint and inconsistencies

[Tim Hudson]

On Fri, Mar 7, 2025 at 7:01 PM Kris Kwiatkowski  wrote:

> May I know if you have a plan for FIPS certificaton for PQC after release?
>

Absolutely - OpenSSL-3.5 will be heading into a fresh FIPS140-3 validation
in April once the release is final - and that will include the PQC
algorithms that have been added.
Our testing for ML-KEM, ML-DSA and SLH-DSA uses ACVP published test data as
the basis along with some interesting scripts to get the test data into a
format our test suites support.

There is also a multi-vendor KMIP PQC interop running this week that has
vendors using OpenSSL-3.5 and Bouncy Castle Java 1.81 (beta) and that is
exercising the same ACVP tests via KMIP between KMIP clients and KMIP
servers - but that is in the context of the day job rather than OpenSSL -
see
https://groups.oasis-open.org/discussion/kmip-tc-interop-process-2025-for-pqcpdf-uploaded
as a starting point for information on that activity. That testing also
covers X25519MLKEM768 for those vendors which have that capability enabled.
ML-DSA certificates are not within the scope of that test activity.

There is also on-going discussion between vendors about a PKCS#11 v3.2 PQC
focused interop but timing and participants for that haven't yet been
figured out.

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

[TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

[Watson Ladd]

Adopt

On Mon, Mar 10, 2025 at 7:59 AM Sean Turner  wrote:
>
> Just a quick reminder that this adoption call is still ongoing.
>
> spt
>
> > On Feb 28, 2025, at 1:56 PM, Sean Turner  wrote:
> >
> > In response to the WG adoption call, Dan Bernstein pointed out some 
> > potential IPR (see [0]), but no IPR disclosure has been made in accordance 
> > with BCP 79.  Additional information is provided here; see [1].
> >
> > BCP 79 makes this important point:
> >
> >  (b) The IETF, following normal processes, can decide to use
> >technology for which IPR disclosures have been made if it decides
> >that such a use is warranted.
> >
> > WG members can take this information into account during this adoption call 
> > to determine if we should adopt these drafts. If this information changes a 
> > view that you have already expressed during this WG adoption call, please 
> > post a follow-up message. We also extend the WG adoption call to 14 March 
> > 2025.
> >
> > Reminder:  This call for adoption has nothing to do with picking the 
> > mandatory-to-implement cipher suites in TLS.
> >
> >
> > Cheers,
> > Joe and Sean
> >
> > [0] https://mailarchive.ietf.org/arch/msg/tls/mt4_p95NZv8duZIJvJPdZV90-ZU/
> > [1] https://mailarchive.ietf.org/arch/msg/spasm/GKFhHfBeCgf8hQQvhUcyOJ6M-kI/
> >
> >> On Feb 26, 2025, at 1:26 PM, Sean Turner  wrote:
> >>
> >> At IETF 121, the WG discussed “Post-Quantum Hybrid ECDHE-MLKEM Key 
> >> Agreement for TLSv1.3”; see [0] and [1]. We also had some discussion in an 
> >> information gathering thread; see [2]. We would like to now determine 
> >> whether there is 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 WG adoption call will close at 2359 UTC on 
> >> 12 March 2025.
> >>
> >> One special note: this adoption call has nothing to do with picking the 
> >> mandatory-to-implement cipher suites in TLS.
> >>
> >> Thanks,
> >> Sean & Joe
> >>
> >> [0] Link to I-D: 
> >> https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-mlkem/
> >> [1] Link to slides: 
> >> https://datatracker.ietf.org/meeting/121/materials/slides-121-tls-post-quantum-hybrid-ecdhe-mlkem-key-agreement-for-tlsv13-00
> >> [2] Link to information gather thread: 
> >> https://mailarchive.ietf.org/arch/msg/tls/yGZV5dBTcxHJhG-JtfaP6beTd68/
> >
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org



-- 
Astra mortemque praestare gradatim

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

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

[internet-drafts]

Internet-Draft draft-ietf-tls-rfc8447bis-11.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-11.txt
   Pages:   17
   Dates:   2025-03-11

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 and adds a
   "Comments" column to all active 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 HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-tls-rfc8447bis-11

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

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