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
> On Sep 14, 2018, at 12:09 PM, Eric Rescorla wrote:
>
> In theory perhaps, but as a practical matter, no browser client, at least,
> can do DNSSEC hard fail, because the rate of organic DNSSEC interference is
> too high. Indeed, this is the primary reason why DANE over TLS is interesting.
* In theory perhaps, but as a practical matter, no browser client, at
least, can do DNSSEC hard fail, because the rate of organic DNSSEC interference
is too high. Indeed, this is the primary reason why DANE over TLS is
interesting.
But that doesn’t make Viktor’s statement wrong, does it? B
On Fri, Sep 14, 2018 at 8:33 AM, Viktor Dukhovni
wrote:
> I'm afraid the below is a strawman hypothetical. Please stop.
>
> 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,
I'm afraid the below is a strawman hypothetical. Please stop.
DNSSEC lookups either return the truth or explicitly
*FAIL*, they don't just return "neutral" results.
As, for example, explained in RFC7672, when TLSA lookups fail the
mail delivery is deferred, and may ultimately bounce if the condi
One other bit of context here: DANE itself doesn't prevent these
"downgrade" attacks in its native form, to say nothing of TLS.
Recall that caching is optional for DNS clients, and the usage of DNSSEC
validation results is up to the application.
Suppose you had an application with the following l
On Wed, Sep 12, 2018 at 10:40:31PM -0400, Richard Barnes wrote:
> > DNS records have semantics beyond a single connection.
>
> DNS records have caching semantics. Those are only relevant for DNS
> resolution. This is the TLS WG, not the DNS.
It's odd you should say that, in draft -07, which yo
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
Your responses here reveal a lot of the assumptions that you're reading in
here that are not actually true, e.g., those noted below.
On Wed, Sep 12, 2018 at 8:56 PM Paul Wouters wrote:
> On Wed, 12 Sep 2018, Richard Barnes wrote:
>
> > Speaking as one of the attendees, I do not agree with that c
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
I may have a conflict with the call, so I've gone ahead and put some
opinion inline below...
On Wed, Sep 12, 2018 at 5:40 PM Paul Wouters wrote:
>
> Hi,
>
> We have made available what we believe is a good starting point for
> further discussion regarding tls-dnssec-chain draft.
>
> While I thou
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
12 matches
Mail list logo
