Hey TLS folks--
apologies for the delay in sending these pull requests.
encrypted content type:
---
https://github.com/tlswg/tls13-spec/pull/51
This should be uncontroversial, and just needed freshening against the
current draft.
padding:
We're now proposing that
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
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 mechanism and a "SHOULD send
On Monday 21 September 2015 00:20:21 Dave Garrett wrote:
> On Sunday, September 20, 2015 10:59:58 pm William Whyte wrote:
> > might be worth increasing the maximum extension size to 2^24-1 for
> > TLS 1.3.
> No, I don't think the limit can be raised. The general ClientHello
> format has to stay fro
On Mon, Sep 21, 2015 at 3:19 AM, Jeffrey Walton wrote:
> On Mon, Sep 21, 2015 at 3:02 AM, Daniel Kahn Gillmor
> wrote:
>> Hey TLS folks--
>>
>> apologies for the delay in sending these pull requests.
>>
>> encrypted content type:
>> ---
>>
>> https://github.com/tlswg/tls13-spe
On Mon, Sep 21, 2015 at 07:38:45AM +0200, Karthikeyan Bhargavan wrote:
>
> In other words, if we do allow this change to client authentication,
> to be safe, we must analyze the resulting protocol *as if*
> applications will use the authentication event to attest to all data,
> past and present, t
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 1
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 0
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 P
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
> pipelining) is still unsafe.
What
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 it is inevitable that implemen
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 side-channel attack.
In
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
servers at the same address:p
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
On Monday, September 21, 2015 03:02:47 am Daniel Kahn Gillmor wrote:
> encrypted content type:
> ---
>
> https://github.com/tlswg/tls13-spec/pull/51
Basing the padding PR(s) on top of this might be a good idea, seeing as it's
desired to do this correctly.
One thought about d
On Monday 21 September 2015 15:04:17 Dave Garrett wrote:
> On Monday, September 21, 2015 07:22:03 am Hubert Kario wrote:
> > On Monday 21 September 2015 00:20:21 Dave Garrett wrote:
> > > A strong reason is it not being possible to change due to the need
> > > for TLS 1.3 clients to be able to conn
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 imap server working with a c
17 matches
Mail list logo
