Re: [TLS] Case for negotiation of PKCS#1.5 RSASSA-PKCS1-v1_5 in TLS 1.3

[Hubert Kario]

On Thursday 21 January 2016 18:25:00 Andrey Jivsov wrote:
> Current draft of TLS 1.3 [1] mandates RSA-PSS in TLS handshake by the
> following language in sec 4.8.1
> 
> > In RSA signing, the opaque vector contains the signature
> > generated
> > using the RSASSA-PSS signature scheme defined in [RFC3447 
> > ] with MGF1. The digest
> > used in the mask generation function MUST be the same as the
> > digest which is being signed (i.e., what appears in
> > algorithm.signature).  The length of the salt MUST be equal to
> > the
> > length of the digest output.  Note that previous versions of TLS
> > used
> > RSASSA-PKCS1-v1_5, not RSASSA-PSS.
> 
> The
> 
> >struct {
> >
> >   SignatureAndHashAlgorithm algorithm;
> >   opaque signature<0..2^16-1>;
> >
> >} DigitallySigned;
> 
> defines RSA PKCS#1 1.5 and RSA PSS as "rsa" and "rsapss", see sec 
A.3.1.1:
> >enum {
> >
> >rsa(1),
> >dsa(2),
> >ecdsa(3),
> >rsapss(4),
> >eddsa(5),
> >(255)
> >
> >} SignatureAlgorithm;
> 
> since draft -09 (posted Oct 2015). "rsa" applies to X.509 certificates
> only.
> 
> 
> Many implementers of TLS 1.3 expressed desire for the TLS 1.3 to be as
> frictionless as possible regarding the upgrade of existing TLS
> installations to TLS 1.3. We should expect that all TLS 1.3 servers
> and clients will have support for older versions of TLS on the same
> node. Ideally, it should be possible to upgrade the software /
> firmware to add TLS 1.3 support on existing hardware with minimal
> penalty.

The transition to TLS 1.3 is not urgent matter. Making sure that it is 
as robust as possible is of higher importance than "making it easy to 
implement for existing TLS1.2 implementations".

That's right there in the charter:
https://datatracker.ietf.org/wg/tls/charter/

> The current list of FIPS 140 products that support RSA shows twice as
> many products that support RSASSA-PKCS1_V1_5 than these that support
> RSASSA-PSS [4]. There is greater than 50% chance to lose FIPS
> certification with TLS 1.3, factoring client auth and servers.

You also need a FIPS certified implementation of HKDF. So yes, it most 
likely will require new certifications.

> The only solution that's available at this point is conditioning TLS
> 1.3 support on appropriate hardware. For this reason TLS 1.3 it
> probably won't be enabled by default in the product I work on. I
> would prefer for TLS 1.3 to be enabled by default and write the code
> to decide whether it does PSS or falls back to RSA PKCS1 1.5.

Yes, it would be nice. But PKCS#1 v1.5 had it long coming. Not cutting 
it off now would be negligent.

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Length of a variable-length vector: Could it be an odd multiple?

[=JeffH]

[ resending from different account - my work addr ends up in spam bucket for 
many it seems ]


On 1/20/16, 11:01 AM, "Benjamin Kaduk"  wrote:
>On 01/20/2016 12:47 PM, Hodges, Jeff wrote:
>> On 1/13/16, 12:53 PM, "Benjamin Kaduk"  wrote:
>>> On 01/13/2016 02:44 PM, Jong-Shian Wu wrote:
 I have a question about the even-vs-odd restrictions on the length of
 a valid variable-length vector defined in TLS specification after
 reading the section 4.3 of RFC 5246 [1] which states that:
 "The length of an encoded vector must be an even multiple of the
length
 of a single element (for example, a 17-byte vector of uint16 would be
 illegal)."

>>> It means "whole-number" as opposed to fractional, i.e., there should
>>>not
>>> be unused "junk bytes" at the end.
>> In case it's helpful, here's a suggested re-write of that quoted
>>sentence
>> above..
>>
>>   The length of an encoded variable-length vector must be an
>>   exact multiple of the length of a single element. For example,
>>   an encoded 17-byte vector of uint16 would be illegal, and an
>>   encoded variable-length vector of four 32 byte elements,
>>   having a ceiling of 2^16-1, will be 130 bytes long overall
>>   (2 byte length field followed by 128 bytes of data).
>
>Wouldn't the ceiling more properly be 2^16-4 in that case?

hm, I'm not sure -- what would be the rationale?  The exact multiple
criteria?  but 2^16 / 32 = 2048  while  (2^16-4) / 32 = 2047.875

i do have further questions regarding variable-length vectors, and how
they are specified, that subsequent discussion will hopefully tease out.

thanks,

=JeffH

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

[TLS] Length of a variable-length vector: zero-length case

[=JeffH]

wrt https://tools.ietf.org/html/draft-ietf-tls-tls13-11#section-4.3

if we have..

  opaque foo<0..2^16-1>;

..with a floor length of zero, thus with an instantiation of foo of zero 
length, we actually will have in terms of encoded bytes on the wire (in hex)..


  00 00

