Re: [Int-area] [DNSOP] please review CGA-TSIG

Hosnieh Rafiee wrote: > Hello, > > We actually put all our efforts to change the document thoroughly and not > only consider the IPv4 scenario that was comment of some people in > mailinglist but also we expand the DNS privacy section and explained it in > more detail (no need to change the proto

[Int-area] various approaches to dns channel secrecy

i've now seen a number of proposals reaction to "the snowden disclosures", seeking channel encryption for dns transactions. i have some thoughts on the matter which are not in response to any specific proposal, but rather, to the problem statement and the context of any solution. first, dns data i

Re: [Int-area] [DNSOP] various approaches to dns channel secrecy

Matthäus Wander wrote: > * Paul Vixie [7/5/2014 5:04 AM]: >> datagram level channel secrecy (for example, DTLS or IPSEC) offers a >> solution which matches the existing datagram level UDP transport used >> primarily by DNS. however, the all-pervasive middleboxes (small p

Re: [Int-area] [DNSOP] various approaches to dns channel secrecy

Matthäus Wander wrote: > * Paul Vixie [7/5/2014 7:47 PM]: >> Matthäus Wander wrote: >>> DTLS works on top of UDP (among others) and thus can pass CPE devices. >> no, it cannot. DTLS does not look something that the CPE was programmed >> to accept; thus in man

Re: [Int-area] [DNSOP] various approaches to dns channel secrecy

Hannes Tschofenig wrote: > Just a minor note on this paragraph: > >> because HTTPS currently depends on X.509 keys, other >>> groups in the IETF world are already working to make HTTPS proof against >>> on-path surveillance. (google for "perfect forward secrecy" to learn >>> more), and others are

Re: [Int-area] [DNSOP] various approaches to dns channel secrecy

Bernard Aboba wrote: >>> this is extremely narrow but i can envision activists and dissidents who >>> rightly fear for their safety based on this narrowly defined threat > > [BA] Presumably protection would only be from an attacker that can snoop on > the wire, but not have access to the logs?

Re: [Int-area] [DNSOP] various approaches to dns channel secrecy

Paul Ferguson wrote: > ... > > That is *not* to say that DANE is not a desirable thing to > deploy/accomplish. DANE relies on DNSSEC which relies on EDNS. the placement of a DNS-over-HTTPS channel would have to be below EDNS in the stack, and non-reliant. therefore my correction up-thread --

Re: [Int-area] [DNSOP] various approaches to dns channel secrecy

Nicholas Weaver wrote: > ... > > One important observation: ONLY the path between the client and the > recursive resolver in the classic model substantially benefits from channel > security. if i were proposing a secrecy scheme that was easy to do on stub-to-recursive but hard to do on recurs

Re: [Int-area] [DNSOP] various approaches to dns channel secrecy

Matthäus Wander wrote: > ... > > I didn't mean to imply that a DTLS solution can be universally deployed. because the dns is a map to the territory known as the internet, and because most internet packet flows begin with a dns transaction, i'm dismissing out of hand anything that will almost uni

Re: [Int-area] [tsvwg] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020

On Tuesday, 9 June 2020 01:41:40 UTC Black, David wrote: > This email announces a limited-scope 3rd TSVWG Working Group Last Call > (WGLC) on: > > Considerations around Transport Header Confidentiality, Network > Operations, and the Evolution of Internet Transport Protocols >

Re: [Int-area] Jumbo frame side meeting at IETF118 - notes

We've got to teach the system how to negotiate and/or discover this. 9000 was about right for fast Ethernet but it's small at gigabit Ethernet and above. Petabit is probably coming within our lifetimes. 9000 would be a great starting point and 64k after that but like the ibmpc 640k memory t

Re: [Int-area] [EXTERNAL] Re: Jumbo frame side meeting at IETF118 - notes

Robinson, Herbie wrote on 2023-12-19 15:49: At some point, it becomes ridiculous to keep band-aiding 40+ year old hardware designs with ever increasing software complexity.  The hard thing to know is when you hit that tipping point. better things do come along. but without backward compatibili

[Int-area] Re: New version of WPADNG

Thank you Alan this resonated strongly worth my own views. Even something no stronger than the pin codes used for Bluetooth pairing with reduce the risk of rogue DHCP. It's necessary for edge devices to securely learn the security policies of a network, for example a proxy if any and the cert

[Int-area] Re: IP Parcels and Advanced Jumbos (AJs)

, Sep 24, 2024, 1:44 PM Templin (US), Fred L wrote: Thanks Paul, as you know well the Internet has come a long way since the days of FDDI but has not done very well at accommodating packet size diversity. We can and should do better, IMO. Fred From: Paul Vixie Sent: Tuesday

[Int-area] Re: IP Parcels and Advanced Jumbos (AJs)

Something like this is long needed and will become badly needed. Every 10X of speed increase since 10mbit/sec has gone straight to PPS, whereas the speed increase from 3mbit/sec to 10mbit/sec was shared between PPS and MTU. If every 10X has been shared between PPS and MTU, say sqrt(10) for eac

[Int-area] Re: [tsvwg] Re: UDP options [was IP Parcels and Advanced Jumbos (AJs)]

On Wed Nov 20, 2024 at 12:18 AM UTC, C. M. Heard wrote: > For the record, Fred, I do not agree with that. IP Parcels should have a > new protocol number (once again, see pont #3 here > ). > One is needed for safety and correc