>From the server operator side, I feel strongly that the multi-CDN example
should show a selected CDN setup not a merged CDN setup.
The "Automation is required to keep these records consistent with the
original records in the CDN providers' zones." mentioned
in the current example is outside of the
On Fri, Oct 4, 2024 at 3:48 PM Salz, Rich wrote:
> This is explicitly prohibited rfc9460 as it would provide linkability.
>
>
>
> So what? We’re not the protocol police and if someone wants to track,
> RFC9460 compliance isn’t going to stop them. Especially for something as
> controversial as EC
On Fri, Oct 4, 2024 at 3:20 PM Stephen Farrell
wrote:
>
> On 10/4/24 19:30, Paul Wouters wrote:
> > Which makes me wonder if it makes sense to advise long TTLs on these
> > records so that they move along on your phone/laptop even if you enter
> > these kind of networks.
>
> There's a tension bet
ver name or information about it by
observing traffic to DNS authorities [rfc9076].
On Fri, Oct 4, 2024 at 3:06 PM Erik Nygren wrote:
> The suggested text seems inoffensive to me as well, but we may also want
> to expand it to cover the recursive-to-authoritative path for resolvers
> as
The suggested text seems inoffensive to me as well, but we may also want to
expand it to cover the recursive-to-authoritative path for resolvers
associated with the client. (ie, just using DoH to your home router isn't
going to help when it uses Do53 to the authorities.).
On the topic of DNSSEC,
ures (this is true for A/, of
> course). Probably not much of an issue for the big public recursives, but
> can definitely be an issue if you are just talking to some locally-supplied
> resolver.
> >
> > -Ekr
> >
> >
> > Op za 30 mrt 2024 om 14:02 schree
od in that it covers
> both DNSSEC and encrypted transports for DNS.
>
> thanks,
> Rob
>
>
> On Sat, Mar 30, 2024 at 10:27 AM Ted Lemon wrote:
>
>> I think that would make sense, yes.
>>
>> On Sat, Mar 30, 2024 at 10:58 AM Erik Nygren
>> wrote:
>
Do we want a few sentences in Security Considerations that references
https://www.rfc-editor.org/rfc/rfc9460.html#section-3.1 to call this out?
This seems like something that became less clear when we split these two
docs apart.
Most of draft-ietf-tls-svcb-ech used to be a section of what is now r
t review to not accidentally use the value for something else.
>
> On Wed, Sep 20, 2023 at 2:44 PM Erik Nygren wrote:
>
>> We're going through AUTH48 with SVCB right now and reviewing edits from
>> the RFC Editor. I think there is a good question of how to handle this.
We're going through AUTH48 with SVCB right now and reviewing edits from the
RFC Editor. I think there is a good question of how to handle this. Right
now it is "RESERVED (will be used for ECH)" for SvcParamKey "ech" (5) but
we also say:
New entries in this registry are subject to an Expert Revie
that doesn't exist.
>>
>> Anything along these lines would need to be tested for compatibility -
>> extensively - before it could even be trialed.
>>
>> (I never saw the DDR as having deployment problems along these lines. It
>> isn't THAT hard to know yo
I’d love to hear
> about those use cases as they’re not on my radar at this time. When I
> wrote the ballot for validation of IP addresses, it was a royal pain and
> took a few years because no one was actually interested in them. My
> impression was that they were slowly going away with
ate. Your design could
>> have those servers searching for a certificate that doesn't exist.
>>
>> Anything along these lines would need to be tested for compatibility -
>> extensively - before it could even be trialed.
>>
>> (I never saw the DDR as having d
00.txt
To: Erik Nygren , Rich Salz
A new version of I-D, draft-nygren-tls-ip-in-sni-00.txt
has been successfully submitted by Erik Nygren and posted to the
IETF repository.
Name: draft-nygren-tls-ip-in-sni
Revision: 00
Title: Representing IP addresses in TLS Server Name
With draft-ietf-dnsop-svcb-https being in WGLC in DNSOP, one feedback that
has come up is that the escaping and parsing for SvcParamValues is
complicated.
Most of this complication comes from trying to support 8-bit clean ALPN
values.
Ideally in presentation format the ALPN list would be something
We've closed out most of the open issues on draft-ietf-dnsop-svcb-https
and it will be going to WGLC shortly.
Current version at:
https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-04.txt
Hopefully we're done, but you can open issues against:
https://github.com/MikeBishop/dns
One quick comment is that binding tokens to IP addresses is strongly
counter-recommended.
It doesn't survive NATs or proxies, mobility, and it is especially
problematic in IPv6+IPv4 dual-stack environments.
(Even in IPv6-only, privacy addressing causes problems here.) Even if you
have a way to con
Are there any objections to "ECH" or should we just go with that?
(I'd like to update the parameter name in SRVB/HTTPSSVC accordingly based
on what gets decided.)
On Wed, May 20, 2020 at 11:37 PM Tommy Pauly wrote:
> ECH is good. Go for it!
>
> Tommy
>
> On M
ECH works for me. (I really don't care between ECH and ETCH and thing both
are fine.)
Erik
On Wed, May 20, 2020 at 2:20 PM Christopher Wood
wrote:
> On Tue, May 19, 2020, at 8:18 PM, Filippo Valsorda wrote:
> > As a data point, I was fairly confused when ECHO came up in
> > conversation,
+1 to "ETCH"
Any objections to that or concerns with that?
(Agreed it would be good to finalize this ASAP.)
On Thu, May 7, 2020 at 7:03 PM Tommy Pauly wrote:
> ECHO is more fun to say, but I do see how it can be confusing (sounding
> like some sort of ping) when out of the context of TLS.
>
> T
also specifies
an HTTPSSVC record for the HTTP(S) use-case.
Based on discussions with various chairs, the plan is to call for adoption
in the DNSOP WG.
Comments/feedback are most welcome.
Erik
-- Forwarded message -
From: Erik Nygren
Date: Tue, Sep 24, 2019 at 9:17 AM
Hi Stephen,
On Mon, Jul 8, 2019 at 5:39 PM Stephen Farrell
wrote:
>
> On 08/07/2019 22:27, Erik Nygren wrote:
> >
> > In particular for the TLS WG, we'd be interested in hearing if this would
> > solve enough of the ESNI-key-delivery-via-DNS needs for the HTTPS
>
For those not on the HTTP-WG or DNSOP lists, Ben Mike and I have
a draft for an "HTTPSSVC" DNS record. There's a -03 that incorporates
some feedback from the first version:
https://tools.ietf.org/html/draft-nygren-httpbis-httpssvc-03
This attempts to address a number of problems (ESNI, QUIC
Following the discussion this week I realized some other major issues we'll
need to make sure we cover:
1) Handling proxies here is going to be tricky. The CONNECT generally
needs to specify the hostname which needs to go to the server which has the
ESNI key for what gets sent in the TLS handshak
Another important scenario that is closely related to multi-cdn is how to
safely enable and disable ESNI, as well as how to handle cases where not
all CDNs in a multi-CDN setup have ESNI turned on. As some examples:
* A site is using a CDN that has ESNI enabled. As part of switching off of
that
;
>> I am not sure why we are giving servers a choice between aborting and
>> accepting the PSK but rejecting 0-RTT (if a matching ClientHello is found),
>> especially not without giving guidance as to why they might choose one or
>> the other. My natural inclination
On Thu, May 4, 2017 at 8:18 PM, Watson Ladd wrote:
> >
> > It should be up to servers whether a request is allowed with 0-rtt.
>
> Which server? It's possible that the backhauls from the server the
> TLS connection is made to to the server actually responding to the
> request do not distinguish
On Thu, May 4, 2017 at 5:37 PM, Eric Rescorla wrote:
>
>
>
> On Thu, May 4, 2017 at 2:27 PM, Kyle Nekritz wrote:
>
>> > 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
>> both session-cache and strike register styles and the merits of each.
>>
>>
>>
>> First, a point of c
On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla wrote:
>
> 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
> both session-cache and strike register styles and the merits of each.
>
I don't believe this is technically viable for the large-scale server
operators most interes
I also prefer TLS 4 but am fine with TLS 1.3
- Erik
On Nov 17, 2016 9:41 PM, "Yoav Nir" wrote:
> Bleh. Can’t we get AOL to release the SSL trademark so that we can call it
> SSLv4?
>
> I hummed for TLS 4, so I’ll stay consistent: TLS 4.
>
> Yoav
>
> > On 18 Nov 2016, at 11:12, Sean Turner wr
Is it worth having a poll (hate it, neutral, love it) on options to judge
preference
It seems like options are (I may have missed some):
- TLS 1.3 (ie, the default if we do nothing)
- TLS 2.0
- TLS 2
- TLS/2
- TLS 4.0
- TLS/4
- TLS 4
- TLS 34
On the topic of "what does this re-open", I'm not con
I'm also very supportive for the reasons you outline.
However, I think we should consider calling it TLS 4 or TLS 4.0 or TLS 5.
In particular, much of the non-technical audience still calls it "SSL" (pet
peeve of many of us, I suspect) and having a version number clearly greater
than SSLv3 and no
most of this can be handled
>> at the higher levels above TLS, or possibly as a custom extension that does
>> not complicate TLS.
>>
>
> A custom extension is a promising approach: this is what Erik Nygren
> proposed in nygren-tls-client-puzzles-00 following discussions with
There are also very common cases of using multiple CDNs or server farms
with different capabilities but with the same host name, or of switching a
live site between platforms. As others have mentioned, the behaviors need
to be well defined and result in extra rtt rather than hard failure to
allow 0
On Sun, Mar 13, 2016 at 12:21 PM, Eric Rescorla wrote:
>
> On Sun, Mar 13, 2016 at 3:51 PM, Yoav Nir wrote:
>
>>
>> > On 13 Mar 2016, at 4:45 PM, Salz, Rich wrote:
>> >
>> >> I also think it is prudent to assume that implementers will turn on
>> replayable
>> >> data even if nobody has figured
That does seem like a good idea to include a client time stamp in the 0RTT
flow to let the server force 1RTT in the case where this is too far off as
this bounds the duration of the replay window. (I suspect we'll find a
whole range of other similar attacks using 0RTT.) An encrypted client
timest
36 matches
Mail list logo
