Re: [TLS] 0RTT and HelloRetryRequest (Re: Narrowing the replay window)

[Ilari Liusvaara]

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 from the
> > main context)?
> 
> Good question. I don't recall that being discussed. I see three options :
> 
> 1. Continue the hash, just like in 1-RTT
> 
> 2. Treat HelloRetryRequest as a denial of the entire first flight.
> 
> 3. Signal the choice.
> 
> 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 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 creating 0-RTT keys
is not tapped from the main hash (if it was, then continuing would be
the simplest).

Relatedly, the proposal for "contexts" dropped the extra messages that
caused the difference between 0-RTT hash and 1-RTT hash.


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call for consensus: Removing DHE-based 0-RTT

[Martin Thomson]

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 the SSLv2-compatible
ClientHello was similarly easy.  It wasn't by any measure simple or
straightforward.  Sure, the request was entirely reasonable, but I now
wish I had pushed back harder.

This involves a different session transcript as input, all the
machinery involved with the ServerConfiguration message, and all the
switching logic associated with a new mode.

I'd rather reduce this to the modes that we know that we need now,
particularly since we know how we could retrofit a DH-based 0-RTT into
a PSK-based protocol.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call for consensus: Removing DHE-based 0-RTT

[Wan-Teh Chang]

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 the
>> difficulties?
>
> We have a prototype 0-RTT PSK implementation and have looked at but not yet
> implemented 0-RTT DHE in NSS. Based on that, my sense is that the cost of
> doing any 0-RTT is the bulk of the additional effort, but that if you have
> PSK already, which you probably want for ordinary resumption, then the
> incremental cost of 0-RTT with PSK is less than with DHE.

By analyzing Sections 7.1 and 7.3 of draft-ietf-tls-tls13-12. I think
I understand what you meant.

For convenience I reproduce the table at the top of page 74:

   +-+++
   | Key Exchange| Static Secret (SS) |  Ephemeral Secret (ES) |
   +-+++
   | (EC)DHE (full   |Client ephemeral w/ |Client ephemeral w/ |
   | handshake)  |   server ephemeral |   server ephemeral |
   | |||
   | (EC)DHE (w/ |Client ephemeral w/ |Client ephemeral w/ |
   | 0-RTT)  |  server static |   server ephemeral |
   | |||
   | PSK | Pre-Shared Key | Pre-shared key |
   | |||
   | PSK + (EC)DHE   | Pre-Shared Key |Client ephemeral w/ |
   | ||   server ephemeral |
   +-+++

In a PSK session resumption handshake, we always use the same (third)
row, with or without 0-RTT.

On the other hand, in a full handshake, without 0-RTT we use the first
row, and with 0-RTT we use the second row.

Is this what you meant?

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.

Wan-Teh Chang

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] updating RFC5929 channel bindings (was: Deprecating tls-unique for TLS 1.3

[jeff . hodges]

[ 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 to negotiate a new revision.

There are three distinct channel binding mechanisms in
https://tools.ietf.org/html/rfc5929..

   3. The 'tls-unique' Channel Binding Type ...3
  3.1. Description 3
  3.2. Registration ...4
   4. The 'tls-server-end-point' Channel Binding Type .5
  4.1. Description 5
  4.2. Registration ...6
   5. The 'tls-unique-for-telnet' Channel Binding Type 6
  5.1. Description 7
  5.2. Registration ...7

..is the proposal to update RFC 5929 to say that both tls-unique and
tls-unique-for-telnet are deprecated and leave tls-server-end-point as is? Are
there any known updates that ought to be applied to tls-server-end-point?
Perhaps the allowed cipher suite list in S 6 ?

Should an updated tls-unique-for-telnet based on RFC5705 EKM be defined in the
proposed 5929bis draft?  Or it could be left as a separate exercise for those
who care about telnet I suppose.

HTH,

=JeffH


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites

[Stephen Farrell]

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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites

[Eric Rescorla]

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 document? What
> > happens when we decide that 3DES is just too limited and there’s not
> > good reason to use it, but there’s really no security issue with
> > using it?
>
> How about starting from the smallest possible set with "Y" in
> the IETF recommended column? And then focus on keeping that set
> as small as possible and actively not letting it grow.
>
> Let's *pretty please* take this opportunity to prune the stupid
> list of nearly 350 all ostensibly but so not equal ciphersuites
> down to the smallest list that can reasonably be recommended.
> Measurements seem to have indicated that just a handful is all
> that really needs to be very widely supported.
>

We already have a proposal for this. Please see:
http://tlswg.github.io/tls13-spec/#iana-considerations

-Ekr




That will require folks here to not mess about and to resist the
> set of people who want ciphersuite foo because it's important to
> just them and a few others.
>
> Remember: Sean's proposed text, is to limit the "Y" to stuff that
> we do expect to, and want to, see widely or very widely implemented
> and deployed.
>
> If this WG fail to take this opportunity to fix the 350 ciphersuite
> stupidity then that'll be a pretty clear fail in which we'll all
> (me included) have sadly partaken. Let's fix that eh?
>
> S.
>
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] 0RTT and HelloRetryRequest (Re: Narrowing the replay window)

[Martin Thomson]

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 discussed. I see three options :

1. Continue the hash, just like in 1-RTT

2. Treat HelloRetryRequest as a denial of the entire first flight.

3. Signal the choice.

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 think that option 1 is easy enough, since both sides have to extend the
hash in any case. 3 is just complexity.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Why again can't we use TLS signing certs to create short-lived sub-certs?

[Eric Rescorla]

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 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) would also be great to have
> >
> >
> > This seems like a fairly blunt instrument. Better to make sure that TLS's
> > negotiaton
> > mechanisms are reliable and trustworthy.
>
> Unfortunately, there's the broken key exchanges, which fundamentally
> compromise any version negotiation.
>
>
> Yes, one could set RSA KeyUsage to just DigitalSignature, which would
> nominally disable those broken key exchanges.


Why is this necessary in this case? If you're a server which won't do static
RSA, why isn't it enough to just refuse to negotiate those cipher suites?

-Ekr

Unfortunately:
>
> - Many clients don't enforce that.
> - That kind of certificates are listed as SHOULD NOT issue.
>
>
> -Ilari
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Why again can't we use TLS signing certs to create short-lived sub-certs?

[Ilari Liusvaara]

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 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) would also be great to have
> 
> 
> This seems like a fairly blunt instrument. Better to make sure that TLS's
> negotiaton
> mechanisms are reliable and trustworthy.

Unfortunately, there's the broken key exchanges, which fundamentally
compromise any version negotiation.


Yes, one could set RSA KeyUsage to just DigitalSignature, which would
nominally disable those broken key exchanges. Unfortunately:

- Many clients don't enforce that.
- That kind of certificates are listed as SHOULD NOT issue.


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites

[Bill Frantz]

+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 use it, but 
there’s really no security issue with using it?


Certainly for downgrading any widely deployed algorithm, e.g. 
RC4, there needs to be a IETF process. The RFC process works, so 
we don't need to invent a new wheel. Therefore a diediedie RFC 
seems the logical choice.


I hope algorithms don't get on the approved list unless they are 
likely to be widely deployed. (But I expect to see counter-arguments.)


Cheers - Bill

---
Bill Frantz| gets() remains as a monument | Periwinkle
(408)356-8506  | to C's continuing support of | 16345 
Englewood Ave
www.pwpconsult.com | buffer overruns. | Los Gatos, 
CA 95032


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites

[Benjamin Kaduk]

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 what they are to do is in 
> [1][2]), or
> b) write some rules for the IANA considerations section that they’ll follow.
>
> I think that a) has worked in the past and would continue to work in the 
> future, but b) couldn’t hurt. If we go for a) then if the expert is ever 
> unsure, they can just ask the AD/WG chair/community for guidance [3][4].  
> Beware that the text for b) will be like a bright light for process moths [5].
>

I feel like (b) will probably result in a lot of time on the list
getting the text "just so"; perhaps that time would be better spent
elsewhere.  That said, I'm happy to help with the editing of such text...

>
>
> Some other things we should be clear on:
>
> 1. All of the drafts referenced and the future drafts requesting code points 
> do *not* need to come through the WG.  But, I do think drafts that want a “Y” 
> need to come through, and we shouldn’t kid ourselves most folks will want the 
> “Y”.  How does this sound (here I assume the algorithms are already published 
> elsewhere i.e., this is just for the assignments):

I agree ... the chairs should use their power to turn things away
judiciously :)

> a) For MTI and “Y” requests,
> a.1) requester’s publish individual draft,
> a.2) requester’s ask for wg adoption,
> a.3) wg chairs do adoption call,
> a.4) wg does its thing on wg draft,
> a.5) ietf does its thing, and
> a.6) iana (assigns #s) & rfc editor (publishes) do their things.
>
> b) For all others: 
> b.1) request is submitted to IANA, WG, WG chair, AD,

That's "one of the above", I presume?

> b.2) request is redirected to designated expert,
> b.3) designated experts reviews request:
> -- if good-to-go designated expert tells IANA to assign code point (goto b.4)
> -- if not-good-to-go for an obvious reasons the designated expert rejects the 
> request with some rationale (and probably lets the sec ADs know about it)
> -- if not-good-to-go for all other reasons the designated expert asks 
> (expert's choice depending on the situation) AD/WG chairs/community for 
> guidance
> b.4) iana makes assignment and includes the cipher suite assignment 
> specification reference in the registry (and possibly the rfc editor does 
> their thing if an RFC is being published)
>
> Early assignment rules can still apply to a) and b).

Sounds good to me.

> 2. As far as draft-ietf-tls-pwd, we need to decide whether it should continue 
> as a WG draft or free Dan to pursue other publication avenues.

No opinion at present.

> 3. We should avoid a long list of “updates” to TLS1.3 RFC#-to-be when new 
> cipher suites get added.  Drafts should only include an “updates” header if 
> we’re modifying the MTIs or we’re adding a new “Y” cipher suite because we 
> only expect all implementations to support these cases.

I support this, yes -- long "updates" lists can be annoying for the reader.

> 4. WRT language -  I’m assuming we’d continue to have English versions of the 
> algorithm specification.
>

If we are using IANA as a service for the global Internet, it is not
entirely clear to me that we need to insist on English versions of the
"specification required" document ... though the capabilities of the
designated expert might affect what would in practice get approved.

-Ben

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Why again can't we use TLS signing certs to create short-lived sub-certs?

[Eric Rescorla]

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. PFS+AEAD w/o resumption or SHA1 or any support for TLS
> <1.2) would also be great to have


This seems like a fairly blunt instrument. Better to make sure that TLS's
negotiaton
mechanisms are reliable and trustworthy.

-Ekr




> . In fact, if an intermediate could also set such a requirement and have
> that be required for all end-entity certs signed by it, that'd be a great
> way to protect against downgrades.
>
>
> Dave
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Why again can't we use TLS signing certs to create short-lived sub-certs?

[Watson Ladd]

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-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.
> >
> > With that said, I think this would be a good feature to look at in
future
> > and the right way to do it is to:
> >
> > 1. Add a "this is only usable for TLS 1.3 [or for subcerts]" extension
to
> > PKIX.
>
> this would need to be a critical extension, since the goal is to have it
> be unusable by existing endpoints, right?  do we have tests about how
> well existing endpoints will fail closed in the face of unknown critical
> extensions?

This won't work to protect against a server misconfigured to use the RSA EE
certificate for Bleichenbacher vulnerable handshakes. We would need to
limit to ECDSA certs and ensure that the subcert cannot be gamed into being
something else that might get signed by a TLS server.

>
> > 2. Add a subcert extension to TLS 1.3.
>
> This would be necessary for clients to signal that it's ok to use such a
> delegated cert or subcert.  we need to think clearly about how to limit
> the scope of such a delegation to make it safe.
>
>   --dkg
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites

[Dave Garrett]

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 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.
> > 
> > I think i agree with Ben here: if we have a tri-state:
> > approved/not-approved/known-bad, then the people will infer that the
> > not-approved ciphersuites are better than the known-bad ones, which
> > isn't necessarily the case.
> > 
> > I think i'd rather see it stay at "approved/not-approved"
> 
> Then how should ciphersuites with explicit diediedie RFCs (currently
> RC4) be presented?

A tri-state that might be more acceptable would be 
approved/not-approved/amended, where "amended" indicates an RFC released after 
the initial specification that is considered mandatory. This would be both 
diediedie RFCs as well as any sort of less severe update, without as much 
implication that "not-approved" automatically implies safety.


Dave

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Why again can't we use TLS signing certs to create short-lived sub-certs?

[Dave Garrett]

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) would also be great to have. In fact, if an intermediate could also set 
such a requirement and have that be required for all end-entity certs signed by 
it, that'd be a great way to protect against downgrades.


Dave

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites

[Ilari Liusvaara]

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 more review than is actually the case, which is what this
> > proposal is trying to get rid of.
> 
> I think i agree with Ben here: if we have a tri-state:
> approved/not-approved/known-bad, then the people will infer that the
> not-approved ciphersuites are better than the known-bad ones, which
> isn't necessarily the case.
> 
> I think i'd rather see it stay at "approved/not-approved"

