> I think we would like to avoid deliberately breaking these devices with TLS
> 1.3. (I think TLS 1.3 has been subject to enough friction already.)
I'm not sure I can agree with fixing TLS 1.3 so that it can work with
potentially backdoored devices. Isn't it the kind of friction we would
want?
D
Good catch. Thanks.
-Ekr
On Wed, Dec 27, 2017 at 10:35 AM, Ilari Liusvaara
wrote:
> On Wed, Dec 27, 2017 at 07:01:30AM -0800, Eric Rescorla wrote:
> > PR:
> > https://github.com/tlswg/tls13-spec/pull/1128
> >
> > I'll merge this next week, barring strong objection.
> >
>
> You might want to re
On Wed, Dec 27, 2017 at 07:01:30AM -0800, Eric Rescorla wrote:
> PR:
> https://github.com/tlswg/tls13-spec/pull/1128
>
> I'll merge this next week, barring strong objection.
>
You might want to rebase that and renumber to #51, now that extension
#50 is used for certificate signature algorithms.
PR:
https://github.com/tlswg/tls13-spec/pull/1128
I'll merge this next week, barring strong objection.
-Ekr
On Tue, Dec 19, 2017 at 8:28 AM, Adam Langley
wrote:
> On Tue, Dec 19, 2017 at 5:07 AM, Stephen Farrell <
> stephen.farr...@cs.tcd.ie> wrote:
>
>> I'm not sure I agree renumbering is th
On Tue, Dec 19, 2017 at 5:07 AM, Stephen Farrell
wrote:
> I'm not sure I agree renumbering is the right reaction,
> though I don't object to that. This could be a case where
> it's overall better that those specific devices suffer
> breakage, and hopefully then do get firmware updated to
> suppor
> I'm not sure I agree renumbering is the right reaction, though I don't
> object to
> that. This could be a case where it's overall better that those specific
> devices
> suffer breakage, and hopefully then do get firmware updated to support
> TLS1.3 or TLS-without-extended-random-or-dual-ec
>
Hiya,
On 19/12/17 13:56, Salz, Rich wrote:
> “dropped as a bad idea” is an interesting end-state. Also “on hold
> for now” (which is how I want to see the TLS-breaking proposals).
>
> Having more I-D workflow options seems like something the IESG should
> take up.
>
Well, TBH I doubt it'd be
“dropped as a bad idea” is an interesting end-state. Also “on hold for now”
(which is how I want to see the TLS-breaking proposals).
Having more I-D workflow options seems like something the IESG should take up.
___
TLS mailing list
TLS@ietf.org
h
Hiya,
On 19/12/17 01:59, Salz, Rich wrote:
> However, since extension numbers are essentially infinite, this WG may
> consider renumbering key_share to avoid the issue.
>
>> I think this would be fine, but not imperative.
>
> I think it would almost be hypocritical if we did not do it.
>
I'm
However, since extension numbers are essentially infinite, this WG may
consider renumbering key_share to avoid the issue.
> I think this would be fine, but not imperative.
I think it would almost be hypocritical if we did not do it.
___
TLS mailing lis
Dear David, dear all,
> These printers use the RSA BSAFE library to implement TLS and this
> library implements the extended_random extension and assigns it number
> 40. This collides with the key_share extension and causes 1.3-capable
> handshakes to fail.
>
[..]
>
> (Lastly, we note that in the
On Mon, Dec 18, 2017 at 11:35 AM, David Benjamin
wrote:
>
>
> The web interface on some Canon printers breaks with 1.3-capable
> ClientHello messages. We have purchased one and confirmed this with a
> PIXMA MX492. User reports suggest that it also affects PIXMA MG3650
> and MX495 models. It poten
12 matches
Mail list logo