..where this is the 2-byte length field, with length value zero, and a
zero-length (ie, absent, empty) vector content, correct ?

thanks,

=JeffH

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

Re: [TLS] Length of a variable-length vector: Could it be an odd multiple?

[Ilari Liusvaara]

On Wed, Jan 20, 2016 at 06:47:12PM +, Hodges, Jeff wrote:
> On 1/13/16, 12:53 PM, "Benjamin Kaduk"  wrote:
> >On 01/13/2016 02:44 PM, Jong-Shian Wu wrote:
> >> I have a question about the even-vs-odd restrictions on the length of
> >> a valid variable-length vector defined in TLS specification after
> >> reading the section 4.3 of RFC 5246 [1] which states that:
> 
> >>"The length of an encoded vector must be an even multiple of the length
> >>of a single element (for example, a 17-byte vector of uint16 would be
> >> illegal)."
> >>
> >
> >It means "whole-number" as opposed to fractional, i.e., there should not
> >be unused "junk bytes" at the end.
> 
> In case it's helpful, here's a suggested re-write of that quoted sentence
> above..
> 
>   The length of an encoded variable-length vector must be an
>   exact multiple of the length of a single element. For example,
>   an encoded 17-byte vector of uint16 would be illegal, and an
>   encoded variable-length vector of four 32 byte elements,
>   having a ceiling of 2^16-1, will be 130 bytes long overall
>   (2 byte length field followed by 128 bytes of data).
> 
> ..assuming I'm correctly understanding variable-length vectors :)

The length of length is inferred from the upper limit:
- 1-255 bytes => 1 Byte
- 256-65535 bytes => 2 Bytes
- 65536-16777215 bytes => 3 bytes
- 16777216-2^32-1 bytes => 4 bytes (not used anywhere)
... And so on.

So yes, 4x32 byte elements in vector with upper limit of 2^16-1 (or
2^16-32 rounded) is 130 bytes total: 2 byte length and 4*32=128 byte
value.

But I think that all lengths above 255 are either specified to be one
byte shy of power of 255 or rounding thereof to integral multiple of
elements (the only exception I offhand remember is session IDs in
TLS 1.0-1.2, which have maximum length of 32).

Then there are vectors with variable length elements. Those can be
created by putting in a vector or discriminant/case in the element
type (the latter can easily lead to interop problems later).


-Ilari

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

Re: [TLS] Length of a variable-length vector: zero-length case

[Eric Rescorla]

On Fri, Jan 22, 2016 at 7:50 AM, =JeffH 
wrote:

> wrt https://tools.ietf.org/html/draft-ietf-tls-tls13-11#section-4.3
>
> if we have..
>
>   opaque foo<0..2^16-1>;
>
> ..with a floor length of zero, thus with an instantiation of foo of zero
> length, we actually will have in terms of encoded bytes on the wire (in
> hex)..
>
>   00 00
>
> ..where this is the 2-byte length field, with length value zero, and a
> zero-length (ie, absent, empty) vector content, correct ?


Yes.

-Ekr


>
>
thanks,
>
> =JeffH
>
> ___
> 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] Case for negotiation of PKCS#1.5 RSASSA-PKCS1-v1_5 in TLS 1.3

[Andrey Jivsov]

On 01/22/2016 03:14 AM, Hubert Kario wrote:

On Thursday 21 January 2016 18:25:00 Andrey Jivsov wrote:

Current draft of TLS 1.3 [1] mandates RSA-PSS in TLS handshake by the
following language in sec 4.8.1


 In RSA signing, the opaque vector contains the signature
 generated
 using the RSASSA-PSS signature scheme defined in [RFC3447
 ] with MGF1. The digest
 used in the mask generation function MUST be the same as the
 digest which is being signed (i.e., what appears in
 algorithm.signature).  The length of the salt MUST be equal to
 the
 length of the digest output.  Note that previous versions of TLS
 used
 RSASSA-PKCS1-v1_5, not RSASSA-PSS.


The


struct {

   SignatureAndHashAlgorithm algorithm;
   opaque signature<0..2^16-1>;

} DigitallySigned;


defines RSA PKCS#1 1.5 and RSA PSS as "rsa" and "rsapss", see sec

A.3.1.1:

enum {

rsa(1),
dsa(2),
ecdsa(3),
rsapss(4),
eddsa(5),
(255)

} SignatureAlgorithm;


since draft -09 (posted Oct 2015). "rsa" applies to X.509 certificates
only.


Many implementers of TLS 1.3 expressed desire for the TLS 1.3 to be as
frictionless as possible regarding the upgrade of existing TLS
installations to TLS 1.3. We should expect that all TLS 1.3 servers
and clients will have support for older versions of TLS on the same
node. Ideally, it should be possible to upgrade the software /
firmware to add TLS 1.3 support on existing hardware with minimal
penalty.


The transition to TLS 1.3 is not urgent matter. Making sure that it is
as robust as possible is of higher importance than "making it easy to
implement for existing TLS1.2 implementations".

That's right there in the charter:
https://datatracker.ietf.org/wg/tls/charter/


The issue here is to be able to use existing hardware with TLS 1.3.