Then how should ciphersuites with explicit diediedie RFCs (currently
RC4) be presented?


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Narrowing the replay window

[Ilari Liusvaara]

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, with
> Certificate+CertificateVerify being omitted if there is no
> certificate.

Oh, yeah, looks like there is always Finished. Does not simplify
implementation in any way (just makes implementation even more
complex).

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)?


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites

[Sean Turner]

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 potential issue).

Technically, the “specification required” rules are the IETF’s [0][1], but yeah 
these rules win over this email thread all day everyday.

spt

[0] https://datatracker.ietf.org/doc/rfc5226/
[1] https://datatracker.ietf.org/doc/draft-leiba-cotton-iana-5226bis/


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites

[Sean Turner]

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 reference tends to be an I-D. That’s stable and publicly 
> available, but we have no idea if it’s peer reviewed or who the author’s 
> peers are.

Note that I think both the cipher suite assignment specification and the 
algorithm specification need to be "stable, publicly available, peer reviewed 
reference.” Normally, the former informatively refers to the latter. [0]  The 
algorithm specification is not always an RFC, but the cipher suite assignment 
specifications have been; this plan changes that under certain circumstances 
(see below).

As far as stable and publicly available are concerned, these are part of the 
process now, as specified in [1] (and if the update ever gets done in [2]):

  Values and their meanings must be
  documented in a permanent and readily available public
  specification, in sufficient detail so that interoperability
  between independent implementations is possible.  When used,
  Specification Required also implies use of a Designated
  Expert, who will review the public specification and
  evaluate whether it is sufficiently clear to allow
  interoperable implementations.  The intention behind
  "permanent and readily available" is that a document can
  reasonably be expected to be findable and retrievable long
  after IANA assignment of the requested value.  Publication
  of an RFC is an ideal means of achieving this requirement,
  but Specification Required is intended to also cover the
  case of a document published outside of the RFC path.

This definition gives power/discretion to the designated expert (it’s ekr btw). 
 We can:

a) defer to the expert's judgement (some of what they are to do is in [1][2]), 
or
b) write some rules for the IANA considerations section that they’ll follow.

I think that a) has worked in the past and would continue to work in the 
future, but b) couldn’t hurt. If we go for a) then if the expert is ever 
unsure, they can just ask the AD/WG chair/community for guidance [3][4].  
Beware that the text for b) will be like a bright light for process moths [5].

As far as peer review, this is where the silent “c” in team comes to play (c is 
for community).  If the expert is not sure, then they'd ask the AD/WG 
chair/community for guidance.  We could also use b) to provide some rules, 
which could include references to BCP 61 [6] (and for MTI algs [7]).

> One other thing, in some of the links you pasted below you give a specific 
> draft version (like 
> https://www.ietf.org/archive/id/draft-zauner-tls-aes-ocb-03.txt) while for 
> the others you give the generic version (like 
> https://datatracker.ietf.org/doc/draft-ietf-tls-pwd/). The former is stable 
> but the latter is not. Are the authors free to keep modifying the 
> specification after getting the code point?

Sorry I wasn’t clear.  The references I listed were not supposed to imply 
stability they were just the list of cipher suites Joe and I have received 
requests from over the past year.   I don’t think that authors are free to keep 
modifying their specification after getting a code point, because of the 
Specification Required definition [8].


Some other things we should be clear on:

1. All of the drafts referenced and the future drafts requesting code points do 
*not* need to come through the WG.  But, I do think drafts that want a “Y” need 
to come through, and we shouldn’t kid ourselves most folks will want the “Y”.  
How does this sound (here I assume the algorithms are already published 
elsewhere i.e., this is just for the assignments):

a) For MTI and “Y” requests,
a.1) requester’s publish individual draft,
a.2) requester’s ask for wg adoption,
a.3) wg chairs do adoption call,
a.4) wg does its thing on wg draft,
a.5) ietf does its thing, and
a.6) iana (assigns #s) & rfc editor (publishes) do their things.

b) For all others: 
b.1) request is submitted to IANA, WG, WG chair, AD,
b.2) request is redirected to designated expert,
b.3) designated experts reviews request:
-- if good-to-go designated expert tells IANA to assign code point (goto b.4)
-- if not-good-to-go for an obvious reasons the designated expert rejects the 
request with some rationale (and probably lets the sec ADs know about it)
-- if not-good-to-go for all other reasons the designated expert asks (expert's 
choice depending on the situation) AD/WG chairs/community for guidance
b.4) iana makes assignment and includes the cipher suite assignment 
specification reference in the registry (and possibly the rfc editor does their 
thing if an RFC is being published)

