On Thu, Oct 10, 2019 at 1:52 PM Christian Huitema
wrote:
> If the Origin is identified by IP address, an observer on path between CDN
> and Origin just has to look at the IP address to find out whatever
> information was in the SNI.
>
I don't think that is true for subdomains, and I also don't th
On Wed, Oct 9, 2019 at 7:01 PM Martin Thomson wrote:
> tl;dr keep the space.
>
> I had a little trouble reproducing the 12 from RFC 8446, so I
> double-checked.
>
>
>
> Working from the base for SHA-256:
>
> The last block of SHA-256 is rounded up to 448 bits (56 bytes), less one
> to allow
The main concern I had about including DTLS explicitly in this document was
because exporters are not officially defined for DTLS. However, some other
documents assume they are portable so maybe this is an overly conservative
choice.
On Wed, Oct 9, 2019 at 6:26 PM Martin Thomson wrote:
> I think
Well, DTLS is one of the primary consumers of exporters
https://tools.ietf.org/rfcmarkup?doc=5764, so as a practical matter I think
we've accepted that. I'm not aware of a practical problem with exporters
and DTLS, but if there is one, we should document it and address it.
-Ekr
On Thu, Oct 10, 2
* I want to keep the SNI encrypted in TLS hops that use client
certificates, but where ESNI won't work.
I have some questions about this, see below.
* For example, how is the SNI transmitted in the parens here:
* [ Client ] -> (ESNI) -> [ CDN ] -> (???) -> [ Origin
On Thu, Oct 10, 2019 at 10:53 PM Salz, Rich wrote:
>
>- For example, how is the SNI transmitted in the parens here:
>
>
>
>- [ Client ] -> (ESNI) -> [ CDN ] -> (???) -> [ Origin
>]
>
>
>
> It is transmitted in the clear. There is no architectural reason why it
> could
On Thu, Oct 10, 2019, 8:54 AM Salz, Rich wrote:
>
>- I want to keep the SNI encrypted in TLS hops that use client
>certificates, but where ESNI won't work.
>
>
>
> I have some questions about this, see below.
>
>
>
>- For example, how is the SNI transmitted in the parens here:
>
>
>
>
* At least one customer of the CDN I work for (namely my own website) uses
an IP address.
Sure, I get it. Which is why I said “in our experience.” :)
* Shared hosting behind a CDN does exist where clients of the service
provider are signed up to the CDN, and it might be interesting
On Tue, Oct 08, 2019 at 08:25:51PM +0700, Rob Sayre wrote:
> On Tue, Oct 8, 2019 at 7:05 PM Benjamin Kaduk wrote:
>
> > it's largely up to the sponsoring AD.
> >
>
> Is that true? I'm not sure which procedure you're describing.
Per https://www.rfc-editor.org/current_queue.php ,
draft-ietf-rctwe
In our experience, the origin is identified by a DNS name. I could
double-check, but I don’t think *any* of our customer origins are identified by
IP address.
* How does that work without introducing a CDN loop? Do you require the
origins to have obscure domain names? FWIW, the Cloudflare
On Thu, Oct 10, 2019 at 11:15 PM Salz, Rich wrote:
>
>- At least one customer of the CDN I work for (namely my own website)
>uses an IP address.
>
>
>
> Sure, I get it. Which is why I said “in our experience.” :)
>
>
>
>- Shared hosting behind a CDN does exist where clients of the s
M
On Thu, Oct 10, 2019 at 11:18 PM Salz, Rich wrote:
> One reason for using DNS is that big sites often use a multi-CDN load
> balancer. They can shift in as little as 10-30 seconds.
>
Also, just to level-set the conversation, I am extremely familiar with this
routine (see sayrer.com)
It seems
On Thu, Oct 10, 2019 at 11:17 PM Benjamin Kaduk wrote:
> The decision about
> whether to make changes to the technical content thus lies with the
> sponsoring AD for that document.
>
>
I don't think that is true. Here is one comment from the document shepherd:
https://mailarchive.ietf.org/arch/ms
On Wed, Oct 9, 2019 at 10:16 PM Rob Sayre wrote:
> On Wed, Oct 9, 2019 at 8:06 PM Eric Rescorla wrote:
>
>>
>>> I don't think that's quite what I'm proposing. I'm proposing
>>> (optionally) sending the SNI with a client certificate.
>>>
>>
>> What are you trying to accomplish by doing that?
>>
>
On Fri, Oct 11, 2019 at 1:08 AM Eric Rescorla wrote:
>
>
> On Wed, Oct 9, 2019 at 10:16 PM Rob Sayre wrote:
>
>> On Wed, Oct 9, 2019 at 8:06 PM Eric Rescorla wrote:
>>
>>>
I don't think that's quite what I'm proposing. I'm proposing
(optionally) sending the SNI with a client certifica
On Fri, Oct 11, 2019 at 12:45:11AM +0700, Rob Sayre wrote:
> On Thu, Oct 10, 2019 at 11:17 PM Benjamin Kaduk wrote:
>
> > The decision about
> > whether to make changes to the technical content thus lies with the
> > sponsoring AD for that document.
> >
> >
> I don't think that is true. Here is o
On Thu, Oct 10, 2019 at 11:19 AM Rob Sayre wrote:
>
>
> On Fri, Oct 11, 2019 at 1:08 AM Eric Rescorla wrote:
>
>>
>>
>> On Wed, Oct 9, 2019 at 10:16 PM Rob Sayre wrote:
>>
>>> On Wed, Oct 9, 2019 at 8:06 PM Eric Rescorla wrote:
>>>
> I don't think that's quite what I'm proposing. I'm
On Fri, Oct 11, 2019 at 1:45 AM Eric Rescorla wrote:
>
> OK, I think we've now reached where we are talking past each other.
>
> At a very high level, here's the TLS 1.3 handshake:
>
> C->S: CH (w/ SNI)
> S->C: SH, CERT, CV, FIN
> C->S: [CERT, CV], FIN
>
> In order for the server to send the cert
On Fri, Oct 11, 2019 at 1:38 AM Benjamin Kaduk wrote:
> On Fri, Oct 11, 2019 at 12:45:11AM +0700, Rob Sayre wrote:
> > On Thu, Oct 10, 2019 at 11:17 PM Benjamin Kaduk wrote:
> >
> > > The decision about
> > > whether to make changes to the technical content thus lies with the
> > > sponsoring AD
Normally, virtual-hosted TLS servers are known to a client by their domain
name, and the client uses DNS to find an IP address corresponding to this
domain name. The ESNI drafts are largely written in reference to this
configuration.
I think Rob is describing the case where a TLS client is contac
On Thu, Oct 10, 2019 at 11:59 AM Rob Sayre wrote:
> On Fri, Oct 11, 2019 at 1:45 AM Eric Rescorla wrote:
>
>>
>> OK, I think we've now reached where we are talking past each other.
>>
>> At a very high level, here's the TLS 1.3 handshake:
>>
>> C->S: CH (w/ SNI)
>> S->C: SH, CERT, CV, FIN
>> C->
On Fri, Oct 11, 2019, at 07:57, Ben Schwartz wrote:
> The obvious solution is for the TLS client (i.e. the CDN) to support
> direct entry of ESNI public keys alongside the IP address. Users who
> want to be able to rotate their ESNI keys more easily should use a
> backend identified by a domain
Thanks, that was my mistake. I confirmed with our code and we are indeed right
up to the line.
On Thu, Oct 10, 2019, at 23:37, Eric Rescorla wrote:
>
>
> On Wed, Oct 9, 2019 at 7:01 PM Martin Thomson wrote:
> > tl;dr keep the space.
> >
> > I had a little trouble reproducing the 12 from RFC
On Fri, Oct 11, 2019 at 5:37 AM Martin Thomson wrote:
> On Fri, Oct 11, 2019, at 07:57, Ben Schwartz wrote:
> > The obvious solution is for the TLS client (i.e. the CDN) to support
> > direct entry of ESNI public keys alongside the IP address. Users who
> > want to be able to rotate their ESNI ke
> On Oct 9, 2019, at 9:04 PM, Martin Thomson wrote:
>
> I think that the discussion Victor started about the number of tickets you
> might want to supply being different for a resumed connection is a sensible
> one, but I would caution against servers making inferences, especially in
> light o
>Isn't that more complicated than sending the SNI in the second client message,
>though?
The server needs to know which cert to use after it receives the *first* client
message.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/t
On Fri, Oct 11, 2019 at 10:28 AM Salz, Rich wrote:
> *>*Isn't that more complicated than sending the SNI in the second client
> message, though?
>
>
> The server needs to know which cert to use after it receives the **first**
> client message.
>
If the CDN ---> Origin traffic is IPv6, there's no
27 matches
Mail list logo
