On Friday 04 March 2016 13:49:11 Scott Fluhrer wrote:
> > -Original Message-
> > From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Nikos
> > Mavrogiannopoulos
> > Sent: Friday, March 04, 2016 3:10 AM
> > To: Hanno Böck; Blumenthal, Uri - 0553 - MITLL; tls@ietf.org
> > Subject: Re: [TLS]
On Thursday 03 March 2016 20:43:42 Dave Garrett wrote:
> Do we want to stick some simple new constraints on SNI in the TLS 1.3
> draft spec? e.g. SHOULD have exactly one host_name which SHOULD be
> less than N bytes (significantly less than the current theoretical
> 64kB ceiling). Just adding a qui
On Friday 04 March 2016 10:16:25 Martin Thomson wrote:
> If we actually have a volunteer for sni-bis, then that would be OK
> with me.
>
> However, I don't regard the errors as important. Any hope that they
> might be used in some automated fashion died a long time ago. Mainly
> due to this comp
On 7 March 2016 at 23:02, Hubert Kario wrote:
> well, if some people don't care about their implementation being
> fingerprintable, let them be, but there should but at least a
> recommendation what to do if you want to avoid that.
I'd be very surprised if this added anything to the fingerprintin
On Monday 07 March 2016 23:32:55 Martin Thomson wrote:
> On 7 March 2016 at 23:02, Hubert Kario wrote:
> > well, if some people don't care about their implementation being
> > fingerprintable, let them be, but there should but at least a
> > recommendation what to do if you want to avoid that.
>
On Fri, 2016-03-04 at 13:49 +, Scott Fluhrer (sfluhrer) wrote:
> Given that there probably is no long term future for RSA anyway
> > > (people want ECC and postquantum is ahead) I doubt anything else
> > > than
> > > the primitives we already have in standards will ever be viable.
> > On the co
On 01/03/2016 11:32, Yoav Nir wrote:
>> On 1 Mar 2016, at 6:56 AM, Martin Thomson wrote:
>>
>> On 1 March 2016 at 04:32, Joseph Salowey wrote:
>>> We make RSA-PSS mandatory to implement (MUST implement instead of MUST
>>> offer). Clients can advertise support for PKCS-1.5 for backwards
>>> comp
> -Original Message-
> From: Hubert Kario [mailto:hka...@redhat.com]
> Sent: Monday, March 07, 2016 6:43 AM
> To: tls@ietf.org
> Cc: Scott Fluhrer (sfluhrer); Nikos Mavrogiannopoulos; Hanno Böck;
> Blumenthal, Uri - 0553 - MITLL
> Subject: Re: [TLS] RSA-PSS in TLS 1.3
>
> On Friday 04 Mar
On Mon, Mar 07, 2016 at 01:51:41PM +, Hannes Mehnert wrote:
> On 01/03/2016 11:32, Yoav Nir wrote:
> >> On 1 Mar 2016, at 6:56 AM, Martin Thomson wrote:
> >>
> >> On 1 March 2016 at 04:32, Joseph Salowey wrote:
> >>> We make RSA-PSS mandatory to implement (MUST implement instead of MUST
> >>>
> -Original Message-
> From: Nikos Mavrogiannopoulos [mailto:n...@redhat.com]
> Sent: Monday, March 07, 2016 8:42 AM
> To: Scott Fluhrer (sfluhrer); Hanno Böck; Blumenthal, Uri - 0553 - MITLL;
> tls@ietf.org
> Subject: Re: [TLS] RSA-PSS in TLS 1.3
>
> On Fri, 2016-03-04 at 13:49 +, Sc
From: Tony Arcieri [mailto:basc...@gmail.com]
Sent: Monday, March 07, 2016 11:40 AM
To: Scott Fluhrer (sfluhrer)
Cc: Nikos Mavrogiannopoulos; Hanno Böck; Blumenthal, Uri - 0553 - MITLL;
tls@ietf.org
Subject: Re: [TLS] RSA-PSS in TLS 1.3
On Mon, Mar 7, 2016 at 8:34 AM, Scott Fluhrer (sfluhrer)
m
On Monday 07 March 2016 15:23:17 Scott Fluhrer wrote:
> > -Original Message-
> > From: Hubert Kario [mailto:hka...@redhat.com]
> > Sent: Monday, March 07, 2016 6:43 AM
> > To: tls@ietf.org
> > Cc: Scott Fluhrer (sfluhrer); Nikos Mavrogiannopoulos; Hanno Böck;
> > Blumenthal, Uri - 0553 - MI
On Mon, Mar 7, 2016 at 8:34 AM, Scott Fluhrer (sfluhrer) wrote:
> Defenses against the first type of attack (passive evesdropping by someone
> who will build a QC sometime in the future) are something that this WG
> should address; even if the PKI people don't have an answer, we would at
> least
Hi Scott:
I think it is really premature to speculate on features PQ-secure
algorithms can or cannot provide (*) and try and have this influence
*current* TLS1.3 protocol design. Should one wish to include PQ
algorithms in a future update of TLS1.3, one can simply specify which
protocol ingr
> I think it is really premature to speculate on features PQ-secure algorithms
> can or cannot provide (*) and try and have this influence *current* TLS1.3
> protocol design. Should one wish to include PQ algorithms in a future update
> of TLS1.3, one can simply specify which protocol ingredients
I'm not precisely sure what you are really saying. Are you claiming that, even
though currently known PQ key exchange don't give all the flexibility that
(EC)DH has, you're pretty sure that'll change in the future? Or, are you
saying that relying on the full flexibility of (EC)DH isn't a probl
All,
The cached-info draft got all the way to the IESG and then we receive a couple
of comments that require we bring the draft back to the WG to discuss.
spt
> Begin forwarded message:
>
> From: Karthikeyan Bhargavan
> Subject: Re: Cached Info
> Date: February 23, 2016 at 12:34:31 GMT+9
> To
17 matches
Mail list logo