Early assignment rules can still apply to a) and b).

2. As far as draft-ietf-tls-pwd, we need to decide whether it should continue 

Re: [TLS] Tickets and cross protocol attacks

[David Benjamin]

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'm referring to fallback in 0-RTT mode. In the normal
> operation case I don't think fallbacks work at all in this mode, so it
> should be fine to reject it to prevent attacks like I mentioned below.
>
> For example let's say a client sends a 0-RTT packet and the server only
> supports TLS1.2, the server will return a server hello with TLS1.2. However
> when it reads data from the session buffer expecting a ClientKeyExchange
> message, it will start getting the 0-RTT data.
>

Oh, I see. Yeah, that TLS 1.3 is backwards incompatible here is
unfortunate, for the same heterogeneous-deployment reasons as session
resumption. As things stand, enabling 0-RTT on one machine in a fleet is a
promise that *all* machines have deployed TLS 1.3 and that TLS 1.3 will
*never* be rolled back (unless turn off 0-RTT on all machines and then wait
for things to expire first, but typically one needs to roll something back
because it is broken and needs attention). Deployments that just ship
pre-packaged server software will not get this right. TLS 1.3 should not
require TLS experts guiding deployment.

(I understand that this backwards incompatibility is necessary for TLS 1.3
clients to stream 0-RTT data. I think this is a mistake for TLS over TCP
(though it is, of course, fine for other profiles like QUIC or DTLS), but
I've probably lost that one.)


> In a case where the server is smart enough to discard all this data (maybe
> its a special TLS1.2  + TLS1.3 server), the behavior when this happens on
> the client side is unspecified, should the client supply the data again in
> the normal TLS stream? should it not resend that data?
>

If the server responds with a != TLS 1.3 ServerHello with an indication
that it accepted the early data then, agreed, that should be a fatal error.
This is for the same reasons as forbidding cross-version session resumption.

If the server responds with a < TLS 1.3 ServerHello and *doesn't* indicate
early data, that's a different question. If the client does accept it, the
client should supply the data again, as it would have with TLS 1.3. But,
actually, I think I may buy this too should be a fatal error, but not for
security reasons. I think trying to use this as version downgrade
protection in so narrow of a scope does not make sense.

Rather, because TLS 1.3 0-RTT is currently backwards-incompatible, TLS 1.3
forces a connection retry fallback[0]. Clients offering 0-RTT need to retry
without 0-RTT enabled[1]. Using "server sent a < TLS 1.3 ServerHello to a
ClientHello with 0-RTT data" as a fallback trigger is at least a reliable
one. If we must have a fallback (I would rather we didn't), it shouldn't be
a flaky one.

David

[0] We seem to have several meanings of the word "fallback" here. :-) One
to mean where we accept a ServerHello at lower version than the
ClientHello, and another to mean when you start a connection over from the
top with different parameters, akin to the insecure TLS version fallback
browsers do/did. I'm referring to the second one.

[1] Without lowering the ClientHello version, of course. Though TLS 1.3
intolerance, sadly, seems to exist, so that might also happen again
independently.


> It's probably better to reject this fallback when the client has chosen to
> explicitly use a TLS 1.3 feature with 0-RTT in general.
>





> Subodh
> 
> From: Martin Thomson [martin.thom...@gmail.com]
> Sent: Tuesday, March 29, 2016 6:29 PM
> To: David Benjamin
> Cc: Subodh Iyengar; tls@ietf.org
> Subject: Re: [TLS] Tickets and cross protocol attacks
>
> On 30 March 2016 at 05:00, David Benjamin  wrote:
> > On the server, OpenSSL already includes the version in the SSL_SESSION
> > structure, and recent enough versions of it will not accept sessions at
> the
> > wrong version
>
>
> NSS too.  This is the right thing, I think.
>
> I have no objection to making this a requirement in the spec.
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites

[Yoav Nir]

> 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 review than is actually the case, which is what this
>> proposal is trying to get rid of.
> 
> I think i agree with Ben here: if we have a tri-state:
> approved/not-approved/known-bad, then the people will infer that the
> not-approved ciphersuites are better than the known-bad ones, which
> isn't necessarily the case.
> 
> I think i'd rather see it stay at "approved/not-approved”

+1

Nothing will ever be marked as known-bad unless it’s in widespread use. 
Nobody’s ever going to write a die-die-die document for some homebrew cipher or 
even for a national cipher unless something really spectacular happens. I’d 
rather not have them marked as “neutral”, which implies they are better than 
RC4’s “known-bad”. 

Besides, what about 3DES? For limited amounts of data it works perfectly fine 
if you follow all the CBC caveats, but with high-speed high-volume connections, 
you’ll have to rekey often. And there are faster, better alternatives. Do we 
mark it as “known-bad”? It’s certainly not broken the way RC4 is. I’d rather we 
not go there.

Yoav

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Tickets and cross protocol attacks

[Subodh Iyengar]

>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 
operation case I don't think fallbacks work at all in this mode, so it should 
be fine to reject it to prevent attacks like I mentioned below.

For example let's say a client sends a 0-RTT packet and the server only 
supports TLS1.2, the server will return a server hello with TLS1.2. However 
when it reads data from the session buffer expecting a ClientKeyExchange 
message, it will start getting the 0-RTT data. 

In a case where the server is smart enough to discard all this data (maybe its 
a special TLS1.2  + TLS1.3 server), the behavior when this happens on the 
client side is unspecified, should the client supply the data again in the 
normal TLS stream? should it not resend that data?

It's probably better to reject this fallback when the client has chosen to 
explicitly use a TLS 1.3 feature with 0-RTT in general.

Subodh

From: Martin Thomson [martin.thom...@gmail.com]
Sent: Tuesday, March 29, 2016 6:29 PM
To: David Benjamin
Cc: Subodh Iyengar; tls@ietf.org
Subject: Re: [TLS] Tickets and cross protocol attacks

On 30 March 2016 at 05:00, David Benjamin  wrote:
> On the server, OpenSSL already includes the version in the SSL_SESSION
> structure, and recent enough versions of it will not accept sessions at the
> wrong version


NSS too.  This is the right thing, I think.

I have no objection to making this a requirement in the spec.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites

[Salz, Rich]

> 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 mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites

[Daniel Kahn Gillmor]

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 to get rid of.

I think i agree with Ben here: if we have a tri-state:
approved/not-approved/known-bad, then the people will infer that the
not-approved ciphersuites are better than the known-bad ones, which
isn't necessarily the case.

I think i'd rather see it stay at "approved/not-approved"

  --dkg

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites

[Henrick Hellström]

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 how about explicitly marking things as "obsolete" instead?

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Why again can't we use TLS signing certs to create short-lived sub-certs?

[Bill Cox]

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 impact of the recent paper by Jager at al. [0] on TLS 1.3 and
> QUIC.
>
> With that said, I think this would be a good feature to look at in future
> and the right way to do it is to:
>
> 1. Add a "this is only usable for TLS 1.3 [or for subcerts]" extension to
> PKIX.
> 2. Add a subcert extension to TLS 1.3.
>

OK, awesome.  Is it too early to volunteer for this effort?  Do you know
who the right person is to contact?

Thanks again,
Bill
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites

[Eric Rescorla]

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 to add an
> “IETF Recommended” column to the registry.  This change is motivated by the
> large # of requests received for code points [0], the need to alter the
> incorrect perception that getting a code point somehow legitimizes the
> suite/algorithm, and to help implementers out.  We need to determine
> whether we have consensus on this plan, which follows:
>
> 1. The IANA registry rules for the TLS cipher suite registry [1] will be
> changed to specification required.
>
> 2. A new “IETF Recommended” column will be added with two values: “Y” or
> “N”.  Y and N have the following meaning:
>
>  Cipher suites marked with a “Y” the IETF has consensus on
>  and are reasonably expected to be supported by widely
>  used implementations such as open-source libraries.  The
>  IETF takes no position on the cipher suites marked with an
>  “N”.  Not IETF recommended does not necessarily (but can)
>  mean that the ciphers are not cryptographically sound (i.e.,
>  are bad).  Cipher suites can be recategorized from N to Y
>  (e.g., Curve448) and vice versa.
>
> 3. We will add a “Note" to the IANA registry itself (i.e., on [0]) that
> matches the above so that the same information is available to those who
> don’t read the IANA considerations section of the RFC.
>
> Please indicate whether or not you could support this plan.
>
> Thanks,
>
> J
>
> [0] In the last year, the chairs have received requests for:
>
> PSK: https://datatracker.ietf.org/doc/draft-mattsson-tls-ecdhe-psk-aead/
> AES-OCB: https://www.ietf.org/archive/id/draft-zauner-tls-aes-ocb-03.txt
> Kcipher2: https://datatracker.ietf.org/doc/draft-kiyomoto-kcipher2-tls/
> dragonfly: https://datatracker.ietf.org/doc/draft-ietf-tls-pwd/
> NTRU:  http://www.ietf.org/id/draft-whyte-qsh-tls12-01.txt
> JPAKE: not sure they got around to publishing a draft.
>
> [1]
> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 回复： A TLS extension transfering service indication information

[Eric Rescorla]

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
> information
>
>
>
> On Tue, Mar 29, 2016 at 6:42 PM, Dacheng Zhang <
> dacheng@alibaba-inc.com> wrote:
>
>> Hi, Ekr:
>>
>> Thanks for reviewing the draft and the comments. Please see my reply
>> inline please.
>>
>> 发件人: Eric Rescorla 
>> 日期: 2016年3月30日 星期三 上午7:21
>> 至: dacheng de 
>> 抄送: Eric Mill , Dave Garrett ,
>> tls 
>> 主题: Re: [TLS] 回复： A TLS extension transfering service indication
>> information
>>
>> I have taken an initial look at this document, but I find myself confused
>> about the security
>> model.
>>
>> Specifically, you say that you can't use SNI because customers will lie
>> and insert
>> the SNI for service A in the ClientHello when going to service B.
>> However, I don't
>> see how this token stops that, since all it represents is a bare
>> assertion of where
>> you are going that is authenticated with a MAC shared between the client,
>> the
>> ICP, and the ISP. What stops the client from doing the same thing, i.e.,
>> injecting
>> the token for service A into a connection destined for service B? B can
>> just ignore
>> the SI token, right?
>>
>> Dacheng： This is a very good point. How to secure the APPs on the client
>> device (e.g., How to secure client and prevent the message sent out from an
>> APP provided by ICP A from being intercepted by an APP provided by ICP B
>> installed on the same mobile)  is a hot topic. Lots of people are
>> working hard to address this issue. For instance, TEE is an attempt of
>> protecting the security of APPS on a mobile. In a TEE, APPs action are
>> controlled and secure channels are provided to distributed keys. So, in our
>> solution, we did not consider the case where the execution environment of
>> APPs is not secure. We assume if an attacker or a malicious has compromise
>> a mobile, it could cause more serious damages.
>>
>
> 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 intends to access. Because the SNI is static which
> may not be changed for months, it is easier for attackers who monitor the
> network to get the SNI and use it to gain benefit. We need a securer
> solution. As I have mentioned in my previous email, this solution will make
> such attacks more difficult. By the way, SNI is not designed for this
> purpose, we need to do some additional work to address this issue, right?
>

Again, you need a threat model. It sounds like you both do and do not trust
the client



> Hmm... I'm not at all sure that TLS should address this problem. However,
> my review
> was directed to whether your proposed solution even works on its own terms.
>
> Dacheng: That is why we need to raise the discussion here. It would be
> great if this issue could be considered by TLS WG.
>

I don't find this to be a very compelling use case and I don't think it's
really appropriate to
try to solve it at the TLS layer. If you want to have secure flow
identification you should
do it at the IP or TCP layers.

-Ekr
>
>
>
>
>> We found this issue when we tried to widely use TLS to secure the
>> communications between our APPs and our services. If there could be any
>> better idea or solution, we will be very happy to support it.
>>
>> Finally, why am I seeing what appears to be a MAC algorithm definition in
>> Section
>> 2.1. Is there a reason you can't just use/cite HMAC?
>>
>> Dacheng: I reuse this content from my previous drafts. If people don’t
>> like it, we could remove it. ^_^
>>
>> Thanks a lot for your review, and look forward to further discussions on
>> this topic. ^_^
>>
>> Cheers
>>
>> Dacheng
>>
>> -Ekr
>>
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Mar 29, 2016 at 12:48 AM, Dacheng Zhang <
>> dacheng@alibaba-inc.com> wrote:
>>
>>> Hi,
>>>
>>> Actually, we refer to the extension as a 'SNI' extension. In this
>>> extension, SI(service indication) information is provided. In the next
>>> version, we will use 'SI extension' to take place of 'SNI extension'. ^_^
>>>
>>> Cheers
>>>
>>> Dacheng
>>>
>>> --
>>> 发件人：Dave Garrett 
>>> 发送时间：2016年3月29日(星期二) 14:52
>>> 收件人：Eric Mill 
>>> 抄 送：tls ，张大成(淡久) 
>>> 主 题：Re: [TLS] A TLS extension transfering service indication information
>>>
>>> On Tuesday, March 29, 2016 01:35:50 am 

Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites

[Benjamin Kaduk]

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” column to the registry.  This change is motivated by the 
> large # of requests received for code points [0], the need to alter the 
> incorrect perception that getting a code point somehow legitimizes the 
> suite/algorithm, and to help implementers out.  We need to determine whether 
> we have consensus on this plan, which follows:
>
> 1. The IANA registry rules for the TLS cipher suite registry [1] will be 
> changed to specification required.
>
> 2. A new “IETF Recommended” column will be added with two values: “Y” or “N”. 
>  Y and N have the following meaning:
>
>  Cipher suites marked with a “Y” the IETF has consensus on
>  and are reasonably expected to be supported by widely
>  used implementations such as open-source libraries.  The
>  IETF takes no position on the cipher suites marked with an
>  “N”.  Not IETF recommended does not necessarily (but can)
>  mean that the ciphers are not cryptographically sound (i.e.,
>  are bad).  Cipher suites can be recategorized from N to Y
>  (e.g., Curve448) and vice versa.
>
> 3. We will add a “Note" to the IANA registry itself (i.e., on [0]) that 
> matches the above so that the same information is available to those who 
> don’t read the IANA considerations section of the RFC.
>
> Please indicate whether or not you could support this plan.
>


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 potential issue).

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.

