ost (if not all) of that disappointment has nothing to do with TLS.
Ciao
Hannes
Gesendet: Donnerstag, 08. November 2018 um 09:44 Uhr
Von: "Ryan Carboni"
An: tls@ietf.org
Betreff: [TLS] Enforcing Protocol Invariants
Hmm. TLS has gotten too complex. How does one create a new proto
On Sun, Nov 18, 2018 at 1:52 PM Viktor Dukhovni wrote:
>
>
>
> > On Nov 18, 2018, at 4:27 PM, Salz, Rich wrote:
> >
> >> [ I don't know why you would choose to argue this point, let's not
> >> confuse TLS with the CA/B forum WebPKI in browsers. My post was
> >> about TLS.
> >
> > I
>[ I don't know why you would choose to argue this point, let's not
confuse TLS with the CA/B forum WebPKI in browsers. My post was
about TLS.
I am not. You say TLS is CA/B WebPKI. I say TLS favors X509 CA-trust model,
and in fact has it as its default. For example, in TLS
On Sun, Nov 18, 2018 at 02:30:53PM +, Salz, Rich wrote:
> >[ FWIW, TLS is trust-model agnostic, it is the WebPKI that uses the
> usual panoply of CAs. ]
>
> No, it is not agnostic. It does support other trust models -- raw keys,
> PGP web-of-trust -- but it's default and primary
>[ FWIW, TLS is trust-model agnostic, it is the WebPKI that uses the
usual panoply of CAs. ]
No, it is not agnostic. It does support other trust models -- raw keys, PGP
web-of-trust -- but it's default and primary model from its inception is X509
and its (so ingrained you might
> On Nov 17, 2018, at 6:07 AM, Lanlan Pan wrote:
>
> And TLS's distribute certificate exchange maybe better than DNSSEC's
> centralized trust anchor.
In principle, yes, when one carefully selects just the appropriate
trust anchor(s) for a given task. Some applications do use specific
Personally I think the low rate of dnssec deployment on SLD authoritative
server and recursive resolver is the problem.
And TLS's distribute certificate exchange maybe better than DNSSEC's
centralized trust anchor.
Ryan Carboni 于2018年11月8日周四 下午4:44写道：
> Hmm. TLS has gotten too complex. How does
On Tuesday, 13 November 2018 00:13:58 CET Viktor Dukhovni wrote:
> [ I agree that this thread is off topic for this WG, thus below
> just a short OT aside on some oft-repeated critiques of DNSSEC. ]
>
> > On Nov 12, 2018, at 2:15 PM, Tony Arcieri wrote:
> >
> > The cryptography employed by
[ I agree that this thread is off topic for this WG, thus below
just a short OT aside on some oft-repeated critiques of DNSSEC. ]
> On Nov 12, 2018, at 2:15 PM, Tony Arcieri wrote:
>
> The cryptography employed by the X..509 PKI is substantially more modern than
> what's in DNSSEC. Much of
On Thu 2018-11-08 18:31:28 -0800, Ryan Carboni wrote:
> Encrypting common knowledge is cargo cult fetishism for cryptography. The
> files could be sent unencrypted, and protected using subresource integrity.
> If you are sharing the same data to multiple second parties to serve to a
> single third
On Fri, Nov 9, 2018 at 10:20 AM Ryan Carboni wrote:
> Okay, a modern browser connecting to a server owned by billion dollar
> corporations are able to implement the latest version of TLS, I’ll concede
> that. Regardless, I can only underline one point: any new protocol needs to
> break both
On Thu, Nov 8, 2018 at 9:31 PM Ryan Carboni wrote:
> On Thursday, November 8, 2018, Eric Rescorla wrote:
>
>> It's also worth noting that in practice, many sites are served on
>> multiple CDNs which do not share keying material.
>>
>
> Encrypting common knowledge is cargo cult fetishism for
On 2018-11-08 20:41 -0500, Jim Reid wrote:
On 8 Nov 2018, at 08:44, Ryan Carboni wrote:
This might be a radical proposal, but maybe the certificate hash could be
placed in a DNS TXT record.
[..]
If you need to put this hash in the DNS, you might as well get a type code
assigned for
> On Nov 8, 2018, at 9:51 PM, Eric Rescorla wrote:
>
> I don't know what you consider "widespread", but presently both Chrome and
> Firefox support TLS 1.3, and our data shows that about 5% of Firefox
> connections use TLS 1.3. Chrome's numbers are similar and the numbers from
> the server
Hello,
пт, 9 нояб. 2018 г., 7:03 Ryan Carboni rya...@gmail.com:
> I think I have implied that ClientHello is unneccesary to an extent, it
> can be replaced by a DNS TXT record.
>
> I think I implied that self-signed certificates are acceptable given the
> precedent of Let’s Encrypt and the use
On Thu, Nov 8, 2018 at 6:31 PM Ryan Carboni wrote:
> On Thursday, November 8, 2018, Eric Rescorla wrote:
>
>> It's also worth noting that in practice, many sites are served on
>> multiple CDNs which do not share keying material.
>>
>>
> Encrypting common knowledge is cargo cult fetishism for
On Thursday, November 8, 2018, Eric Rescorla wrote:
> It's also worth noting that in practice, many sites are served on
> multiple CDNs which do not share keying material.
>
>
Encrypting common knowledge is cargo cult fetishism for cryptography. The
files could be sent unencrypted, and
On 8 Nov 2018, at 08:44, Ryan Carboni wrote:
>
> This might be a radical proposal, but maybe the certificate hash could be
> placed in a DNS TXT record.
This is a bad idea.
Overloading TXT records with special semantics rarely, if ever, has a happy
ending. For instance application software
> On Nov 8, 2018, at 4:34 AM, Salz, Rich wrote:
>
> What makes you say that? Please be specific about what you think should be
> taken out.
One example area where the complexity is noticeably high:
* Certificate selection metadata specificity seems to far exceed
plausible diversity of
Hi Ryan,
Thanks for your comments.
On Thu, Nov 8, 2018 at 12:44 AM Ryan Carboni wrote:
> Hmm. TLS has gotten too complex. How does one create a new protocol? Maybe
> we should ask Google.
>
> The SSHFP DNS record exists. DNSSEC exists.
>
> This might be a radical proposal, but maybe the
I think I have implied that ClientHello is unneccesary to an extent, it can
be replaced by a DNS TXT record.
I think I implied that self-signed certificates are acceptable given the
precedent of Let’s Encrypt and the use of DNSSEC (has there been evidence
of DNS spoofing attacks against a CA?).
>Hmm. TLS has gotten too complex.
What makes you say that? Please be specific about what you think should be
taken out.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
;
Subject: Re: [TLS] Enforcing Protocol Invariants
This scheme probably isn't sufficient by itself, since a middlebox just has to
be aware of the anti-ossification extension and can parse the server's response
by decrypting it with the known mapping (either from the RFC or fetching the
latest updated
n
Sent: Tuesday, June 12, 2018 12:28 PM
To:
Subject: [TLS] Enforcing Protocol Invariants
Hi all,
Now that TLS 1.3 is about done, perhaps it is time to reflect on the
ossification problems.
TLS is an extensible protocol. TLS 1.3 is backwards-compatible and may be
incrementally roll
The two mechanisms address different targets but overall I prefer the
design of the new proposal.
Yours,
Daniel
On Wed, Jun 13, 2018 at 4:29 PM, David Benjamin
wrote:
> Are you asking about this new proposal (which still needs an amusing
> name), or the original GREASE mechanism?
>
> The
On Wed, Jun 13, 2018 at 5:04 PM Christopher Wood <
christopherwoo...@gmail.com> wrote:
> On Wed, Jun 13, 2018 at 11:06 AM Alessandro Ghedini
> wrote:
> >
> > On Tue, Jun 12, 2018 at 12:27:39PM -0400, David Benjamin wrote:
> > > Hi all,
> > >
> > > Now that TLS 1.3 is about done, perhaps it is
On Wed, Jun 13, 2018 at 11:06 AM Alessandro Ghedini
wrote:
>
> On Tue, Jun 12, 2018 at 12:27:39PM -0400, David Benjamin wrote:
> > Hi all,
> >
> > Now that TLS 1.3 is about done, perhaps it is time to reflect on the
> > ossification problems.
> >
> > TLS is an extensible protocol. TLS 1.3 is
Are you asking about this new proposal (which still needs an amusing name),
or the original GREASE mechanism?
The original GREASE mechanism was only targetting ClientHello intolerance
in servers. It's true that it uses specific values, and indeed there is
nothing stopping buggy implementations
I also support something is being done in this direction. I like the idea
of taking ephemeral non allocated code points.
What is not so clear to me is how GREASE prevents a buggy implementations
from behaving correctly for GREASE allocated code points, while remaining
buggy for the other
On Tue, Jun 12, 2018 at 12:27:39PM -0400, David Benjamin wrote:
> Hi all,
>
> Now that TLS 1.3 is about done, perhaps it is time to reflect on the
> ossification problems.
>
> TLS is an extensible protocol. TLS 1.3 is backwards-compatible and may be
> incrementally rolled out in an existing
Hi all,
Now that TLS 1.3 is about done, perhaps it is time to reflect on the
ossification problems.
TLS is an extensible protocol. TLS 1.3 is backwards-compatible and may be
incrementally rolled out in an existing compliant TLS 1.2 deployment. Yet
we had problems. Widespread non-compliant
31 matches
Mail list logo
