I see one possible problem with TLS1.3 not being a superset of TLS1.2.
Consider the following:
Server which supports TLSv1.3 but is configured to accept only AES256
ciphers.
Client which advertises TLSv1.3, but no support for AES256-GCM. The client
advertises also CBC ciphers (both AES128 a
On Tue, Jul 28, 2015 at 05:41:58PM +0200, Hubert Kario wrote:
> I see one possible problem with TLS1.3 not being a superset of TLS1.2.
>
> Consider the following:
> Server which supports TLSv1.3 but is configured to accept only AES256
> ciphers.
>
> Client which advertises TLSv1.3, but no suppor
Sent from the right email this time. (Sorry folks who got it twice. One of
these days I'll not mess this up! :-) )
On Tue, Jul 28, 2015 at 6:28 PM David Benjamin wrote:
> On Fri, Jul 24, 2015 at 1:02 AM Andrei Popov
> wrote:
>
>> Thanks for the detailed comments, Ilari.
>>
>> Based on the discu
On Wed, Jul 22, 2015 at 1:16 PM, Viktor Dukhovni
wrote:
> On Wed, Jul 22, 2015 at 07:45:17AM -0400, Paul Wouters wrote:
>
> > I think the server should stick to one chain, from the root to itself,
> > so it does not have to deal with variable chain blobs per client.
> > That will allow server cod
On 7/28/15 5:44 PM, Shumon Huque wrote:
> I'd prefer to wait till the trans-ct-dnssec draft has progressed a bit
> more before considering DNSSEC key transparency issues.
>
> It looks like that draft proposes SCT RRs (with DS+chain data in them,
> signed by log providers), so we could in the futu
On Tue, Jul 28, 2015 at 09:44:34PM -0400, Shumon Huque wrote:
> For the following hypothetical example:
>
> _443._tcp.www.example.com. IN CNAMEca.example.net.
> ca.example.net. IN TLSA 2 0 1
This is simpler than the general case, everything is still "linear",
because
On Tue, Jul 28, 2015 at 10:05 PM, Viktor Dukhovni
wrote:
> On Tue, Jul 28, 2015 at 09:44:34PM -0400, Shumon Huque wrote:
>
> This is no longer the DNS response to a single query (iterative
> resolvers generally chase CNAMEs), since one first CNAME expands
> the original target hostname to obtain
On Tue, Jul 28, 2015 at 10:43:29PM -0400, Shumon Huque wrote:
> > This is no longer the DNS response to a single query (iterative
> > resolvers generally chase CNAMEs), since one first CNAME expands
> > the original target hostname to obtain the TLSA base domain (provided
> > the CNAME chain is va
