On Thu, Oct 20, 2016 at 05:33:41PM -0700, Eric Rescorla wrote:
> We used to explicitly say that you had to check SNI for 0-RTT (but
> didn't say anything about resumption). On the principle that 0-RTT and
> resumption should be the same I removed that, but it turns out that
> the document doesn't a
On Thu, Oct 20, 2016 at 09:32:36AM -0700, Eric Rescorla wrote:
> Folks,
>
> I have just uploaded draft-ietf-tls-tls13-17.
Updated my own implementation from -16 to -17 (TODO: Add to
implementations page, it isn't any of the ones listed).
And since that implementation supports RFC7250 (for the se
On Fri, Oct 21, 2016 at 2:33 AM, Ilari Liusvaara
wrote:
> On Thu, Oct 20, 2016 at 09:32:36AM -0700, Eric Rescorla wrote:
> > Folks,
> >
> > I have just uploaded draft-ietf-tls-tls13-17.
>
> Updated my own implementation from -16 to -17 (TODO: Add to
> implementations page, it isn't any of the one
On 21 October 2016 at 19:55, Ilari Liusvaara wrote:
> Of course, defining the "same certificate" is
> way trickier than it initially seems
Not if you think simplistically: same octets in EE ASN1Cert in both handshakes.
___
TLS mailing list
TLS@ietf.org
Currently TLS has two alert descriptions for when there is no intersection
between ciphers/sigalgs/groups advertises by client and ones that are enabled
in server. It's the handshake_failure and insufficient_security alerts.
While it is a step in good direction in providing users with better mes
Andrei Popov wrote:
>
> Perhaps it's OK to resume a session with a different SNI if in this
> session the server has proved an identity that matches the new SNI.
> In order to enforce this, the server would have to cache (or save in
> the ticket) a list of identities it presented in each resumable
On Fri, Oct 21, 2016 at 04:39:59AM -0700, Eric Rescorla wrote:
> On Fri, Oct 21, 2016 at 2:33 AM, Ilari Liusvaara
> wrote:
>
> And since that implementation supports RFC7250 (for the server
> > certificate), here is my interpretation of it:
> >
> > The certificate type is sent in extensions of EE
On Fri, Oct 21, 2016 at 11:41:59PM +1100, Martin Thomson wrote:
> On 21 October 2016 at 19:55, Ilari Liusvaara wrote:
> > Of course, defining the "same certificate" is
> > way trickier than it initially seems
>
> Not if you think simplistically: same octets in EE ASN1Cert in both
> handshakes.
Ilari Liusvaara wrote:
> On Fri, Oct 21, 2016 at 11:41:59PM +1100, Martin Thomson wrote:
>> On 21 October 2016 at 19:55, Ilari Liusvaara
>> wrote:
>>> Of course, defining the "same certificate" is
>>> way trickier than it initially seems
>>
>> Not if you think simplistically: same octets in EE A
On Fri, Oct 21, 2016 at 12:38:29PM +1100, Martin Thomson wrote:
> So I think that the problem could be reduced in complexity. A little
> at least. The obvious consequence of changing SNI is that you end up
> somewhere different than last time. But we can still ensure that the
> connection is to
On Fri, Oct 21, 2016 at 04:35:12PM +0200, Martin Rex wrote:
> Ilari Liusvaara wrote:
> > On Fri, Oct 21, 2016 at 11:41:59PM +1100, Martin Thomson wrote:
> >> On 21 October 2016 at 19:55, Ilari Liusvaara
> >> wrote:
> >>> Of course, defining the "same certificate" is
> >>> way trickier than it ini
I am a bit worried about privacy implications of the SNI. Suppose that we
invent an obfuscation mechanism that prevents third parties to track which
service corresponds to an SNI string. The SNI would then be different for any
connection, including resumptions. Do we want to prevent that with a
On Fri, Oct 21, 2016 at 7:00 AM, Ilari Liusvaara
wrote:
> On Fri, Oct 21, 2016 at 04:39:59AM -0700, Eric Rescorla wrote:
> > On Fri, Oct 21, 2016 at 2:33 AM, Ilari Liusvaara <
> ilariliusva...@welho.com>
> > wrote:
> >
> > And since that implementation supports RFC7250 (for the server
> > > certi
On Fri, Oct 21, 2016 at 08:00:33AM -0700, Eric Rescorla wrote:
> On Fri, Oct 21, 2016 at 7:00 AM, Ilari Liusvaara
> wrote:
>
> > On Fri, Oct 21, 2016 at 04:39:59AM -0700, Eric Rescorla wrote:
> > > On Fri, Oct 21, 2016 at 2:33 AM, Ilari Liusvaara <
> > ilariliusva...@welho.com>
> > > wrote:
> > >
On Fri, Oct 21, 2016 at 07:58:57AM -0700, Christian Huitema wrote:
> I am a bit worried about privacy implications of the SNI. Suppose
> that we invent an obfuscation mechanism that prevents third parties
> to track which service corresponds to an SNI string. The SNI would
> then be different for a
On Fri, Oct 21, 2016 at 8:06 AM, Ilari Liusvaara
wrote:
> On Fri, Oct 21, 2016 at 08:00:33AM -0700, Eric Rescorla wrote:
> > On Fri, Oct 21, 2016 at 7:00 AM, Ilari Liusvaara <
> ilariliusva...@welho.com>
> > wrote:
> >
> > > On Fri, Oct 21, 2016 at 04:39:59AM -0700, Eric Rescorla wrote:
> > > > O
On Fri, Oct 21, 2016 at 08:14:50AM -0700, Eric Rescorla wrote:
> On Fri, Oct 21, 2016 at 8:06 AM, Ilari Liusvaara
> wrote:
>
> > On Fri, Oct 21, 2016 at 08:00:33AM -0700, Eric Rescorla wrote:
> > > On Fri, Oct 21, 2016 at 7:00 AM, Ilari Liusvaara <
> > ilariliusva...@welho.com>
> > > wrote:
> > >
> On Oct 21, 2016, at 07:39, Eric Rescorla wrote:
>
> On Fri, Oct 21, 2016 at 2:33 AM, Ilari Liusvaara
> wrote:
> On Thu, Oct 20, 2016 at 09:32:36AM -0700, Eric Rescorla wrote:
> > Folks,
> >
> > I have just uploaded draft-ietf-tls-tls13-17.
>
> Updated my own implementation from -16 to -17 (
I mentioned obfuscation as one possible solution. I know that I can make it
work for small scale servers, e.g., up to a few hundreds registered clients.
But if we can achieve the same privacy results with some mechanisms using
dynamic certificates, that's fine too. My only point is, please don't
An update to a meeting session request has just been submitted by Stephanie
McCammon, on behalf of the tls working group.
-
Working Group Name: Transport Layer Security
Area Name: Security Area
Session Requester: Stephanie McCammon
Numbe
> The server ought to perform a full handshake whenever the full handshake will
> result in selection & use of a _different_ TLS server certificate than what
> was used for the original full handshake on a session resumption.
I think this is correct, assuming a server is only able to present one
2016-10-21 18:33 GMT+09:00 Ilari Liusvaara :
> On Thu, Oct 20, 2016 at 09:32:36AM -0700, Eric Rescorla wrote:
>> Folks,
>>
>> I have just uploaded draft-ietf-tls-tls13-17.
>
> Updated my own implementation from -16 to -17 (TODO: Add to
> implementations page, it isn't any of the ones listed).
>
> A
Dear Sean Turner,
The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request.
tls Session 1 (2:30:00)
Tuesday, Afternoon Session II 1550-1820
Room Name: Park Ballroom 1 size: 125
23 matches
Mail list logo
