On Sat, Dec 08, 2018 at 11:42:56AM -0700, David Fifield wrote:
> On Sat, Dec 08, 2018 at 06:38:30PM +0200, Ilari Liusvaara wrote:
> > While thinking about the previous, I ran into some issues with the
> > split mode. Firstly, if the fronting server does not encrypt the
> > client_hello when
On Sat, Dec 08, 2018 at 06:38:30PM +0200, Ilari Liusvaara wrote:
> While thinking about the previous, I ran into some issues with the
> split mode. Firstly, if the fronting server does not encrypt the
> client_hello when transmitting it to backend server, passive attack
> can match incoming
On Tue, Nov 20, 2018 at 09:45:51PM +, Stephen Farrell wrote:
>
> I'm fine that such changes don't get done for a while (so
> I or my student get time to try make stuff work:-) and
> it might in any case take a while to figure out how to
> handle the multi-CDN use-case discussed in Bangkok
On Tue, Nov 20, 2018 at 11:28 PM Paul Wouters wrote:
> Although, if I am correct, the epectation is that all of this data
> will be used without mandating DNSSEC validation, so all these
> security parameters could be modified by any DNS party in transit
> to try and break the protocol or
* Paul Wouters:
> On Wed, 21 Nov 2018, Stephen Farrell wrote:
>
>>> We currently permit >1 RR, but
>>> actually
>>> I suspect that it would be better to try to restrict this.
>>
>> Not sure we can and I suspect that'd raise DNS-folks' hackles,
>> but maybe I'm wrong.
>
> I think the SOA record is
On Wed, 21 Nov 2018, Stephen Farrell wrote:
We currently permit >1 RR, but
actually
I suspect that it would be better to try to restrict this.
Not sure we can and I suspect that'd raise DNS-folks' hackles,
but maybe I'm wrong.
I think the SOA record is the only exception allowed (and there
On Tue, Nov 20, 2018 at 7:40 PM Salz, Rich wrote:
>
>- No, I don't think so. The server might choose to not support one of
>the TLS 1.3 ciphers, for instance. And even if that weren't true, how would
>we add new ciphers?
>
>
>
> Standard TLS negotiation. I don’t see that we need to
* No, I don't think so. The server might choose to not support one of the
TLS 1.3 ciphers, for instance. And even if that weren't true, how would we add
new ciphers?
Standard TLS negotiation. I don’t see that we need to specify ciphers at the
DNS layer. A client with new ciphers will add
On Tue, Nov 20, 2018 at 6:04 PM Salz, Rich wrote:
> >Sure a list of ciphersuites isn't bad. But the current
> design has a set of keys and a set of ciphersuites and a
> set of extensions and a set of Rdata values in the RRset.
>
> Since this is defined for TLS 1.3 with all known-good
>Sure a list of ciphersuites isn't bad. But the current
design has a set of keys and a set of ciphersuites and a
set of extensions and a set of Rdata values in the RRset.
Since this is defined for TLS 1.3 with all known-good ciphers, can't that field
be eliminated?
>I'd bet a
(Trimming bits down...)
On 21/11/2018 00:59, Eric Rescorla wrote:
> On Tue, Nov 20, 2018 at 4:36 PM Stephen Farrell
>> Aren't DNS answers RRsets? I may be wrong but I thought DNS
>> clients have to handle that anyway,
>
>
> Not really, because any of them is co-valid.
Sure, in DNS terms.
>
On Tue, Nov 20, 2018 at 4:36 PM Stephen Farrell
wrote:
>
> Hiya,
>
> On 20/11/2018 23:30, Eric Rescorla wrote:
> > On Tue, Nov 20, 2018 at 1:46 PM Stephen Farrell <
> stephen.farr...@cs.tcd.ie>
> > wrote:
> >
> >>
> >> Hiya,
> >>
> >> I've started to try code up an openssl version of this. [1]
>
Hiya,
On 20/11/2018 23:30, Eric Rescorla wrote:
> On Tue, Nov 20, 2018 at 1:46 PM Stephen Farrell
> wrote:
>
>>
>> Hiya,
>>
>> I've started to try code up an openssl version of this. [1]
>> (Don't be scared though, it'll likely be taken over by a
>> student in the new year:-)
>>
>
> Thanks
On Tue, Nov 20, 2018 at 1:46 PM Stephen Farrell
wrote:
>
> Hiya,
>
> I've started to try code up an openssl version of this. [1]
> (Don't be scared though, it'll likely be taken over by a
> student in the new year:-)
>
Thanks for your comments. Responses below.
>From doing that I think the
Hiya,
I've started to try code up an openssl version of this. [1]
(Don't be scared though, it'll likely be taken over by a
student in the new year:-)
From doing that I think the ESNIKeys structure is too
complicated and could do with a bunch of changes. The ones
I'd argue for would be:
- use a
15 matches
Mail list logo