-Ben

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Why again can't we use TLS signing certs to create short-lived sub-certs?

[Eric Rescorla]

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.

With that said, I think this would be a good feature to look at in future
and the right way to do it is to:

1. Add a "this is only usable for TLS 1.3 [or for subcerts]" extension to
PKIX.
2. Add a subcert extension to TLS 1.3.

Best,
-Ekr

[0]  https://www.nds.rub.de/media/nds/.../2015/08/21/*Tls13Quic*Attacks.pdf

On Wed, Mar 30, 2016 at 2:46 AM, Bill Cox  wrote:

> IIRC, TLS 1.3 will not offer big companies the ability to create
> short-lived sub-certificates specific to remote satellite locations.  This
> forces companies to choose between good physical security for their signing
> certs, or having fast connection times.  Am I recalling correctly that TLS
> 1.3 has this problem?  I thought we fixed this in QUIC crypto.
>
> Thanks,
> Bill
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites

[Henrick Hellström]

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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites

[Dmitry Belyavsky]

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 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” column to the registry.  This change is motivated by the
> large # of requests received for code points [0], the need to alter the
> incorrect perception that getting a code point somehow legitimizes the
> suite/algorithm, and to help implementers out.  We need to determine
> whether we have consensus on this plan, which follows:
>
> 1. The IANA registry rules for the TLS cipher suite registry [1] will be
> changed to specification required.
>
> 2. A new “IETF Recommended” column will be added with two values: “Y” or
> “N”.  Y and N have the following meaning:
>
>  Cipher suites marked with a “Y” the IETF has consensus on
>  and are reasonably expected to be supported by widely
>  used implementations such as open-source libraries.  The
>  IETF takes no position on the cipher suites marked with an
>  “N”.  Not IETF recommended does not necessarily (but can)
>  mean that the ciphers are not cryptographically sound (i.e.,
>  are bad).  Cipher suites can be recategorized from N to Y
>  (e.g., Curve448) and vice versa.
>
> 3. We will add a “Note" to the IANA registry itself (i.e., on [0]) that
> matches the above so that the same information is available to those who
> don’t read the IANA considerations section of the RFC.
>
> Please indicate whether or not you could support this plan.
>
> Thanks,
>
> J
>
> [0] In the last year, the chairs have received requests for:
>
> PSK: https://datatracker.ietf.org/doc/draft-mattsson-tls-ecdhe-psk-aead/
> AES-OCB: https://www.ietf.org/archive/id/draft-zauner-tls-aes-ocb-03.txt
> Kcipher2: https://datatracker.ietf.org/doc/draft-kiyomoto-kcipher2-tls/
> dragonfly: https://datatracker.ietf.org/doc/draft-ietf-tls-pwd/
> NTRU:  http://www.ietf.org/id/draft-whyte-qsh-tls12-01.txt
> JPAKE: not sure they got around to publishing a draft.
>
> [1]
> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
SY, Dmitry Belyavsky
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Narrowing the replay window

[Martin Thomson]

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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls