> Dan Kaminksy's issue accidentally leaked?

i don't think it was an accident.

> > ... completely undeployable. tcp is blocked in way too many places,
> > and the large commercial stub vendors would never implement #3 above,
> > which turns this into the same basic downgrade vector all versions of
> > XQID or cookies have ever had.

>
> At least this shows us a path that gives immediate benefit to those who
> play, especially the "opportunistic keep-state EDNS PING" where resolvers
> cache who has done EDNS PING in te past, and know they should not be
> downgraded (for now).


what's your plan for times when the responder legitimately does downgrade,
or when load balancing (in the local or wide or remote area) replaces the
endpoint entity in an on-path (non-spoofed) way?

> EDNS PING moved to EDNS option 5 today. I'll wrap up some informal specs
> and see who plays.


this being the internet, there's room for a zillion boutique solutions.

> There is an immediate benefit for everybody who joins.


that may be so, but also, immediate risks, which will prevent scale.

note, i've met several large internet companies recently who refuse to
deploy EDNS at all, one said their eyeball count dropped by 3% when they
started honouring EDNS signalling in their DNS responses.

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: