I do like the dnssec-chain-extension.
I think the server should stick to one chain, from the root to itself,
so it does not have to deal with variable chain blobs per client.
That will allow server code to stick to something like hourly
regenerating the blob for use with all clients.
I do stron
On Wed, 22 Jul 2015, Viktor Dukhovni wrote:
I think the server should stick to one chain, from the root to itself,
so it does not have to deal with variable chain blobs per client.
That will allow server code to stick to something like hourly
regenerating the blob for use with all clients.
Fr
them,
signed by log providers), so we could in the future incorporate SCT RRs
in the chain.
That draft really is pretty immature and at this point it's not
clear whether and how it's going to progress. Paul Wouters can
speak for himself about where he thinks the draft needs to go
Th
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
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 wo
> On Oct 11, 2015, at 09:46, Watson Ladd wrote:
>
>
> I would suggest piggybacking on the PSK mode, using the key Kerberos
> provides at both ends as the PSK key. This would address all of these
> issues in TLS 1.3
>
Which would also match how Kerberos is used in IKE/IPsec
Paul
___
On Fri, 16 Oct 2015, Rick van Rein wrote:
3) Similar to OpenPGP: Negotiate cert-type
There is a cert-type for X.509 and for OpenPGP; add one for Kerberos Tickets.
PRO: Good integration with TLS: Tickets are transported in the
ClientCertificate, and an Authenticator is the ClientVerify. DH is
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 n
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
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 the
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 fol
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 Connoll
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 has
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 n
On Thu, 22 Feb 2018, Shumon Huque wrote:
On Wed, Feb 21, 2018 at 2:48 PM, Paul Wouters 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 understanding that the format of
On Thu, 1 Mar 2018, Shumon Huque wrote:
I do not know if the draft authors and/or WG have an appetite to do the much
more major change suggested by Viktor (i.e in-protocol pinning TTL commitment
and requiring subsequent denial of existence proof if DANE is removed).
I think it is worth discus
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 the expiry date on the
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 qu
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
b/draft-ietf-tls-d
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 publicat
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 denial
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 WebP
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 al
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 techn
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 verifyi
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 pe
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 lo
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. I'd
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 pin
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, th
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 sen
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. From
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
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., I
> 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:
https://tools.ietf.org/html/draft-a
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
https://github.com/tlswg/dnssec-chain-ex
On Mon, 25 Jun 2018, Joseph Salowey wrote:
There has been some discussion with a small group of folks on github -
https://github.com/tlswg/dnssec-chain-extension/pull/19.
I want to make sure there is consensus in the working group to take on the
pinning work and see if there is consensus for
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
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 this
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
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 int
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 _sho
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 apparen
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 extension,
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 protec
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
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
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 i
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 mandato
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
On Mon, 5 Nov 2018, Salz, Rich wrote:
Is it fair to describe the draft as enabling a trust model based on DNSSEC,
rather than the default X.509 hierarchy and trust store which is implemented by
default?
The draft tries to enable a trust model based on DNSSEC, but due to
missing pinning, fail
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
player
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
__
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.
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 offli
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
i
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 non
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 ro
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 rea
AD review draft-ietf-tls-esni-22
Thanks for this document. It is a very interesting technology and I want
to thank everyone who worked on this. As expected, I found no major issues
in it :-) I do have a few minor questions and nits below:
Section 1
that allows clients to encrypt their C
Hi,
I have done my AD review of draft-ietf-tls-svcb-ech. Some history was well
summarized by the Document
Shepherd:
Please note that the text in this I-D was initially developed in the DNSOP WG,
went through IETF LC, and IESG review. The result of the IESG review was to take
the text in this I-D
On Sun, Oct 6, 2024 at 12:17 PM Eric Rescorla wrote:
> This is explicitly prohibited rfc9460 as it would provide linkability.
>>> See rfc9460 section 12: "Clients MUST ensure that their DNS cache is
>>> partitioned for each local network, or flushed on network changes, to
>>> prevent a local adve
On Mon, Oct 7, 2024 at 9:26 AM Eric Rescorla wrote:
>
>
> On Mon, Oct 7, 2024 at 6:01 AM Paul Wouters wrote:
>
>>
>> On Sun, Oct 6, 2024 at 12:17 PM Eric Rescorla wrote:
>>
>>> This is explicitly prohibited rfc9460 as it would provide linkability.
>
On Thu, 17 Oct 2024, Sean Turner wrote:
On Oct 17, 2024, at 15:29, Paul Wouters
wrote:
RFC8996 seems to be a broken reference ? Might be a tooling issue but it is
already broken in the xml file on the datatracker.
I’ll check on this.
https://bib.ietf.org/public/rfc/bibxml/reference.RFC
On Wed, 16 Oct 2024, Martin Thomson wrote:
A retry fallback happens with the public name. The server that offers ECH
lists a public name. If the ECH config (for key A) turns out to be unusable,
the server offers a regular handshake with that public name, where it offers
retry_configs.
So,
I have reviewed draft-ietf-tls-rfc8446bis-11.
I think it is becoming commonplace to list errata incorporated into the
document as informative references (eg [Err6151]) and then list in the
Abstract or Introduction which errata the bis document resolves. Please
consider doing this.
I have just gon
t; >>
> >> ------
> >> Status: Held for Document Update
> >> Type: Editorial
> >>
> >> Reported by: Ben Smyth
> >> Date Reported: 2020-04-29
> >> Held by: Paul Wouters (IESG)
> >>
> >> Secti
[kind of off-topic here, and also speaking as just an individual]
On Fri, Oct 4, 2024 at 3:28 PM Erik Nygren wrote:
>
> On Fri, Oct 4, 2024 at 3:20 PM Stephen Farrell
> wrote:
>
>>
>> On 10/4/24 19:30, Paul Wouters wrote:
>> > Which makes me wonder if it m
ed value.
>
> If you think this analysis is wrong, please explain the attack
> which is prevented by client-side DNSSEC validation, remembering
> that it can only be done reliably when the client already is
> using a TRR.
>
> -Ekr
>
>
> [0] DNSSEC validation at the recursive
t; --
> *From:* Eric Rescorla
> *Sent:* Friday, October 4, 2024 8:07 AM
> *To:* Salz, Rich
> *Cc:* Arnaud Taddei ; Ben Schwartz <
> bem...@meta.com>; Paul Vixie ; Paul Wouters <
> paul.wout...@aiven.io>; draft-ietf-tls-svcb-ech.auth...@ietf.org
trusted DNS servers.
As for the RFC1034 reference, Warren suggested to maybe use: "DNS (see
RFC1034, BCP219)" (where BCP219 is the latest DNS Terminology doc).
Paul
--
> *From:* Salz, Rich
> *Sent:* Monday, September 30, 2024 1:29 PM
> *To:* Ben S
[drifting off topic]
> On Oct 2, 2024, at 00:10, Paul Vixie
> wrote:
>
>
>
>
> i would not. much of the world now relies upon inauthentic dns responses for
> defense against bad actors.
that's a limitation of RPZ. Years ago I proposed to move the Answer to the
Authority section so you c
On Fri, 11 Oct 2024, Eric Rescorla wrote:
Thanks you for your review. I have created a PR that addresses a number of
these.
https://github.com/tlswg/draft-ietf-tls-esni/pull/632
That looks fine, other than the accidental typo introduction I pointed out.
[ deleted agreements, thanks for prop
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.
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"
74 matches
Mail list logo
