Subject: [TLS] Additional changes for draft-ietf-tls-iana-registry-updates

From: Sean Turner <[email-masked]>
Date: Fri, 16 Mar 2018 14:01:48 +0000

During Adam Roach’s AD review of draft-ietf-tls-tls13, he noted something about the HashAlgorithm and that made me go look at what was said in draft-ietf-tls-iana-registry-updates.  Turns out that 4492bis assigned some values draft-ietf-tls-iana-registry-updates was marking as reserved.  I have fixed that up in:
https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/65

One further point brought out in discussions with Adam was that if we’re really closing the HashAlgorithm and SignatureAlgorithms registry we need to also mark 224-255 as deprecated.  Currently these are marked as Reserved for Private Use.  So the question is should we mark 224-255 as deprecated in these two registries?

spt

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 16 Mar 2018 15:07:19 -0500

> One further point brought out in discussions with Adam was that if we’re really closing the HashAlgorithm and SignatureAlgorithms registry we need to also mark 224-255 as deprecated.  Currently the…

With no hats, yes, we should mark those ranges as deprecated, since
there is no warning about them in the SignatureScheme registry and
the latter is the way of the future.

-Ben

---

From: Rene Struik <[email-masked]>
Date: Tue, 20 Mar 2018 10:51:11 -0400

Hi Sean:

Quick question: does "closing the registry" not contradict catering towards crypto agility? What happens if, say, one wishes to add another signature scheme, besides Ed25519, to the mix. If there is no private field, does this mean that, e.g., Schnorr+BSI Brainpool256r1 is now ruled out? 

My more serious concern is, however, that if the Private Use case is "verboten", there is no chance for people to signal private extensions (since IETF will just have killed this off).

