On Apr 03, 2016, at 22:24, Dan Harkins wrote:
>
> I wonder if you have thought this through or prepped the
> stuckee?
During Wed’s session the chairs took the action to prep the “stuckee(s)”.
Those other stuckee(s) include:
- Our AD (Stephen for the next year): is following along.
- The Ind
not right to me.
Regards,
Quynh.
From: TLS on behalf of Hannes Tschofenig
Sent: Thursday, March 31, 2016 9:45 AM
To: Sean Turner;
Subject: Re: [TLS] call for consensus: changes to IANA registry rules for
cipher suites
Hi Sean,
What is the
On Apr 06, 2016, at 12:21, Aaron Zauner wrote:
>
> Hi,
>
>> On 30 Mar 2016, at 03:53, 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 d
Hi,
> On 30 Mar 2016, at 03:53, 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
On Tue, April 5, 2016 7:42 am, Adam Langley wrote:
> On Tue, Apr 5, 2016 at 4:55 PM, Peter Gutmann
> wrote:
>> How hard can it be to implement TLS-PSK? I did it in a few hours in my
>> crypto
>> library.
>
> This is getting off topic (which is my fault) but, for us, it wouldn't
> be "just" imple
On Tue, Apr 5, 2016 at 4:55 PM, Peter Gutmann wrote:
> How hard can it be to implement TLS-PSK? I did it in a few hours in my crypto
> library.
This is getting off topic (which is my fault) but, for us, it wouldn't
be "just" implementing PSK.
We would need to evangelise it sufficiently with eno
Adam Langley writes:
>Ideas for supporting this case (i.e. the "I want to do HTTPS to my router"
>problem) in browsers have done the rounds a few times.
This isn't for HTTPS to a router, it's to SCADA devices. The preferred
interface to them is HTTPS, but since browsers have refused to implemen
On Mon, Apr 4, 2016 at 9:39 PM, Peter Gutmann wrote:
> Because they have neither a DNS name nor a fixed IP address. I ran into this
> just last week with a customer, they couldn't use certs for their embedded
> devices and couldn't use PSK because the browser vendors have chosen not to
> support
On Mon, April 4, 2016 10:46 am, Phil Lello wrote:
>>
>> >> Usually what happens is the server generates a self-signed
>> certificate
>> >> and the apps are given some "username" and "password" and the app
>> >> ignores the unauthenticated nature of the TLS connection and sends
>> >> the u/p crede
>
> >> Usually what happens is the server generates a self-signed certificate
> >> and the apps are given some "username" and "password" and the app
> >> ignores the unauthenticated nature of the TLS connection and sends
> >> the u/p credential on through.
> >
> > Isn't this use case more of an arg
On Mon, April 4, 2016 8:50 am, Phil Lello wrote:
> On Mon, Apr 4, 2016 at 3:36 PM, Dan Harkins wrote:
>
>>
>> Usually what happens is the server generates a self-signed certificate
>> and the apps are given some "username" and "password" and the app
>> ignores the unauthenticated nature of the T
On 4/4/16, 12:50, "Phil Lello" wrote:
>
>
>On Mon, Apr 4, 2016 at 3:36 PM, Dan Harkins
> wrote:
>
>
>
>
>Isn't this use case more of an argument for an updated auth-digest to use
>something better than MD5? I'm not convinced MITM is a real concern for a
>typical IoT environment (however that's
On Mon, Apr 4, 2016 at 3:36 PM, Dan Harkins wrote:
>
>
> On Mon, April 4, 2016 7:17 am, Watson Ladd wrote:
>
> Usually what happens is the server generates a self-signed certificate
> and the apps are given some "username" and "password" and the app
> ignores the unauthenticated nature of the TLS
Watson Ladd writes:
>Actually, PKI certs are not required. There is an extension to support use of
>bare keys for authentication. And if you can provision with a shared secret,
>you can provision with a private key.
And how many browsers support that?
Peter.
On Mon, Apr 4, 2016 at 7:39 AM, Peter Gutmann wrote:
> Watson Ladd writes:
>
>>Why can't embedded devices use certificates?
>
> Because they have neither a DNS name nor a fixed IP address. I ran into this
> just last week with a customer, they couldn't use certs for their embedded
> devices and
Watson Ladd writes:
>Why can't embedded devices use certificates?
Because they have neither a DNS name nor a fixed IP address. I ran into this
just last week with a customer, they couldn't use certs for their embedded
devices and couldn't use PSK because the browser vendors have chosen not to
s
On Mon, April 4, 2016 7:17 am, Watson Ladd wrote:
> On Mon, Apr 4, 2016 at 7:05 AM, Dan Harkins wrote:
>>
>>
>> On Thu, March 31, 2016 10:51 am, Stephen Farrell wrote:
>>>
>>> If smaller devices don't use algorithms that can be used to talk to
>>> random servers on the Internet, then they are ch
> > Not always; ISO et al.
>
> That's why I said "basically"; it's a qualifier.
I know; I was trying to emphasize, not correct :).
> But keep in mind what kind of stable, publicly available document needs to
> be published: a description not of the algorithm but of how that algorithm
> get
On Mon, Apr 4, 2016 at 7:05 AM, Dan Harkins wrote:
>
>
> On Thu, March 31, 2016 10:51 am, Stephen Farrell wrote:
>>
>> If smaller devices don't use algorithms that can be used to talk to
>> random servers on the Internet, then they are choosing to not try to
>> get interop. That seems like a shame
On Thu, March 31, 2016 10:51 am, Stephen Farrell wrote:
>
> If smaller devices don't use algorithms that can be used to talk to
> random servers on the Internet, then they are choosing to not try to
> get interop. That seems like a shame to me, unless there's a really
> good reason and IMO, mostl
On Sun, April 3, 2016 7:24 pm, Salz, Rich wrote:
>
>> A stable, publicly available document is basically an RFC.
>
> Not always; ISO et al.
That's why I said "basically"; it's a qualifier.
But keep in mind what kind of stable, publicly available
document needs to be published: a descripti
> A stable, publicly available document is basically an RFC.
Not always; ISO et al.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Hi Sean,
In general I support this but
A stable, publicly available document is basically an RFC.
So when the TLS WG says no that means asking an AD to sponsor
or putting it into the Independent Stream process. So what it
looks like you're doing is punting this problem into the lap of
iginal Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Stephen Farrell
Sent: Thursday, March 31, 2016 10:52 AM
To: Hannes Tschofenig ; Salz, Rich
; Kaduk, Ben ;
Subject: Re: [TLS] call for consensus: changes to IANA registry rules for
cipher suites
If smaller devices don't
Hi,
> I am just a little bit worried that everything developed for the IoT
> enviroment is quite likely labled as not recommended by the IETF in this
> registry because of the Web focus in this group.
>
RFC 5246 speaks of "Application Profiles" and it seems like this
discussion that started to sim
If smaller devices don't use algorithms that can be used to talk to
random servers on the Internet, then they are choosing to not try to
get interop. That seems like a shame to me, unless there's a really
good reason and IMO, mostly there isn't, at the ciphersuite level. I
would hope we all won't
Hannes,
Aside from JPAKE, which algorithms are you concerned about?
-Ekr
On Thu, Mar 31, 2016 at 10:40 AM, Hannes Tschofenig <
hannes.tschofe...@gmx.net> wrote:
> I can see some value in having this IANA registry list for ciphersuites
> in the way being proposed (even if it may be interpreted
I can see some value in having this IANA registry list for ciphersuites
in the way being proposed (even if it may be interpreted differently by
different audiences). There have been, of course, too many algorithms
used only in specific countries and those substantially increased the
ciphersuite lis
> Interesting idea. You see this IANA registry more as the mandatory to
> implement algorithm list (for Web apps).
I don't. But lots of outsiders do, and I know they exert pressure on various
projects and TLS/AD "leadership". I've only had a little bit of it via openssl
compared to those folks
Hi Rich,
On 03/31/2016 07:17 PM, Salz, Rich wrote:
> I am very confident it will help. For example, it now becomes a
> reasonable position for most TLS stacks to include only Y
> ciphersuites in their default source or build or deploy methods. It
> will also have an effect on reducing clientHell
Well, "most people [in the world" do not care about any documents the
IETF puts out. I am not sure what population of people you are actually
trying to make a statement about.
I am not confident that adding this column will actually have a useful
impact, but I think the experiment is worth perfor
The primary purpose of this compromise is to unjam the many requests for
code
points that otherwise clog the WG and expert review process. I believe it
will at
least do that.
-Ekr
On Thu, Mar 31, 2016 at 10:14 AM, Benjamin Kaduk wrote:
> Well, "most people [in the world" do not care about any
> I am not confident that adding this column will actually have a useful impact,
> but I think the experiment is worth performing.
I am very confident it will help. For example, it now becomes a reasonable
position for most TLS stacks to include only Y ciphersuites in their default
source or b
In essence you are saying that most people are not going to care about
the Y/N in the IANA table anyway. Somewhat similar to people not
understanding the difference between the different types of RFCs.
That sounds pragmatic.
Ciao
Hannes
On 03/31/2016 06:52 PM, Benjamin Kaduk wrote:
> On 03/31/20
On 03/31/2016 11:20 AM, Hannes Tschofenig wrote:
> Hi Ben,
>
> just think about the mentioned JPAKE extension: what type of deployment
> can you expect? It is something that Thread decided to use. Will Thread,
> as a mesh networking technology, be successful and widely be deployed?
> We don't know
> 802.15.4 then it will be fairly widely used in the IoT sector. I am sure the
> authors of the Thread specifications (and the members of the Thread
> consortium) expect their stuff to be widely used (in IoT -- not on the Web).
They can get a code-point but not a Y since there is no IETF consensus
Hi Ben,
just think about the mentioned JPAKE extension: what type of deployment
can you expect? It is something that Thread decided to use. Will Thread,
as a mesh networking technology, be successful and widely be deployed?
We don't know yet but if it becomes a technology of choice for use with
IE
On 03/31/2016 08:45 AM, Hannes Tschofenig wrote:
> Hi Sean,
>
> What is the requirement for adding a spec to the list with the value
> IETF Recommended = "Y" (or to change an entry from "Y" to "N")?
>
> You mention two conditions:
>
> * IETF has consensus
> * Are reasonably expected to be support
> A black/white
> distinction will probably lead to a lot of discussion, and different
> implementation purposes could call for more subtlety.
I strongly thing it's the exact opposite. A simple "yes an IETF WG came to
consensus on this" is much simpler than trying to debate various shades of
g
Hi,
In general I think this is a good form of relaxation. However,
>
> Cipher suites marked with a “Y” the IETF has consensus on
An alternative could be to mark the entry with the RFC 5226 level of the
documentation, and indicate what levels are acceptable. A black/white
distinction will prob
consensus: changes to IANA registry rules for
cipher suites
Hi Sean,
What is the requirement for adding a spec to the list with the value
IETF Recommended = "Y" (or to change an entry from "Y" to "N")?
You mention two conditions:
* IETF has consensus
* Are reaso
> What is the requirement for adding a spec to the list with the value IETF
> Recommended = "Y" (or to change an entry from "Y" to "N")?
I believe the primary concern is *not* to address IETF products, but rather
non-IETF organizations that want a codepoint.
_
Hi Sean,
What is the requirement for adding a spec to the list with the value
IETF Recommended = "Y" (or to change an entry from "Y" to "N")?
You mention two conditions:
* IETF has consensus
* Are reasonably expected to be supported by widely used
implementations such as open-source libraries
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/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
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
+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 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 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 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 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 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
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 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 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 Tue 2016-03-29 21:53:13 -0400, Sean Turner wrote:
> 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
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
Strongly support this.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
67 matches
Mail list logo
