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
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 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.
_
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 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”
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
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 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
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 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 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
> 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: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 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 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
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,
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 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
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 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 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 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 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 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 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 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 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
+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 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
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
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 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
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
(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 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
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
___
[ 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 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
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".
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 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
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 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
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
44 matches
Mail list logo
