On Wed, Aug 24, 2022, at 08:30, Stephen Farrell wrote:
> Currently chromium and firefox disagree on whether ECH is
> setup correctly for one of my test pages
I'm fairly confident that that is a bug on the Firefox end. The person looking
into it has been on leave, but as far as I can tell the DNS
On Wed, Aug 31, 2022, at 18:39, Brian Dickson wrote:
> One additional suggested addition to the end of section 3.1 is:
>>If DNS responses are cryptographically protected, and at least
>>one HTTPS AliasMode record has been received successfully,
>>clients MAY apply Section 9.5 (HSTS equi
On Thu, Sep 8, 2022, at 13:29, Brian Dickson wrote:
> If no AliasMode record was processed, then $QNAME would be the origin
> name PLUS the prefix(es) of type attrleaf ( underscore thingies). Those
> won't be legitimate A/ owner names (and shouldn't exist), and if a
> client did that it w
On Fri, Feb 24, 2023, at 05:03, Christopher Wood wrote:
> +1 to this plan. Once the ECH content is removed from this draft, the
> authors of draft-ietf-tls-esni will work to incorporate it there as
> necessary.
Warren's proposed plan is good.
I'm less sure about the various options for documen
On Tue, Mar 14, 2023, at 09:44, Mark Nottingham wrote:
> I do wonder whether 'alt' is appropriate -- 'alternative' begs the
> question of 'alternative to what?' and the answer is a technical detail
> that most Internet users are blissfully unaware of. It seems to me that
> it'd be better to choo
On Sat, Aug 3, 2019, at 01:04, Tim Wicinski wrote:
> This starts a Call for Adoption for draft-sah-resolver-information
I think that I might have said this before, but I don't think that asking an
HTTP server about a DNS server is the right solution. If this is information
about the operation o
On Sun, Aug 4, 2019, at 00:37, Paul Hoffman wrote:
> > I think that I might have said this before, but I don't think that asking
> > an HTTP server about a DNS server is the right solution.
>
> It is not "the" right solution, but it is one of them. That's why there
> is also a DNS-based soluti
> Abstract:
>This document reserves a string (ALT) to be used as a TLD label in
>non-DNS contexts. It also provides advice and guidance to developers
>developing alternative namespaces.
In discussion, the alternative name .arc was proposed as short for "alternative
resolution context
There's an interesting (web-only) effort looking at a similar problem:
https://github.com/krgovind/first-party-sets There, the goal is to establish
commonality for the purposes of sharing state (and fate).
A great counter-example in that case is the relationship between github.com and
github.i
On Fri, Feb 14, 2020, at 05:56, Paul Vixie wrote:
> something of this form will likely be created, in order to support quic, a
> new
> udp based transport protocol which is expected to be used by http/3.
Not wanting to distract from Paul's request for consideration of the UDP
options draft. Ho
On Wed, Mar 4, 2020, at 06:11, Brotman, Alex wrote:
> https://datatracker.ietf.org/doc/draft-brotman-rdbd/
As I think I mentioned before, there is similar work going on at higher layers
of the stack. See https://github.com/krgovind/first-party-sets
That work acknowledges a number of things, mos
On Wed, Jun 17, 2020, at 04:49, Dmitry Belyavsky wrote:
> I don't think there are good or bad time periods to adopt nation-wide
> crypto profiles. For me, the difference between the GOST profile and
> hypothetical Korean or German profile is close to zero, and if anybody
> brings such a profile
On Fri, Jun 19, 2020, at 01:30, Paul Hoffman wrote:
> It might be better, and faster, for this WG to adopt a one-paragraph
> draft that makes the DS registry "RFC required", like the other
> DNSSEC-related registries.
I think you mean "Specification Required". RFC required has the same net
eff
rough draft.
My initial thinking was that this was general enough that TLS is the right
venue, but I can also see reasons for having some discussion here.
- Original message -
From: Martin Thomson
To: t...@ietf.org
Subject: [TLS] Authenticating incompatible protocols
Date: Tuesday, July
As requested (I'm not engaged here enough to understand the terms of
engagement, so my apologies for using an interaction form I'm accustomed to),
moving discussion from https://github.com/MikeBishop/dns-alt-svc/issues/287 to
here:
The SVCB draft basically mandates a fallback to A/. I thin
On Sat, Jan 16, 2021, at 06:01, Ben Schwartz wrote:
> FWIW, I think this is really an editorial question.
...
> https://github.com/MikeBishop/dns-alt-svc/pull/288
...
> https://github.com/MikeBishop/dns-alt-svc/pull/289
Neither of these work for me. Both do the same thing in different ways. B
On Wed, Jan 20, 2021, at 02:09, Ben Schwartz wrote:
> I think #288 is quite "specific" about what happens in that case.
> (Whether it's "sensible" is a separate question.)
Sorry, I was talking mostly about #299, which has the problem I identified.
The problem with #288 is that it doesn't say th
On Wed, Jan 20, 2021, at 09:17, Ben Schwartz wrote:
> As I noted in that discussion, the client generally doesn't know in
> advance that they aren't needed.
I am asserting that the client very much knows. Indeed, it has to know. If we
define a new protocol that relies on SVCB and that protoc
> * Assuming Cloudflare has the only current large-scale deployment of
> HTTPS records.
>
> On Tue, Jan 19, 2021 at 10:00 PM Ben Schwartz wrote:
> >
> >
> > On Tue, Jan 19, 2021 at 7:40 PM Martin Thomson wrote:
> >> On Wed, Jan 20, 2021, at 09:17, Ben
On Thu, May 20, 2021, at 10:35, Brian Dickson wrote:
> I was under the impression that the extensibility is for the SVCB type,
> and not strictly needed for HTTPS.
It is absolutely needed for HTTPS.
I also want to add to what Tommy (P) said about deployment. We've deployed the
current wire for
On Thu, May 20, 2021, at 11:08, Paul Wouters wrote:
> This discussion should be around reasonable and secure wire and
> presentation formats, not about "but we already deployed this".
> It should surely be taken into account if changing at this point
> gives enough benefits, but the idea of changin
On Thu, May 20, 2021, at 11:32, Brian Dickson wrote:
> Is it one of those things that are "Well, we think we might need
> something", or is it "We already know something we need"?
The former is definitely a factor. Though you might reasonably say that
defining another HTTPSv2 codepoint is feasi
Hey,
I've just opened https://github.com/MikeBishop/dns-alt-svc/issues/326
It's a bit long and I won't repeat it here, but I don't think that the current
state of the document is good with respect to its handling of ECH and
alternative services.
___
On Wed, Mar 2, 2022, at 14:18, Benjamin Kaduk via Datatracker wrote:
> This (mostly implicit) requirement is a potential barrier for adoption of
> the HTTPS RRtype, and while the precondition is very often going to be
> satisfied, I wanted to get a sense for whether we should make the
> requirement
I favour #3 over #2 on the basis that you can't reasonably put the "how to
convert" text into a registry.
On Mon, Mar 21, 2022, at 20:19, Ben Schwartz wrote:
> Hi DNSOP,
>
> The latest draft of the SVCB specification says [1]
>
>> Entries in this registry are subject to a First Come First Serve
On Wed, Mar 23, 2022, at 02:45, Murray S. Kucherawy wrote:
> On Mon, Mar 21, 2022 at 2:20 AM Ben Schwartz
> wrote:
>> [...] any individual I-D is considered a qualified specification as soon as
>> it is uploaded to the Datatracker.
>
> Do you have a reference that asserts this? An I-D that i
I agree with Tommy.
Selecting an expert who is able to recognize when wider review might help is a
far lower bar than the one Ray suggests might be necessary.
On Wed, Mar 23, 2022, at 05:29, Tommy Pauly wrote:
> If this space is not extensible from non-IETF RFCs, we’ll have missed
> the mark. T
This is intended to do what? Indicate where the response came from?
Why does the client care? I assume that it doesn't apply to requests,
or that would get into draft-bellis-dnsop-xpf territory.
BTW, you really need to drop UDP from the media type name now.
application/dns-udpwireformat;original
If I understand your response (not sure that I do), that seems pretty
academic and not at all persuasive. For instance, if a client cared
about testing TCP capabilities, it can always do its own resolution.
On Tue, Apr 3, 2018 at 7:44 PM, Davey Song wrote:
>
>
> On 3 April 2018 at 15:3
On Tue, Apr 3, 2018 at 11:27 PM, Paul Hoffman wrote:
> Martin: Are you saying that you want DOH to remove the optional parameter
> from the application/dns-udpwireformat registration? If so, what do you
> propose for the DNSOP WG?
Right now, abandon draft-ietf-dnsop-dns-wireformat-http. But I'
On Thu, Apr 5, 2018 at 2:42 AM, Paul Vixie wrote:
> that would be low fidelity. i need to run clients whose internet experience
> will not be influenced by middleboxes.
So don't include the middlebox in your communications. It's all the
rage nowadays.
___
+1 to this.
And maybe there is an outcome that doesn't need this parameter. I
probably misunderstood some of the expectations people have for the
parameter. With the benefit of time and sleep, it's possible that I
now understand the disconnect.
My model of content-type - and by extension its pa
On Sat, Apr 7, 2018 at 9:29 AM, Paul Vixie wrote:
> my original design added an http header, which was seen as even worse.
> someone suggested adding to the content-type, and i went along with it even
> though there is no difference in actual type of actual content.
A header field isn't all bad.
Thanks for starting the discussion Shane.
On 8 August 2016 at 23:41, Shane Kerr wrote:
> My own feeling is that this should be
> enough; apparently the recommendation to require TLS was made in the
> HTTP/2 working group and rejected, so I am not sure that we need to
> re-visit the entire discuss
On 3 November 2016 at 14:55, Daniel Migault wrote:
> The version to be reviewed is
> https://tools.ietf.org/html/draft-ietf-curdle-dnskey-eddsa-01
Does this use Ed25519 or Ed25519ctx? It describes a context string,
which Ed25519 throws away.
___
DNSOP
On 4 November 2016 at 09:11, Salz, Rich wrote:
> I think the issue about signature contexts first, and mainly, came up with
> TLS which generates a variety of private key material based on shared secret
> info, and the concern that those different keys could be used for
> cross-protocol attac
36 matches
Mail list logo
