Hi Tommy,
Encrypted DNS servers SHOULD NOT attempt to authenticate clients to
identify the appropriate resolution policy to use when the difference
in resolution behavior between them is not imposed by the operator of
the server but instead is chosen by the client.
There are certain us
+1 for a separate draft on in-band reporting.
Neil
> On 10 May 2016, at 16:14, Daniel Margolis wrote:
>
> Yeah, I think we've spent more time on this discussion than we would on some
> simple implementations. ;)
>
> I think Viktor is right that sending something other than "QUIT" is quite
>
> On 1 May 2016, at 11:29, Stephen Farrell wrote:
>
> Wouldn't the same argument tend to indicate SRV or a sub-domain are
> as troublesome, given in many enterprises, mail and DNS can be in
> different silos? After all, isn't that the core of the stated argument
> for not doing DANE/DNSSEC? Whil
> On 13 Apr 2016, at 10:38, Daniel Margolis wrote:
>
>
> On Wed, Apr 13, 2016 at 11:34 AM, Neil Cook <mailto:neil.c...@noware.co.uk>> wrote:
> Well, both need to work independently as you say below. But I might still
> have an STS policy (using a different, CA-
> On 13 Apr 2016, at 10:04, Daniel Margolis <mailto:dmargo...@google.com>> wrote:
>
> On Wed, Apr 13, 2016 at 10:40 AM, Neil Cook <mailto:neil.c...@noware.co.uk>> wrote:
>
>> On 13 Apr 2016, at 08:48, Daniel Margolis > <mailto:dmargo...@google.com>
> On 13 Apr 2016, at 08:48, Daniel Margolis wrote:
>
> What's the complexity you're worried about? Is it mainly that there's another
> switch to flip incorrectly (i.e. inadvertent misconfiguration, at a greater
> risk due to the presence of more configurations) or the risk of malicious DoS?
>
> On 11 Apr 2016, at 22:38, Mark Risher wrote:
>
> Hi, everyone:
> Hope you all made it home safely.
>
> I think we can do that by requiring that outbound MTAs
> that implement the "webby" approach MUST/SHOULD first test
> for, and process, TLSA records for the next MX in the path.
> In other
> On 24 Mar 2016, at 19:16, Viktor Dukhovni wrote:
>
> This sure ain't pretty! I sure wish you guys would hurry up and
> do DANE, but wishing it won't make it so... :-(
>
I’m also wondering why all this work on a new standard, and why not just do
DANE…
Neil
signature.asc
Description: Mes
ack out of scope for now (though
> potentially a good application of public key pinning, CT, or similar).
>
> In the section you quote from 3.3, I think that should refer to
> "authentication", not "validation." :)
>
> Dan
>
> On Tue, Mar 22, 2016 at 10:
> On 22 Mar 2016, at 08:49, Viktor Dukhovni wrote:
>
> On Tue, Mar 22, 2016 at 08:58:25AM +0100, Daniel Margolis wrote:
>
> My (strong) suggestion: use DNS for just cache invalidation, and
> perhaps also publication (via a separate record) of the "rua"
> reporting URI. Do not duplicate data wh
Some feedback on this draft:
1) The language around policy authentication vs validation vs application is
very confusing to me. The terms “authentication” and “validation” seem to be
used in a variety of contexts with different meanings.
For example in "3.3. Policy Authentication"
The secu
11 matches
Mail list logo
