Martin Hoffmann wrote:
>
> Downgrade seems to be an issue with all proposals.
The tradeoffs seem to revolve around how much you leak before you work out
whether you can use strict DoT, and how much added latency that costs.
If you are talking to a nameserver via its canonical name, then asking
Tony Finch wrote:
>
> I think signalling in the hostname has to be a hint rather than an
> assertion, since it's vulnerable to a downgrade attack because delegation
> NS records are unsigned (as Robert pointed out).
Downgrade seems to be an issue with all proposals. To solve them,
there may
Warren Kumari wrote:
>
> If the NS records / labels were _ta.a.iana-servers.net and _
> ta.b.iana-servers.net, that could be used as a positive signal that the
> resolver (or if the underscore freaks people out,
> dns-o-tls.a.iana-servers.net) is listening on 853 and that an inability
> to
Warren Kumari wrote:
> I'd also like to point out another option -- I threw up a little when first
> suggesting it, but it may be worth considering again (and please feel free
> to point me at the list if it already was).
> An opportunistic solution is vulnerable to intentional (or accidental)
>
On Mon, Sep 10, 2018 at 10:48 AM Tony Finch wrote:
> In the most general terms, when upgrading a protocol from cleartext to
> TLS, there are a couple of questions the client has to answer:
>
> 1. Does this server support TLS?
> 2. How can I authenticate it?
>
> And there are a couple of
Am 13.09.18 um 14:14 schrieb Willem Toorop:
> An alternative for TLSA glue could be a label in the NS name indicating
> DoT support perhaps? It's not pretty, but at least it would work right now.
Hello,
yes, a special authoritative server name was also the mechanism, DJB choose to
publish
a
Op 12-09-18 om 17:10 schreef Paul Wouters:
> On Wed, 12 Sep 2018, Willem Toorop wrote:
>
>> Op 12-09-18 om 13:57 schreef Ilari Liusvaara:
>>> On Wed, Sep 12, 2018 at 12:02:56PM +0100, Tony Finch wrote:
The reason for wanting to include the NS targets' TLSA records in
the glue
Paul Wouters wrote:
> On Wed, 12 Sep 2018, Tony Finch wrote:
> >
> > RFC 7901 doesn't work when asking authoritative servers because they
> > don't have a copy of the chain.
>
> You can set the start of the chain to the zone, so as long as any
> chaining would remain within the zone or
Op 12-09-18 om 17:22 schreef Tony Finch:
> Paul Wouters wrote:
>>
>> Then use RFC 7901 DNS chain queries (or the hopefully soon
>> tls-dnssec-chain TLS extension)
>
> RFC 7901 doesn't work when asking authoritative servers because they
> don't have a copy of the chain.
>
> tls-dnssec-chain will
On Wed, 12 Sep 2018, Tony Finch wrote:
Then use RFC 7901 DNS chain queries (or the hopefully soon
tls-dnssec-chain TLS extension)
RFC 7901 doesn't work when asking authoritative servers because they
don't have a copy of the chain.
You can set the start of the chain to the zone, so as long
Paul Wouters wrote:
>
> Then use RFC 7901 DNS chain queries (or the hopefully soon
> tls-dnssec-chain TLS extension)
RFC 7901 doesn't work when asking authoritative servers because they
don't have a copy of the chain.
tls-dnssec-chain will not help iterative resolvers because they will
already
On Wed, 12 Sep 2018, Willem Toorop wrote:
Op 12-09-18 om 13:57 schreef Ilari Liusvaara:
On Wed, Sep 12, 2018 at 12:02:56PM +0100, Tony Finch wrote:
The reason for wanting to include the NS targets' TLSA records in the glue
is so that the resolver can immediately connect over DoT with
Op 12-09-18 om 13:57 schreef Ilari Liusvaara:
> On Wed, Sep 12, 2018 at 12:02:56PM +0100, Tony Finch wrote:
>>
>> The reason for wanting to include the NS targets' TLSA records in the glue
>> is so that the resolver can immediately connect over DoT with
>> authentication, without having to spend
Erik Kline wrote:
> On Wed, 12 Sep 2018 at 15:38, Shane Kerr wrote:
> >
> > Note that we can also use the RTT of this query to set a reasonable
> > timeout for our port 853 traffic. A DNS server administrator may have
> > configured port 853 support, but the network administrator may block
> >
Tony,
On 2018-09-10 16:48, Tony Finch wrote:
Opportunistic TLS
-
The only mechanism we have is to probe port 853 and fall back to 53 if
TLS isn't available.
This is fraught with problems since in many cases firewalls will drop
packets to port 853 rather than promptly
In the most general terms, when upgrading a protocol from cleartext to
TLS, there are a couple of questions the client has to answer:
1. Does this server support TLS?
2. How can I authenticate it?
And there are a couple of approaches to answering them:
A. opportunistic
B. explicit
16 matches
Mail list logo
