Re: [TLS] Should we require implementations to send alerts?

On Friday 18 September 2015 15:13:37 Bill Frantz wrote: > On 9/18/15 at 4:27 AM, hka...@redhat.com (Hubert Kario) wrote: > >except that a TLS1.3 version intolerant implementation won't > >show its ugly head until TLS1.4 gets deployed > > Is there a reason a test suite can't offer TLS 1.4, even if

Re: [TLS] Should we require implementations to send alerts?

On Friday 18 September 2015 13:24:33 Brian Smith wrote: > On Fri, Sep 18, 2015 at 4:36 AM, Hubert Kario wrote: > > On Friday 18 September 2015 00:58:19 Martin Rex wrote: > > > Easier troubleshooting is IMO a sufficient rationale to justify > > > existence of the alert

Re: [TLS] Review of PR #209

Daniel Kahn Gillmor writes: > Consider a server has an ongoing session wrapped in TLS that uses client > authentication to approve or deny some requests from the client. It > remembers what requests the client has made as some sort of relevant > state. Let's take an

Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)

On Fri 2015-08-28 09:22:52 -0700, Viktor Dukhovni wrote: > So the client would now need to cache some session data by transport > address, and other data by name and port. That's rather complex. This is already done by HTTP/2 clients, since they can access multiple

Re: [TLS] encrypted content type and padding

On Mon 2015-09-21 04:43:27 -0700, Watson Ladd wrote: > Is this actually true in the second pull request? No: a moment of > actually reading reveals that the string is inside an AEAD encrypted > packet. There is no way in which this padding could be modified for > use in a

[TLS] Fall Interim webex/jabber details

Please note that I sent two webex invites one for each day and that they have different meeting #s but the same pwd: Monday: https://mailarchive.ietf.org/arch/msg/tls/2wD0hlicN7oaBbWO8qKqtXAhfos Tuesday: https://mailarchive.ietf.org/arch/msg/tls/mP16zjy9h7eH2y02WTEnTqDKey4 We’re starting at 9

Re: [TLS] Review of PR #209

On Sun 2015-09-20 22:38:45 -0700, Karthikeyan Bhargavan wrote: > As dkg points out, dynamically authenticating clients later in the connection > brings up > API issues of how to notify the application about the scope of this new > authentication event. > > I think

[TLS] '15 TLS WG interim materials

I’ve uploaded the slides I’ve received to: https://www.ietf.org/proceedings/interim/2015/09/21/tls/proceedings.html spt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

[TLS] WebEx meeting invitation: '15 Fall Interim

Hello, TLS Working Group invites you to join this WebEx meeting. '15 Fall Interim Tuesday, September 22, 2015 9:00 am | Pacific Daylight Time (San Francisco, GMT-07:00) | 1 hr JOIN WEBEX MEETING https://ietf.webex.com/ietf/j.php?MTID=m3a04aa0bc197fc8e2a2c45b34ac5136b Meeting number: 648

Re: [TLS] Review of PR #209

On Sep 21, 2015 7:02 AM, "Ilari Liusvaara" wrote: > Under such assumption, even dynamic reauth in HTTP/1.1 is unsafe. If > one additionally assumes causality, dynamic reauth in non-pipelined > HTTP/1.1 may be safe, but dynamic reauth in HTTP/2 (or HTTP/1.1 with >

[TLS] WebEx meeting invitation: '15 Fall Interim

Hello, TLS Working Group invites you to join this WebEx meeting. '15 Fall Interim Monday, September 21, 2015 9:00 am | Pacific Daylight Time (San Francisco, GMT-07:00) | 8 hrs JOIN WEBEX MEETING https://ietf.webex.com/ietf/j.php?MTID=mf2ecbe12f0cf7a93601297ea89cbf5ce Meeting number: 642