[TLS] Re: Question to draft-ietf-tls-esni 6.2.1.
You might be interested in the draft being discussed here (I believe this is on the agenda for next week as well): https://mailarchive.ietf.org/arch/msg/tls/dT5e5F1yWtFbs0dpESsWO-Cg0AM/ There's also this draft, which could be used to probe servers for ECH support: https://datatracker.ietf.org/doc/html/draft-ietf-tls-wkech-05 Best, Chris P. On Tue, Mar 11, 2025 at 3:30 AM 风扇 滑翔翼 wrote: > 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 mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: draft-ietf-tls-trust-anchor-ids-00
Hi Luke! Thanks for the thoughts! I don't remember if there was a particular reason originally, probably just an artifact of them being in separate sections. :-) Reusing it makes sense, although there are some differences here: Regarding mismatching signatures and whatnot, the original thinking with the EncryptedExtensions retry was that the server would filter the list down based on all its other selection criteria. If the server knows the client doesn't support ECDSA, there is no point in saying you have a trust anchor that has only signed an ECDSA key. The server already has all that information available by way of the ClientHello. But it looks like we half-forgot to write that. (Half because there's one sentence that only makes sense if the text were there, but the text itself is missing.) I filed a bug to track this: https://github.com/tlswg/tls-trust-anchor-ids/issues/97 Assuming the WG ends up sticking with that design, that should avoid the sigalg issues described in Section 5.3, but not things being out of sync if you got routed to a different server instance. In that case, yeah, I could see the client wanting to offer a couple of them a la Section 5.3. (Though there are other ways to solve this, including the client trying a couple times or an in-handshake retry. This is basically the same problem space as in the ECH retry, except that we can offer multiple and ECH cannot.) If we go with the client offering multiple options, there is an added input to the procedure: did the client like the *particular certificate* that the server already presented? If not, the client may want to specifically exclude that trust anchor in the retry and use this mechanism as a way to iterate over what the server has. This can be useful in corner cases when the client imposes custom policies like SCTNotAfter[0] or name-constraining a trust anchor, e.g. as part of a partial distrust. While those are broadly invisible, you can hit a corner case if *all* of the following happen: - The client has put some trust anchor under a constraint - The server has some certificate A from the trust anchor that breaks the constraint (and is thus not useful to the client) - But certificate A may be useful to some *other* client (e.g. an older one), which is why the server still wants to keep getting certs from the trust anchor for now. (I'm very interested in helping server operators de-risk configuration changes as PKIs evolve, and being able to retain your previous cert profile while transitioning in your new one helps do that.) - The server has some certificate B from some other trust anchor that would satisfy the client - For some reason, when offered both, the server picked A instead of B In that case, the client might say "well, you have A and B available, but you gave me A and I see now that that is unacceptable, let me try again asking just for B". The retry mechanism then lets you repair mishaps in these kinds of complicated corner cases that can arise, without the complexity of encoding the ad-hoc policies into the protocol. Of course, the cost is that we repair mishaps with an expensive retry, but as long as these are exceptional cases, I think that's fine. To that end, the client here might want to tweak the Section 5.3 behavior where, if it sees two trust anchors in DNS, one of which it has constrained and another which it has not, it may wish to only ask for the unconstrained one to direct the server to pick the one that's more likely to be acceptable. I.e. only request constrained trust anchors as a last resort. That should avoid the retry most of the time. The server adjusting its preference order to put B over A would also avoid it. (This allowance wasn't actually an original design goal, rather a happy accident that fell out of inverted selection order. We then also got feedback from another client that this sort of thing was useful for something else they were doing, though I don't know the specific details and wouldn't want to speak on their behalf.) Anyway, clearly the draft should give some more guidance here. To go full circle, more guidance means more reason to share the underlying text sections so we don't have to write similar guidance twice. I'll file a bug referencing this thread to keep track of all this. :-) David [0] https://dadrian.io/blog/posts/sct-not-after/ On Tue, Mar 11, 2025 at 11:10 AM Luke T2 wrote: > 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
[TLS] Publication has been requested for draft-ietf-tls-hybrid-design-12
Joseph Salowey has requested publication of draft-ietf-tls-hybrid-design-12 as Informational on behalf of the TLS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/ ___ 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
On Sat, 1 Mar 2025 at 00:22, Stephen Farrell wrote: > > > Hiya, > > On 28/02/2025 18:56, 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. > > While I don't think the lack of an IPR declaration is fatal > here, I do think it'd be great if that uncertainty could be > reduced. I think I saw that Russ tried to reach out to one > of the possible patent holders to ask if they'd be willing > to make a declaration. I've no idea where that's at, but I'd > encourage the TLS chairs and SEC ADs to see if they can help > get that to happen as reducing uncertainty would be good and > if we can't, then this topic will just keep cropping up and > Dan is not the only person I've heard express concerns in > this regard. > I agree with Dr Stephen on this one. It would help if we can get declarations from patent holders early. For example, OpenSSH implemented DSA as there was less risk of patents: " The second major variety of SSH is the SSH 2 protocol. SSH 2 was invented to avoid the patent issues regarding RSA (patent issues which no longer apply, since the patent has expired), to fix the CRC data integrity problem that SSH1 has, and for a number of other technical reasons. By requiring only the asymmetric DSA and DH algorithms, protocol 2 avoids all patents. " If there is any risk of a patent, can we look at a backup choice for ML-KEM in TLS, especially for implementers who are very patent averse ? Should I start a new thread ? > Cheers, > S. > > PS: I do realise we can't force someone to make an IPR > declaration. > > ___ > 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] Last Call: (IANA Registry Updates for TLS and DTLS) to Proposed Standard
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'IANA Registry Updates for TLS and DTLS' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2025-04-09. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/ No IPR declarations have been submitted directly on this I-D. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Question to draft-ietf-tls-esni 6.2.1.
Hiya, On 12/03/2025 23:25, Christopher Patton wrote: There's also this draft, which could be used to probe servers for ECH support:https://datatracker.ietf.org/doc/html/draft-ietf-tls-wkech-05 Just on the status of the wkech draft - we're playing about with (re-)implementing that using python now that we have a PoC ECH integration with cpython [1], so there's nothing to report in terms of the draft content this time, but should be in the not too distant future. If the WG want to make other use(s) of the mechanism as part of addressing this question, that'd be fine. Cheers, S. [1] https://github.com/defo-project/ech-dev-utils/blob/main/howtos/cpython.md OpenPGP_signature.asc Description: OpenPGP digital signature ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
