On Wed, 2020-11-18 at 23:09 +, Tony Finch wrote:
> > > * Authenticate the server by `subjectAltName` `iPAddress`. [snip]
> >
> > For DOTPIN, Ralph Dolmans had the bright insight to suggest not sending
> > a server name at all (which matches what I said earlier - name servers
> > have IPs,
Peter van Dijk wrote:
>
> What I think I mean to say there is 'if an auth NS responds on port 853,
> it had better offer me all the data it also has to offer on 53'.
Yes, I think that makes the most sense.
> > * Authenticate the server by `subjectAltName` `iPAddress`. [snip]
>
> For DOTPIN,
On Tue, 2020-11-17 at 01:21 +, Tony Finch wrote:
> Thanks for reading and providing feedback!
>
> Peter van Dijk wrote:
>
> > On Wed, 2020-11-11 at 19:07 +, Tony Finch wrote:
> > > * Encryption would apply to the server as a whole, whereas the
> > > working group consensus is that
Thanks for reading and providing feedback!
Peter van Dijk wrote:
> On Wed, 2020-11-11 at 19:07 +, Tony Finch wrote:
> >
> > * Encryption would apply to the server as a whole, whereas the
> > working group consensus is that it should be possible for
> > different zones on the same
On Wed, 2020-11-11 at 19:07 +, Tony Finch wrote:
>
> * Encryption would apply to the server as a whole, whereas the
> working group consensus is that it should be possible for
> different zones on the same server to use encrypted and
> unencrypted transports.
(plus, in another
Manu Bretelle wrote:
> The "cloud provider" case, e.g few name servers for many zones is also
> tricky.
I prefer to think of this as the normal common case, since I'm not a cloud
provider and I have many more zones than servers :-)
> I think in those cases, TLSA may be the best bet as this is
On Wed, Nov 11, 2020 at 4:00 PM Tony Finch wrote:
> Manu Bretelle wrote:
> >
> > Totally fair, pretty sure there were no speaker notes ;) . The
> > presentation is available at https://youtu.be/MIapQ6UXrdg?t=5387 .
> > Originally, there was this draft
> >
>
Manu Bretelle wrote:
>
> Totally fair, pretty sure there were no speaker notes ;) . The
> presentation is available at https://youtu.be/MIapQ6UXrdg?t=5387 .
> Originally, there was this draft
> https://tools.ietf.org/html/draft-bretelle-dprive-dot-for-insecure-delegations-01
> and the solutions
On Wed, Nov 11, 2020 at 1:20 PM Tony Finch wrote:
> Manu Bretelle wrote:
>
> > Having this as an ID or possibly a github repo may make it easier to
> refer
> > to/iterate than just this email.
>
> Yes! https://github.com/fanf2/draft-dprive-adot
Thanks!
>
>
> > I had attempted to quickly
On 11/11/2020 20:32, Manu Bretelle wrote:
Thanks Tony for the exhaustive list of approaches with their pros and cons,
+many - very useful,
Thanks,
S.
OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
On Wed, Nov 11, 2020 at 11:07 AM Tony Finch wrote:
> I haven't seen anything written down that explains why it is difficult to
> do DoT to authoritative servers. There was a good discussion earlier this
> year about draft-vandijk-dprive-ds-dot-signal-and-pin which covered some
> of the issues. I
Thanks Tony for the exhaustive list of approaches with their pros and cons,
helping in deciding where the tradeoff may be made.
Having this as an ID or possibly a github repo may make it easier to refer
to/iterate than just this email.
I had attempted to quickly categorize some of those
Eric Rescorla wrote:
> On Wed, Nov 11, 2020 at 11:07 AM Tony Finch wrote:
>
> > 2. Signal in an EDNS [@?RFC6891] or DSO [@?RFC8490] option: the
> > resolver starts by connecting in the clear, and upgrades to an
> > encrypted connection if the authoritative server supports it.
> >
> >
Hollenbeck, Scott wrote:
>
> It's not an EPP limitation. We can always define an EPP extension to add
> information to the parent zone. The issue is if the zone administrator
> can/will publish that information in the zone and if EPP clients are able and
> willing to provide it.
True! I am using
> -Original Message-
> From: dns-privacy On Behalf Of Tony Finch
> Sent: Wednesday, November 11, 2020 2:07 PM
> To: dns-privacy@ietf.org
> Subject: [EXTERNAL] [dns-privacy] how can we ADoT?
>
> Caution: This email originated from outside the organization. Do not cli
On Wed, Nov 11, 2020 at 11:07 AM Tony Finch wrote:
> 2. Signal in an EDNS [@?RFC6891] or DSO [@?RFC8490] option: the
> resolver starts by connecting in the clear, and upgrades to an
> encrypted connection if the authoritative server supports it.
>
> This is vulnerable to downgrade
I haven't seen anything written down that explains why it is difficult to
do DoT to authoritative servers. There was a good discussion earlier this
year about draft-vandijk-dprive-ds-dot-signal-and-pin which covered some
of the issues. I have done a braindump that attempts to cover all the
angles
17 matches
Mail list logo
