Thanks again for your comments. See my reply inline please. ^_^
>
> I'm not following. If you trust the device, then why do you need any kind of
> cryptographic
> authentication on the token.
>
> Dacheng：Let assume we trust the device. But the APP use a SNI to indicate the
> service that the APP
On 31 March 2016 at 16:09, Ilari Liusvaara wrote:
>> I think that option 1 is easy enough, since both sides have to extend the
>> hash in any case. 3 is just complexity.
>
> Yeah, I agree 3 is just complexity. Except I disagree that currently
> option 1 is easy enough, since the hash going to crea
On Thu, Mar 31, 2016 at 09:57:51AM +1100, Martin Thomson wrote:
> On 31 Mar 2016 5:56 AM, "Ilari Liusvaara" wrote:
> > Then on topic of 0-RTT, how does 0-RTT key hashes behave if
> > handshake is restarted (main handshake hash continues, but
> > 0-RTT hash context currently needs to be separate fr
On 31 March 2016 at 12:41, Wan-Teh Chang wrote:
> But if you already implemented the first row, which is a must, the
> incremental effort to implement the second row seems small -- you just
> need to use server static instead of server ephemeral for SS.
Someone recently suggested that handling th
Hi Eric,
Thank you for the reply.
On Tue, Mar 29, 2016 at 10:57 AM, Eric Rescorla wrote:
>
> On Tue, Mar 29, 2016 at 10:14 AM, Wan-Teh Chang wrote:
>>
>> [...] I am curious to know how we concluded that 0-RTT PSK is simpler to
>> implement. Did anyone implement both 0-RTT modes and can compare
On 30 March 2016 at 12:53, Sean Turner wrote:
> Cipher suites marked with a “Y” the IETF has consensus on
As long as that consensus is for the "Y", then this is a great plan.
I think that there's consensus on a lot of "N" entries too. However,
if there is any dispute or doubt, it's still "N".
On 31 March 2016 at 09:59, Eric Rescorla wrote:
>> Option 2 suits best if we consider HelloRetryRequest to be a DoS feature
>> exclusively or at least primarily. But we have other reasons for it and I
>> don't think that DoS mitigation is a big factor for TCP.
>
>
> I believe Option #2 is simplest
[ resurrecting ancient thread ]
Andrei said on November 4, 2015..
> So perhaps the simplest fix is to update RFC 5929 to say that tls-unique
> is deprecated and EKM should be used instead, with certain recommended
> parameters. This does mean that any protocols that rely on tls-unique
> will need
On 31/03/16 00:22, Eric Rescorla wrote:
> We already have a proposal for this. Please see:
> http://tlswg.github.io/tls13-spec/#iana-considerations
I like, support and will buy that a beer:-)
Thanks,
S.
smime.p7s
Description: S/MIME Cryptographic Signature
___
On Wed, Mar 30, 2016 at 4:16 PM, Stephen Farrell
wrote:
>
> (with no hats, except the one irritated with loadsa ciphersuites:-)
>
> On 30/03/16 21:26, Yoav Nir wrote:
> > That brings up another question. How do things move from “approved”
> > to “not-approved”? Does it require a diediedie documen
(with no hats, except the one irritated with loadsa ciphersuites:-)
On 30/03/16 21:26, Yoav Nir wrote:
> That brings up another question. How do things move from “approved”
> to “not-approved”? Does it require a diediedie document? What
> happens when we decide that 3DES is just too limited and
On Wed, Mar 30, 2016 at 3:57 PM, Martin Thomson
wrote:
> On 31 Mar 2016 5:56 AM, "Ilari Liusvaara"
> wrote:
> > Then on topic of 0-RTT, how does 0-RTT key hashes behave if
> > handshake is restarted (main handshake hash continues, but
> > 0-RTT hash context currently needs to be separate from th
On 31 Mar 2016 5:56 AM, "Ilari Liusvaara" wrote:
> Then on topic of 0-RTT, how does 0-RTT key hashes behave if
> handshake is restarted (main handshake hash continues, but
> 0-RTT hash context currently needs to be separate from the
> main context)?
Good question. I don't recall that being discus
Hello,
> In Yokohama, we discussed changing the IANA registry assignment rules
> for cipher suites
Has a similar thing been discussed for TLS Extensions as well? That
list now requires "IETF Consensus", and it doesn't even have Private and
Experimental allocations, let alone a portion with "Spec
On Wed, Mar 30, 2016 at 2:47 PM, Ilari Liusvaara
wrote:
> On Wed, Mar 30, 2016 at 01:33:57PM -0700, Eric Rescorla wrote:
> > On Wed, Mar 30, 2016 at 1:23 PM, Dave Garrett
> > wrote:
> >
> > > On Wednesday, March 30, 2016 11:22:15 am Eric Rescorla wrote:
> > > > 1. Add a "this is only usable for
On Wed, Mar 30, 2016 at 01:33:57PM -0700, Eric Rescorla wrote:
> On Wed, Mar 30, 2016 at 1:23 PM, Dave Garrett
> wrote:
>
> > On Wednesday, March 30, 2016 11:22:15 am Eric Rescorla wrote:
> > > 1. Add a "this is only usable for TLS 1.3 [or for subcerts]" extension to
> > > PKIX.
> >
> > Adding a
+1 for the change.
On 3/30/16 at 1:26 PM, ynir.i...@gmail.com (Yoav Nir) wrote:
That brings up another question. How do things move from
“approved” to “not-approved”? Does it require a
diediedie document? What happens when we decide that 3DES is
just too limited and there’s not good reason to
On 03/30/2016 01:03 PM, Sean Turner wrote:
> I apologize in advance; this is about process so it’s long.
>
It seems correct and reasonably comprehensive.
> This definition gives power/discretion to the designated expert (it’s ekr
> btw). We can:
>
> a) defer to the expert's judgement (some of w
On Wed, Mar 30, 2016 at 1:23 PM, Dave Garrett
wrote:
> On Wednesday, March 30, 2016 11:22:15 am Eric Rescorla wrote:
> > 1. Add a "this is only usable for TLS 1.3 [or for subcerts]" extension to
> > PKIX.
>
> Adding a PKIX extension to mandate a minimum threshold of security
> configuration (e.g.
On Mar 30, 2016 9:03 AM, "Daniel Kahn Gillmor"
wrote:
>
> On Wed 2016-03-30 11:22:15 -0400, Eric Rescorla wrote:
> > This got a lot of discussion early in the design process and the
consensus
> > was that the risk of having the default mode (with existing certs)
allow the
> > creation of a long-te
On Wednesday, March 30, 2016 03:20:08 pm Ilari Liusvaara wrote:
> On Wed, Mar 30, 2016 at 12:05:26PM -0400, Daniel Kahn Gillmor wrote:
> > On Wed 2016-03-30 11:33:09 -0400, Benjamin Kaduk wrote:
> > > I am not sure that we want to be in the business of explicitly marking
> > > things as insecure ot
> On 30 Mar 2016, at 10:44 PM, Daniel Kahn Gillmor
> wrote:
>
> On Wed 2016-03-30 15:20:08 -0400, Ilari Liusvaara wrote:
>> On Wed, Mar 30, 2016 at 12:05:26PM -0400, Daniel Kahn Gillmor wrote:
>>> On Wed 2016-03-30 11:33:09 -0400, Benjamin Kaduk wrote:
I am not sure that we want to be in t
On Wednesday, March 30, 2016 11:22:15 am Eric Rescorla wrote:
> 1. Add a "this is only usable for TLS 1.3 [or for subcerts]" extension to
> PKIX.
Adding a PKIX extension to mandate a minimum threshold of security
configuration (e.g. PFS+AEAD w/o resumption or SHA1 or any support for TLS
<1.2) wo
On Wed 2016-03-30 15:20:08 -0400, Ilari Liusvaara wrote:
> On Wed, Mar 30, 2016 at 12:05:26PM -0400, Daniel Kahn Gillmor wrote:
>> On Wed 2016-03-30 11:33:09 -0400, Benjamin Kaduk wrote:
>> > I am not sure that we want to be in the business of explicitly marking
>> > things as insecure other than o
On Wed, Mar 30, 2016 at 12:05:26PM -0400, Daniel Kahn Gillmor wrote:
> On Wed 2016-03-30 11:33:09 -0400, Benjamin Kaduk wrote:
> > I am not sure that we want to be in the business of explicitly marking
> > things as insecure other than our own RFCs, though -- there could be an
> > implication of mo
On Wed, Mar 30, 2016 at 08:35:31PM +1100, Martin Thomson wrote:
> On 30 March 2016 at 16:15, Ilari Liusvaara wrote:
> > Only if using 0-RTT auth, which seems is going to be removed (yay).
>
> My reading is that Finished is always present. That is, the
> authentication messages are always sent, w
On Mar 30, 2016, at 11:33, Benjamin Kaduk wrote:
>
> I support this plan (with the expectation that the IANA "specification
> required" rules take precedence over the informal text in this mail
> about a "stable, publicly available, peer reviewed reference document",
> as Yoav noted as a potentia
I apologize in advance; this is about process so it’s long.
On Mar 30, 2016, at 01:29, Yoav Nir wrote:
>
> Hi Sean
>
> I also strongly support this. I’m just wondering how we plan to enforce the
> "stable, publicly available, peer reviewed reference” part. As your examples
> below show, the
On Wed, Mar 30, 2016 at 12:29 PM Subodh Iyengar wrote:
> >I disagree with point #3 and think the "prevent fallback" portion would
> be a mistake. Possession of a TLS 1.3 session to offer should not disable
> TLS 1.2 if the client would have accepted this without that session.
>
> @David, for #3,
> On 30 Mar 2016, at 7:05 PM, Daniel Kahn Gillmor
> wrote:
>
> On Wed 2016-03-30 11:33:09 -0400, Benjamin Kaduk wrote:
>> I am not sure that we want to be in the business of explicitly marking
>> things as insecure other than our own RFCs, though -- there could be an
>> implication of more revi
>I disagree with point #3 and think the "prevent fallback" portion would be a
>mistake. Possession of a TLS 1.3 session to offer should not disable TLS 1.2
>if the client would have accepted this without that session.
@David, for #3, I'm referring to fallback in 0-RTT mode. In the normal
operat
On Wed 2016-03-30 11:22:15 -0400, Eric Rescorla wrote:
> This got a lot of discussion early in the design process and the consensus
> was that the risk of having the default mode (with existing certs) allow the
> creation of a long-term delegation was too high. See, for instance, the
> relative imp
> I think i'd rather see it stay at "approved/not-approved"
There is also the concern that various parties (e.g., national crypto) can get
upset by this kind of thing. Which is why I prefer "approved/no-comment" as
the dividing line.
___
TLS mailin
On Wed 2016-03-30 11:33:09 -0400, Benjamin Kaduk wrote:
> I am not sure that we want to be in the business of explicitly marking
> things as insecure other than our own RFCs, though -- there could be an
> implication of more review than is actually the case, which is what this
> proposal is trying
On 2016-03-30 17:33, Benjamin Kaduk wrote:
I am not sure that we want to be in the business of explicitly marking
things as insecure other than our own RFCs, though -- there could be an
implication of more review than is actually the case, which is what this
proposal is trying to get rid of.
So
On Wed, Mar 30, 2016 at 8:37 AM, Bill Cox wrote:
> On Wed, Mar 30, 2016 at 8:22 AM, Eric Rescorla wrote:
>
>> This got a lot of discussion early in the design process and the consensus
>> was that the risk of having the default mode (with existing certs) allow
>> the
>> creation of a long-term d
On Wed, Mar 30, 2016 at 8:22 AM, Eric Rescorla wrote:
> This got a lot of discussion early in the design process and the consensus
> was that the risk of having the default mode (with existing certs) allow
> the
> creation of a long-term delegation was too high. See, for instance, the
> relative
I am in favor of this.
On Tue, Mar 29, 2016 at 6:53 PM, Sean Turner wrote:
> Hi!
>
> In Yokohama, we discussed changing the IANA registry assignment rules for
> cipher suites to allow anyone with a stable, publicly available, peer
> reviewed reference document to request and get a code point and
On Tue, Mar 29, 2016 at 9:04 PM, Dacheng Zhang
wrote:
> Hi, Erk:
>
> My reply inline please.
>
> Cheers
>
> Dacheng
>
> 发件人: Eric Rescorla
> 日期: 2016年3月30日 星期三 上午11:19
> 至: dacheng de
> 抄送: Eric Mill , Dave Garrett ,
> tls
> 主题: Re: [TLS] 回复： A TLS extension transfering service indication
> in
On 03/29/2016 08:53 PM, Sean Turner wrote:
> Hi!
>
> In Yokohama, we discussed changing the IANA registry assignment rules for
> cipher suites to allow anyone with a stable, publicly available, peer
> reviewed reference document to request and get a code point and to add an
> “IETF Recommended”
This got a lot of discussion early in the design process and the consensus
was that the risk of having the default mode (with existing certs) allow the
creation of a long-term delegation was too high. See, for instance, the
relative impact of the recent paper by Jager at al. [0] on TLS 1.3 and
QUIC
On 2016-03-30 13:27, Dmitry Belyavsky wrote:
Dear Sean,
I support the plan in general, but I think that we need to separately
indicate
that a particular algorithm/ciphersuite is not just "Not recommended"
but found insecure.
This does indeed sound reasonable.
_
Dear Sean,
I support the plan in general, but I think that we need to separately
indicate
that a particular algorithm/ciphersuite is not just "Not recommended" but
found insecure.
Thank you!
On Wed, Mar 30, 2016 at 4:53 AM, Sean Turner wrote:
> Hi!
>
> In Yokohama, we discussed changing the IA
On 30 March 2016 at 16:15, Ilari Liusvaara wrote:
> Only if using 0-RTT auth, which seems is going to be removed (yay).
My reading is that Finished is always present. That is, the
authentication messages are always sent, with
Certificate+CertificateVerify being omitted if there is no
certificate
44 matches
Mail list logo
