I think there may be lower overhead ways (that don’t require frequent TLS
library code changes) to prevent ossification of the ServerHello using a
mechanism similar to the cleartext cipher in quic. For example, a client could
offer an “anti-ossification” extension containing an identifier that
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
Thanks for the replies; I put a summary in
https://github.com/openssl/openssl/issues/6484 for OpenSSL
(ooh, look, I got a DMARC work-around :)
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
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
This is BoringSSL's interpretation as well. We don't support renegotiation
on the server at all, but our server still implements the
renegotiation_info extension in the degenerate case for the initial
handshake. It is vacuously true that all renegotiations we'll perform on
that connection are
On Wed, Jun 13, 2018 at 07:47:11PM +, Salz, Rich wrote:
> It seems that the semantics of the "renegotiation_info" extension are
> slightly muddy. Qualys understands it to mean that the server will
> not perform insecure renegotiation, full stop. But OpenSSL further
> understands it to mean
Hi Rich,
I think that the Qualys interpretation might be safer. That is, you
probably should send R-I always. See Karthik's response to my
suggestion that it might be OK to omit R-I in some cases:
https://mailarchive.ietf.org/arch/msg/tls/TfiUa3M390augtvUoxH2D7L5LGM
On Wed, Jun 13, 2018 at
It seems that the semantics of the "renegotiation_info" extension are slightly
muddy. Qualys understands it to mean that the server will not perform insecure
renegotiation, full stop. But OpenSSL further understands it to mean that the
server *will* perform secure negotiation. OpenSSL therefore
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
On Saturday, 9 June 2018 03:13:29 CEST Christian Huitema wrote:
> On 6/8/2018 7:35 AM, David Benjamin wrote:
> > On Fri, Jun 8, 2018 at 10:07 AM R duToit wrote:
> > > GREASE values should not make their way into code. The whole
> >
> > point is to get code used to the fact that
On Wednesday, 6 June 2018 21:08:28 CEST David Benjamin wrote:
> 1) "ignore/" is a pretty long ALPN prefix and also might encourage folks to
> parse out the "ignore/" string. Instead, what do folks think about just
> using two byte strings. Perhaps the same two byte pattern we're currently
> doing?
On Monday, 11 June 2018 23:52:55 CEST David Benjamin wrote:
> In both TLS 1.2 and TLS 1.3, SHA-256 isn't hardcoded per se. It's a
> function of the cipher suite you negotiate (and also, separately, the
> signature algorithm you negotiate). That said, in practice, both are pretty
> solidly
15 matches
Mail list logo