The CAs got PKCS#1 1.5 exemption under TLS 1.3. I suppose that the 
reason HS did not get matching capability is it was believed that 
PSS-only would not be a problem. I noted a few problems with PSS in HS.





The current list of FIPS 140 products that support RSA shows twice as
many products that support RSASSA-PKCS1_V1_5 than these that support
RSASSA-PSS [4]. There is greater than 50% chance to lose FIPS
certification with TLS 1.3, factoring client auth and servers.


You also need a FIPS certified implementation of HKDF. So yes, it most
likely will require new certifications.


HKDF is somewhat orthogonal to the this thread.

I was pointing out that there are devices, e.g. FIPS PCI cards or 
smartcard, that "hold" RSA keys. Some of them can only do RSA PKCS#1 1.5 
signing with these keys. These devices work with TLS 1.2 and won't work 
with TLS 1.3. These problems might be fixable if vendors are willing to 
do so, but observe that for FIPS devices this means more costly and 
slower re-certification, not just firmware update.


Regarding HKDF, note that FIPS 140-2 specifically says that it doesn't 
certify TLS, SSH, or protocols in general. It certifies crypto 
primitives. Vendors are free to chose which crypto primitives they 
certify (and this set is noted on the FIPS certificate).


KDFs in TLS are covered by 
http://csrc.nist.gov/groups/STM/cavp/documents/components/askdfvs.pdf. 
TLS 1.2 KDF is noted as "TLS KDF" on 
http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2014.htm . 
Not many modules claim certification for TLS KDF for current TLS and 
this may continue to be the case for HKDF in TLS.


In our case we do TLS KDF "ourselves" and I think other conceivable 
implementations can do this too, so this is not an issue in this thread.





The only solution that's available at this point is conditioning TLS
1.3 support on appropriate hardware. For this reason TLS 1.3 it
probably won't be enabled by default in the product I work on. I
would prefer for TLS 1.3 to be enabled by default and write the code
to decide whether it does PSS or falls back to RSA PKCS1 1.5.


Yes, it would be nice. But PKCS#1 v1.5 had it long coming. Not cutting
it off now would be negligent.


You mean for HS only, while leaving it for X.509 certs?

More importantly, note that while I understand the intent to increase 
security by mandating PSS in TLS 1.3, in practice it doesn't work.


We/our customers will have to select the highest protocol that works (or 
is reasonably fast). If the spec is written to mean (TLS1.3 && PSS), if 
we can't do PSS, we can't do TLS 1.3. There are other desirable security 
enhancements in TLS 1.3, besides PSS, that would be nice to deploy.


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

Re: [TLS] Length of a variable-length vector: Could it be an odd multiple?

[Benjamin Kaduk]

On 01/22/2016 09:42 AM, =JeffH wrote:
> [ resending from different account - my work addr ends up in spam
> bucket for many it seems ]
>
> On 1/20/16, 11:01 AM, "Benjamin Kaduk"  wrote:
> >On 01/20/2016 12:47 PM, Hodges, Jeff wrote:
> >> On 1/13/16, 12:53 PM, "Benjamin Kaduk"  wrote:
> >>> On 01/13/2016 02:44 PM, Jong-Shian Wu wrote:
>  I have a question about the even-vs-odd restrictions on the
> length of
>  a valid variable-length vector defined in TLS specification after
>  reading the section 4.3 of RFC 5246 [1] which states that:
>  "The length of an encoded vector must be an even multiple of the
> length
>  of a single element (for example, a 17-byte vector of uint16
> would be
>  illegal)."
> 
> >>> It means "whole-number" as opposed to fractional, i.e., there should
> >>>not
> >>> be unused "junk bytes" at the end.
> >> In case it's helpful, here's a suggested re-write of that quoted
> >>sentence
> >> above..
> >>
> >>   The length of an encoded variable-length vector must be an
> >>   exact multiple of the length of a single element. For example,
> >>   an encoded 17-byte vector of uint16 would be illegal, and an
> >>   encoded variable-length vector of four 32 byte elements,
> >>   having a ceiling of 2^16-1, will be 130 bytes long overall
> >>   (2 byte length field followed by 128 bytes of data).
> >
> >Wouldn't the ceiling more properly be 2^16-4 in that case?
>
> hm, I'm not sure -- what would be the rationale?  The exact multiple
> criteria?  but 2^16 / 32 = 2048  while  (2^16-4) / 32 = 2047.875

Ah, I seem to have conflated bits and bytes due to reading too quickly
and should have said (2^16-32), as Ilari alluded to with "or rounding
thereof to integral multiple of
elements".

Sorry for the confusion.

-Ben

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

Re: [TLS] Case for negotiation of PKCS#1.5 RSASSA-PKCS1-v1_5 in TLS 1.3

[Hubert Kario]

On Friday 22 January 2016 10:39:26 Andrey Jivsov wrote:
> On 01/22/2016 03:14 AM, Hubert Kario wrote:
> >> The only solution that's available at this point is conditioning
> >> TLS
> >> 1.3 support on appropriate hardware. For this reason TLS 1.3 it
> >> probably won't be enabled by default in the product I work on. I
> >> would prefer for TLS 1.3 to be enabled by default and write the
> >> code
> >> to decide whether it does PSS or falls back to RSA PKCS1 1.5.
> > 
> > Yes, it would be nice. But PKCS#1 v1.5 had it long coming. Not
> > cutting it off now would be negligent.
> 
> You mean for HS only, while leaving it for X.509 certs?

If we don't do it for HS in TLS first, we'll never get rid of it in 
X.509 certs.

We need to start somewhere, and it's more reasonable to expect that 
hardware with support for new protocols will get updated for RSA-PSS 
handling than that libraries and hardware will suddenly start 
implementing it in droves just in anticipation of the time when CAs 
_maybe_ will start issuing certificates signed with RSA-PSS.

> More importantly, note that while I understand the intent to increase
> security by mandating PSS in TLS 1.3, in practice it doesn't work.

We had to wait for XP SP2 to be over 10 years old for the CA's to even 
_consider_ using anything but SHA-1 for signatures. And most of them did 
that only on explicit request when requesting certificates.

If new signature types can't be deployed for new protocols they will 
never get deployed. There always will be implementations that do the 
absolute minimum to get interoperability *right now* and not a single 
extra step.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Length of a variable-length vector: Could it be an odd multiple?

[=JeffH]

[ fixed pitch font advised here ]

> On 01/22/2016 09:42 AM, =JeffH wrote:
> > [ resending from different account - my work addr ends up in spam
> > bucket for many it seems ]
> >
> > On 1/20/16, 11:01 AM, "Benjamin Kaduk"  wrote:
> > >On 01/20/2016 12:47 PM, Hodges, Jeff wrote:
> > >> On 1/13/16, 12:53 PM, "Benjamin Kaduk"  wrote:
> > >>> On 01/13/2016 02:44 PM, Jong-Shian Wu wrote:
> >  I have a question about the even-vs-odd restrictions on the
> > length of
> >  a valid variable-length vector defined in TLS specification after
> >  reading the section 4.3 of RFC 5246 [1] which states that:
> >  "The length of an encoded vector must be an even multiple of the
> > length
> >  of a single element (for example, a 17-byte vector of uint16
> > would be
> >  illegal)."
> > 
> > >>> It means "whole-number" as opposed to fractional, i.e., there should
> > >>>not
> > >>> be unused "junk bytes" at the end.
> > >> In case it's helpful, here's a suggested re-write of that quoted
> > >>sentence
> > >> above..
> > >>
> > >>   The length of an encoded variable-length vector must be an
> > >>   exact multiple of the length of a single element. For example,
> > >>   an encoded 17-byte vector of uint16 would be illegal, and an
> > >>   encoded variable-length vector of four 32 byte elements,
> > >>   having a ceiling of 2^16-1, will be 130 bytes long overall
> > >>   (2 byte length field followed by 128 bytes of data).
> > >
> > >Wouldn't the ceiling more properly be 2^16-4 in that case?
> >
> > hm, I'm not sure -- what would be the rationale?  The exact multiple
> > criteria?  but 2^16 / 32 = 2048  while  (2^16-4) / 32 = 2047.875
>
> Ah, I seem to have conflated bits and bytes due to reading too quickly
> and should have said (2^16-32), as Ilari alluded to with "or rounding
> thereof to integral multiple of
> elements".

hm, but in this case it seems that a variable-length vector declared with a 
length range of <0..2^16-1> would exactly accommodate up to 2048 32-byte 
elements..


  opaqueFoo[32] ;

  Foo   fooSequence<0..2^16-1>; /* will accommodate up to 2048
   Foo instances */

..because it has a zero-based index, as in this example..


  opaque Array<0..2^2-1> ;  /* should accommodate 2^2 = 4 1-byte elements */

  /*
  Array with 4
  elements in memory:   [ xx xx xx xx ]
  indices (hex):   0  1  2  3   3 = 2^2-1

  indices (binary):   00 01 10 11

  */


..yes?  or am I missing something?


thanks,

=JeffH







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

Re: [TLS] Length of a variable-length vector: Could it be an odd multiple?

[=JeffH]

On 01/22/2016 12:29 PM, =JeffH wrote:

[ fixed pitch font advised here ]


the below is corrected to use "byte count" rather than "index" or "indicies" 
(and to ditch the tabs)..



> On 01/22/2016 09:42 AM, =JeffH wrote:
> > [ resending from different account - my work addr ends up in spam
> > bucket for many it seems ]
> >
> > On 1/20/16, 11:01 AM, "Benjamin Kaduk"  wrote:
> > >On 01/20/2016 12:47 PM, Hodges, Jeff wrote:
> > >> On 1/13/16, 12:53 PM, "Benjamin Kaduk"  wrote:
> > >>> On 01/13/2016 02:44 PM, Jong-Shian Wu wrote:
> >  I have a question about the even-vs-odd restrictions on the
> > length of
> >  a valid variable-length vector defined in TLS specification after
> >  reading the section 4.3 of RFC 5246 [1] which states that:
> >  "The length of an encoded vector must be an even multiple of the
> > length
> >  of a single element (for example, a 17-byte vector of uint16
> > would be
> >  illegal)."
> > 
> > >>> It means "whole-number" as opposed to fractional, i.e., there should
> > >>>not
> > >>> be unused "junk bytes" at the end.
> > >> In case it's helpful, here's a suggested re-write of that quoted
> > >>sentence
> > >> above..
> > >>
> > >>   The length of an encoded variable-length vector must be an
> > >>   exact multiple of the length of a single element. For example,
> > >>   an encoded 17-byte vector of uint16 would be illegal, and an
> > >>   encoded variable-length vector of four 32 byte elements,
> > >>   having a ceiling of 2^16-1, will be 130 bytes long overall
> > >>   (2 byte length field followed by 128 bytes of data).
> > >
> > >Wouldn't the ceiling more properly be 2^16-4 in that case?
> >
> > hm, I'm not sure -- what would be the rationale?  The exact multiple
> > criteria?  but 2^16 / 32 = 2048  while  (2^16-4) / 32 = 2047.875
>
> Ah, I seem to have conflated bits and bytes due to reading too quickly
> and should have said (2^16-32), as Ilari alluded to with "or rounding
> thereof to integral multiple of
> elements".

hm, but in this case it seems that a variable-length vector declared with a 
length range of <0..2^16-1> would exactly accommodate up to 2048 32-byte 
elements..


  opaque Foo[32] ;

  FoofooSequence<0..2^16-1>; /* will accommodate up to 2048
Foo instances */

..because it has a zero-based byte count, as in this example..


  opaque Array<0..2^2-1> ;  /* should accommodate
   2^2 = 4  1-byte elements */

  /*
  Array with 4
  elements in memory:  [ xx xx xx xx ]
  byte count (hex):   0  1  2  33 = 2^2-1

  byte count (binary):   00 01 10 11

  */


..yes?  or am I missing something?


thanks,

=JeffH







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

Re: [TLS] Length of a variable-length vector: Could it be an odd multiple?

[Benjamin Kaduk]

On 01/22/2016 03:26 PM, =JeffH wrote:
> On 01/22/2016 12:29 PM, =JeffH wrote:
>> [ fixed pitch font advised here ]
>
> the below is corrected to use "byte count" rather than "index" or
> "indicies" (and to ditch the tabs)..
>
>
> > On 01/22/2016 09:42 AM, =JeffH wrote:
> > > [ resending from different account - my work addr ends up in spam
> > > bucket for many it seems ]
> > >
> > > On 1/20/16, 11:01 AM, "Benjamin Kaduk"  wrote:
> > > >On 01/20/2016 12:47 PM, Hodges, Jeff wrote:
> > > >> On 1/13/16, 12:53 PM, "Benjamin Kaduk"  wrote:
> > > >>> On 01/13/2016 02:44 PM, Jong-Shian Wu wrote:
> > >  I have a question about the even-vs-odd restrictions on the
> > > length of
> > >  a valid variable-length vector defined in TLS specification
> after
> > >  reading the section 4.3 of RFC 5246 [1] which states that:
> > >  "The length of an encoded vector must be an even multiple of the
> > > length
> > >  of a single element (for example, a 17-byte vector of uint16
> > > would be
> > >  illegal)."
> > > 
> > > >>> It means "whole-number" as opposed to fractional, i.e., there
> should
> > > >>>not
> > > >>> be unused "junk bytes" at the end.
> > > >> In case it's helpful, here's a suggested re-write of that quoted
> > > >>sentence
> > > >> above..
> > > >>
> > > >>   The length of an encoded variable-length vector must be an
> > > >>   exact multiple of the length of a single element. For example,
> > > >>   an encoded 17-byte vector of uint16 would be illegal, and an
> > > >>   encoded variable-length vector of four 32 byte elements,
> > > >>   having a ceiling of 2^16-1, will be 130 bytes long overall
> > > >>   (2 byte length field followed by 128 bytes of data).
> > > >
> > > >Wouldn't the ceiling more properly be 2^16-4 in that case?
> > >
> > > hm, I'm not sure -- what would be the rationale?  The exact multiple
> > > criteria?  but 2^16 / 32 = 2048  while  (2^16-4) / 32 = 2047.875
> >
> > Ah, I seem to have conflated bits and bytes due to reading too quickly
> > and should have said (2^16-32), as Ilari alluded to with "or rounding
> > thereof to integral multiple of
> > elements".
>
> hm, but in this case it seems that a variable-length vector declared
> with a length range of <0..2^16-1> would exactly accommodate up to
> 2048 32-byte elements..
>
>   opaque Foo[32] ;
>
>   FoofooSequence<0..2^16-1>; /* will accommodate up to 2048
> Foo instances */
>
> ..because it has a zero-based byte count, as in this example..
>
>
>   opaque Array<0..2^2-1> ;  /* should accommodate
>2^2 = 4  1-byte elements */
>
>   /*
>   Array with 4
>   elements in memory:  [ xx xx xx xx ]
>   byte count (hex):   0  1  2  33 = 2^2-1
>
>   byte count (binary):   00 01 10 11
>
>   */
>
>
> ..yes?  or am I missing something?

You are missing something.

The encoded length represents the actual number of bytes that will
follow, so that a zero-length array with maximum length 2^16-1 is
encoded as just 00 00.  So, even though the index into the array starts
at zero, the actual length "starts at" 1, just like in C.

-Ben

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

Re: [TLS] Simplifying signature algorithm negotiation

[David Benjamin]

I've put together a pull request with some initial text for this proposal
if folks decide to adopt it.
https://github.com/tlswg/tls13-spec/pull/404

(I'm sure there's no end of editorial problems. I think this is the first
time I've done non-trival spec work.)

David

On Fri, Jan 15, 2016 at 3:45 PM David Benjamin 
wrote:

> Hi folks,
>
> This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In TLS
> 1.2, signature algorithms are spread across the handshake. We have
> SignatureAlgorithm, NamedGroup/Curve (for ECDSA), and HashAlgorithm, all in
> independent registries. NamedGroup is sent in one list, also used for
> (EC)DH, while the other two are sent as a pair of (HashAlgorithm,
> SignatureAlgorithm) tuples but live in separate registries.
>
> This is a lot of moving parts. Signature negotiation in TLS 1.2 tends to
> be messy to implement. Client certificate keys may be in smartcards via
> OS-specific APIs, so a lot of time is spent transiting new preference
> shapes across API boundaries in order to discover smartcard bugs. Sometimes
> I think people deploy client certs because they hate me and want to cause
> me pain… :-)
>
> Anyway, the new CFRG curves also bind signature curve and hash together.
> The current draft represents this as eddsa_ed25519 and eddsa_ed448
> NamedGroups and eddsa SignatureAlgorithm. But this doesn’t capture that
> EdDSA + Ed25519 + SHA-256 is illegal. (Or ECDSA + FF3072.)
>
> I propose we fold the negotiable parameters under one name. Think of how
> we’ve all settled on AEADs being a good named primitive with a common type
> signature[1]. Specifically:
>
> 1. Drop eddsa_ed25519(31) and eddsa_ed448(32) from NamedGroup. From now
> on, NamedGroup is only used for (EC)DH.
>
> 2. Remove HashAlgorithm, SignatureAlgorithm, SignatureAndHashAlgorithm as
> they are. Introduce a new SignatureAlgorithm u16 type and negotiate that
> instead. (Or maybe a different name to not collide.) u8 is a little tight
> to allocate eddsa_ed25519 and eddsa_ed448 separately, but u16 is plenty.
>
> 3. Allocate values for SignatureAlgorithm wire-compatibly with TLS 1.2 by
> (ab)using the old (HashAlgorithm, SignatureAlgorithm) tuples. 0x0401
> becomes rsa_pkcs1_sha256, etc. Reserve ranges consistently with
> HashAlgorithm from TLS 1.2. Note this does not introduce new
> premultiplications on the wire. Just in the spec and registry.
>
> 4. Deprecate ecdsa_sha256, etc., in favor of new
> ecdsa_{p256,p384,p521}_{sha256,sha384,sha512} allocations. The old ecdsa_*
> values are for TLS 1.2 compatibility but ignored in TLS 1.3. Although this
> introduces new premultiplications, it’s only 9 values with the pruned TLS
> 1.3 lists. I think this is worth 9 values to keep NamedGroups separate.
>
> 5. Add new allocations for eddsa_ed25519, eddsa_ed448, and
> rsapss_{sha256,sha384,sha512}. These come with the signature algorithm and
> curve pre-specified. (See [2] at the bottom for full list of allocations.)
>
> Thoughts?
>
> David
>
> [1] We’re stuck with RSA-PSS's generality, so that'll need some mapping to
> a subset of X.509's RSA-PSS. We'll just not bother with RSA-PSS with
> hashAlgorithm SHA-256, maskGenAlgorithm
> MGF-7-v3.0-SHA-334-saltLengthQuotient-5/7, saltLength 87, trailerField 14.
> And RSA key generation still has size parameter. Hopefully future things
> can look more like Ed25519.
>
> [2]
> 0x-0x06ff - Reserved range for TLS 1.2 compatibility values. Note this
> is wire-compatible with TLS 1.2.
> - 0x0101 - rsa_pkcs1_md5
> - 0x0201 - rsa_pkcs1_sha1
> - 0x0301 - rsa_pkcs1_sha224
> - 0x0401 - rsa_pkcs1_sha256
> - 0x0501 - rsa_pkcs1_sha334
> - 0x0601 - rsa_pkcs1_sha512
> - 0x{01-06}02 - dsa_md5, etc. Ignored in TLS 1.3.
> - 0x{01-06}03 - ecdsa_md5, etc. Advertised for TLS 1.2 compatibility but
> ignored in TLS 1.3.
>
> 0x0700-0xfdff - Allocate new values here. Optionally avoid 0x??0[0-3] to
> avoid colliding with existing signature algorithms, but I don’t think
> that’s necessary[3].
> - rsapss_sha256
> - rsapss_sha384
> - rsapss_sha512
> - ecdsa_p256_sha256
> - ecdsa_p256_sha384
> - ecdsa_p256_sha512
> - ecdsa_p384_sha256
> - ecdsa_p384_sha384
> - ecdsa_p384_sha512
> - ecdsa_p521_sha256
> - ecdsa_p521_sha384
> - ecdsa_p521_sha512
> - eddsa_ed25519
> - eddsa_ed448
>
> 0xfe00-0x - reserved for private use, compatible with existing
> HashAlgorithm reservation.
>
> [3] If a TLS 1.2 implementation sees 0x0701 and interprets it as {hash(7),
> RSA}, they should ignore it since hash 7 doesn't exist.
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Length of a variable-length vector: Could it be an odd multiple?

[=JeffH]

ON Fri, 22 Jan 2016 15:53:27 Benjamin Kaduk noted:
> On 01/22/2016 03:26 PM, =JeffH wrote:
> > On 01/22/2016 12:29 PM, =JeffH wrote:
> >> [ fixed pitch font advised here ]
> >
> > the below is corrected to use "byte count" rather than "index" or
> > "indicies" (and to ditch the tabs)..
> >
> >
> > > On 01/22/2016 09:42 AM, =JeffH wrote:
> > > > [ resending from different account - my work addr ends up in spam
> > > > bucket for many it seems ]
> > > >
> > > > On 1/20/16, 11:01 AM, "Benjamin Kaduk"  wrote:
> > > > >On 01/20/2016 12:47 PM, Hodges, Jeff wrote:
> > > > >> On 1/13/16, 12:53 PM, "Benjamin Kaduk"  wrote:
> > > > >>> On 01/13/2016 02:44 PM, Jong-Shian Wu wrote:
 I have a question about the even-vs-odd restrictions on the
 length of a valid variable-length vector defined in TLS
 specification  after reading the section 4.3 of RFC 5246
 [1] which states that: "The length of an encoded vector
 must be an even multiple of the length of a single element
 (for example, a 17-byte vector of uint16 would be
 illegal)."

>>> It means "whole-number" as opposed to fractional, i.e., there
>>> should not be unused "junk bytes" at the end.
>>
>> In case it's helpful, here's a suggested re-write of that
>> quoted sentence above..
> > > > >>
> > > > >> The length of an encoded variable-length vector must be an
> > > > >> exact multiple of the length of a single element. For example,
> > > > >> an encoded 17-byte vector of uint16 would be illegal, and an
> > > > >> encoded variable-length vector of four 32 byte elements,
> > > > >> having a ceiling of 2^16-1, will be 130 bytes long overall
> > > > >> (2 byte length field followed by 128 bytes of data).
> > > > >
> > > > >Wouldn't the ceiling more properly be 2^16-4 in that case?
> > > >
> > > > hm, I'm not sure -- what would be the rationale? The exact multiple
> > > > criteria? but 2^16 / 32 = 2048 while (2^16-4) / 32 = 2047.875
> > >
> > > Ah, I seem to have conflated bits and bytes due to reading too quickly
> > > and should have said (2^16-32), as Ilari alluded to with "or rounding
> > > thereof to integral multiple of
> > > elements".
> >
> > hm, but in this case it seems that a variable-length vector declared
> > with a length range of <0..2^16-1> would exactly accommodate up to
> > 2048 32-byte elements..
> >
> > opaque Foo[32] ;
> >
> > Foo fooSequence<0..2^16-1>; /* will accommodate up to 2048
> > Foo instances */
> >
> > ..because it has a zero-based byte count, as in this example..
> >
> >
> > opaque Array<0..2^2-1> ; /* should accommodate
> > 2^2 = 4 1-byte elements */
> >
> > /*
> > Array with 4
> > elements in memory: [ xx xx xx xx ]
> > byte count (hex): 0 1 2 3 3 = 2^2-1
> >
> > byte count (binary): 00 01 10 11
> >
> > */
> >
> >
> > ..yes? or am I missing something?
>
> You are missing something.
>
> The encoded length represents the actual number of bytes that will
> follow, so that a zero-length array with maximum length 2^16-1 is
> encoded as just 00 00. So, even though the index into the array starts
> at zero, the actual length "starts at" 1, just like in C.

Ok, thanks, yes, I was confusing byte count with indices.

To test my understanding:

Given..

   opaque Foo[32] ;

   Foo fooSequence<0..2^16-32> ;


..fooSequence will accommodate up to 2047 Foo instances, and the length 
prefix of fooSequence will itself be two bytes long, yes?



AFAICT, though, from [1] (and prior TLS specs), it seems legit to declare 
fooSequence like so..


 Foo fooSequence<0..2^16-1> ;

..with the expectation that a correct implementation will allow only 2047 
Foo instances to be encoded into a fooSequence on the wire, yes ?



Also, if one actually needs to be able to accommodate up to _2048_ Foo 
instances, and can tolerate having the length prefix be three bytes long, 
then one could declare fooSequence as..


   Foo fooSequence<0..2^16>;

..or..

   Foo fooSequence<0..2^24-1>;

..yes?


thanks again,


=JeffH

[1] https://tools.ietf.org/html/draft-ietf-tls-tls13-11#section-4.3

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

Re: [TLS] Length of a variable-length vector: Could it be an odd multiple?

