Re: [TLS] chacha/poly for http/2

[Hubert Kario]

On Wednesday 13 January 2016 17:48:37 Salz, Rich wrote:
> We (OpenSSL) have already tested interop of chacha/poly with other
> browsers and TLS stacks, and now it all works.  (The official IETF
> version, not the QUIC version).

I was able to confirm interoperability between tlslite-ng[1] and current 
OpenSSL master (0e76014e584ba7), using draft-ietf-tls-chacha20-
poly1305-04 implementation.

 1 - https://github.com/tomato42/tlslite-ng/tree/chacha-ecdhe
-- 
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] Simplifying signature algorithm negotiation

[David Benjamin]

On Mon, Jan 18, 2016 at 6:48 AM Hubert Kario  wrote:

> On Friday 15 January 2016 20:45:34 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
>
> Then what ECDHE share gets signed?
> if the same as the curve, what about FFDHE, what about ECDHE-RSA? why no
>  - rsapss_dh2048_sha256
>  - rsapss_dh3072_sha256
>  - rsapss_dh4096_sha384
>  - (etc.)
>  - rsapss_p256_sha256
>  - rsapss_p384_sha384
>  - (etc.)
>
> If it does not specify the DH share signed, it doesn't really change
> anything...
>

Why would it need to specify what [DH group's] DH share gets signed?
NamedGroup still exists for the key exchange (see step 1). I'm only
proposing pulling signature curves out of NamedGroup.

(Is the DH share even signed directly? It looks like TLS 1.3 signs via
CertificateVerify's handshake context in both directions. Either way, it's
just a byte-string message. We could also backport this sort

Re: [TLS] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448

[Joseph Salowey]

Any objections to early allocation for X25519 and X448?  Are there
implementers with code ready to test interop?

Thanks,

Joe

On Thu, Jan 14, 2016 at 3:22 PM, Brian Smith  wrote:

> Simon Josefsson  wrote:
>
>> Allocating a code point for X25519 could be done and is long overdue
>> (first draft September 2013).  X448 is also stable.  Code points for
>> Ed25519 and Ed448 is more problematic since TLS authentication has
>> historically had interaction with PKIX certs.  I agree with Yoav's
>> assertion that the curve point verification issue is not big enough to
>> stall code point allocation.
>
>
> I agree with this.
>
> Cheers,
> Brian
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448

[David Benjamin]

BoringSSL has a pair of implementations ready (in C and in our fork of Go's
TLS stack for testing). We're using the value in the TLS 1.3 draft, so 29.
It's not currently enabled in any Chrome builds, but I'm expecting to
change this soon.

David

On Tue, Jan 19, 2016 at 12:54 PM Joseph Salowey  wrote:

> Any objections to early allocation for X25519 and X448?  Are there
> implementers with code ready to test interop?
>
> Thanks,
>
> Joe
>
> On Thu, Jan 14, 2016 at 3:22 PM, Brian Smith  wrote:
>
>> Simon Josefsson  wrote:
>>
>>> Allocating a code point for X25519 could be done and is long overdue
>>> (first draft September 2013).  X448 is also stable.  Code points for
>>> Ed25519 and Ed448 is more problematic since TLS authentication has
>>> historically had interaction with PKIX certs.  I agree with Yoav's
>>> assertion that the curve point verification issue is not big enough to
>>> stall code point allocation.
>>
>>
>> I agree with this.
>>
>> Cheers,
>> Brian
>>
>
> ___
> 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] Simplifying signature algorithm negotiation

[Hubert Kario]

On Tuesday 19 January 2016 16:50:18 David Benjamin wrote:
> On Mon, Jan 18, 2016 at 6:48 AM Hubert Kario  
wrote:
> > On Friday 15 January 2016 20:45:34 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
> > 
> > Then what ECDHE share gets signed?
> > if the same as the curve, what about FFDHE, what about ECDHE-RSA?
> > why no> 
> >  - rsapss_dh2048_sha256
> >  - rsapss_dh3072_sha256
> >  - rsapss_dh4096_sha384
> >  - (etc.)
> >  - rsapss_p256_sha256
> >  - rsapss_p384_sha384
> >  - (etc.)
> > 
> > If it does not specify the DH share signed, it doesn't really change
> > anything...
> 
> 

Re: [TLS] Simplifying signature algorithm negotiation

[David Benjamin]

On Tue, Jan 19, 2016 at 1:25 PM Hubert Kario  wrote:

> > > If it does not specify the DH share signed, it doesn't really change
>
> > anything...
> >
> > Why would it need to specify what [DH group's] DH share gets signed?
> > NamedGroup still exists for the key exchange (see step 1). I'm only
> > proposing pulling signature curves out of NamedGroup.
> >
> > (Is the DH share even signed directly? It looks like TLS 1.3 signs via
> > CertificateVerify's handshake context in both directions. Either way,
> > it's just a byte-string message. We could also backport this sort of
> > thing to TLS 1.2 and the signature algorithm still doesn't care about
> > the DH share. That gets encoded into a byte string somehow.)
> >
> > I'm trying to make the decompositions and premultiplications align
> > with how the protocol is structured. TLS 1.2 decomposed algorithm,
> > signing curve, and hash which isn't universal (Ed25519, Ed448, even
> > RSA-PSS's params in full generality aren't the same shape, the
> > definition of "digitally-signed" takes only a byte-string message as
> > input), so they should be premultiplied. Whereas signature algorithm
> > and DH group are cleanly separated in the protocol and needn't be
> > premultiplied.
>
> Problem I am pointing out is that NamedGroup specifies not only what
> curves can be used for signing but also what curves can get signed.
>
> Or are you saying that the NamedGroup would stay, and would now specify
> only the supported parameters for the key exchange, not how they are
> authenticated (as it is now)?
>

Yes.

> On Friday 15 January 2016 20:45:34 David Benjamin wrote:
> 1. Drop eddsa_ed25519(31) and eddsa_ed448(32) from NamedGroup. From now
on, NamedGroup is only used for (EC)DH.

> On Tuesday 19 January 2016 16:50:18 David Benjamin wrote:
> Why would it need to specify what [DH group's] DH share gets signed?
> NamedGroup still exists for the key exchange (see step 1). I'm only
> proposing pulling signature curves out of NamedGroup.


Or to put it other way: what extensions and with what values should I
> sent if I support only TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 with either
> P-256 or P-384 curve, signed with SHA-256, SHA-384 or SHA-512 using RSA?


supported_groups {p256, p384}
supported_signature_algorithms {rsa_pkcs1_sha256, rsa_pkcs1_sha384,
rsa_pkcs1_sha512}
(Or s/rsa_pkcs1_/rsa_pss_/g if you meant that one.)

For your example, nothing on the wire changes at all. Before, you'd end up
sending:
supported_groups {p256, p384}
supported_signature_algorithms {{sha256, rsa}, {sha384, rsa}, {sha512, rsa}}
And rsa_pkcs1_sha256 should be allocated to align with {sha256, rsa}, etc.

The interesting case is Ed25519 and Ed448. You'd currently have to send:
supported_groups {..., eddsa_ed25519, eddsa_ed448}
supported_signature_algorithms {..., {sha512, eddsa}, {shake256[1], eddsa}}

However, this does not capture that {shake256, eddsa} + eddsa_ed25519 isn't
legal. Instead I want:
supported_groups {..., irrelevant to ed25519 and friends}
supported_signature_algorithms {..., eddsa_ed25519, eddsa_ed448}

David

[1] I have not been following the CFRG curve work very closely. Adam tells
me Ed448 is likely to be bound to SHAKE-256. For the sake of discussion,
let's assume that's how it ends up.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448

[Andrei Popov]

Yes, please allocate, esp. 25519. MS will start testing interop soon.

Cheers,

Andrei

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of David Benjamin
Sent: Tuesday, January 19, 2016 10:01 AM
To: Joseph Salowey ; Brian Smith 
Cc: Adam Langley ; Simon Josefsson 
; tls@ietf.org
Subject: Re: [TLS] Correction: early codepoint assignment for Curve25519, 
Curve448, Ed25519 and Ed448

BoringSSL has a pair of implementations ready (in C and in our fork of Go's TLS 
stack for testing). We're using the value in the TLS 1.3 draft, so 29. It's not 
currently enabled in any Chrome builds, but I'm expecting to change this soon.

David

On Tue, Jan 19, 2016 at 12:54 PM Joseph Salowey 
mailto:j...@salowey.net>> wrote:
Any objections to early allocation for X25519 and X448?  Are there implementers 
with code ready to test interop?

Thanks,

Joe

On Thu, Jan 14, 2016 at 3:22 PM, Brian Smith 
mailto:br...@briansmith.org>> wrote:
Simon Josefsson mailto:si...@josefsson.org>> wrote:
Allocating a code point for X25519 could be done and is long overdue
(first draft September 2013).  X448 is also stable.  Code points for
Ed25519 and Ed448 is more problematic since TLS authentication has
historically had interaction with PKIX certs.  I agree with Yoav's
assertion that the curve point verification issue is not big enough to
stall code point allocation.

I agree with this.

Cheers,
Brian

___
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] Simplifying signature algorithm negotiation

[Ilari Liusvaara]

On Tue, Jan 19, 2016 at 06:55:49PM +, David Benjamin wrote:
> On Tue, Jan 19, 2016 at 1:25 PM Hubert Kario  wrote:
> 
> >
> > Problem I am pointing out is that NamedGroup specifies not only what
> > curves can be used for signing but also what curves can get signed.
> >
> > Or are you saying that the NamedGroup would stay, and would now specify
> > only the supported parameters for the key exchange, not how they are
> > authenticated (as it is now)?
> >
> 
> Yes.

Also, IIRC some have expressed that sometimes softare can sanely do
ECDHE over some curve but not signature verification. Or it can sanely
do signature verification but not ECDSA.
 
> > On Friday 15 January 2016 20:45:34 David Benjamin wrote:
> > 1. Drop eddsa_ed25519(31) and eddsa_ed448(32) from NamedGroup. From now
> on, NamedGroup is only used for (EC)DH.
> 
> > On Tuesday 19 January 2016 16:50:18 David Benjamin wrote:
> > Why would it need to specify what [DH group's] DH share gets signed?
> > NamedGroup still exists for the key exchange (see step 1). I'm only
> > proposing pulling signature curves out of NamedGroup.
> 
> 
> Or to put it other way: what extensions and with what values should I
> > sent if I support only TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 with either
> > P-256 or P-384 curve, signed with SHA-256, SHA-384 or SHA-512 using RSA?
> 
> 
> supported_groups {p256, p384}
> supported_signature_algorithms {rsa_pkcs1_sha256, rsa_pkcs1_sha384,
> rsa_pkcs1_sha512}
> (Or s/rsa_pkcs1_/rsa_pss_/g if you meant that one.)

Of course, one wants at least semi-sane behaviour when downnegotiating...

> [1] I have not been following the CFRG curve work very closely. Adam tells
> me Ed448 is likely to be bound to SHAKE-256. For the sake of discussion,
> let's assume that's how it ends up.

Actually, it isn't raw SHAKE256 but some weird prefixed variant...
Fortunately only matters for TLS 1.2 client signatures, due to every-
thing else being highly temporally localized.

I do have should-be-final reference implementation and test vectors
(and another implementation that is just slow and has the test
vectors pass). Currently waiting on co-editor.


-Ilari

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

Re: [TLS] Early code point assignment for ChaCha20-poly1305 cipher suites

[Joseph Salowey]

We're asking the IESG for early allocation of these code points.  ​
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Technical Errata Reported] RFC5054 (4546)

[Rick van Rein]

Hello,

Could I bring this erratum reported in November to your attention once
more?  I think it calls for correction.

Thanks,
 -Rick
> RFC Errata System 
> 30 November 2015 at 17:02
> The following errata report has been submitted for RFC5054,
> "Using the Secure Remote Password (SRP) Protocol for TLS Authentication".
>
> --
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=5054&eid=4546
>
> --
> Type: Technical
> Reported by: Rick van Rein 
>
> Section: 2.6
>
> Original Text
> -
> B = k*v + g^b % N
>
> Corrected Text
> --
> B = ( k*v + g^b ) % N
>
> Notes
> -
> The customary binding is that + has lower priority than % and so the
> default reading of the expression would be
> B = k*v + ( g^b % N )
> That is inconsistent with the existence of PAD(B) and the size of B in
> the test vectors, so the context hints at proper brackets, but this
> may still lead to implementation errors (of which I actually ran into
> an example).
>
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --
> RFC5054 (draft-ietf-tls-srp-14)
> --
> Title : Using the Secure Remote Password (SRP) Protocol for TLS
> Authentication
> Publication Date : November 2007
> Author(s) : D. Taylor, T. Wu, N. Mavrogiannopoulos, T. Perrin
> Category : INFORMATIONAL
> Source : Transport Layer Security
> Area : Security
> Stream : IETF
> Verifying Party : IESG
>

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

Re: [TLS] [Technical Errata Reported] RFC5054 (4546)

[Nikos Mavrogiannopoulos]

Hi,
 I find the reported errata reasonable.

On Sun, Jan 17, 2016 at 7:53 PM, Rick van Rein  wrote:
> Hello,
>
> Could I bring this erratum reported in November to your attention once
> more?  I think it calls for correction.
>
> Thanks,
>  -Rick
>> RFC Errata System 
>> 30 November 2015 at 17:02
>> The following errata report has been submitted for RFC5054,
>> "Using the Secure Remote Password (SRP) Protocol for TLS Authentication".
>>
>> --
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=5054&eid=4546
>>
>> --
>> Type: Technical
>> Reported by: Rick van Rein 
>>
>> Section: 2.6
>>
>> Original Text
>> -
>> B = k*v + g^b % N
>>
>> Corrected Text
>> --
>> B = ( k*v + g^b ) % N
>>
>> Notes
>> -
>> The customary binding is that + has lower priority than % and so the
>> default reading of the expression would be
>> B = k*v + ( g^b % N )
>> That is inconsistent with the existence of PAD(B) and the size of B in
>> the test vectors, so the context hints at proper brackets, but this
>> may still lead to implementation errors (of which I actually ran into
>> an example).
>>
>> Instructions:
>> -
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party (IESG)
>> can log in to change the status and edit the report, if necessary.
>>
>> --
>> RFC5054 (draft-ietf-tls-srp-14)
>> --
>> Title : Using the Secure Remote Password (SRP) Protocol for TLS
>> Authentication
>> Publication Date : November 2007
>> Author(s) : D. Taylor, T. Wu, N. Mavrogiannopoulos, T. Perrin
>> Category : INFORMATIONAL
>> Source : Transport Layer Security
>> Area : Security
>> Stream : IETF
>> Verifying Party : IESG
>>

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

Re: [TLS] Simplifying signature algorithm negotiation

[David Benjamin]

On Fri, Jan 15, 2016 at 10:13 PM Brian Smith  wrote:

> David Benjamin  wrote:
>
>> (Whether such certificates exist on the web is probably answerable via CT
>> logs, but I haven't checked.)
>>
>
> Me neither, and I think that's the key thing that would need to be checked
> to see if my suggestion is viable.
>

Looks like DigiCert's EC intermediates are P-384 and they sign SHA-256 more
often than not.
https://crt.sh/?CN=%25&iCAID=1516

But it's not actually all that many hostnames (all of which presumably
don't speak TLS 1.3 yet), the existing semantics of TLS 1.2 won't change,
and whether sigalgs are stronger than a hint w.r.t. X.509 is...
controversial. I wasn't able to find anyone else doing it. So +1 from me on
dropping the 3x3 product to just the three you listed.

I'm less confident about the consequences of reusing the TLS 1.2 ecdsa_*
allocations, but I can't think of any weird behaviors, so it seems
reasonable.

(The one thing I can think of is requires we keep ecdsa_p384_sha256. Then a
client wishing to advertise ecdsa_p384_sha256 and not ecdsa_p256_sha256 and
yet still speaking TLS 1.2 would have problems. But if we're actually
limiting to those three, that can't happen anyway, and this hypothetical
client seems pretty weird.)

If other people still want to allow ecdsa_p384_sha256 and friends, I'm also
happy with allocating 6 values and throwing out
ecdsa_p256_sha384, ecdsa_p256_sha512, and ecdsa_p384_sha512.

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

Re: [TLS] Simplifying signature algorithm negotiation

[David Benjamin]

Sorry, sent from the wrong address.

On Tue, Jan 19, 2016 at 5:19 PM David Benjamin  wrote:

> On Sat, Jan 16, 2016 at 5:00 AM Hanno Böck  wrote:
>
>> Hi,
>>
>> I generally like the idea of simplifying the different algorithm
>> negotiation things, but:
>>
>> On Fri, 15 Jan 2016 20:45:34 +
>> David Benjamin  wrote:
>>
>> > [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.
>>
>> I think a couple of them (esp. everything with dsa and _md5) should get
>> a diediedie rfc and never be seen again.
>>
>
> Sounds good. I included all the TLS 1.2 values thinking we'd want to
> retroactively express TLS 1.2 (DSA, MD5, and SHA-1 warts and all) this way
> too. But leaving it alone is probably simpler. Reserving the range should
> be sufficient to keep collisions out.
>
> If TLS 1.3 takes this proposal, I expect that I will make BoringSSL
> implement TLS 1.2 this way (with whatever quirks are needed around ECDSA)
> for convenience, but there's no reason this needs to be reflected in the
> spec.
>
>
>> > - 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
>>
>> Do we really need that many?
>> I think the "complexity zoo" of TLS is one of its current downsides and
>> I really think we should go with fewer options in the future. Can we
>> strip that down to - below 5 or something? (personal opinion: Strip
>> down to 2, but this may be too radical for now.)
>>
>
> Brian Smith proposed elsewhere in the thread to cutting the ECDSA ones
> down to just
> - ecdsa_p256_sha256
> - ecdsa_p384_sha384
> - ecdsa_p521_sha512
> and folding them into the TLS 1.2 compatibility ECDSA values, which I
> think I am in favor of. I'm personally okay losing P-521 too since
> BoringSSL doesn't advertise it, but I imagine others might object, so
> *shrug*.
>
> That brings us down to 8. No strong opinions from me on whether we need
> all three rsapss_* values. I just took what was in the 1.3 draft.
>
>
> David
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls