[TLS] TLS chair update: Deirdre Connolly replacing Christopher Wood

Hi everyone, At the IETF we try to change chairs regularly for a variety of reasons. We like to encourage new participants to gain chairing experience alongside more experienced chairs. This also prevents ossification of WGs :) Christopher Wood has stepped down as TLS WG chair and Deirdre

Re: [TLS] [Editorial Errata Reported] RFC5054 (7538)

Thanks Chris, I've checked the errata and it is correct. I've marked it as Verified. Paul On Tue, Oct 10, 2023 at 8:11 PM Chris Smiley wrote: > > H Paul, > > We are unable to verify this erratum that the submitter marked as > editorial. > Please note that we have changed the “Type” of the

Re: [TLS] Question regarding RFC 8446

On Mon, 7 Nov 2022, Eric Rescorla wrote: Subject: Re: [TLS] Question regarding RFC 8446 Hi David, This question seems a bit out of scope for TLS, which is kind of indifferent to the transport interaction. Perhaps it might make sense to be in UTA, though unfortunately, RFC 7525-bis is in

Re: [TLS] (bonus) AD review draft-ietf-tls-subcerts

On Wed, May 11, 2022 at 1:08 PM Nick Sullivan wrote: > Hi Paul, > > Thank you for the review. I've put up a PR to address your points: > > https://github.com/tlswg/tls-subcerts/compare/nick/wouters-review-may22?expand=1 > > Comments inline. > Thanks for the changes and explanations. Looks good

[TLS] (bonus) AD review draft-ietf-tls-subcerts

As this document already saw an AD review by Ben Kaduk, I will not further hold up this document. Ben's write up can be found at: https://mailarchive.ietf.org/arch/msg/tls/qa908s0dMNxbUOZhnUel0qEVBSg/ Please treat the below as you would treat any other comments. Test vectors available but still

Re: [TLS] Alternative ESNI?

On Fri, 14 Dec 2018, Eric Rescorla wrote: However, in a large number of cases (e.g., an attacker on your local network, there are non-DNSSEC ways of obtaining this property, such as using DoH. Data origin authenticity is not the same as transport security. DoH offers no guarantee that the

Re: [TLS] ESNIKeys over complex

On Wed, 21 Nov 2018, Stephen Farrell wrote: We currently permit >1 RR, but actually I suspect that it would be better to try to restrict this. Not sure we can and I suspect that'd raise DNS-folks' hackles, but maybe I'm wrong. I think the SOA record is the only exception allowed (and there

[TLS] Thanks to Benjamin Kaduk

I wanted to thank Ben for the outreach he did in the last six months on the tls dnssec chain extension. It has been a difficult issue and I do wish the outcome was different. But during this time Ben put a lot of effort in trying to get the issues clarified and resolved both on the list of

Re: [TLS] some thoughts on dnssec-chain-extension, pinning, and broader semantics

On Wed, 7 Nov 2018, Tim Wicinski wrote: My question would be "what will the HTTP community do if they find this whole process unwieldy and long"? Answer  They will come up with a solution that does nothing with DANE.  They dont need to do anything to not have DANE. They already not have it.

Re: [TLS] some thoughts on dnssec-chain-extension, pinning, and broader semantics

On Tue, 6 Nov 2018, Benjamin Kaduk wrote: I think I'm confused about what you mean by "the downgrade-resistance that DNSSEC gives automatically". You cannot filter DNSSEC without the target being aware of being filtered (where filtering == downgrading) Paul

Re: [TLS] some thoughts on dnssec-chain-extension, pinning, and broader semantics

On Mon, 5 Nov 2018, Benjamin Kaduk wrote: The draft tries to enable a trust model based on DNSSEC, but due to missing pinning, fails to deliver that. A better way is saying the draft enables a trust model that restricts the webpki, addressing the problems of too many unrestricted root CA

Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps

On Tue, 16 Oct 2018, Daniel Kahn Gillmor wrote: That said, it sounds like negotiating the details of how to do this pinning is the main blocker, and i'm sick of this proposal being blocked (because i want it for "greenfield" implementations last year). Imagine how sick I will be when I try to

[TLS] TLS interim meeting notes

My rough notes of the meeting. All mistakes are mine, please speak up to the list if I got something wrong 2018-10-14 TLS interim meeting problem statement viktor: authors seemed focus on dprive but not scoped as such. Scope in document is DANE PKI. dprive can make extension

Re: [TLS] TLS interim meeting material

On Fri, 14 Sep 2018, Eric Rescorla wrote: DNSSEC lookups either return the truth or explicitly *FAIL*, they don't just return "neutral" results. In theory perhaps, but as a practical matter, no browser client, at least, can do DNSSEC hard fail, because the rate of organic DNSSEC

Re: [TLS] TLS interim meeting material

On Wed, 12 Sep 2018, Richard Barnes wrote: DNS records have caching semantics.  Those are only relevant for DNS resolution.  This is the TLS WG, not the DNS. You are resolving a TLSA record via a TLS transport. A zone owner sent a TLSA record in a TLS handshake.  This document says nothing

Re: [TLS] TLS interim meeting material

On Wed, 12 Sep 2018, Richard Barnes wrote: Speaking as one of the attendees, I do not agree with that conclusion. What came to light in that meeting is that the assertive cases of DANE require that the certificate That is not what came to light. What came to light was that the assertive use

[TLS] TLS interim meeting material

Hi, We have made available what we believe is a good starting point for further discussion regarding tls-dnssec-chain draft. While I thought we had reached some additional consensus in a side meeting at IETF 102 that every use case was per definition restrictive, and that thus downgrade

Re: [TLS] TLS DANE chain, detailed response to concerns raised in the room on Monday

On Wed, 18 Jul 2018, Eric Rescorla wrote: detailed response to concerns raised in the room on Monday On Tue, Jul 17, 2018 at 7:30 PM, Viktor Dukhovni wrote:         c. Testing is not a good fit at this layer, all that's            pinned is the ability to deliver the

Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations

On Wed, 4 Jul 2018, Eric Rescorla wrote: > > > Do we have a count of major implementors who say they will do so? > > > > Well, what is a "major implementation"? > > Well, we could start with "what implementations are going to do this"? [postfix and openssl

Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations

On Wed, 4 Jul 2018, Eric Rescorla wrote: In any case, as Martin Thomson says, we have a perfectly good extension mechanism which can be used to add pinning later without creating any placeholder here. The IETF should not publish security protocols that are trivially downgraded. The work

Re: [TLS] Encrypted SNI

On Tue, 3 Jul 2018, Eric Rescorla wrote: but in this particular case, can't enterprise just strip ESNI records from DNS? Not if endnodes within the enterprise also use DNSSEC. Unless you want the enterprise to run authoritative fake DNSSEC for the entire world. It also requires installing

Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations

On Tue, 3 Jul 2018, Allison Mankin wrote: 2.  Do you support the reserved bytes in the revision for a future pinning mechanism? ​Reserving the bytes without a mechanism is not a good idea, so no.  I think the method for modifications or another approach is something to be worked on in future

Re: [TLS] DNS-based Encrypted SNI

On Mon, 2 Jul 2018, Eric Rescorla wrote: It is strongly recommended not to use TXT records. Why not use a new RRTYPE? Everything these days knows how to serve unknown record types (see RFC 3597). The only possibly exception is provisioning tools of small players, but

Re: [TLS] DNS-based Encrypted SNI

On Mon, 2 Jul 2018, Eric Rescorla wrote:   https://tools.ietf.org/html/draft-rescorla-tls-esni-00 This is at a pretty early stage, so comments, questions, defect reports welcome. This structure is placed in the RRData section of a TXT record as a base64-encoded string. If

Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations

On Mon, 4 Jun 2018, Benjamin Kaduk wrote: Hi Ben, I've taken a stab at putting together some security considerations text for draft-ietf-tls-dnssec-chain-extension that reflects my understanding of the current state of affairs. It's in a pull request at

Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

> On May 17, 2018, at 19:44, Tim Hollebeek wrote: > > Making things more complicated with no obvious benefit just makes things > more complicated. > > I oppose adding two bytes for some nebulous future purpose. The consequence of this opinion would be this:

[TLS] Redirecting draft-ietf-tls-dnssec-chain-extension discussion back to the TLS list

On Tue, 15 May 2018, Eric Rescorla wrote: [ On advise of Eric, replaced the large CC: list with the TLS WG list ] I think I've been pretty clear about my position, but in case it's not clear: - I'm not sure pinning is a great idea for the reasons I've already mentioned   in the thread (i.e.,

Re: [TLS] Precluding bilateral opt-in for downgrade protection.

On Sat, 28 Apr 2018, Shumon Huque wrote: I wish I could be confident that such a specification would be allowed to move forward.  My fear is that the same visceral opposition to DANE and DNSSEC would play out, and so I may as well try to get past these now. I would like

Re: [TLS] Precluding bilateral opt-in for downgrade protection.

On Sat, 28 Apr 2018, Shumon Huque wrote: [ not going to repeat my technical arguments here, just going to comment on process ] First, there is no agreement that your reason for doing pinning, i.e. that DANE needs downgrade resistance against PKIX attacks is even valid. This is incorrect.

Re: [TLS] Draft updates: tls-dnssec-chain

On Sat, 28 Apr 2018, Shumon Huque wrote:    TLS servers that do not have a signed TLSA record MAY instead return    a DNSSEC chain that provides authenticated denial of existence.  This    specification does not require TLS servers to provide such a denial    of existence chain, The second

Re: [TLS] Proposed text for dnsssec chain extension draft

On Wed, 25 Apr 2018, Eric Rescorla wrote: The conventional reason to reserve this kind of field is that you need to leave space for an extension in some PDU, because it's hard to add later. But that's not true here (or in TLS in general) because we already have an extension mechanism (indeed,

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

On Wed, 18 Apr 2018, Joseph Salowey wrote: This is a combined response of Viktor, Nico and Paul. Concerns have been raised about the trade-offs associated with pinning and I do not think we currently have consensus to add pinning.  While I think it may be possible to come to consensus on

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

On Mon, 16 Apr 2018, Viktor Dukhovni wrote: * We might want to say that if the TTL is zero then the clients MUST NOT pin and must clear any pin. And we might do this in spite of not describing any pinning semantics -- explicitly leaving pinning semantics to a future document. Exactly.

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

On Thu, 12 Apr 2018, Richard Barnes wrote: The question Ben was asking, though, is whether the impact of that process mistake is serious enough to merit pulling back the doc from the RFC editor. That can only be answered after the consensus call. I don't think anyone is really objecting as

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

On Wed, 11 Apr 2018, Benjamin Kaduk wrote: I don't really agree with that characterization. To state my understanding, as responsible AD, of the status of this document: this document is in the RFC Editor's queue being processed. That was a process mistake. 1) ekr filed a DISCUSS 2) other

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

On Tue, 10 Apr 2018, Willem Toorop wrote: I just want to clarify one misconception in Willem's statement. See my previous emails to thist list for my full arguments on this issue. The chain extension already contains verification of Denial Of Existence proofs, because that is needed for

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

On Wed, 4 Apr 2018, Eric Rescorla wrote: The motivation for opportunistically using this is to be able to incrementally deploy DANE for HTTPS (and browsers).  Without that it won't get deployed at all for HTTPS. I don't see how this is responsive to the concern that this

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

On Thu, 5 Apr 2018, Richard Barnes wrote: And just to be clear, by "downgrade attack", you mean "normal PKI authentication that we rely on today".  There's nothing in here that degrades security You mean other then LetsEncrypt destroying the ecosystem and leading to a "one key to rule them

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

On Wed, 4 Apr 2018, Eric Rescorla wrote: 1. Assertive: To avoid having to engage with the WebPKI (e.g., because it's a pain). This rationale was stronger back before Let's Encrypt, but I suppose some people may still feel that way. 2. Restrictive: To protect yourself from compromise of the

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

On Wed, 4 Apr 2018, Eric Rescorla wrote: HPKP had a TTL and yet as a practical matter, people found it very problematic. And, of course, if you're concerned with hijacking attacks, the hijacker will just advertise a very long TTL. By publising DANE records with either a TLSA record or a

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

On Wed, 4 Apr 2018, Joseph Salowey wrote: This is a consensus call on how to progress this document.  Please answer the following questions: 1) Do you support publication of the document as is, leaving these two issues to potentially be addressed in follow-up work? I do NOT support

[TLS] proposed text for draft-ietf-tls-dnssec-chain-extension-06

I think the below change would address my issue, without stepping on the things people brought up today (other then suggesting, not mandating, to send proof of non-existence when halting TLSA support in the zone) Paul diff --git a/draft-ietf-tls-dnssec-chain-extension-07.xml

Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)

On Mon, 5 Mar 2018, Willem Toorop wrote: No Paul, the division in sections is irrelevant for a verifier. The only bit of information in a DNS message that is used by a verifier is the question. From the question, validation starts and the relevant records are followed and verified. But the

Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)

On Mon, 5 Mar 2018, Viktor Dukhovni wrote: On Mar 5, 2018, at 4:32 AM, Willem Toorop wrote: Therefore, any long-term caching of a destination's support for the extension should require server opt-in, and must have a maximum duration. How do you (all) feel about using

Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)

On Thu, 22 Feb 2018, Shumon Huque wrote: On Wed, Feb 21, 2018 at 2:48 PM, Paul Wouters <p...@nohats.ca> wrote: On Wed, 21 Feb 2018, Shumon Huque wrote: Okay, got it. For people that have already implemented this, I think there has been an implicit underst

Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)

On Wed, 21 Feb 2018, Shumon Huque wrote: Okay, got it. For people that have already implemented this, I think there has been an implicit understanding that the format of the chain data is a sequence of concatenated wire format RRs exactly as they appear in a DNS message section Note, I would

Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)

On Thu, 8 Feb 2018, Viktor Dukhovni wrote: For clients that do reject PKIX success based on DANE failure, and cache obtained TLSA records, it might have been good to recommend refreshing the TLSA records while the cached data is still valid (say the smaller of some refresh time or 50% of TTL

Re: [TLS] [Technical Errata Reported] RFC7250 (5013)

On Wed, 10 May 2017, Sean Turner wrote: I would definitively re-categorize this “editorial”; there’s no 2119-changes proposed and there’s no bits on the wire changes. And, I’d either reject this one because technically the existing text is correct (i.e., they are two extensions) and this

Re: [TLS] Call for WG adoption of draft-shore-tls-dnssec-chain-extension

On Mon, 25 Apr 2016, Sean Turner wrote: draft-shore-tls-dnssec-chain-extension was originally discussed at IETF 93 [0], and the authors have been biding their time while the WG thrashed out TLS1.3s' issues. At IETF 95, they presented again [1], but this time the chairs took a sense of the

Re: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)TLS

On Mon, 24 Aug 2015, Eric Rescorla wrote: TLS 1.3 encrypts both the client's and server's certificates already. The server's certificate is secure only against passive attack. Not having read the TLS 1.3 draft, in IKE parties can send a hash of the CAs they trust, so unless you receive a hash

Re: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)TLS

On Tue, 25 Aug 2015, Viktor Dukhovni wrote: Not having read the TLS 1.3 draft, in IKE parties can send a hash of the CAs they trust, so unless you receive a hash of a known CA to you, you can withold your own certificate from being sent. Is a similar mechanism not planned for TLS 1.3? This