[Benjamin Kaduk]

On 01/22/2016 06:43 PM, =JeffH wrote:
> ON Fri, 22 Jan 2016 15:53:27 Benjamin Kaduk noted:
> > On 01/22/2016 03:26 PM, =JeffH wrote:
> > > On 01/22/2016 12:29 PM, =JeffH wrote:
> > >> [ fixed pitch font advised here ]
> > >
> > > the below is corrected to use "byte count" rather than "index" or
> > > "indicies" (and to ditch the tabs)..
> > >
> > >
> > > > On 01/22/2016 09:42 AM, =JeffH wrote:
> > > > > [ resending from different account - my work addr ends up in spam
> > > > > bucket for many it seems ]
> > > > >
> > > > > On 1/20/16, 11:01 AM, "Benjamin Kaduk"  wrote:
> > > > > >On 01/20/2016 12:47 PM, Hodges, Jeff wrote:
> > > > > >> On 1/13/16, 12:53 PM, "Benjamin Kaduk" 
> wrote:
> > > > > >>> On 01/13/2016 02:44 PM, Jong-Shian Wu wrote:
>  I have a question about the even-vs-odd restrictions on the
>  length of a valid variable-length vector defined in TLS
>  specification  after reading the section 4.3 of RFC 5246
>  [1] which states that: "The length of an encoded vector
>  must be an even multiple of the length of a single element
>  (for example, a 17-byte vector of uint16 would be
>  illegal)."
> 
> >>> It means "whole-number" as opposed to fractional, i.e., there
> >>> should not be unused "junk bytes" at the end.
> >>
> >> In case it's helpful, here's a suggested re-write of that
> >> quoted sentence above..
> > > > > >>
> > > > > >> The length of an encoded variable-length vector must be an
> > > > > >> exact multiple of the length of a single element. For example,
> > > > > >> an encoded 17-byte vector of uint16 would be illegal, and an
> > > > > >> encoded variable-length vector of four 32 byte elements,
> > > > > >> having a ceiling of 2^16-1, will be 130 bytes long overall
> > > > > >> (2 byte length field followed by 128 bytes of data).
> > > > > >
> > > > > >Wouldn't the ceiling more properly be 2^16-4 in that case?
> > > > >
> > > > > hm, I'm not sure -- what would be the rationale? The exact
> multiple
> > > > > criteria? but 2^16 / 32 = 2048 while (2^16-4) / 32 = 2047.875
> > > >
> > > > Ah, I seem to have conflated bits and bytes due to reading too
> quickly
> > > > and should have said (2^16-32), as Ilari alluded to with "or
> rounding
> > > > thereof to integral multiple of
> > > > elements".
> > >
> > > hm, but in this case it seems that a variable-length vector declared
> > > with a length range of <0..2^16-1> would exactly accommodate up to
> > > 2048 32-byte elements..
> > >
> > > opaque Foo[32] ;
> > >
> > > Foo fooSequence<0..2^16-1>; /* will accommodate up to 2048
> > > Foo instances */
> > >
> > > ..because it has a zero-based byte count, as in this example..
> > >
> > >
> > > opaque Array<0..2^2-1> ; /* should accommodate
> > > 2^2 = 4 1-byte elements */
> > >
> > > /*
> > > Array with 4
> > > elements in memory: [ xx xx xx xx ]
> > > byte count (hex): 0 1 2 3 3 = 2^2-1
> > >
> > > byte count (binary): 00 01 10 11
> > >
> > > */
> > >
> > >
> > > ..yes? or am I missing something?
> >
> > You are missing something.
> >
> > The encoded length represents the actual number of bytes that will
> > follow, so that a zero-length array with maximum length 2^16-1 is
> > encoded as just 00 00. So, even though the index into the array starts
> > at zero, the actual length "starts at" 1, just like in C.
>
> Ok, thanks, yes, I was confusing byte count with indices.
>
> To test my understanding:
>
> Given..
>
>opaque Foo[32] ;
>
>Foo fooSequence<0..2^16-32> ;
>
>
> ..fooSequence will accommodate up to 2047 Foo instances, and the
> length prefix of fooSequence will itself be two bytes long, yes?
>

Yes.

>
> AFAICT, though, from [1] (and prior TLS specs), it seems legit to
> declare fooSequence like so..
>
>  Foo fooSequence<0..2^16-1> ;
>
> ..with the expectation that a correct implementation will allow only
> 2047 Foo instances to be encoded into a fooSequence on the wire, yes ?
>

I believe a correct implementation would do so, yes, though I am not
quite enough of a spec lawyer to be able to state that authoritatively. 
The <0..2^16-32> form is perhaps friendlier to the reader.

>
> Also, if one actually needs to be able to accommodate up to _2048_ Foo
> instances, and can tolerate having the length prefix be three bytes
> long, then one could declare fooSequence as..
>
>Foo fooSequence<0..2^16>;
>
> ..or..
>
>Foo fooSequence<0..2^24-1>;
>
> ..yes?

Yes.  (The latter form might permit an attacker to force a peer to
consume a lot of memory processing a request, of course.)

-Ben

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