On Wed, 4 Jul 2018, Eric Rescorla wrote:
> > > Do we have a count of major implementors who say they will do so?
> >
> > Well, what is a "major implementation"?
>
> Well, we could start with "what implementations are going to do this"?
[postfix and openssl
On Wed, Jul 04, 2018 at 08:42:38PM -0700, Eric Rescorla wrote:
> It would be nice to hear from those maintainers, as well as from some of
> the bigger email senders (e.g., GMail, Yahoo Mail, etc.)
The question is premature, some implementations are not candidate
early adopters. Once library
On Wed, 4 Jul 2018, Eric Rescorla wrote:
In any case, as Martin Thomson says, we have a perfectly good
extension mechanism which can be used to add pinning later without creating any
placeholder here.
The IETF should not publish security protocols that are trivially downgraded.
The work
On Wed, Jul 04, 2018 at 07:46:13PM -0700, Eric Rescorla wrote:
> > > Do we have a count of major implementors who say they will do so?
> >
> > Well, what is a "major implementation"?
>
> Well, we could start with "what implementations are going to do this"?
Since Postfix supports not just
On Wed, Jul 04, 2018 at 06:51:46PM -0800, Melinda Shore wrote:
> On 7/4/18 6:33 PM, Viktor Dukhovni wrote:
> > I thought the authors wanted this done quickly, but lately they
> > seem to be in no rush to get the document finished.
>
> I'm still trying to figure out a way forward that's useful
>
On 7/4/18 6:33 PM, Viktor Dukhovni wrote:
> I thought the authors wanted this done quickly, but lately they
> seem to be in no rush to get the document finished.
I'm still trying to figure out a way forward that's useful
for the people who intend to use this extension and that doesn't
add cruft
On Wed, Jul 04, 2018 at 06:34:44PM -0700, Eric Rescorla wrote:
> > 1. Do you support the working group taking on future work on a pinning
> > mechanism (based on the modifications or another approach)?
>
> Unsure. I'd like to see some real evidence that it will be widely consumed.
> Do we have
David Benjamin writes:
>The bad feedback was not even at a 2048-bit minimum, but a mere 1024-bit
>minimum. (Chrome enabled far more DHE ciphers than others, so we encountered
>a lot of this.) 2048-bit was completely hopeless. At the time of removal, 95%
>of DHE negotiations made by Chrome used
On Tue, Jun 26, 2018 at 2:21 PM Joseph Salowey wrote:
> 1. Do you support the working group taking on future work on a pinning
> mechanism (based on the modifications or another approach)?
I don't think that pinning is a good idea. We've experience that
suggests that it's more of a footgun
On Wed, Jul 04, 2018 at 06:34:44PM -0700, Eric Rescorla wrote:
> 3. Do you support the proof of denial of existence text in the revision?
>
> The mechanism seems fine, but it doesn't seem to me that the specification
> is clear on what the semantics are. I think what they are is that you can
>
Kurt Roeckx writes:
>The extensions are not related to TLS, but are extentions / add-ons of the
>browser itself. Firefox dropped support for the old way of doing extensions
>in version 57. They also added the WebExtensions API that is also implemented
>in other browsers. This required major
Ilari Liusvaara writes:
>Chrome initially did that. It caused quite a lot of bad feedback from owners
>of various bad embedded stuff. The thread on relevant forums was quite
>something. Hundreds of messages blaming Google for breaking stuff.
If there were "hundreds of messages" doesn't that
On Mon, Jun 25, 2018 at 9:20 PM, Joseph Salowey wrote:
> Hi Folks,
>
> There has been some discussion with a small group of folks on github -
> https://github.com/tlswg/dnssec-chain-extension/pull/19. I want to make
> sure there is consensus in the working group to take on the pinning work
>
2018-07-05 3:23 GMT+09:00 Eric Rescorla :
>
>
> On Wed, Jul 4, 2018 at 11:07 AM, Stephen Farrell
> wrote:
>>
>>
>> Hiya,
>>
>> Just on this bit...
>>
>> On 04/07/18 18:20, Eric Rescorla wrote:
>> > The structure started a bit simpler and got new features to
>> > deal with new issues.
On Wed, Jul 4, 2018 at 7:55 PM Hubert Kario wrote:
> Despite this, is it correct to terminate a connection with "illegal_parameter"
> upon receiving a Finished handshake message with a 100 byte payload? or a 20
> byte payload? My opinion is that it is not, "decode_error" is more specific so
> it
Sent from my mobile device
> On Jul 4, 2018, at 2:20 PM, Eric Rescorla wrote:
>
> Hi Kathleen,
>
>> On Wed, Jul 4, 2018 at 11:10 AM, Kathleen Moriarty
>> wrote:
>> I’m also fine with the work going forward, however it was only in March that
>> EKR assured people concerned that they don’t
On Wed, Jul 4, 2018 at 11:07 AM, Stephen Farrell
wrote:
>
> Hiya,
>
> Just on this bit...
>
> On 04/07/18 18:20, Eric Rescorla wrote:
> > The structure started a bit simpler and got new features to
> > deal with new issues. Specifically:
> >
> > - The checksum is intended to deal with corruption
Hi Kathleen,
On Wed, Jul 4, 2018 at 11:10 AM, Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:
> I’m also fine with the work going forward, however it was only in March
> that EKR assured people concerned that they don’t need to worry about SNI
> being encrypted repeating similar
Sent from my mobile device
> On Jul 4, 2018, at 9:01 AM, Stephen Farrell wrote:
>
>
> Hiya,
>
>> On 03/07/18 00:39, Eric Rescorla wrote:
>> Hi folks,
>>
>> I just submitted:
>>
>> https://tools.ietf.org/html/draft-rescorla-tls-esni-00
>
> Thanks for writing that up. I think it's an
Hiya,
Just on this bit...
On 04/07/18 18:20, Eric Rescorla wrote:
> The structure started a bit simpler and got new features to
> deal with new issues. Specifically:
>
> - The checksum is intended to deal with corruption
I'm not sure I see why that's needed, but I believe you if
you say it
Stephen,
Thanks for your comments.
On Wed, Jul 4, 2018 at 6:01 AM, Stephen Farrell
wrote:
>
> Hiya,
>
> On 03/07/18 00:39, Eric Rescorla wrote:
> > Hi folks,
> >
> > I just submitted:
> >
> > https://tools.ietf.org/html/draft-rescorla-tls-esni-00
>
> Thanks for writing that up. I think it's
On Wed, Jul 4, 2018 at 6:36 AM, Hubert Kario wrote:
> On Wednesday, 4 July 2018 15:00:18 CEST Eric Rescorla wrote:
> > I think it's a close call, because the length is sort of external to the
> > language.
>
> which language? the decode_error alert description literally says "length
> of
> the
On Wed, Jul 4, 2018 at 6:08 AM, Ilari Liusvaara
wrote:
> On Wed, Jul 04, 2018 at 05:56:07AM -0700, Eric Rescorla wrote:
> > On Tue, Jul 3, 2018 at 9:48 PM, Ilari Liusvaara <
> ilariliusva...@welho.com>
> > wrote:
> >
> > > On Mon, Jul 02, 2018 at 04:39:14PM -0700, Eric Rescorla wrote:=
> > > > I
On Wed, Jul 4, 2018 at 6:27 AM, Hubert Kario wrote:
> On Wednesday, 4 July 2018 15:06:27 CEST Ilari Liusvaara wrote:
> > On Wed, Jul 04, 2018 at 02:42:51PM +0200, Hubert Kario wrote:
> > > All the implementations I deal with in my day-to-day work fail to
> handle
> > > the 0-RTT client hello
On Tue, Jul 3, 2018 at 10:08 AM Bret Jordan wrote:
> From my personal perspective, we need to be careful with all of these
> efforts. It feels like the pendulum has swung so far to one side, the side
> of privacy-at-any-cost, that we are unknowingly increasing the risk to
> individuals and
On Wed, Jul 4, 2018 at 11:15 AM David Benjamin
wrote:
> On Wed, Jul 4, 2018 at 4:41 AM Nikos Mavrogiannopoulos
> wrote:
>
>> On Wed, 2018-07-04 at 11:15 +0300, Ilari Liusvaara wrote:
>> > On Wed, Jul 04, 2018 at 07:57:41AM +, Peter Gutmann wrote:
>> > > Ilari Liusvaara writes:
>> > >
>> >
On Wed, Jul 4, 2018 at 8:15 AM, David Benjamin
wrote:
>
> Indeed. The bad feedback was not even at a 2048-bit minimum, but a mere
> 1024-bit minimum. (Chrome enabled far more DHE ciphers than others, so we
> encountered a lot of this.) 2048-bit was completely hopeless. At the time
> of removal,
On Tue, Jul 3, 2018 at 5:19 PM Brian Sniffen wrote:
> Hanno Böck writes:
>
> > So-called "Enterprise" infrastructure has delayed the work of this group
> > for at least a year. Noone of the people creating that mess has reached
> > out to this group to explain why they constantly break TLS -
On Wed, Jul 4, 2018 at 4:41 AM Nikos Mavrogiannopoulos
wrote:
> On Wed, 2018-07-04 at 11:15 +0300, Ilari Liusvaara wrote:
> > On Wed, Jul 04, 2018 at 07:57:41AM +, Peter Gutmann wrote:
> > > Ilari Liusvaara writes:
> > >
> > > > More serious problem is servers returning too small modulus
>The following is an attempt to condense some off-list discussions with
> SCADA
folks about the broken behaviour of some browsers when it comes to
interaction
Thanks for doing this. It's always useful to get real-world usage information,
especially in the non-Web world.
>if the interpretation of "I know this _message_ _length_ is wrong because
> of
some other values I negotiated before, so I'll send illegal_parameter" was
correct, then overflow_error, decrypt_error and probably few others would
also
need to be replaced with
On Wednesday, 4 July 2018 15:00:18 CEST Eric Rescorla wrote:
> I think it's a close call, because the length is sort of external to the
> language.
which language? the decode_error alert description literally says "length of
the message was incorrect."
> That's why, for instance, NSS sends
On Wednesday, 4 July 2018 15:06:27 CEST Ilari Liusvaara wrote:
> On Wed, Jul 04, 2018 at 02:42:51PM +0200, Hubert Kario wrote:
> > All the implementations I deal with in my day-to-day work fail to handle
> > the 0-RTT client hello correctly when the 0-RTT support is not enabled on
> > the server.
On Wed, Jul 04, 2018 at 05:56:07AM -0700, Eric Rescorla wrote:
> On Tue, Jul 3, 2018 at 9:48 PM, Ilari Liusvaara
> wrote:
>
> > On Mon, Jul 02, 2018 at 04:39:14PM -0700, Eric Rescorla wrote:=
> > > I am working on an implementation for NSS/Firefox and I know some
> > > others are working on
On Wed, Jul 04, 2018 at 02:42:51PM +0200, Hubert Kario wrote:
> All the implementations I deal with in my day-to-day work fail to handle the
> 0-RTT client hello correctly when the 0-RTT support is not enabled on the
> server.
>
> I.e. they ignore the MUST clause from
>
Hiya,
On 03/07/18 00:39, Eric Rescorla wrote:
> Hi folks,
>
> I just submitted:
>
> https://tools.ietf.org/html/draft-rescorla-tls-esni-00
Thanks for writing that up. I think it's an interesting
addition to the set of potential solutions.
>
> This draft describes a DNS-based approach to
I think it's a close call, because the length is sort of external to the
language. That's why, for instance, NSS sends "illegal_parameter". So,
absent specific text about this value, I think this is something we can
leave to the implementations.
-Ekr
On Wed, Jul 4, 2018 at 2:54 AM, Hubert
On Tue, Jul 3, 2018 at 9:48 PM, Ilari Liusvaara
wrote:
> On Mon, Jul 02, 2018 at 04:39:14PM -0700, Eric Rescorla wrote:=
> > I am working on an implementation for NSS/Firefox and I know some
> > others are working on their own implementations, so hopefully we can
> > do some interop in Montreal.
All the implementations I deal with in my day-to-day work fail to handle the
0-RTT client hello correctly when the 0-RTT support is not enabled on the
server.
I.e. they ignore the MUST clause from
https://tools.ietf.org/html/draft-ietf-tls-tls13-28#page-58 stating that the
server can handle an
On Wed, Jul 04, 2018 at 12:01:18PM +0200, Hubert Kario wrote:
> what "browser extensions"? you can't really do a modern TLS 1.2 without
> extensions, let alone TLS 1.3 (which is now enabled by default in NSS). I'm
> quite sure NSS didn't drop any consequential ones...
The extensions are not
On Wednesday, 4 July 2018 09:45:36 CEST Peter Gutmann wrote:
> Martin Thomson writes:
> >As of the latest version, things should be the same - extensions shouldn't
> >affect whether connections work.
>
> Sure, the only reason for mentioning the "last version with extensions" is
> that apparently
Despite this, is it correct to terminate a connection with "illegal_parameter"
upon receiving a Finished handshake message with a 100 byte payload? or a 20
byte payload? My opinion is that it is not, "decode_error" is more specific so
it should be used instead.
Specification says the
On Wed, 4 Jul. 2018, 18:42 Nikos Mavrogiannopoulos,
wrote:
> We had similar experience when we required a minimum of 2048-bit
> modulus for all TLS connections in Fedora 28 beta irrespective of back-
> end lib. It broke connections to VPN servers and web internal web sites
> and we had to revert
On Wed, 2018-07-04 at 11:15 +0300, Ilari Liusvaara wrote:
> On Wed, Jul 04, 2018 at 07:57:41AM +, Peter Gutmann wrote:
> > Ilari Liusvaara writes:
> >
> > > More serious problem is servers returning too small modulus due
> > > lack of
> > > negotiation. Which was the reason why Chrome
On Wed, Jul 04, 2018 at 07:57:41AM +, Peter Gutmann wrote:
> Ilari Liusvaara writes:
>
> >More serious problem is servers returning too small modulus due lack of
> >negotiation. Which was the reason why Chrome disabled DHE.
>
> Why not reject the handshake if the modulus is too small,
Ilari Liusvaara writes:
>More serious problem is servers returning too small modulus due lack of
>negotiation. Which was the reason why Chrome disabled DHE.
Why not reject the handshake if the modulus is too small, rather than
disabling all DHE suites on the off chance that the server returns a
Martin Thomson writes:
>How is the client doing any of this? The server picks the cipher suite.
Sorry, I meant the client only offers pure-RSA, not DHE+RSA, so the server is
forced to pick pure-RSA, e.g.:
Chrome:
Offered suite: TLS_RSA_WITH_AES_128_CBC_SHA.
Accepted suite:
On Wed, Jul 04, 2018 at 05:05:08PM +1000, Martin Thomson wrote:
> On Wed, Jul 4, 2018 at 4:53 PM Peter Gutmann
> wrote:
> > ... Client negotiates non-PFS pure-RSA and ignores PFS DHE ...
>
> How is the client doing any of this? The server picks the cipher suite.
>
> > Least broken browser:
On Wed, Jul 4, 2018 at 4:53 PM Peter Gutmann wrote:
> ... Client negotiates non-PFS pure-RSA and ignores PFS DHE ...
How is the client doing any of this? The server picks the cipher suite.
> Least broken browser: Firefox (at least for the last proper version they
> released)
Newer versions
The following is an attempt to condense some off-list discussions with SCADA
folks about the broken behaviour of some browsers when it comes to interaction
with SCADA devices running TLS. tl;dr: Chrome is practically unusable, at the
other end of the scale Firefox is fine, and there's something
50 matches
Mail list logo