I do not think it is prudent to have a slow process in place (IETF standardization) to effectuate crypto agility, if private use can already do this without waiting for 3-year public discussions and heated debate (if a weakness is discovered, dark forces will exploit this right away and won't wait for IETF to catch up to exploit an issue).

As case in point, suppose US Gov't wants to roll its own "Suite A" scheme, or if one wants to use TLS with something tailored towards the sensor world (which operates in quite a hostile environment for implementation security), how is one going to do this in context of TLS if the signaling required has just been removed?

NOTE: this is not an invite for endless discussions on the legitimacy of whoever may wish a private extensions (it is private after all), it does question though the wisdom of removing the option for using this. If Zulu hour arrives, one should have tools to act...

Best regards, Rene

On 3/16/2018 10:01 AM, Sean Turner wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 20 Mar 2018 14:54:24 +0000

On Tue, Mar 20, 2018 at 2:51 PM, Rene Struik <[email-masked]> wrote:

> Hi Sean:
>
> Quick question: does "closing the registry" not contradict catering
> towards crypto agility? What happens if, say, one wishes to add another
> signature scheme, besides Ed25519, to the mix. If there is no private
> field, does this mean that, e.g., Schnorr+BSI Brainpool256r1 is now ruled
> out?
>

No. Private just means "we're not going to allocate these code points, so
you should use them without coordination".

The key point here is that this is a big space and so we're instead going
to make it easy for people to reserve code points by writing a stable spec,
that need not be an IETF standard, and that's what they should do.

-Ekr

>
> My more serious concern is, however, that if the Private Use case is
> "verboten", there is no chance for people to signal private extensions
> (since IETF will just have killed this off).
>
> I do not think it is prudent to have a slow process in place (IETF
> standardization) to effectuate crypto agility, if private use can already
> do this without waiting for 3-year public discussions and heated debate (if
> a weakness is discovered, dark forces will exploit this right away and
> won't wait for IETF to catch up to exploit an issue).
>
> As case in point, suppose US Gov't wants to roll its own "Suite A" scheme,
> or if one wants to use TLS with something tailored towards the sensor world
> (which operates in quite a hostile environment for implementation
> security), how is one going to do this in context of TLS if the signaling
> required has just been removed?
>
> NOTE: this is not an invite for endless discussions on the legitimacy of
> whoever may wish a private extensions (it is private after all), it does
> question though the wisdom of removing the option for using this. If Zulu
> hour arrives, one should have tools to act...
>
> Best regards, Rene
>
> > During Adam Roach’s AD review of draft-ietf-tls-tls13, he noted
> something about the HashAlgorithm and that made me go look at what was said
> in draft-ietf-tls-iana-registry-updates.  Turns out that 4492bis assigned
> some values draft-ietf-tls-iana-registry-updates was marking as
> reserved.  I have fixed that up in:
> > One further point brought out in discussions with Adam was that if we’re
> really closing the HashAlgorithm and SignatureAlgorithms registry we need
> to also mark 224-255 as deprecated.  Currently these are marked as Reserved
> for Private Use.  So the question is should we mark 224-255 as deprecated
> in these two registries?
> >
> > spt

---

From: Rene Struik <[email-masked]>
Date: Tue, 20 Mar 2018 13:06:43 -0400

Hi Eric:

I may have an incorrect impression about the code points, but, let us
say, one finds out an attack on one of the TLS1.3 algorithms and wishes
to swap the algorithm set for a new one (that is clearly specified, say,
"RS-Alg-X"). How does one do this if one marks 224-255 as deprecated.
How does one signal private use of "RS-Alg-X" now. If you could tell me,
please let me know, so that I feel more at ease with this. {This should
not be something where reliability is impossible to achieve).

Thanks!

Rene

> One further point brought out in discussions with Adam was that if
we’re really closing the HashAlgorithm and SignatureAlgorithms registry
we need to also mark 224-255 as deprecated.  Currently these are marked
as Reserved for Private Use.  So the question is should we mark 224-255
as deprecated in these two registries?

On 3/20/2018 10:54 AM, Eric Rescorla wrote:
>
>
> On Tue, Mar 20, 2018 at 2:51 PM, Rene Struik <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Sean:
>
>     Quick question: does "closing the registry" not contradict
>     catering towards crypto agility? What happens if, say, one wishes
>     to add another signature scheme, besides Ed25519, to the mix. If
>     there is no private field, does this mean that, e.g., Schnorr+BSI
>     Brainpool256r1 is now ruled out?
>
>
> No. Private just means "we're not going to allocate these code points,
> so you should use them without coordination".
>
> The key point here is that this is a big space and so we're instead
> going to make it easy for people to reserve code points by writing a
> stable spec, that need not be an IETF standard, and that's what they
> should do.
>
>
> -Ekr
>  
>
>
>     My more serious concern is, however, that if the Private Use case
>     is "verboten", there is no chance for people to signal private
>     extensions (since IETF will just have killed this off).
>
>     standardization) to effectuate crypto agility, if private use can
>     already do this without waiting for 3-year public discussions and
>     heated debate (if a weakness is discovered, dark forces will
>     exploit this right away and won't wait for IETF to catch up to
>     exploit an issue).
>
>     As case in point, suppose US Gov't wants to roll its own "Suite A"
>     scheme, or if one wants to use TLS with something tailored towards
>     the sensor world (which operates in quite a hostile environment
>     for implementation security), how is one going to do this in
>     context of TLS if the signaling required has just been removed?
>
>     NOTE: this is not an invite for endless discussions on the
>     legitimacy of whoever may wish a private extensions (it is private
>     after all), it does question though the wisdom of removing the
>     option for using this. If Zulu hour arrives, one should have tools
>     to act...
>
>     Best regards, Rene
>
>     something about the HashAlgorithm and that made me go look at what
>     was said in draft-ietf-tls-iana-registry-updates.  Turns out that
>     4492bis assigned some values draft-ietf-tls-iana-registry-updates
>     was marking as reserved.  I have fixed that up in:
>     >
>     <https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/65>
>     >
>     > One further point brought out in discussions with Adam was that
>     if we’re really closing the HashAlgorithm and SignatureAlgorithms
>     registry we need to also mark 224-255 as deprecated.  Currently
>     these are marked as Reserved for Private Use.  So the question is
>     should we mark 224-255 as deprecated in these two registries?
>     >
>     > spt
>     > [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/tls>
>
>
>     --
>     email: [email-masked] <mailto:[email-masked]> |
>     Skype: rstruik
>     cell: +1 (647) 867-5658 <tel:%2B1%20%28647%29%20867-5658> | US: +1
>     (415) 690-7363 <tel:%2B1%20%28415%29%20690-7363>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/tls>
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 20 Mar 2018 17:26:52 +0000

On Tue, Mar 20, 2018 at 5:06 PM, Rene Struik <[email-masked]> wrote:

> Hi Eric:
>
> I may have an incorrect impression about the code points, but, let us say,
> one finds out an attack on one of the TLS1.3 algorithms and wishes to swap
> the algorithm set for a new one (that is clearly specified, say,

I don't understand the question. There are plenty of other code points, we
just no longer break them up into signature/hash pairs.

> How does one signal private use of "RS-Alg-X" now.
>

You publish a specification that meets the specification bar and file for a
code point.

-Ekr

> If you could tell me, please let me know, so that I feel more at ease with
> this. {This should not be something where reliability is impossible to
> achieve).
>

>> scheme, or if one wants to use TLS with something tailored towards the
>> sensor world (which operates in quite a hostile environment for
>> implementation security), how is one going to do this in context of TLS if
>> the signaling required has just been removed?
>>
>> in draft-ietf-tls-iana-registry-updates.  Turns out that 4492bis
>> assigned some values draft-ietf-tls-iana-registry-updates was marking as
>> we’re really closing the HashAlgorithm and SignatureAlgorithms registry we
>> need to also mark 224-255 as deprecated.  Currently these are marked as
>> Reserved for Private Use.  So the question is should we mark 224-255 as
>> deprecated in these two registries?
>> >
>> > spt
>> cell: +1 (647) 867-5658 <%2B1%20%28647%29%20867-5658> | US: +1 (415)
>> 690-7363 <%2B1%20%28415%29%20690-7363>
>>
> cell: +1 (647) 867-5658 <(647)%20867-5658> | US: +1 (415) 690-7363 <(415)%20690-7363>
>
>

---

From: Sean Turner <[email-masked]>
Date: Thu, 22 Mar 2018 10:07:16 +0000

I had a quick chat with the iANA folks about the HashAlgorithm and SignatureAlgorithm, which we are effectively closing by marking all unregistered bits as either reserved or depcreated.  IANA suggested another way which is to just close the registry,   An example for the registry follows:

	TLS HashAlgorithm Registry

	Registration Procedure(s)

	Closed see [this-to-be-rfc]

	Reference

	[RFC5246][this-to-be-rfc]

We’d make the following changes to the draft:

OLD:
    [SHALL update/has updated] the TLS HashAlgorithm Registry to list
    values 7-223 as "Reserved" and the TLS SignatureAlgorithm registry
    to list values 4-223 as "Reserved”.

NEW:
    [SHALL close/has closed] the TLS HashAlgorithm Registry and
    the TLS SignatureAlgorithm registries for new assignments.

I personally think this is cleaner that reserving the values.  But, it does mean that this registries are closed for assignments.

spt

> On Mar 16, 2018, at 14:01, Sean Turner <[email-masked]> wrote:
>

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 22 Mar 2018 10:10:36 +0000

Sean Turner <[email-masked]> writes:

>I had a quick chat with the iANA folks about the HashAlgorithm and
>SignatureAlgorithm, which we are effectively closing by marking all
>unregistered bits as either reserved or depcreated.  IANA suggested another
>way which is to just close the registry,

This seems a bit of a strange thing to do, if it's going to be closed as soon
as the RFC is published then why have it?  A registry implies you can register
things in it, while this will be just a publication of existing values with no
ability to register new ones.  If it's that then it's a List of Algorithm IDs,
not a Registry.

Peter.

---

From: Sean Turner <[email-masked]>
Date: Thu, 22 Mar 2018 11:42:00 +0000

> On Mar 22, 2018, at 10:10, Peter Gutmann <[email-masked]> wrote:
> 

Peter,

I think you’re saying that once the registries are closed we don’t call them registries?  I think I can get the registry title to be:

TLS HashAlgorithm - Registry Closed

spt

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 22 Mar 2018 12:53:22 +0000

I am inclined to agree with Peter.  It doesn't quite seem like a registry if the very first time there is a list of things in it, that list is now frozen.

Why are we closing/reserving all the bits?

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 23 Mar 2018 07:57:59 -0500

> Why are we closing/reserving all the bits?

Huh?  These are for the old TLS 1.2 separately negotiated Hash and
Signature registries, that have been pouplated for quite some time.
We need to close them or reserve "all" free values in order to not
conflict with the new TLS 1.3 SignatureScheme registry that uses
combined 16-bit codepoints, but share space on the wire.

Closing the registries does seem to be a better match for our
intended future for these registries, but I am curious if you asked
what the procedure would be on the off chance that we did need to
reopen them for some reason.

-Ben

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 23 Mar 2018 12:59:57 +0000

So we have two registries that share a number space.

Sounds like the right solution is for the registries to coordinate.

---

From: Alex C <[email-masked]>
Date: Sat, 24 Mar 2018 19:20:21 +1300

I'm hesitant to call a 16-bit registry "big" in any context.
But if allocating a value requires a specification, that's probably okay.
(There aren't even close to 2^16 RFCs in total)

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 26 Mar 2018 12:18:06 -0500

> Sounds like the right solution is for the registries to coordinate. 

Well, there are three registries involved -- two existing one octet
registries that apply to TLS 1.2 and below, and a new TLS 1.3 registry
with two octets of space.  The original proposal by the authors was to
mark all the unallocated entries in the existing two registries as
either reserved or deprecated.  IANA noted that this is effectively the
same as closing the registries in terms of the difficulty of making
further registrations, though I am not sure that the authors replied to
the question that I think I asked about what the procedure is for
re-opening a registry should a need arise to allocate an additional
codepoint from it.

Anyway, it seems rather challenging to try to keep all three registries
open and coordinate amongst them, given that the new two-octet registry
has a pretty low "specification required" registration policy, and
allocations from the existing registries would apparently both require a
"contiguous" 256 values to be free in the new registry and then "knock
out" those 256 values from further use.  This would eat up the free
space in the new registry relatively quickly, and presumably would not
be compatible with a weak "specification required" policy (which is
currently the policy for values 64-223).  If we agree that
"specification required" is not appropriate for the existing one-octet
registries in a proposed "coordinate" scenario, then I don't see what
the policy would be other than "standards action" (the current policy
for values 0-63).  And if "standards action" is the bar, that would
require the IETF to do work on TLS 1.2 in order to need a new
registration, but this WG is chartered primarily for TLS 1.3 and
"require significant justification" to take on work for older versions. 
So it's extremely unclear to me that there's a plausible scenario in
which a registration in the existing registries would occur.  Such a
case could presumably reopen the existing registries for its use anyway,
given the level of review that would be needed.

So, in summary, closing these registries seems to adequately reflect (my
understanding of) our expectations for what will happen to them.  I'm
curious to know how your understanding differs.

-Ben

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 26 Mar 2018 17:24:54 +0000

Is it now impossible adding new things to TLS 1.2?  I don't believe the WG understood that this would be the situation.  So I disagree with your claim that this was our understanding of the situation.

Okay, it turns out that David's neat hack make some things harder. So what?

---

From: David Benjamin <[email-masked]>
Date: Mon, 26 Mar 2018 17:29:25 +0000

On Mon, Mar 26, 2018 at 1:25 PM Salz, Rich <[email-masked]> wrote:

> Is it now impossible adding new things to TLS 1.2?  I don't believe the WG
> understood that this would be the situation.  So I disagree with your claim
> that this was our understanding of the situation.
>

The intent was that additions to TLS 1.2 would just use the new registry
too (since the hack can be backported easily), e.g.
draft-ietf-tls-rfc4492bis-17. Though, yeah, it is a bit awkward text-wise.
:-/

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 26 Mar 2018 12:36:31 -0500

> Is it now impossible adding new things to TLS 1.2?  I don't believe the WG understood that this would be the situation.  So I disagree with your claim that this was our understanding of the situati…

I was under the impression that the WG was well aware, e.g., in my
comments on the 2nd WGLC, where I say "It looks like we no longer do
anything to obsolete/reserve/similar the HashAlgorithm and
SignatureAlgorithm registries; was that just an editorial mixup or an
intended change?", and Ekr replies with a link to the appropriate
section of draft-ietf-tls-iana-registry-updates, as seen at
https://www.ietf.org/mail-archive/web/tls/current/msg23865.html

> Okay, it turns out that David's neat hack make some things harder. So what?

I thought that's what I was asking you -- you seem to feel that we
should care about this, and I still don't understand why.

-Ben

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 26 Mar 2018 17:39:37 +0000

Was there a consensus to no longer accept 1.2 hash/sig alg identifiers? I don't recall that, and it clearly wasn't David's intent, as his mail to the list today shows.
    
    Seems like there's just some confusion that can be fixed with some text pointers.  The registry shouldn't be closed, but things reserved and a pointer to the 1.3 registry given instead.

---

From: Sean Turner <[email-masked]>
Date: Tue, 27 Mar 2018 07:13:10 +0100

> On Mar 26, 2018, at 18:18, Benjamin Kaduk <[email-masked]> wrote:
> 
>  IANA noted that this is effectively the

I’ll have to ask, but I suspect that someone who wanted a new assignment would draft an I-D that assigned the code point and it would go through the process.  I.e., I think it’s mostly symbolic.

spt