dear sir, I am very much interested about the meeting regardingnon working
group item and reavent agenda. I am requesting you for a time on the agenda .My
local time Dhaka(+6.00). thanking you
—
Sent from Mailbox
On Sun, Oct 18, 2015 at 6:28 AM, Joseph Salowey wrote:
> Please email the chai
Please email the chairs if you have a request for time on the agenda. We
expect to spend the meeting time discussing TLS 1.3 and other working
group items. You can request time for non-working group items, however we
cannot guarantee that there will be time for them.
Thanks,
J&S
_
On Oct 17, 2015, at 08:30, Ilari Liusvaara wrote:
> Okay, did a review of draft-ietf-tls-curve25519 (since it still
> doesn't seem to have been WGLC'd):
Note that draft-ietf-tls-curve25519 is getting merged into
draft-ietf-tls-rfc4492bis.
Note that the cfrg-curves draft’s RFC5742-review (aka t
On Sat, Oct 17, 2015 at 03:20:08PM -0700, Eric Rescorla wrote:
> I don't feel strongly about this, but I don't see how what you suggest
> is any simpler than the version number encoding I proposed. Arguably,
> it's more complicated since you can't implement the sentinel check with
> memcmp().
Th
On Sat, Oct 17, 2015 at 3:17 PM, Viktor Dukhovni
wrote:
> On Sat, Oct 17, 2015 at 03:10:01PM -0700, Eric Rescorla wrote:
>
> > > This argument is not complete. The false negative rate from TCP
> > > is not by itself sufficient to determine the observed error rate.
> > > One needs to combine that
On Sat, Oct 17, 2015 at 03:10:01PM -0700, Eric Rescorla wrote:
> > This argument is not complete. The false negative rate from TCP
> > is not by itself sufficient to determine the observed error rate.
> > One needs to combine that with the undetected error rate from
> > underlying network to obta
On Sat, Oct 17, 2015 at 3:05 PM, Viktor Dukhovni
wrote:
> On Sat, Oct 17, 2015 at 02:53:57PM -0700, Eric Rescorla wrote:
>
> > > It also has a slightly better collision risk, though it's already down
> > > quite low
> >
> > Given that the TCP checksum has a false negative rate far higher than
> >
On Sat, Oct 17, 2015 at 02:53:57PM -0700, Eric Rescorla wrote:
> > It also has a slightly better collision risk, though it's already down
> > quite low
>
> Given that the TCP checksum has a false negative rate far higher than
> 2^{-56} and
> any TCP errors cause TLS handshake failures, this doesn
On Saturday, October 17, 2015 05:53:57 pm Eric Rescorla wrote:
> On Sat, Oct 17, 2015 at 2:34 PM, Dave Garrett
> wrote:
> > A 64-bit sentinel can be trivially checked as a 64-bit uint.
>
> And a 56-bit value can be trivially checked by masking off the last byte.
> Or, memcmp().
My point is that
On Sat, Oct 17, 2015 at 2:34 PM, Dave Garrett
wrote:
> On Saturday, October 17, 2015 05:16:49 pm Eric Rescorla wrote:
> > On Sat, Oct 17, 2015 at 2:08 PM, Dave Garrett
> > wrote:
> >
> > > On Saturday, October 17, 2015 03:10:18 pm Martin Thomson wrote:
> > > > The observation is still valuable i
On Saturday, October 17, 2015 05:16:49 pm Eric Rescorla wrote:
> On Sat, Oct 17, 2015 at 2:08 PM, Dave Garrett
> wrote:
>
> > On Saturday, October 17, 2015 03:10:18 pm Martin Thomson wrote:
> > > The observation is still valuable in the sense that prohibiting values
> > > > 1.3 would reduce the l
On Sat, Oct 17, 2015 at 02:16:49PM -0700, Eric Rescorla wrote:
> 3. (Optional) If you have a downgrade, parse the last byte to see the
> server's actual version.
> In any case, abort.
>
> What have I missed?
>From my perspective, there's not much benefit to knowing the actual
version, and an
On Sat, Oct 17, 2015 at 2:08 PM, Dave Garrett
wrote:
> On Saturday, October 17, 2015 03:10:18 pm Martin Thomson wrote:
> > The observation is still valuable in the sense that prohibiting values
> > > 1.3 would reduce the likelihood of a false positive by some
> > miniscule amount. In other words
Since we’ve been using github as an issue tracker, I’m going to copy these
comments there. I’m going to put “CELLOS” somewhere in the issue so they can
be easily found. Also note that some of these are resolved, similar to others,
or over taken by events so I expect some to be closed almost im
On Saturday, October 17, 2015 03:10:18 pm Martin Thomson wrote:
> The observation is still valuable in the sense that prohibiting values
> > 1.3 would reduce the likelihood of a false positive by some
> miniscule amount. In other words, I agree with ekr here, though we
> could cap the value to 1.3
On 17 October 2015 at 12:03, Eric Rescorla wrote:
>> Just a single
>> fixed patter signalling ">= 1.3" would then suffice.
>
>
> If you wanted to cover 1.2 -> 1.1, then you would want this.
The observation is still valuable in the sense that prohibiting values
> 1.3 would reduce the likelihood of
On Sat, Oct 17, 2015 at 12:00 PM, Viktor Dukhovni
wrote:
> On Sat, Oct 17, 2015 at 11:35:35AM -0700, Eric Rescorla wrote:
>
> > Trying to close the loop on this, I think people are generally in favor
> of
> > this
> > mechanism, so we just need a concrete construction.
> >
> > I propose we use an
On Sat, Oct 17, 2015 at 11:35:35AM -0700, Eric Rescorla wrote:
> Trying to close the loop on this, I think people are generally in favor of
> this
> mechanism, so we just need a concrete construction.
>
> I propose we use an N bit field divided as follows
>
> - N - 8 bits of fixed sentinel.
> -
Trying to close the loop on this, I think people are generally in favor of
this
mechanism, so we just need a concrete construction.
I propose we use an N bit field divided as follows
- N - 8 bits of fixed sentinel.
- 8 bits of version number with the semantics being the highest TLS version
numb
On 10/17/2015 01:48 AM, Rick van Rein wrote:
> It still surprises me, but Kerberos is able to send a message one-way
> and achieve mutual authentication. The trick is of course that prior
> key exchanges have setup links that make
No, mutual authentication requires the client to receive a message
On Thu, Oct 15, 2015 at 04:09:39PM +0300, Ilari Liusvaara wrote:
>
> Diffie-Hellman:
> ---
> There is already a WG draft about this. The one remaining technical
> issue seems to be wheither to share the curves with signatures or
> dedicate those for DH.
Okay, did a review of draft-iet
Hi Karthikeyan,
> I don’t fully understand the constraints of the Kerberos+DH use-case, but
> using DHE-PSK seems like the best idea.
It certainly has some virtue to view Kerberos as a preshared key (on
steroids). But let me explain what bothers me about that appraoch :-
* PSK was designed t
> - Original Message -
>>> Hello,
>>> 3) Similar to OpenPGP: Negotiate cert-type
>>>
>>> There is a cert-type for X.509 and for OpenPGP; add one for Kerberos
>>> Tickets.
>>> PRO: Good integration with TLS: Tickets are transported in the
>>> ClientCertificate, and an Authenticator is the C
> 2) Embed the Ticket + Authenticator in a PSK
I don’t fully understand the constraints of the Kerberos+DH use-case, but using
DHE-PSK seems like the best idea.
The planned session resumption mechanism for TLS 1.3 also uses DHE-PSK, and
uses a session ticket mechanism
that is not so far from the
24 matches
Mail list logo
