Christian Huitema wrote:
>
> An attacker could replay the 0-RTT packet, and observe whether it
> creates a particular side effect at the server end. For example, replay
> the traffic from client to recursive, and observe whether the resolver
> issues a query to particular DNS server.
Ah, yes, if
On 9/25/2018 2:30 PM, Mukund Sivaraman wrote:
> Hi Christian
>
> On Tue, Sep 25, 2018 at 01:40:59PM -0700, Christian Huitema wrote:
>> On 9/25/2018 12:15 PM, Tony Finch wrote:
>>
>>> For DNS-over-QUIC I think that could drop to 2RTT, or maybe 1RTT? I don't
>>> know QUIC's handshake.
>>>
>>> The
On 9/26/2018 4:15 AM, Tony Finch wrote:
> Christian Huitema wrote:
>> The basic QUIC handshake will be 1-RTT before sending the first query,
>> with two exceptions:
> Thanks for those details!
>
>> Using 0-RTT is a trade-off between security and performance, because
>> 0-RTT packets can be subj
Christian Huitema wrote:
>
> The basic QUIC handshake will be 1-RTT before sending the first query,
> with two exceptions:
Thanks for those details!
> Using 0-RTT is a trade-off between security and performance, because
> 0-RTT packets can be subject to replay attacks. That's true for 0-RTT in
>
Hi Christian
On Tue, Sep 25, 2018 at 01:40:59PM -0700, Christian Huitema wrote:
> On 9/25/2018 12:15 PM, Tony Finch wrote:
>
> > For DNS-over-QUIC I think that could drop to 2RTT, or maybe 1RTT? I don't
> > know QUIC's handshake.
> >
> > The warm start time should soon be 0RTT.
>
> The basic QUI
On 9/25/2018 12:15 PM, Tony Finch wrote:
> For DNS-over-QUIC I think that could drop to 2RTT, or maybe 1RTT? I don't
> know QUIC's handshake.
>
> The warm start time should soon be 0RTT.
The basic QUIC handshake will be 1-RTT before sending the first query,
with two exceptions:
1) The server may
Mukund Sivaraman wrote:
>
> During the "how-to-achieve-it" phase, attention should be given to not
> adding extra roundtrips (to keep it as close as possible to the RFC 1035
> UDP scenario). Various new facilities such as TCP's fast open, TLS false
> start, etc. should not be taken for granted - c
On Tue, Sep 25, 2018 at 10:43:44PM +0530, Mukund Sivaraman wrote:
> DNS is at the head of any user-initiated internet connection and the
> turnaround time of a DNS request is definitely influenced by the
> resolution time at the head of the sequence of steps.
That should say "turnaround time of th
On Thu, Jul 19, 2018 at 02:23:53PM -0400, Brian Haberman wrote:
> This thread is for discussion of the user perspective of DNS privacy
> between the recursive resolver and authoritative servers.
>
> - Focus on *what* is needed.
> - Avoid *how* to achieve it.
> - Consider both ends of D
clients hide on proxy, but still get the specified network topological
close response.
Brian Haberman 于2018年7月20日周五 上午2:24写道：
> This thread is for discussion of the user perspective of DNS privacy
> between the recursive resolver and authoritative servers.
>
> - Focus on *what* is needed.
>
On 24 Sep 2018, at 7:08, Brian Haberman wrote:
> All,
> I would like the focus for this week (9/24-9/30) to be on
> clarifying the requirements from the user's perspective. So far, I have
> seen:
>
> * DNS transaction privacy, if possible
> * User willingness to send PII if transaction is enc
Tony Finch wrote:
> Amelia Andersdotter wrote:
>>
>> I have difficulties seeing how a user (within the meaning of individual
>> internet consumer) has any practical choice to other than to share PII
>> with a DNS provider?
>
> Yes, me too.
There’s always the option to run your own recursive, p
Amelia Andersdotter wrote:
>
> I have difficulties seeing how a user (within the meaning of individual
> internet consumer) has any practical choice to other than to share PII
> with a DNS provider?
Yes, me too.
Since the overall topic is recursive -> authoritative, the questions imply
some mech
On 9/24/18 11:58 AM, Amelia Andersdotter wrote:
> I have difficulties seeing how a user (within the meaning of individual
> internet consumer) has any practical choice to other than to share PII
> with a DNS provider? It's not so much about "willingness" as it is about
> "feeling comfortable with".
On 2018-09-24 16:08, Brian Haberman wrote:
> All,
> I would like the focus for this week (9/24-9/30) to be on
> clarifying the requirements from the user's perspective. So far, I have
> seen:
>
> * DNS transaction privacy, if possible
> * User willingness to send PII if transaction is encrypte
All,
I would like the focus for this week (9/24-9/30) to be on
clarifying the requirements from the user's perspective. So far, I have
seen:
* DNS transaction privacy, if possible
* User willingness to send PII if transaction is encrypted
Do others have additional requirements?
If you agree
1) User may be willing to send PII (such as ECS) to authority if the
transaction is encrypted.
2) user may be willing to be signaled that the response is “validated” if
the authoritative answer was obtained over an authenticated link for
unsigned zones ( similar to 4. from Paul)
Manu
> _
The user scenarios that I can think of are:
1) Users want DNS transaction privacy if possible
2) Users need absolute DNS privacy
3) Users want DNS transaction authentication if possible
4) Users need absolute DNS authentication
#1 is basically opportunistic encryption: the resolver keeps going e
18 matches
Mail list logo
